iSNS: Responses to David Black Technical Comments

[Joshua Tseng <jtseng@NishanSystems.com>]

Please see below responses to the technical comments.  I will respond
to the editorial comments separately.

Josh

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Monday, October 14, 2002 2:25 AM
> To: jtseng@NishanSystems.com; ips@ece.cmu.edu
> Cc: erodrigu@Brocade.COM
> Subject: iSNS: More Last Call comments
> 
> 
> Here are mine.  Sorry to be a bit tardy on these but
> the powers that be decided that I had to spend most of
> Friday and Saturday packing and unpacking to move to a
> new office.  Thanks, --David
> 
> ----- Technical -----
> 
> -- Section 3.3.2
> 
>    The iSNS server may refuse SCN service by returning a SCN
>    Registration Rejected (Status Code 17).  The rejection might occur
>    in situations where the network size or current number of SCN
>    registrations, has passed an implementation-specific threshold.  A
>    client not allowed to register for SCNs may decide to monitor its
>    sessions with other storage devices directly.
> 
> The "may" needs to be upper case, and this text strikes me as being
> a bit too cavalier about situations in which iSNS is unable to provide
> the requested service.  A sentence should be added cautioning
> implementers that both hardware and software resources should be
> provided in sufficient quantities to make this refusal of service
> a sufficiently rare case.

The text will be changed to read:

The iSNS server SHOULD be implemented with sufficient hardware and software
resources needed to support the expected number of iSNS clients.  However,
if resources are unexpectedly exhausted, then the iSNS server MAY refuse SCN
service by returning a SCN Registration Rejected (Status Code 17).  The
rejection might occur in situations where the network size or current number
of SCN registrations, has passed an implementation-specific threshold.  A
client not allowed to register for SCNs may decide to monitor its sessions
with other storage devices directly.

> 
> -- Section 3.4
> 
> Need a couple of "MUST"s in this section:
> - One to require the existence of an administrative control 
> interface for
> 	the listed parameters.
> - One to require the default settings be used in the absence of other
> 	configuration (could be a "SHOULD").

Done.

> 
> -- Section 3.5.2
> 
> Will need to instruct IANA (and the RFC editor) to fill in 
> the iSNS DHCP
> option number when it is allocated.

Noted.

> 
> -- Section 3.6
> 
> NAT discussion also needs to talk about using "global" addresses/port
> numbers
> for services/communication endpoints that need to be 
> accessible.  This is
> for an environment in which the administrator of iSNS knows 
> about the NATs
> and can configure appropriate static mappings in them so that 
> iSNS operates
> in the "global" domain and with a little care, everything 
> "just works",
> even though NATs are involved (in essence, nodes behind NATs 
> have a local
> address/port that they use for communication and a "global" one that
> they report to iSNS, with the NAT[s] translating between 
> them).  This is
> a "no free lunch" discussion, as it implies extra overhead in 
> configuring
> the NAT[s] and care to deal with the fact that an endpoint now has two
> <IP address, TCP port> address pairs.  There ought to be some useful
> material on this in the NAT RFCs (and possibly drafts) somewhere.

The following text was added the the end of section 3.6:

Finally, note that it is possible for an iSNS server in the private
addressing domain behind a NAT boundary to exclusively support iSNS clients
that are operating in the global IP addressing domain.  If this is the case,
the administrator only needs to ensure that the appropriate mappings are
configured on the NAT gateways to allow the iSNS clients to initiate iSNSP
sessions to the iSNS server.  All registered addresses contained in the iSNS
server are thus public IP addresses for use outside the NAT boundary.  Care
should be taken to ensure that there are no iSNS clients querying the server
from inside the NAT boundary.

> 
> -- Section 3.8
> 
> The discussion of iSNS database synchronization needs to 
> mention distributed
> transactions as a way of doing this, although it would be ok 
> to discourage
> them on complexity/overhead/latency grounds.

The following has been added to the text:

For the purposes of this discussion, the specified backup mechanisms pertain
to interaction among different logical iSNS servers.  Note that it is
possible to create multiple physical iSNS servers to form a single logical
iSNS server cluster, and thus distribute iSNS transaction processing among
multiple physical servers.  However, a more detailed discussion of the
interactions between physical servers within a logical iSNS server cluster
is beyond the scope of this document. 

> 
>    A maximum of one backup iSNS server SHALL exist at any 
> individual IP
>    address.
> 
> Why?  At a minimum, this needs to be explained.

This statement has been modified as follows:

