Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id h087MH713347 for ips-outgoing; Wed, 8 Jan 2003 02:22:17 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h087MFW13339 for ; Wed, 8 Jan 2003 02:22:15 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id h087M1ab045950; Wed, 8 Jan 2003 08:22:02 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h087M03J262614; Wed, 8 Jan 2003 08:22:01 +0100 To: ips@ece.cmu.edu Cc: Allison Mankin Subject: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Wed, 8 Jan 2003 09:21:59 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 08/01/2003 09:22:01, Serialize complete at 08/01/2003 09:22:01 Content-Type: multipart/alternative; boundary="=_alternative 00283297C2256CA8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00283297C2256CA8_= Content-Type: text/plain; charset="US-ASCII" How about the following text to replace the draconian "only those 2" text for naming and open the way for other naming (if we really want them): These two naming authority designators where considered sufficient at the time of writing this document. The creation of additional naming type designators for iSCSI may be considered by the IETF and detailed in separate RFCs. Regards, Julo ----- Forwarded by Julian Satran/Haifa/IBM on 08/01/03 09:16 ----- "Randy Jennings" Sent by: owner-ips@ece.cmu.edu 07/11/02 18:50 To cc Subject ISCSI: NAA naming format I will not be in the Atlanta meeting, so I will have to open this can of worms here. > - NAA naming format for iSCSI (30 min) draft-krueger-iscsi-name-ext-00.txt > This draft proposes to add a new .naa naming format to iSCSI in > addition to the current .iqn and .eui formats. A significant > motivation for this is an desire by T10 (ANSI organization that > handles SCSI standards) to obtain consistent SCSI device > naming across SCSI transports. > > The authors request that the IPS WG adopt this draft as an official > work item. It would become a separate RFC rather than being folded > into the main iSCSI draft. I first want to say that whether the NAA naming format is adopted or not does not matter to me, but it matters to me if the following text is left in the Proposed Standard version of the iSCSI draft: (pg39, line from start of document 2340) As these two naming authority designators will suffice in nearly every case for both software and hardware-based entities, the creation of additional type designators is prohibited. Now, it does not use the MUST language required by IETF drafts (as I understand it), but prohibited is a strong word for me. (On a side note, it would be interesting to open up a thesaurus and search for other such words in the draft (i.e. 'mandatory').) I do not want to see a sorry chap reading this draft, see the word 'prohibited' and not ever worry about another name format ever being made. It gives this nice sense of (false?) security that made me like math and standards in the first place. Sincerely, Randy Jennings Data Transit ----- Forwarded by Julian Satran/Haifa/IBM on 08/01/03 09:16 ----- "Mallikarjun C." Sent by: owner-ips@ece.cmu.edu 08/11/02 07:42 To "Randy Jennings" , cc Subject Re: ISCSI: NAA naming format Good catch. The statement would need to be modified to state that: this version of the iSCSI draft allows only two name type designators, and using user-defined name type designators is prohibited. Implementations complying with the iSCSI RFC would then support only those two formats, while new name formats may in addition be supported based on compliance to additional RFCs, as may be approved by the WG from time to time. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Randy Jennings" To: Sent: Thursday, November 07, 2002 8:50 AM Subject: ISCSI: NAA naming format > I will not be in the Atlanta meeting, so I will have to open this can of > worms here. > > > - NAA naming format for iSCSI (30 min) > draft-krueger-iscsi-name-ext-00.txt > > This draft proposes to add a new .naa naming format to iSCSI in > > addition to the current .iqn and .eui formats. A significant > > motivation for this is an desire by T10 (ANSI organization that > > handles SCSI standards) to obtain consistent SCSI device > > naming across SCSI transports. > > > > The authors request that the IPS WG adopt this draft as an > official > > work item. It would become a separate RFC rather than being > folded > > into the main iSCSI draft. > I first want to say that whether the NAA naming format is adopted or not > does not matter to me, but it matters to me if the following text is > left in the Proposed Standard version of the iSCSI draft: > > (pg39, line from start of document 2340) > As these two naming authority designators will suffice in nearly > every case for both software and hardware-based entities, the > creation of additional type designators is prohibited. > > Now, it does not use the MUST language required by IETF drafts (as I > understand it), but prohibited is a strong word for me. (On a side > note, it would be interesting to open up a thesaurus and search for > other such words in the draft (i.e. 'mandatory').) > > I do not want to see a sorry chap reading this draft, see the word > 'prohibited' and not ever worry about another name format ever being > made. It gives this nice sense of (false?) security that made me like > math and standards in the first place. > > Sincerely, > Randy Jennings > Data Transit > > --=_alternative 00283297C2256CA8_= Content-Type: text/html; charset="US-ASCII"
How about the following text to replace the draconian "only those 2" text for naming and open the way for other naming (if we really want them):

