[Ips] RE: Publication Requested: iSCSI Node Architecture Key

[[e-mail]]

Cut/paste error - First line should have said:

RFC publication has just been requested for the iSCSI Node
Architecture Key draft.

Sorry,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------

> -----Original Message-----
> From: Black, David 
> Sent: Thursday, October 12, 2006 2:56 PM
> To: [e-mail]
> Cc: Black, David
> Subject: Publication Requested: iSCSI Node Architecture Key
> 
> RFC publication has just been requested for the VF MIB draft.  The
> PROTO process (cf. draft-ietf-proto-wgchair-doc-shepherding-07.txt)
> is being used.  Here is the PROTO writeup:
> 
>       Declarative Public Extension Key for iSCSI Node Architecture
>                 draft-ietf-ips-iscsi-nodearch-key-02.txt
> 
> Requested Publication Status: Informational
> PROTO shepherd: David L. Black (IPS WG Chair)
> --------------------------------------------------------------
> ----------
> 
>    (1.a)  Who is the Document Shepherd for this document?
> 
> David L. Black <[e-mail]>
> 
>           Has the Document Shepherd personally reviewed this version
>           of the document and, in particular, does he or she 
> believe this
>           version is ready for forwarding to the IESG for publication?
> 
> Yes.
> 
>    (1.b)  Has the document had adequate review both from key 
> WG members
>           and from key non-WG members?
> 
> Yes.
> 
>           Does the Document Shepherd have any concerns about the depth
>           or breadth of the reviews that have been performed?
> 
> No - the WG went over this draft with a fine-toothed comb.
> 
>    (1.c)  Does the Document Shepherd have concerns that the document
>           needs more review from a particular or broader perspective,
>           e.g., security, operational complexity, someone 
> familiar with
>           AAA, internationalization or XML?
> 
> No.
> 
>    (1.d)  Does the Document Shepherd have any specific concerns or
>           issues with this document that the Responsible Area Director
>           and/or the IESG should be aware of?  For example, perhaps he
>           or she is uncomfortable with certain parts of the 
> document, or
>           has concerns whether there really is a need for it.  In any
>           event, if those issues have been discussed in the WG and the
>           WG has indicated that it still wishes to advance 
> the document,
>           detail those concerns here.
> 
> The design of this key is based on HTTP mechanisms that have 
> been abused
> to identify browsers, causing interoperability issues rising 
> to the level
> of refusing to allow certain browsers to access certain web 
> sites.  This
> draft contains language intended to strongly discourage that 
> sort of abuse,
> and while it is impossible to prohibit such abuse, in 
> practice it can be
> accomplished by other means (e.g., look for presence or 
> absence of a private
> key specific to an implementation).  The iSCSI protocol is 
> also considerably
> constrained (functionally) by comparison to web content 
> (e.g., Javascript),
> and initial iSCSI interoperability experience has been good.
> 
> This document is being published as Informational because RFC 
> 3720 indicates
> that this class of key specification should be published as 
> informational.
> RFC 2119 terminology is nonetheless appropriate because this document
> specifies a protocol extension.
> 
>    (1.e)  How solid is the WG consensus behind this document?  Does it
>           represent the strong concurrence of a few individuals, with
>           others being silent, or does the WG as a whole 
> understand and
>           agree with it?
> 
> There is solid WG consensus behind this document.
> 
>    (1.f) <Not sent to WG>
> 
>    (1.g)  Has the Document Shepherd verified that the 
> document satisfies
>           all ID nits?  (See http://www.ietf.org/ID-Checklist.html and
>           http://tools.ietf.org/tools/idnits/).  Boilerplate 
> checks are
>           not enough; this check needs to be thorough.
> 
> The online checker finds no problems.
> 
>    (1.h)  Has the document split its references into normative and
>           informative?
> 
> Yes.
> 
>           Are there normative references to documents that
>           are not ready for advancement or are otherwise in an unclear
>           state?  If such normative references exist, what is the
>           strategy for their completion?
> 
> No.
> 
>           Are there normative references
>           that are downward references, as described in [RFC3967]?  If
>           so, list these downward references to support the Area
>           Director in the Last Call procedure for them [RFC3967].
> 
> No.
> 
>    (1.i)  The IESG approval announcement includes a Document
>           Announcement Write-Up.  Please provide such a Document
>           Announcement Write-Up.  Recent examples can be found in the
>           "Action" announcements for approved documents.  The approval
>           announcement contains the following sections:
> 
>           Technical Summary
> 
>    The iSCSI protocol, described in RFC 3720, allows for extension
>    items to the protocol in the form of Private or Public Extension
>    Keys.  This Internet-Draft describes a Public Extension Key for the
>    purpose of enhancing iSCSI supportability.  The key 
> accomplishes this
>    objective by allowing iSCSI nodes to communicate 
> architecture details
>    during the iSCSI login sequence.  The receiving node can then use
>    this information for enhanced logging and support.
> 
>           Working Group Summary
> 
>    This document was carefully reviewed in the WG primarily 
> for security
>    concerns (protecting sensitive information about what is 
> running) and
>    the possible abuse of this key in a fashion similar to the abuse of
>    the HTTP "Server" and "User-Agent" fields that can damage
>    interoperability.  As a result of this WG attention, the draft
>    contains specific text to address both concerns.
> 
>           Document Quality
> 
>    There are implementations of functionality similar to that provided
>    by this key.
> 
>    This draft was reviewed for the IPS WG by David L. Black.
> 
> Thanks,
> --David
> 
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 
> 

_______________________________________________
Ips mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ips