A maximum of one logical backup iSNS server SHALL exist at any individual IP
address, in order to avoid conflicts from multiple servers listening on the
same canonical TCP or UDP port number.

> 
>    Each backup server should note its relative precedence in 
> the active
>    server's list of backup servers.
> 
> That "should" needs to be at least "SHOULD" and it may need 
> to be a "MUST"
> as failure to do this could lead to more than one backup 
> server believing
> that it is primary after a failure of the active server.

Done.

> 
>    If a backup server establishes that it has lost connectivity to the
>    active server and other backup servers of higher 
> precedence, then it
>    shall assume that it is the active server.  The method of
>    determining whether connectivity has been lost is implementation-
>    specific.  One possible approach is to assume that if the backup
>    server does not receive iSNS hearbeat messages for a 
> period of time,
>    then connectivity to the active server has been lost.   
> Alternately,
>    the backup server may establish TCP connections to the 
> active server
>    and other backup servers, and loss of connectivity determined
>    through non-response to periodic echo messages (using iSNSP, SNMP,
>    or other protocols).
> 
> "shall" --> "SHOULD", but this is a disaster waiting to 
> happen, as different
> iSNS implementations will get this just different enough that 
> the result
> will be split-brain (more than one server believing it's 
> primary) on loss
> of communication.  This area is *hard* to get right (what's 
> needed here
> is an HA cluster coordination protocol) - an expedient way out for now
> may be to limit support to one primary and one backup.

Done.  Your comment is noted, and that is why I left the method for
determining election/re-election of the primary server up to the specific
implementation.  Yes, an HA cluster protocol would be ideal, but not
necessarily required in all situations.

> 
>    When a backup server becomes the active server, it shall assume all
>    active server responsibilities, including (if used) transmission of
>    the iSNS heartbeat message.
> 
> "shall" --> "SHALL", although this is probably editorial.

Done.

> 
> -- Section 5.1.1, 5.1.3, 5.2.1, and 5.2.3
> 
>    The following attributes are available to support iSCSI.  
> Attributes
>    indicated in the REQUIRED TO IMPLEMENT column MUST be supported by
>    an iSNS server used to support iSCSI. Attributes indicated in the
>    REQUIRED TO USE column MUST be supported by an iSCSI device that
>    elects to use the iSNS.
> 
> Suggest retitling the columns as "REQUIRED for Server" and 
> "REQUIRED for
> Client", and noting that the attributes required for a Client 
> will always
> be used in practice.  Similar comments apply to the other 3 
> requirements
> tables.

Done.

> 
>    All iSCSI user-specified and vendor-specified attributes are
>    optional to implement and use.
> 
> "optional" --> "OPTIONAL", and add corresponding versions of this to 
> the other 3 requirements tables (this is a recent IESG "hot button").

Done.  The statement was added for the other attribute table for iFCP.

> 
> -- Section 5.1.3 and 5.2.3
> 
> What is the difference between NOT USED and RESERVED?  A 
> possible guess is
> that NOT USED will never be used, whereas RESERVED is for 
> possible future
> use.  This needs to be explained, or substitute RESERVED for 
> "NOT USED".

Done - Func_ID values indicated as NOT USED have been combined with
RESERVED.
> 
> -- Section 6.1.1
> 
>    The iSNSP version described in this document is 0x0001.
> 
> Say that all other values are reserved.

Done.

> 
> -- Section 6.5
> 
> The use of "Multicast" at this juncture will be assumed to be 
> IP Multicast,
> and needs to be explained earlier.  Add an explanation of iSNS
> Multicast and Broadcast somewhere in Section 3 and reference it here.
> Need to explain which messages can be Multicast/Broadcast.

I've added a new section 3.9 to talk about transport protocols for iSNS.
I've also consolidated what formerly was in section 5.3 and 5.4 into this
section.  A reference to 3.9.3 was also added to section 6.5.

> 
> -- Section 6.6.5.3
> 
> Add a discussion of what happens if the iSNS database is 
> updated during
> a sequence of GetNext operations.  Is it possible to lose one's place
> if an object is deleted?  How is a client expected to cope with this?

The following text has been added to the end of section 6.6.5.3:

The iSNS client is responsible for ensuring that information acquired
through use of the DevGetNext message is accurate and up-to-date.  There is
no assurance that the iSNS database will not change between successive
DevGetNext request messages.  If the Message Key provided does not match an
existing database entry, then attributes for the next object key following
the Message Key provided SHALL be returned.  For example, an object entry
may have been deleted between successive DevGetNext messages.  This may
result in a DevGetNext request where the Message Key does not match an
existing object entry.  In this case, attributes for the next object stored
in the iSNS database are returned.
> 
> -- Section 7
> 
> This looks like it should be retitled to IANA Considerations, 
> with all of
> this stuff going into registries, and the section needs to be 
> expanded to
> include things like the BSD from Section 6.5.  Some of the material in
> the table in Section 7.1 may not be appropriate for an IANA registry,
> though.

A new IANA Considerations section has been inserted as section 9, as shown
below:

9. IANA Considerations
The well-known TCP and UDP port number for iSNS is 3205.
In order to maintain a registry of block storage protocols supported by
iSNSP, IANA MUST assign a 32-bit unsigned integer number for each protocol.
This number is stored in the iSNS database as the Entity Protocol.  The
initial set of values to be maintained by IANA for Entity Protocol is
indicated in the table in section 7.2.2.
IANA is responsible for maintaining the complete list of iSNS attributes.
This information MUST include for each iSNS attribute, its tag value, the
attribute's length, and the set of permissible registration and query keys
that can be used for that attribute.  The initial list of iSNS attributes to
be maintained by IANA is indicated in section 7.1.  
Finally, IANA is also responsible for assigning values to be used for the
Block Structure Descriptor for the Authentication Block (see section 6.5).


> 
> -- Section 7.2.1
> 
> 7.2.1   Entity Identifier (EID)
> 
>    The Entity Identifier (EID) is a variable-length field containing
>    user-readable UTF-8 text, and is terminated with at least one NULL
>    character. variable length identifier   This field uniquely
>    identifies each network entity registered in the iSNS server.
> 
> Does this need to be stringprep'ed?  "variable length 
> identifier" looks
> like it escaped from previous editing.  Check all other UTF-8 
> attributes
> for possible needs for stringprep.

Variable-length fields that are used as key attributes (i.e., EID, iSCSI
Name)
need to be stringprep-ed.  Those that are not key attributes are used as
descriptive fields, and so do not need to be normalized.  The following text
will be added to each variable-length field that is used as a primary key:

This attribute MUST be normalized according to the stringprep template
[STRINGPREP] before it is stored in the iSNS database.

Note that since we are now using the stringprep document generically, not
just
for iSCSI names, then I would suggest removing the iSCSI label for that
document.

> 
>    By convention, EIDs generated by the iSNS server begin with
>    the string "iSNS:".  iSNS clients MUST NOT generate and register
>    EIDs beginning with the string "iSNS:".
> 
> Replace "By convention" with a "MUST" requirement on server generation
> of EIDs.

Done.

> 
> -- Section 7.2.3
> 
>    This field contains the IP Address used to manage the 
> Network Entity
>    and all Storage Nodes contained therein.  The Management IP Address
>    is a 16-byte field that may contain either a 32-bit IPv4 or 128-bit
>    IPv6 address.  When this field contains an IPv4 value, the most
>    significant 12 bytes are set to 0x00.  When this field contains an
>    IPv6 value, the entire 16-byte field is used.  If the 
> network entity
>    is capable of being managed and this field is not set, then in-band
>    management through the IP address of one of the Portals of the
>    Network Entity is assumed.
> 
> What is this IP address used for?  Why is an IP address, as opposed to
> an IP address plus TCP or UDP port?

Both IP address and TCP/UDP Port are required to identify a Portal.  The
Portal object is therefore referenced by two attributes--its primary
key has two fields.  The IP address alone is insigificant--it must be
accompanied by the TCP/UDP Port Number to have any meaning in iSNS.

> 
> -- Section 7.2.7
> 
>    The Entity Index is a 4-byte integer value that uniquely identifies
>    each network entity registered in the iSNS server.  The 
> Entity Index
>    is assigned by the iSNS server during the initial 
> registration of an
>    Entity.  It can be used to represent a registered entity in
>    situations where the Entity Identifier is too long to be used.
> 
> Explain the requirements on "uniquely identifies", in particular rules
> about if/when an iSNS server can reuse an Entity Index value.
> Same comment applies to Portal Index (Section 7.3.7) and 
> iSCSI Node Index
> (Section 7.4.5).

The text for 7.2.7 has been modified as follows:

