Solciting feedback on submission of iSCSI public extension key, X#NodeArchitecture, for March '06 IETF meeting

[David Wysochanski <davidw@netapp.com>]

Last year I submitted an earlier revision of this proposal
for an iSCSI public extension key to enhance supportability.
Attached is the latest revision and I would solicit candid
feedback from the iSCSI authors and the group.  In particular,
do you have any major concerns about this proposal?  Do you
view this as a useful addition to the iSCSI protocol, and
a viable work item the group might sponsor?

I believe the main usefulness of the proposal is seen when
considering iSCSI in support situations (though there may be
other valid uses).  The idea behind the support efficiency is
that one may avoid at least some of the "Which version of X is
running on the other side?" back and forth iterations.  Avoiding
even one of these iterations is not insignificant, because each
iteration may take hours or even days.  In this way, this
small extension to the iSCSI protocol has the potential to
make iSCSI more supportable, and thus, more sellable.

There are of course downsides to the proposal, and new
potential problems.  I believe I have thought through and
tried to address at least some of the major ones, and we
can discuss if/when concerns arise.

Provided there are no major concerns or objections, I
would like to submit an IPS WG Internet Draft based on
this proposal in time for the March '06 IETF meeting,
and drive this towards Informational RFC status in '06.

Thanks for your consideration.

      Declarative Public Extension Key to Enhance iSCSI Supportability

This proposal identifies a declarative Public Extension Key as defined by
section 12.22 of RFC 3720 that may be used to communicate additional iSCSI
node information to the opposite node in a session.  The information carried
in the proposed 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.

The key has been modelled after the "Server" and "User-Agent" header fields as
specified in sections 14.38 and 14.43 of RFC 2616 [1], with the text-values
of the key roughly equivalent to Product Tokens in section 3.8 of RFC 2616.

The following proposed Public Extension Key is sent during the login phase
of an iSCSI normal session.  It is important to note that the intent of
providing this key is for better understanding of customer environments.
The key MUST NOT be used by iSCSI nodes for things such as interoperability,
performance, exclusion or deception of other nodes, or other uses not defined
by this proposal.  To enforce proper use, iSCSI nodes MUST NOT allow user
modification of the key value(s), but MUST set the value automatically based
on standard internal interfaces.

In certain environments where security is a primary concern, the use of this
key MAY NOT be appropriate as it reveals specific details about an iSCSI node.
For these environments, nodes implementing this public extension key SHOULD
provide a method to disable sending the key.

The definition of the proposed key is as follows, with example text-values
conforming to section 5.1 of RFC 3720.

X#NodeArchitecture

   Use: IO, Declarative, Any-Stage
   Senders: Initiator and Target
   Scope: SW

   X#NodeArchitecture=<list-of-values>

   Examples:

      X#NodeArchitecture="os/1.2.3.4,iscsi-vendor-software/1.2.3.4"
      X#NodeArchitecture="os/1.2.3.4,cpu-type-x,cpu-speed/2.0ghz,
                          iscsi-vendor-hardware/1.2.3.4,
                          iscsi-vendor-firmware/1.2.3.4"

   The initiator or target declares the details of its iSCSI node architecture
   to the remote endpoint.  These details may include, but are not limited to,
   the OS version, CPU or hardware architecture, iSCSI vendor software and/or 
   firmware version, iSCSI vendor hardware revision, and so on.

   NodeArchitecture MUST NOT be redeclared.



[1] Hypertext Transfer Protocol -- HTTP/1.1;
http://www.faqs.org/rfcs/rfc2616.html

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips