Subject: RE: DRAFT Minneapolis Minutes -- ACA Discussion

From: Charles Monia <[email-masked]>
Date: Thu, 12 Apr 2001 10:25:39 -0700

> - 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".
> 
A point of clarification:

Without going into the gory details, the ACA mechanism has been suggested as
a way of avoiding the loss of strict ordering that occurs when a logical
unit completes a command with an error status.

Keeping in mind the underlying iSCSI issue, I assume the question here is
not support for the ACA function as a SCSI option but whether or not iSCSI
will MANDATE the implementation of ACA as a condition for iSCSI compliance.
In that context, "dropping ACA" would amount to not requiring a logical unit
to implement the feature.

A subsidiary issue, not discussed, was whether to request a T10 extension to
the ACA semantics to cover command processing errors other than those
represented by the CHECK CONDITION status (e.g., QUEUE_FULL). 

Charles
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 06, 2001 7:27 PM
> To: [email-masked]
> Subject: DRAFT Minneapolis Minutes
> 
> 
> Many thanks to Mark Carlson and Elizabeth Rodriguez for
> taking the minutes.  Please send corrections to the list,
> as well as any objections to rough consensus decisions
> reached in the meeting.  The deadline for changes to
> get incorporated in the official minutes is the end of
> the day on Wednesday, April 11th.  Thanks, --David
> 
> IPS WG Meeting Minutes - DRAFT
> 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 [email-masked] .
> ***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.
>

---

From: [email-masked]
Date: Thu, 12 Apr 2001 21:56:26 -0400

> - SCSI ACA discussion
> 
> > ACA (Auto Contingent Allegiance) is an optional SCSI mechanism that
stops execution
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".
>

That is the current question - "SHOULD" and "MAY" refer to their
definitions in RFC 2119, and "MANDATE" would correspond to "MUST".
I apologize if this shorthand was confusing

> to implement the feature.

That's not correct because "dropping ACA" refers to a future transition of
iSCSI
from Proposed Standard to Draft Standard status.  As part of that
transition,
any feature without two independently developed interoperable
implementations
is removed from the RFC as part of revising it for Draft Standard.  The
feature
isn't just made optional - the text describing such a feature is deleted.
The WG
has a fair amount of control over when the transition occurs, but the
transition
should be a goal, as the resulting cleansing of unimplemented features from
the specification is usually a good thing.  In ACA's case, its removal would
not be a good thing since it would cause iSCSI to no longer be a complete
SCSI transport mapping, and hence it behooves us to word the specification
now to encourage ACA to be implemented.

As I said, this situation is complex - I hope this explanation is clearer.

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------