RE: iSCSI: v15 issue: iqn. name format inconsistencies

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

The reversed domain name is included in the name string for the purpose of
identifying the naming authority.  The intent of a colon separator after the
domain name was so that the identified naming authority was clearly
separable.  It isn't appropriate (or at least interesting) to identify the
companies' "sub-domain names" in the iSCSI names - they are NOT the names
that are registered with the qualifying date field.  Remember, this domain
name string is NOT intended to have any meaning within the string other than
identification of the naming authority - in the examples you have sited, the
naming authority is ajax.com, NOT mother.ajax.com.  Once the naming
authority is identified, anything beyond the reversed-domain name MUST be
guaranteed unique *by that naming authority*.  

Your intent seems to be to allow "sub-domain names" to be identified as
naming authoritys - I think that's not appropriate, not necessary (and not
particularly interesting to the other "naming authoritys").  If a particular
naming authority (ajax.com) wants to use that scheme it's free to do so, but
the responsible naming authority remains ONLY ajax.com.

I think your examples should be:

"com.ajax:mother:wonder.mydiskarray" and
 "com.ajax:mother.wonder:mydiskarray".

Although I think these are bad examples because it is not advisable for
ajax.com to construct a naming scheme using it's sub-domain names in that
manner.  A companies "sub-domain names" are typically organized in a manner
to facilitate the IT operations of a company, not to separate the business
units.  

Each company should construct a product naming scheme that makes sense for
their product divisions - for instance, a company manufacturing both servers
and storage might construct a naming scheme like:

iqn.1999-05.com.widget:storagearray.product1.<unique string>
for their storage array division and

iqn.1999-05.com.widget:server.fastestyet.<unique string>
for their server initiators.

I stand by my original recommendation.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions
Hewlett-Packard

> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Wednesday, July 17, 2002 12:52 AM
> To: KRUEGER,MARJORIE (HP-Roseville,ex1)
> Cc: Ips Reflector (E-mail)
> Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies
> 
> 
> 
> Marjorie,
> I think it is OK to make some of the example changes you have 
> indicated,
> but it is not required to always use the ":"  It depends on 
> the way your
> company manages their sub domain names.   It is still valid 
> to use an all
> dotted name.
> 
> The ":" was needed since a company can hand out subdomains 
> with names like
> "mother" and "mother.wonder" to different departments and therefore it
> would be possible for both departments to create a name like
> "com.ajax.mother.wonder.mydiskarray".  The use of ":" permits the
> departments to make their names unique by placing the ":" 
> following their
> subdomain portions.  That is, they can use the same characters but
> separated with a colon as follows 
> "com.ajax.mother:wonder.mydiskarray" and
> "com.ajax.mother.wonder:mydiskarray".
> 
> Therefore, I do not think that all examples should include a colon.
> 
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136, Cell: (408) 499-9702
> Internet address: hufferd@us.ibm.com
> 
> 
> "KRUEGER,MARJORIE (HP-Roseville,ex1)" 
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 07/16/2002 02:44:37 PM
> 
> Sent by:    owner-ips@ece.cmu.edu
> 
> 
> To:    "Ips Reflector (E-mail)" <ips@ece.cmu.edu>
> cc:
> Subject:    iSCSI: v15 issue: iqn. name format inconsistencies
> 
> 
> 
> 
> 
> There is currently an inconsistency in the way iSCSI  "iqn."-formatted
> names are illustrated and described between the iSCSI 
> protocol  document
> and the iSCSI Naming and Discovery document.  In particular, 
> the  separator
> character between the reversed-domain name and the rest of 
> the string  is
> defined to be "." but some examples in the N&D document describe it as
> ":".
> 
> I remember discussion (among the N&D team) that this 
> separator  should be
> ":" in order to distinguish the reversed domain name from the 
> rest of  the
> string, but this got lost somewhere along the line.  If there are no
> objections to changing this in the main draft, this 
> translates into changes
> for  both the iSCSI main draft and the N&D draft in cleaning up the
> examples and  making sure they are consistent (some use "." 
> and some use
> ":").
> 
> Here are  the changes I recommend to the main draft:
> In section  2.2.6.3
> 
> 
>      The  iSCSI qualified name string consists of:
>         -  The string "iqn."
>        -  A date  code, in yyyy-mm format.  This date MUST be a  date
>           during which the  naming authority owned the domain 
> name  used
>           in this format,  and SHOULD be the date on which the  domain
>           name was  acquired by this naming authority.  This 
> date  code
>           uses the  Gregorian calendar.  All four digits in 
> the year  must
>           be present.   Both digits of the month must be 
> present,  with
>           January == "01"  and December == "12".  The dash must  be
>            included.
>        -  A dot  ".".
>        -  The reversed domain name of  the naming authority 
> (person  or
>           organization)  creating this iSCSI name.
>        -  A  colon ":".
>        -  Any string, within  the character set and length  
> boundaries,
>           that the  owner of the domain name deems 
> appropriate.  This  may
>           contain product  types, serial numbers, host 
> identifiers,  soft-
>           ware keys, or  anything else that makes sense to 
> uniquely  iden-
>           tify the  initiator or target.  Everything after  "<reversed
>           domain  name>:", can be assigned as desired by the owner  of
>           the domain  name.  It is the responsibility of the 
> entity  that
>           is the naming  authority to ensure that the iSCSI names  it
>           assigns are world  wide unique.
> 
>      For example, "ACME Storage Arrays,  Inc.", might own the 
> domain name
>      "acme.com". The  following are examples of iSCSI 
> qualified names that
>       might be generated by "ACME Storage Arrays,  Inc."
> 
>                      Organization
>                          Naming     String defined  by
>           Type   Date     Auth      "acme.com"  naming authority
>            +--++-----+ +------+  +--------------------------------+
>            |  ||     | |      |  |
> 
>            iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309
>            iqn.2001-04.com.acme:server.megafast900.i95874
> 
> In section 11.4 TargetName
> 
>       Examples:
> 
>         TargetName=iqn.1993-11.com.diskvendor:diskarrays.sn.45678
> 
> In section 11.5 InitiatorName
> 
>       Examples:
> 
>         InitiatorName=iqn.1992-04.com.osvendor:plan9.cdrom.12345
>         InitiatorName=iqn.2001-02.com.ssp:users.customer235.host90
> 
> <Julian, make sure to delete the last example in the current  
> text, as it's
> invalid>
> 
> In appendix
> 
>      In the first  example, the initiator and target authenticate each
> other
>      via  Kerberos:
> 
>        I-> Login (CSG,NSG=0,1  T=1)
>             InitiatorName=iqn.1999-07.com.os:hostid.77
>             TargetName=iqn.1999-07.com.acme:diskarray.sn.88
>             AuthMethod=KRB5,SRP,None
> 
> etc - all these Login  examples that contain iSCSI names need 
> to be fixed.
> 
> In appendix
> 
>      Target sends a  text response that contains:
> 
>         TargetName=iqn.1993-11.com.acme:diskarray.sn.8675309
> 
> etc - all TargetName examples need to be  fixed.
> 
> Several examples in the Naming and Discovery draft need to  
> be fixed - I'll
> address that in a separate  email.
> 
> Marjorie Krueger
> Networked  Storage Architecture
> Networked Storage Solutions
> Hewlett-Packard
> 
> 
> 
> 
>