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. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