The Entity Index is a 4-byte integer value that uniquely identifies each
network entity registered in the iSNS server.  Upon initial registration of
an Entity, the iSNS server assigns an unused value for the Entity Index for
that Entity.  Each Entity in the iSNS database MUST be assigned a value for
the Entity Index that is not assigned to any other Entity.  The Entity Index
MAY be used to represent the Entity in situations when the Entity Identifier
is too long or otherwise inappropriate.

The 1st paragraph for 7.3.7 has been modified as follows:

The Portal Index is a 4-byte integer value that uniquely identifies each
portal registered in the iSNS database.  Upon initial registration of a
Portal, the iSNS server assigns an unused value for the Portal Index of that
Portal.  Each Portal in the iSNS database MUST be assigned a value for the
Portal Index that is not assigned to any other Portal.

The 1st paragraph for 7.4.5 has been modified as follows:

The iSCSI Node Index is a 4-byte integer value that uniquely identifies each
iSCSI node registered in the iSNS database.  Upon initial registration of
the iSCSI node, the iSNS server assigns an unused value for the iSCSI Node
Index.  Each iSCSI Node MUST be assigned a value for the iSCSI Node Index
that is not assigned to any other iSCSI Node.  

> 
> -- Section 7.4.7
> 
> Remove DH-CHAP value.

Done.

> 
> -- Section 7.5.3
> 
> Remove mFCP value.
> 
Done.

> -- Section 7.7.1
> 
>    This is a 4-byte field, and is used to provide a FC-4 type during a
>    FC-4 Type query.  The FC-4 types are consistent with the FC-4 Types
>    as defined in FC-PH.  Byte 0 contains the FC-4 type.  All other
>    bytes are reserved.
> 
> Update FC-PH reference as T11 is obsoleting FC-PH.

This reference has been replaced with a reference to FC-FS.

> 
> -- Section 7.9
> 
>    To avoid
>    misinterpreting proprietary attributes, it is RECOMMENDED that the
>    vendor's own OUI (Organizationally Unique Identifier) be placed in
>    the upper three bytes of the attribute field itself.  If the OUI is
>    not used, then some other unique marker recognizable by the vendor
>    SHOULD be used.
> 
> Should these be REQUIRED/MUST rather than RECOMMENDED/SHOULD? 
>  The second
> sentence is an invitation to problems, and needs to be rethought -
> Enterprise
> numbers (as used for MIBs) are a possibility, and there needs 
> to be a way
> to distinguish whether an OUI or something else is in this field.

The OUI will be REQUIRED.  The last sentence in the paragraph has been
deleted.

> 
> -- Section 7.11     Standards-Based Extensions
> 
>    These attributes are reserved for future work by other standards
>    bodies.
> 
> Which attributes are these?  I don't see any corresponding 
> entry in the
> table in Section 7.1.

Section 7.11 has been deleted.

> 
> -- Section 8.2
> 
>    If the iSNS server is used to distribute authorizations for
>    communications between iFCP and iSCSI peer devices, IPsec ESP with
>    null transform MUST be implemented, and non-null transform MAY be
>    implemented.  If a non-null transform is implemented, then the DES
>    encryption algorithm MUST NOT be used.

Done.

> 
> "SHOULD NOT be used" is sufficient for DES, also applies to next text:
> 
>    If the iSNS server is used to distribute security policy for iFCP
>    and iSCSI devices, then authentication, data integrity, and
>    confidentiality must be supported and used.  Where confidentiality
>    is desired or required, IPSec ESP with non-null transform SHOULD be
>    used, and the DES encryption algorithm MUST NOT be used.

Done.

> 
> "must" --> "MUST", and there are a number of other places in 
> this section
> where RFC 2119 words need to be in upper-case.

Done.

> 
>    Note that the
>    authentication block is used only for iSNS broadcast or multicast
>    messages, and SHOULD NOT be used in unicast iSNS messages.
> 
> "SHOULD NOT" --> "MUST NOT" here and in earlier discussion of 
> this block
> to avoid any need for recipients to deal with it in unicast messages.
> 
Done.

> -- Section 8.6
> 
>    When IPSec security is enabled, each iSNS client that is registered
>    in the iSNS database SHALL maintain at least one phase-1 and one
>    phase-2 security association with the iSNS server.  All iSNS
>    protocol messages between iSNS clients and the iSNS server SHALL be
>    protected by a phase-2 security association.
> 
> This prohibits discarding and recreating the phase 2 
> associations, e.g.,
> to deal with limited crypto resources.  If that was intended, explain
> why, as keeping the phase-1 ought to be sufficient to maintain the 
> security context.

"and one phase-2" has been deleted from the first sentence in 8.6.