Re: [storm] Combined iSCSI draft - Proposed Standard, not Draft Standard

[<[e-mail]>]

Hi Paul,

Thanks for responding.

> I guess I may need to read up on the formal requirements.

Ok, here's the initial reading list:

(1) RFC 2026 defines the levels of IETF protocol standards in Section 4; they are (in order) Proposed Standard, Draft Standard and Internet (full) Standard.  The iSCSI specifications are currently Proposed Standards, as is the case for a large number of IETF protocols.

(2) RFC 5657 explains what's involved in moving a protocol from Proposed Standard status to Draft Standard status - an interoperability report is required.  That report is a WG output; it has to represent both implementation interoperability "facts on the ground" and WG rough consensus, and it's generally published as an RFC.

(3) Process change may be in the works here.  A current draft by the IETF chair and co-authors on standards track RFC maturity levels is relevant to this discussion, draft-housley-two-maturity-levels-04.txt
	(http://datatracker.ietf.org/doc/draft-housley-two-maturity-levels/).

> Clearly there is a large body of
> experience with interoperability of iSCSI implementations.  So it can't be the case that the
> maturity isn't there; if paper has to be pushed, perhaps contractors could be funded by interested
> parties to make that happen.

I absolutely agree that iSCSI maturity and deployment are there, but getting to a Draft Standard RFC involves considerably more than pushing paper.  For iSCSI, the interoperability report is likely to be detailed (e.g., it will need to cover all the text keys used for login and subsequent renegotiation, although probably at a coarser granularity than a feature per key).  In addition, the requirement for at least two interoperable implementations was written for symmetric protocols (e.g., TCP/IP); for iSCSI, I would expect the minimum requirement to be at least two initiators(I) and two targets(T), with interoperability of all four I-T combinations checked.  In practice, if we start this adventure, I would expect that we'll see more that two of each type of implementation, in which case a suitable subset of the 3-dimensional initiator-target-feature matrix that provides at least 2x2 I-T coverage for each feature ought to suffice.

In moving to a Draft Standard RFC, any functionality that doesn't interoperate (e.g., because it's not implemented) usually needs to be removed, see Section 5.6 of RFC 5657.  To take a specific example discussed earlier on this list, the unimplemented iSCSI support for Kerberos would almost certainly have to be dropped, as any attempt to include it as an important unimplemented optional feature is likely to founder on an IETF Security Area critique of the iSCSI Kerberos design as the "wrong way" in principle to support Kerberos.  These decisions cannot be left to contractors - they are clearly WG responsibilities.

> I'm concerned about the message implicit in not advancing the level.  If we send out STORM with the
> same "draft standard" status as the original RFC 3720, that sounds like we're telling the world that
> there has been no significant increase in standards maturity in the past 7 years.  I can't believe
> that this is the sort of message we would send out lightly.

I'm less concerned, as outside the IETF, my impression is that the difference between Proposed Standard and Draft Standard is not well understood.  For example, the use of "draft standard" in the above text is a backhanded confirmation of that situation ;-).  Within IETF, there is no "shame" in issuing an updated protocol RFC that remains at Proposed Standard status - many important protocols have never progressed beyond Proposed Standard, see http://www.rfc-editor.org/rfcxx00.html#Proposed .

Another concern that has been raised to me in the context of the new features draft is that if we take iSCSI to a Draft Standard RFC status now, the result could be to effectively stall its SCSI support at the SAM-2 level that was used in RFC 3720 because none of the iSCSI features in the new features draft are sufficiently implemented to be demonstrably interoperable (no surprise there, they're new features).  The result would be a Draft Standard iSCSI RFC based on SAM-2 and a Proposed Standard RFC for all the new features (based on SAM-4 + some changes in SAM-5) - that difference could be viewed as a disincentive to implementation of the new features.  An alternative to consider is to publish both drafts as Proposed Standards soon, and then consider the implementation uptake of the new features in making a decision about whether to embark on producing an iSCSI Draft Standard RFC document a year or so from now (e.g., after SAM-5 becomes a standard).

Thanks,
--David

> -----Original Message-----
> From: Paul Koning [mailto:[e-mail]]
> Sent: Monday, March 14, 2011 9:15 PM
> To: Black, David
> Cc: [e-mail]
> Subject: Re: [storm] Combined iSCSI draft - Proposed Standard, not Draft Standard
> 
> I guess I may need to read up on the formal requirements.  Clearly there is a large body of
> experience with interoperability of iSCSI implementations.  So it can't be the case that the
> maturity isn't there; if paper has to be pushed, perhaps contractors could be funded by interested
> parties to make that happen.
> 
> I'm concerned about the message implicit in not advancing the level.  If we send out STORM with the
> same "draft standard" status as the original RFC 3720, that sounds like we're telling the world that
> there has been no significant increase in standards maturity in the past 7 years.  I can't believe
> that this is the sort of message we would send out lightly.
> 
> 	paul
> 
> On Mar 14, 2011, at 6:54 PM, <[e-mail]> <[e-mail]> wrote:
> 
> > We have the following milestone on our charter that needs some attention:
> >
> > Working Group decision on whether to seek Draft Standard RFC status for the combined
> > iSCSI draft (3720bis).
> >
> > Based on level of activity and interest that I've observed on and off the list, I don't see much
> > interest in doing the interoperability report work that would be required to take this draft
> > through the formal IETF process required for Draft Standard status.
> >
> > Speaking for myself, I don't have the cycles available to do the work that would be required
> > to oversee this process, and I don't believe that iSCSI is experiencing the sort of
> > interoperability problems in practice that this work would help with.
> >
> > Therefore I believe that the rough consensus of the storm WG is that the combined iSCSI draft
> > (draft-ietf-storm-iscsi-cons) should be published as a Proposed Standard RFC (same status as
> > RFC 3720 and RFC 5048, among others).
> >
> > Anyone who disagrees should post to the list and explain why they disagree with this course
> > of action.
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > [phone]             FAX: [phone]
> > [e-mail]        Mobile: [phone]
> > ----------------------------------------------------