FCIP: Authors 9/19 Meeting Minutes

["Murali Rajagopal" <muralir@lightsand.com>]

Meeting Minutes submitted by Robert Snively, Brocade

The meeting considered the following subjects.

1)  Security

   Page 8, item 12

	This led to the following proposed change in 8.3.1:
	The second paragraph must be clarified to indicate that
	Null Encryption is not required if data integrity is
	not specified.  No confidentiality + Yes Data Integrity =
	ESP with null encryption.

   Concern by Larry Lamers about definition of counter mode.

	At present, the document references an IETF document
	which has not yet been provided.  The document is
	a reference document, but not yet an IETF draft.
	Ralph will make the corresponding change.

   FCIP requirements for AES.

	At present, the next to the last paragraph of 8.3.1 is
	suspect.  The 1 and 10 Gig implementations will require
	AES with counter mode, but the previous sentence provides
	all the "musts" and "shoulds" independently.

	Larry suggests more detailed tutorials or else removing
	the paragraph.  

	Ralph will remove the offending paragraph.

   8.1, item 3

	The grammar of the sentence was corrected.

   8.1, item 4

	"Validly and invalid formed" s/b " Valid and invalid".

   8.2, item 1

	"policy" s/b "policies".

   8.3.2, third paragraph

	"PFS" s/b "PFS (Perfect Forward Secrecy)".  The
	reference is IKE, RFC 2409.

   8.3.2, eighth paragraph

	"the FCIP" s/b "FCIP".

   8.4.3, first sentence

	The comment was withdrawn.

   8.4.1, page 28, second line

	"performed" s/b "completed".

   Aggressive vs. Main Mode:

	Aggressive mode is needed if you use 
	group pre-shared keys because there are holes in
	main mode.  We recommend against group pre-shared
	keys.  Because many gateways do not support
	aggressive mode, main mode is mandatory and
	aggressive mode is optional to implement.  This
	is part of the negotiation during IKE phase 1.

   Tunnel vs. Transport:

	Venkat has requested information from William Dixon.

   Static IP Addresses:

	Venkat has requested information from William Dixon.

2)  Publication

	The document is ready for NAPT.  NAPT should probably
	go out separately first.

	Elizabeth suggests sending out the draft with
	security and without NAPT to IETF.  At present, there
	are no "open" issues.

3)  NAPT

	 The preliminary proposals for handling NAPT
	environments were discussed.

	After the authors' discussion next week refines those
	preliminary proposals, a NAPT proposal will be
	published for broader review."

4)  Next meeting

	The next meeting will be arranged by Cisco.   Murali
	will contact David Peterson to be sure that he is available. 

ATTENDEES:

Murali Rajagopal		LightSand Communications	
Raj Bhagwat			LightSand Communications
Andy Helland		              LightSand Communications
Anil Rijhsinghani		McData
Larry Lamers			SAN Valley
Jim Nelson			Vixel Corporation
Don Fraser			Compaq Computer Corp.
Milan Merhar			Pirus Networks
Venkat Rangan			Rhapsody Networks
Bob Snively			Brocade Communications	
Ralph Weber			ENDL Texas, for Brocade
Vi Chau				Gadzoox Networks
Elizabeth Rodriguez   		Lucent Technology