Re: [Ips] AD review of draft-ietf-ips-iscsi-nodearch-key-02

Dave W <wysochanski@pobox.com> Mon, 16 October 2006 03:01 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZIix-0004Ca-EP; Sun, 15 Oct 2006 23:01:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZIiv-0004CV-Vc for ips@ietf.org; Sun, 15 Oct 2006 23:01:05 -0400
Received: from web36803.mail.mud.yahoo.com ([209.191.85.54]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZIit-0002lt-LS for ips@ietf.org; Sun, 15 Oct 2006 23:01:05 -0400
Received: (qmail 53417 invoked by uid 60001); 16 Oct 2006 03:00:43 -0000
Message-ID: <20061016030043.53415.qmail@web36803.mail.mud.yahoo.com>
Received: from [69.134.212.78] by web36803.mail.mud.yahoo.com via HTTP; Sun, 15 Oct 2006 20:00:43 PDT
X-RocketYMMF: deepthinkingguy
Date: Sun, 15 Oct 2006 20:00:43 -0700
From: Dave W <wysochanski@pobox.com>
Subject: Re: [Ips] AD review of draft-ietf-ips-iscsi-nodearch-key-02
To: Lars Eggert <lars.eggert@netlab.nec.de>, ips@ietf.org
In-Reply-To: <D2027212-B716-445B-8FB2-FE43F90228D3@netlab.nec.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc:
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: wysochanski@pobox.com
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=subscribe>
Errors-To: ips-bounces@ietf.org

--- Lars Eggert <lars.eggert@netlab.nec.de> wrote:

> Section 1.2., paragraph 3:
>  >    The key is sent during operational parameter negotiation of an  
> iSCSI
>  >    session's login phase.  The intended use of this key is to provide
>  >    enhanced logging and support capabilities, and to enable  
> collection
>  >    of iSCSI implementation and usage information.  Functional  
> behavior
>  >    of the iSCSI node (this includes the iSCSI protocol logic -- the
>  >    SCSI, iSCSI, and TCP/IP protocols) MUST NOT depend on the  
> presence,
>  >    absence, or content of the key.  The key MUST NOT be used by iSCSI
>  >    nodes for interoperability, or exclusion of other nodes.  To  
> ensure
>  >    proper use, key values SHOULD be set by the node itself, and there
>  >    SHOULD NOT be provisions for the key values to contain user- 
> defined
>  >    text.
> 
>    Suggest to move the text starting with "Functional behavior..." to
>    Section 3 (Overview is not the place for this.)
> 
Agreed - thanks for the suggestion.  Fits nicely as the first paragraph of Section 3.


>    Finally - why is this going for Informational and not PS? PS seems
>    appropriate.
> 
I defer to the chair and other 3720 authors on this one.




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