FINAL Minneapolis Minutes

[Black_David@emc.com]

Since there were no changes or corrections reported,
the DRAFT Minneapolis minutes posted to the list last
week have become the final minutes, and the rough
consensus agreements reached in the meeting are
now confirmed as the rough consensus of the WG.
A copy of those minutes (which have been submitted
for the official proceedings) is appended below.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> IPS WG Meeting Minutes - FINAL
> IETF #50
> Minneapolis MN
> 
> 
> Interim Meeting - There will be an interim meeting for the IPS working
> group. 
> It will be co-located with T10 in Nashua, NH on April 30 & May 1.  
> FC related topics will be covered on Monday, April 30.  
> SCSI related documents will be covered on Tuesday, May 1.
> In addition to the IPS meetings, on Wednesday, May 2, during the
> T10 CAP meeting, a discussion of a SCSI MIB will be held. 
> Details of this meeting, including location and hotel room information,
> have been sent to the IPS mailing list.
> 
> TCP framing discussion will be in TSVWG WG meeting the evening of Monday,
> March 19.
> IPS working group attendees are encouraged to attend, be familiar with the
> draft,
> and ask questions. The draft was cross-posted to both IPS and TSVWG
> mailing
> lists.
> To subscribe to the TSVWG mailing list or to view the archive, see
> www.ietf.org/mailman/listinfo/tsvwg
> 
> RDMA - RDMA is a separate effort from the framing discussion.
> A separate mailing list has been formed to address RDMA
> To join, send an email to rdma-subscribe@yahoogroups.com .
> ***NOTE***: This address has been corrected from the one discussed in the
> meeting.
> 
> T10 is considering a new SCSI model.  T10 participants agreed that it may
> have
> advantages but will be very different from current SCSI model.  Therefore
> it
> is currently deferred to SAM-3.
> This model may be of interested to iSCSI, as it will have advantages for
> iSCSI.
> 
> -- iSCSI Requirements --
> 
> iSCSI requirements - document is almost complete.
> draft-ietf-ips-iscsi-rqmts-01.txt.
> 1 more draft will be sent out, and then a last call will occur in
> approximately 1 month
> with the hope of submitted the result as an informational RFC around the
> time of the
> interim meeting (end of April).  Everyone should review the draft on the
> list and
> especially check that the MUSTs and SHOULDs are correct and nothing is
> missing.
> 
> -- iSCSI specification - draft-ietf-ips-iscsi-05.txt --
> 
> - CRCs for iSCSI.  Two presentations made with respect to CRC vs checksum
> usage in iSCSI.
> Recommendation was to use a 32 bit CRC; three mentioned as candidates -
> CRC-32C; CRC-32Q and CCITT-CRC32.  Reported that there really is no need
> for
> a 64 bit CRC.
> Consensus call on use of CRC instead of checksum. Loud CRC hum; no hum for
> checksum,
> 	so use of CRC rather than checksums is the rough consensus of this
> meeting.
> Consensus call will be taken on which CRC to use at interim meeting, so
> that
> WG has
> more time to investigate and understand the options presented.
> 
> Request made for a single mandatory to implement CRC algorithm as opposed
> to making the CRC algorithm selection negotiable.
> 
> - iSCSI Digests.  Current draft has multiple digests.  
> 3 proposals presented for digest and related header formats.
> Request made for use of TLV format in whatever solution is finalized on.  
> Consensus call made to have 1 header digest instead of multiple.  
> Barry Reinhold and Julian Satran were asked to work and come back with a
> single
> proposed format at the Wed  meeting.  The rough consensus of the meeting
> was
> that
> the data length should always be in the same place in the header.
> 
> Consensus call - descriptors and diagrams should always be kept together
> in
> the document.
> 	This is the rough consensus of the meeting.
> 
> Error Recovery will be addressed at the interim meeting
> 
> 
> - Security
> Public Key and TLS were removed in version 05 of the iSCSI draft.
> Public Key will be reinstated in the 06 draft.
> MUST provide authentication and data integrity.
> MAY provide data privacy (encryption).
> 
> Need to have at least 1 mandatory to implement security protocol.
> IPSec seems to be the selection in current draft.
> Consensus call - Make IPSec mandatory to implement?  Arguments against, no
> consensus.
> Consensus call - mandatory to implement SRP?  Hum against.  Will be taken
> to
> interim meeting.
> Both Public Key and Radius authentication mechanisms will be added to the
> next version
> of the draft.
> 
> - SCSI ACA discussion
> 
> ACA (Auto Contingent Allegiance) is an optional SCSI mechanism that stops
> execution
> of a sequence of dependent SCSI commands when one of them fails.  The
> situation
> surrounding it is complex - T10 specifies ACA in SAM2, and hence iSCSI has
> to
> specify it and endeavor to make sure that ACA gets implemented
> sufficiently 
> (two independent interoperable implementations) to avoid dropping ACA in
> the
> transition from Proposed Standard to Draft Standard.  On the list David
> Black
> noted that this would make ACA implementation at least a "SHOULD" rather
> than a "MAY".
> 
> The current iSCSI draft has language requiring use of ACA rather than
> implementation;
> that's overspecified (it's ok for cooperating iSCSI nodes to decide not to
> use ACA),
> and will be changed.
> 
> In practice, ACA is not a complete solution (e.g., if a Fibre Channel
> switch
> drops
> a frame due to a CRC error, ACA will not kick in).  T10 has been working
> on
> other
> mechanisms that address problems that ACA addresses in a more
> comprehensive
> fashion,
> but has not moved to drop ACA from SAM2, hence iSCSI has to deal with it.
> 
> 
> -- iSCSI Boot presentation - draft-ietf-ips-iscsi-boot-02.txt
> 
> This draft is relatively stable - the bulk of this draft will become an
> informational RFC rather than standards track.  David Black will figure
> out whether some piece of it needs to be standards track.
> 
> -- iSCSI MIB work presented. - draft-bakke-iscsimib-02.txt
> 
> Difficulty in making this an iSCSI MIB only,
> in that there is no SCSI MIB currently, but people want to see both iSCSI
> and SCSI information addressed.
> SCSI MIB will be a topic on the agenda at the next T10 CAP meeting, May 2.
> 
> iSCSI MIB accepted as a WG item; next submission will be official WG item.
> 
> -- iSCSI naming and Discovery presented  -
> draft-ietf-ips-iscsi-name-disc-00.txt
> 
> Two discovery methods presented - iSNS and SLP based.
> 
> iSNS is an new name server, specific to IPS.  Question raised as to why
> not
> use SLP.  
> Separate SLP presentation presented following; both iSNS and SLP can be
> used.  
> SLP works for basic discovery whereas iSNS provides additional
> information/capabilities, 
> including management functionality.
> 
> -- URN Namespace document presented - draft-bakke-iscsi-wwui-urn-00.txt
> 
> While the meeting consensus was to accept this as an official WG work
> item,
> this was overridden by direction from the IESG subsequent to the meeting.
> 
> -- SLP document presented - draft-bakke-iscsi-slp-00.txt 
> 
> Meeting consensus was to accept this as an official WG item.
> 
> -- Back to iSCSI headers (first thing Wednesday)
> 
> Follow up from Monday:  Two header formats presented to WG for
> consideration.   One has data length in fixed location, but limits size
> of data.  Second more flexible, but data length field not in fixed
> location.
> More details on each format to be written up and posted to list; 
> decision on which header format to follow to be decided on list; 
> Julian requests decision within 10 days.  The list subsequently
> chose the "Format 2" prepared/proposed by Barry Reinhold.
> 
> -- iSNS draft presented - draft-ietf-ips-isns-01.txt
> 
> Primarily a status report and description of how iSNS applies to all three
> protocols in the WG (iFCP, iSCSI, FCIP).  It's required by iFCP, but
> optional
> for the others.
> 
> Rationale for why SLP isn't enough and iSNS is needed will be sent to
> list.
> 
> A concern was raised about relying on iSNS for certificate distribution
> vs.
> certificate exchange between the two ends of an IP Storage connection.
> Not
> resolved in the meeting and will need further consideration as part of
> protocol
> security work.
> 
> -- Fibre Channel related topics: --
> 
> Fibre Channel Common Encapsulation team being formed.  
> Small team, with a target size of 6 people.  
> Interested people to see David or Elizabeth (co-chairs) by Friday, March
> 23.
> 
> Three encapsulation presentations made: 
>   Two had encapsulation format recommendations -
> draft-weber-fcip-encaps-00.txt and
> 	a presentation from Vi Chau (FCIP draft co-author)
>   Third consisted of requirements needed for iFCP -
> draft-monia-ips-ifcpenc-00.txt
> 
> Discussions of expectations from common encapsulation format - 
> should provide some means of data integrity & synchronization by 
> guarding against accidental interpretation of encapsulated data as an FC
> frame if framing synchronization to the data stream is lost and being
> recovered;
> this is not a requirement to provide a means of preventing intentional
> hijacking;
> simply a means of validation that what is seen is actually current and
> valid.
> The WG co-chair made it clear that the encapsulation design team must take
> this
> issue seriously.
> 
> FC Frames have CRC around them, so no CRC needed there, 
> but what needs to be wrapped around the common encapsulation piece (header
> and/or
> header + SOF/EOF codes) to insure that data is correct?  
> Statement of direction from WG, based on show of hands, is that CRC should
> be used.
> This is the rough consensus of the meeting.
> 
> One requirement of the draft was initially to make the common header
> extensible - 
> not needed by FCIP or iFCP.  Consensus call - remove this requirement.
> This
> is the
> rough consensus of this meeting.
> 
> -- FCIP draft update discussed - draft-ietf-ips-fcovertcpip-01.txt
> 
> No draft submitted since Dec IETF meeting.  
> Changes made and discussed by authors, but major pending changes did
> not make updated the draft for this meeting reasonable.
> Next draft will include changes recommended at both IETF-49 and the
> interim
> meeting, 
> as well as a better description of the FCIP port models, encapsulation,
> etc.
> 
> Next draft due April, prior to next interim meeting.
> 
> -- FCIP Model presentation - Mike O'Donnell
> 
> FCIP port model usage.  In current FCIP draft, unclear as to whether this
> is
> following
> a B-Port,  E-Port or some other kind of port model.  Presentation makes
> clear that
> both E-Ports and B-Ports  can be used by the FCIP device.  In the absence
> of
> FCIP,
> an inter-switch link in Fibre Channel connects two E-ports.  If FCIP is
> implemented
> in the Fibre Channel switch, the result is a logical E-port communicating
> over FCIP.
> If FCIP is implemented in an external bridge, a real E-port on the switch
> communicates
> with a B-port on the bridge and the result is still a logical E-port on
> the
> FCIP
> side of the switch.  These implementation structures will interoperate
> (i.e.,
> a logical E-port in a switch can communicate via FCIP with a logical
> E-port
> implemented in a bridge that uses a B-port to talk to an E-port on a
> switch
> - the
> FCIP protocol is the same).
> 
> FC-BB2 meeting announced - during T11 week in Toronto, Canada on April 9.
> Meeting is open to all.  FC-BB2 handles the aspects of FCIP usage that
> require
> Fibre Channel standards.
> 
> 
> -- iFCP status - draft-ietf-ips-ifcp-00.txt
> 
> 3 additional versions of the draft anticipated between now and August
> 2001.
> 
> Target is that this August draft will be complete, w/o any TBDs.
> 
> Noting that the draft contained a MIB lead to a more general discussion of
> MIBs.
> In general, MIBs should be advanced as separate documents, and authors
> need
> to
> look at the FC MIBs developed in the ipfc WG to avoid duplication.
> The iSCSI MIB may provide a model for some of the iFCP MIB.
> 
> Final note - somehow, we managed to get 3 anagrammed acronyms.  FCIP and
> iFCP are
> protocols in this WG, and IPFC is the IP over Fibre Channel protocol done
> by
> the
> ipfc WG.