[Ips] WG Last Call review: draft-ietf-ips-iscsi-nodearch-key-01.txt

[[e-mail]]

I found a bunch of editorial nits, plus a need to correct a registry
problem at IANA.  Please do not revise this draft until WG Last Call
is complete (next week).

As I read this draft now, I'd prefer 'Node Architecture' to be replaced
by 'Node Implementation', but I think we're entirely too far along for
for that sort of change, so I can live with 'Architecture'.

Section 1.2:

   This Internet-Draft describes a declarative Public Extension Key as
   defined by section 12.22 of RFC 3720 [2] that may be used to
   communicate additional iSCSI node information to the opposite node in
   a session.

'opposite' --> 'peer'

   The information carried in the described key has been
   found to be valuable in real iSCSI customer environments as initiator
   and target vendors collaborate to resolve technical issues and better
   understand the evolving iSCSI market.

'evolving iSCSI market' --> 'interaction of iSCSI implementations'
FWIW, 'market' is a dangerous word to use in any protocol standard.

   The key has been modeled after the "Server" and "User-Agent" header
   fields as specified in sections 14.38 and 14.43 of RFC 2616 [3]

Insert 'HTTP' before '"Server"' for clarity.

   The key MUST NOT be used by iSCSI
   nodes for interoperability, or exclusion or deception of other nodes.

Explain or remove 'deception'.

Section 2:

   The key is defined with a Use of "LO", making it a Leading Only key,
   and does not amend sections 11 or 12 of RFC 3720 [2].

'amend' --> 'modify'

Section 3:

   Nodes implementing this key may choose to only transmit the key, only

'may' --> 'MAY'
This change doesn't make much difference, but it does call attention to
this important sentence.

   Nodes that implement transmission and/or logging of the key values
   may also implement switches which disable and/or change the logging
   and key transmission detail (see Security Considerations). 

'switches which' -> 'administrative mechanisms that'
'switches' will be misread as being akin to 'Ethernet switches' ;-),
and 'which' needs to be replaced by 'that'.

   Thus, a
   valid implementation of this key may be that a node is completely
   silent (the node does not transmit any key value, and simply discards
   any key values it receives).

I think this needs to also say 'without issuing a NotUnderstood
response'
at the end of the parenthetical discussion of discarding received
values.
This helps line up with the previous paragraph, and makes it clear how
silence qualifies as support.

Section 4:

   The choice of which countermeasure is most appropriate depends on the
   environment.  However, the first countermeasure may be acceptable in
   many environments, since it provides a compromise between sending too
   much information and the other more complete countermeasures of not
   sending the key at all or using IPsec.

I think this should say 'However, the latter countermeasure'.  Recheck
this text with respect to the immediately preceding paragraph in the
draft.

Section 5:

Oops - looking at the IANA registry, it looks like IANA didn't set
it up correctly - the registry contains Number, Extension Key, and
Reference - it should contain Key Name, Description, and Reference.
Ultimately, some combination of Lars (AD) and yours truly (WG chair)
are going to have to work this out with IANA, but let's put some text
in this draft telling IANA what should be done, so that they'll know
to ask.  Please add the following text:

	The IANA iSCSI Extended Key registry does not correspond to
	RFC 3720 that defined it.  The registry should contain three
	fields for each extended key:
		- Key Name
		- Description
		- Reference
	IANA should modify the registry accordingly, and then register
	this key as follows:
		- Key Name: X#NodeArchitecture
		- Description: Node architecture details
		- Reference: [this RFC-to-be]
-- RFC Editor: This paragraph (starting from "The IANA iSCSI Extended
Key"
	should be removed prior to RFC publication.

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