Subject: [Ips] iSCSI extension key to enhance supportability

From: David Wysochanski <[email-masked]>
Date: Fri, 03 Feb 2006 17:17:59 -0500

I submit the attached Internet-Draft for the March IETF meeting
in Dallas.  Please note that I have already been in contact with
the IP Storage WG, and WG chair David Black has put this item
on the agenda for that meeting.

Thanks,

Dave Wysochanski
INTERNET-DRAFT                                       Dave Wysochanski
Expires: August 3, 2006                        Network Appliance, Inc
                                                     February 3, 2006

      Declarative Public Extension Key to Enhance iSCSI Supportability
               draft-wysochanski-xkey-iscsi-support-00.txt

Status of this Memo 

   By submitting this Internet-Draft, each author represents 
   that any applicable patent or other IPR claims of which he or 
   she is aware have been or will be disclosed, and any of which 
   he or she becomes aware will be disclosed, in accordance with 
   Section 6 of BCP 79. 

   Internet-Drafts are working documents of the Internet 
   Engineering Task Force (IETF), its areas, and its working 
   groups.  Note that other groups may also distribute working 
   documents as Internet-Drafts. 

   Internet-Drafts are draft documents valid for a maximum of 
   six months and may be updated, replaced, or obsoleted by 
   other documents at any time.  It is inappropriate to use 
   Internet-Drafts as reference material or to cite them other 
   than as "work in progress." 

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/1id-abstracts.html 

   The list of Internet-Draft Shadow Directories can be accessed 
   at http://www.ietf.org/shadow.html.  

   This Internet-Draft will expire on August 3, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   RFC 3270 defines the iSCSI protocol and 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.

Wysochanski              Expires August 3, 2006            [Page  1] 


Internet-Draft          iSCSI Supportability           February 2006
 
1.  Introduction

1.1  Terminology

   The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
   "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in
   this document are to be interpreted as described in RFC2119.

1.2  Overview

   This Internet-Draft describes 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 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.

   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, with the text-value(s) of the key roughly equivalent to
   Product Tokens in section 3.8 of RFC 2616.  Note however that
   the text-value(s) in the keys list-of-values MUST conform to
   the Text Format as specified in section 5.1 of RFC 3720.

   The following described Public Extension Key is sent during
   the login phase of an iSCSI normal session.  It is important
   to note that the proper use of this key is to provide enhanced
   logging and support capabilities, and 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 here.  To enforce proper use, iSCSI nodes MUST NOT
   allow user modification of the key value(s), and SHOULD set
   the value automatically based on standard internal interfaces.

Wysochanski              Expires August 3, 2006            [Page  2] 


Internet-Draft          iSCSI Supportability           February 2006

2.  Definition

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

X#NodeArchitecture

   Use: LO, Declarative
   Senders: Initiator and Target
   Scope: SW

   X#NodeArchitecture=<list-of-values>

   Examples:

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

   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, iSCSI vendor software, firmware, or
   hardware versions, the OS version, or hardware architecture.

   X#NodeArchitecture MUST NOT be redeclared.

Wysochanski              Expires August 3, 2006            [Page  3] 


Internet-Draft          iSCSI Supportability           February 2006
 
3.  Security Considerations 

   In certain environments where security is a primary concern,
   the use of this extension 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.

 
Wysochanski              Expires August 3, 2006            [Page  4] 


Internet-Draft          iSCSI Supportability           February 2006
 
4.  IANA Considerations 

   This document defines the iSCSI Extension Key NodeArchitecture 
   to be registered in the IANA iSCSI extended key registry.

 
Wysochanski              Expires August 3, 2006            [Page  5] 


Internet-Draft          iSCSI Supportability           February 2006
 
5.  References

5.1  Normative References 

   [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997.  

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
             an IANA Considerations Section in RFCs.", BCP 26, RFC
             2434, October 1998.

   [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, 
             M., and E. Zeidner, "Internet Small Computer Systems 
             Interface (iSCSI)", RFC 3720, April 2004. 

5.2  Informative References 

   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
             Masinter, L., Leach, P., and T. Berners-Lee, 
             "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
             June 1999.

 
 
Wysochanski              Expires August 3, 2006            [Page  6] 


Internet-Draft          iSCSI Supportability           February 2006
 
6.  Author's Address 

   Dave Wysochanski
   Network Appliance, Inc.
   7301 Kit Creek Road
   P. O. Box 13917
   Research Triangle, NC 27709
   Phone: +1-919-476-5628
   E-mail: [email-masked]

 
Wysochanski              Expires August 3, 2006            [Page  7] 


Internet-Draft          iSCSI Supportability           February 2006
 
7.  Acknowledgements 

   The IP Storage (ips) Working Group in the Transport Area of 
   IETF has been responsible for defining the iSCSI protocol 
   (apart from a host of other relevant IP Storage protocols).  
   The editor acknowledges the contributions of the entire 
   working group.   

   The following individuals directly contributed to identifying 
   issues and/or suggesting resolutions to the issues found in this
   document: David Black, Paul Koning, Julian Satran, John Hufferd,
   Claire Kraft, Ranga Sankar, Joseph Pittman, Greg Berg, and
   John Forte. This document benefited from all these contributions. 

 
Wysochanski              Expires August 3, 2006            [Page  8] 


Internet-Draft          iSCSI Supportability           February 2006
 
8.  Full Copyright Statement 

   Copyright (C) The Internet Society (2006).  This document is 
   subject to the rights, licenses and restrictions contained in 
   BCP 78, and except as set forth therein, the authors retain 
   all their rights.  

   This document and the information contained herein are 
   provided on an "AS IS" basis and THE CONTRIBUTOR, THE 
   ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 
   THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 
   DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 
   OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

 
Wysochanski              Expires August 3, 2006            [Page  9] 


Internet-Draft          iSCSI Supportability           February 2006
 
9.  Intellectual Property Statement  

   The IETF takes no position regarding the validity or scope of    
   any Intellectual Property Rights or other rights that might 
   be claimed to pertain to the implementation or use of the 
   technology described in this document or the extent to which 
   any license under such rights might or might not be 
   available; nor does it represent that it has made any 
   independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can 
   be found in BCP 78 and BCP 79.  

   Copies of IPR disclosures made to the IETF Secretariat and 
   any assurances of licenses to be made available, or the 
   result of an attempt made to obtain a general license or 
   permission for the use of such proprietary rights by 
   implementers or users of this specification can be obtained 
   from the IETF on-line IPR repository at http://www.ietf.org/ipr.  

   The IETF invites any interested party to bring to its 
   attention any copyrights, patents or patent applications, 
   or other proprietary rights that may cover technology that 
   may be required to implement this standard.  Please address 
   the information to the IETF at [email-masked].  

 
Wysochanski              Expires August 3, 2006            [Page 10] 

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