Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture
draft-ietf-ips-iscsi-nodearch-key-03

[Ballot comment]
The document was initially submitted for Informational and the PROTO write-up included the following:

'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.'

However shortly after the intended status was changed to standards track. What is the reason, and does the initial reasoning under which Informational was asked not apply any more?

IANA Last call Comments:

Upon approval of this document, the IANA will make the
following assignments in the "iSCSI Parameters - per
[RFC3720]" registry located at

http://www.iana.org/assignments/iscsi-parameters
Sub-registry: "iSCSI extended key "
==================

OLD:
Number Extension Key Reference
------ --------------------- ---------
None registered at this time.


NEW:
Extension Key Name Desciption Reference
--------------------- --------------------- ---------
X#NodeArchitecture Node architecture details [RFC-iscsi-
nodearch-key-03]

Allocation procedure is RFC Publication.


We understand the above to be the only IANA Action for
this document.

[Ballot comment]
This is a strange specification in that (as far as I can tell) iscsi implementations that do absolutely nothing mentioned in this draft seem to be 100% compliant with the specification. Vendors will love it but I suspect it may not be as customers to learn that their equipment is RFC XXXX compliant.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document?

David L. Black 

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) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire will
be entered into the ID Tracker.)

No.

(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.