[Ips] Protocol Action: 'Declarative Public Extension Key for iSCSI Node Architecture' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'Declarative Public Extension Key for iSCSI Node Architecture '
   <draft-ietf-ips-iscsi-nodearch-key-03.txt> as a Proposed Standard

This document is the product of the IP Storage Working Group. 

The IESG contact persons are Lars Eggert and Magnus Westerlund.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-nodearch-key-03.txt

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 theabuse 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.
 
Protocol 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., who also
   acted as PROTO Document Shepherd.

   Lars Eggert reviewed this document for the IESG.

Note to RFC Editor

Section 3, paragraph 2
OLD:

   Nodes implementing this key MAY choose to only transmit the key, only
   log the key values received from other nodes, or both transmit and
   log the key values.

NEW:

   Nodes implementing this key MUST choose one of the following
   implementation options:
	o only transmit the key
	o only log the key values received from other nodes or
	o both transmit and log the key values. 

Section 3, paragraph 3
OLD:

   Thus, a valid implementation of this key may be that a node is
   completely silent

NEW:

   Thus, a valid behavior for this key may be that a node is
   completely silent

 
In Section 5 IANA Considerations, insert the following
text after the first paragraph:

NEW:

      The update to RFC 3720 to allow additional types of RFCs for
      iSCSI Extension items has the same effect as if the following
      changes were made to the text of RFC 3720 (RFC text cannot be
      changed after publication):

      1) In Section 11.1, the requirement that Z# Authentication methods
         "MUST be described by an informational RFC." is changed to
         "MUST be described by a standards track RFC, an experimental
         RFC or an informational RFC."

      2) In Section 12.1, the requirement that Y# Digest algorithms
         "MUST be described by an informational RFC." is changed to
         "MUST be described by a standards track RFC, an experimental
         RFC or an informational RFC."

      3) In Section 12.22, the requirement that X# text keys
         "MUST be described by an informational RFC." is changed to
         "MUST be described by a standards track RFC, an experimental
         RFC or an informational RFC."

      4) In Section 13.3, the description of allowed RFC types for
         extension items is changed from "The RFC may be informational
         rather than Standards-Track," to "The RFC MUST be standards
         track, experimental or informational,"

      5) In Section 13.5.2, the phrase "standards track" is changed to
         "standards track or experimental" in the last sentence of
         the first paragraph, so that the sentence reads: "If the
         specification is a standards track or experimental document,
         the usual IETF procedures for such documents are followed."

      The registries for iSCSI extension items should be managed as
      if these changes had been made to the text of RFC 3720.


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