These two naming authority designators where considered sufficient at the time of writing this document.  The creation of additional naming type designators for iSCSI may be considered by the IETF and detailed in separate RFCs.

Regards,
Julo
----- Forwarded by Julian Satran/Haifa/IBM on 08/01/03 09:16 -----
"Randy Jennings" <randyj@data-transit.com>
Sent by: owner-ips@ece.cmu.edu

07/11/02 18:50

To
<ips@ece.cmu.edu>
cc
Subject
ISCSI: NAA naming format





I will not be in the Atlanta meeting, so I will have to open this can of
worms here.

> - NAA naming format for iSCSI (30 min)
draft-krueger-iscsi-name-ext-00.txt
>                 This draft proposes to add a new .naa naming format to iSCSI in
>                 addition to the current .iqn and .eui formats.  A significant
>                 motivation for this is an desire by T10 (ANSI organization that
>                 handles SCSI standards) to obtain consistent SCSI device
>                 naming across SCSI transports.
>
>                 The authors request that the IPS WG adopt this draft as an
official
>                 work item.  It would become a separate RFC rather than being
folded
>                 into the main iSCSI draft.
I first want to say that whether the NAA naming format is adopted or not
does not matter to me, but it matters to me if the following text is
left in the Proposed Standard version of the iSCSI draft:

(pg39, line from start of document 2340)
  As these two naming authority designators will suffice in nearly
  every case for both software and hardware-based entities, the
  creation of additional type designators is prohibited.

Now, it does not use the MUST language required by IETF drafts (as I
understand it), but prohibited is a strong word for me.  (On a side
note, it would be interesting to open up a thesaurus and search for
other such words in the draft (i.e. 'mandatory').)

I do not want to see a sorry chap reading this draft, see the word
'prohibited' and not ever worry about another name format ever being
made.  It gives this nice sense of (false?) security that made me like
math and standards in the first place.

Sincerely,
Randy Jennings
Data Transit
----- Forwarded by Julian Satran/Haifa/IBM on 08/01/03 09:16 -----
"Mallikarjun C." <cbm@rose.hp.com>
Sent by: owner-ips@ece.cmu.edu

08/11/02 07:42

To
"Randy Jennings" <randyj@data-transit.com>, <ips@ece.cmu.edu>
cc
Subject
Re: ISCSI: NAA naming format





Good catch.

The statement would need to be modified to state that: this version
of the iSCSI draft allows only two name type designators, and using
user-defined name type designators is prohibited.

Implementations complying with the iSCSI RFC would then support
only those two formats, while new name formats may in addition be
supported based on compliance to additional RFCs, as may be approved
by the WG from time to time.

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com

----- Original Message -----
From: "Randy Jennings" <randyj@data-transit.com>
To: <ips@ece.cmu.edu>
Sent: Thursday, November 07, 2002 8:50 AM
Subject: ISCSI: NAA naming format


> I will not be in the Atlanta meeting, so I will have to open this can of
> worms here.
>
> > - NAA naming format for iSCSI (30 min)
> draft-krueger-iscsi-name-ext-00.txt
> > This draft proposes to add a new .naa naming format to iSCSI in
> > addition to the current .iqn and .eui formats.  A significant
> > motivation for this is an desire by T10 (ANSI organization that
> > handles SCSI standards) to obtain consistent SCSI device
> > naming across SCSI transports.
> >
> > The authors request that the IPS WG adopt this draft as an
> official
> > work item.  It would become a separate RFC rather than being
> folded
> > into the main iSCSI draft.
> I first want to say that whether the NAA naming format is adopted or not
> does not matter to me, but it matters to me if the following text is
> left in the Proposed Standard version of the iSCSI draft:
>
> (pg39, line from start of document 2340)
>    As these two naming authority designators will suffice in nearly
>    every case for both software and hardware-based entities, the
>    creation of additional type designators is prohibited.
>
> Now, it does not use the MUST language required by IETF drafts (as I
> understand it), but prohibited is a strong word for me.  (On a side
> note, it would be interesting to open up a thesaurus and search for
> other such words in the draft (i.e. 'mandatory').)
>
> I do not want to see a sorry chap reading this draft, see the word
> 'prohibited' and not ever worry about another name format ever being
> made.  It gives this nice sense of (false?) security that made me like
> math and standards in the first place.
>
> Sincerely,
> Randy Jennings
> Data Transit
>
>

--=_alternative 00283297C2256CA8_=--