Subject: iSNS: Responses to David Black Technical Comments

From: Joshua Tseng <[email-masked]>
Date: Sat, 19 Oct 2002 23:19:28 -0700

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

Josh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 14, 2002 2:25 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> 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.

---

From: [email-masked]
Date: Wed, 23 Oct 2002 20:48:10 -0400

Josh,

Most of the responses are fine, but there's one major issue
(iSNS Backup servers) and several minor issues, one of which is
unfortunately new and affects IP address formats.  Thanks, --David

-- iSNS Backup Servers --

> >    active server and other backup servers of higher precedence, then it
> >    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
> > "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

I remain concerned that the text here not only allows, but may encourage
building iSNS backup in a fashion that will fail split-brain with
potentially disastrous consequences.  On further reading, the thing to
do may be to modify the following sentence:

   Therefore, it is beyond the scope of this specification to
   facilitate more than a basic interoperability among failover
   mechanisms.

to add specifics about what is and is not specified for interoperability.
What is specified is:
- Client behavior and protocol interaction in the presence of multiple
	iSNS servers, some of which are Backup iSNS servers.
- Required failover behaviors of the collection of iSNS servers that
	includes Active and Backup servers.
What is not specified is:
- Complete functional failover requirements on each iSNS server and the
	protocols needed for a collection of iSNS servers to realize the
	required failover behaviors in an interoperable fashion.

While it's missing some aspects of interoperability, I think getting the
client foundation in place that allows failover to a backup server is
important enough to be worth including, even at the expense of not
mixing different iSNS implementations in a collection of Active/Backup
servers.

-- Minor Issues --

> > 
> > -- Section 6.6.5.3
> > 
> > Add a discussion of what happens if the iSNS database is updated during

Added text snipped - it's ok.  

Unless I missed it somewhere a sentence is needed
saying that the iSNS database MUST have an implicit internal linear
order of entries.  This is needed to give a meaning to words like
"after", "next" and "following" in this section.  It also might be
good to say than an iSNS database SHOULD NOT be reorganized with
respect to that implied order as a consequence of insertions and
deletions (i.e., relative order of entries that remain in the
database SHOULD be preserved so that GetNext encounters generally
reasonable behavior).
 
> > -- 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
> A new IANA Considerations section has been inserted as section 9, as shown

Good start, but instructions to IANA for handling additions are missing.
Please see RFC 2434 for information on what needs to be in this section.

> > Does this need to be stringprep'ed?  "variable length identifier" looks
> > like it escaped from previous editing.  Check all other UTF-8 attributes
Name)
just
> for iSCSI names, then I would suggest removing the iSCSI label for that

Ok, let's consider that a late WG Last Call comment against the iSCSI
stringprep draft - please contact Mark Bakke directly about revising it.

> > -- Section 7.2.3
> > 
> >    This field contains the IP Address used to manage the Network Entity
> >    IPv6 value, the entire 16-byte field is used.  If the network entity

But this is the Management IP address and I don't see a Management IP Port -
did I miss something?  The phrases "used to manage" and "capable of being
managed" need to be defined - if this means SNMP, say so.

Also, I don't see any external way of indicating whether the address is
IPv4 or IPv6, and hence I believe Section 2.5.4 of RFC 2373 applies to
IP addresses in iSNS - unfortunately, the convention that's currently
being used for address formats implies that all IPv4 addresses in iSNS
are for IPv6-capable nodes, which is probably not what was intended
(sorry for the late catch on this one, but better now than to have one
of the ADs find it).

> >    each network entity registered in the iSNS server.  The Entity Index
> >    is assigned by the iSNS server during the initial registration of an
> > Same comment applies to Portal Index (Section 7.3.7) and iSCSI Node
Index
> is too long or otherwise inappropriate.

That takes care of assignment, what about reuse?  Short-term reuse SHOULD
NOT be done, as it's an invitation to confusion in places where the Entity
Index has been used.  Similarly for 7.3.7 and 7.4.5.

---

From: Joshua Tseng <[email-masked]>
Date: Sat, 26 Oct 2002 17:31:25 -0700

David,

Please see my responses to your iSNS technical comments below.

I will submit a revision -14 within the next day or so.  We can
then continue the last call comment and revision process against
the revision -14 draft.

Josh

> Sent: Wednesday, October 23, 2002 5:48 PM
> Subject: RE: iSNS: Responses to David Black Technical Comments
> 
> 
> Josh,
> 
<<text removed>>
> mixing different iSNS implementations in a collection of Active/Backup

The first two paragraphs of 3.8 have been replaced with the following:

This section offers a broad framework for implementation and deployment of
iSNS backup servers.  Server failover and recovery are topics of continuing
research and adequate resolution of issues such as split brain and primary
server selection is dependent on the specific implementation requirements
and deployment needs.  The failover mechanisms discussed in this document
focuses on the interaction between iSNS clients and iSNS servers.
Specifically, what is covered in this document includes the following:

-  iSNS client behavior and the iSNS protocol interaction between the client
and multiple iSNS servers, some of which are backup servers.

-  Required failover behaviors of the collection of iSNS servers that
includes active and backup servers.

However, note that this document does not specify the complete functional
failover requirements of each iSNS server.  In particular, it does not
specify the complete set of protocol interactions among the iSNS servers
that are required to achieve stable failover operation in an interoperable
manner.

> database SHOULD be preserved so that GetNext encounters generally

The following paragraph has been added to the beginning of seciton 4.7:

4.7 iSNS Database Model

Each object type in the iSNS database MUST have an implicit internal linear
ordering based on the key(s) for that object type.  This ordering provides
the ability to respond to DevGetNext queries (see section 6.6.5.3).  The
ordering of objects in the iSNS database SHOULD NOT be changed with respect
to that implied ordering, as a consequence of object insertions and
deletions.  That is, the relative order of surviving object entries in the
iSNS database SHOULD be preserved so that the DevGetNext message encounters
generally reasonable behavior.

> Please see RFC 2434 for information on what needs to be in 

Section 9 has been expanded to include the following text:

9. IANA Considerations

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.  Additional values for new block
storage protocols to be supported by iSNS SHALL be assigned by IANA on a
First Come, First Served basis.

IANA is responsible for maintaining the complete list of iSNS attributes
described in section 7.  This information MUST include for each iSNS
attribute, its tag value, the attribute 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.

Additions of new attributes to the iSNS attribute list that use tag values
currently indicated as RESERVED in section 7.1 SHALL require proper
documentation.  This documentation SHALL include as a minimum, the new
attribute tag value, attribute length, and the set of permissible
registration and query keys that can be used for the new attribute.
Possible forms of documentation include, but are not limited to, RFCs or the
product of another standards body. Other requests may also be accepted,
under the advice of a "designated expert". (Contact the IANA for the contact
information of the current expert.)

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 15 of [RFC2608] describes the process for allocation of new BSD
values.

> > descriptive fields, and so do not need to be normalized.  
> The following
> text

iSCSI Names are normalized according to Mark's draft.  EIDs are
normalized according to the nameprep draft (draft-ietf-idn-nameprep-11.txt).

> (sorry for the late catch on this one, but better now than to have one

The text for section 7.2.3 describing the management port has been revised
as follows:

7.2.3 Management IP Address

This field contains the IP Address used to manage the Network Entity and all
Storage Nodes contained therein through SNMP [RFC1157] [iSNSMIB].  Some
implementations MAY also use this IP address to support vendor-specific
proprietary management protocols.  The Management IP Address is a 16-byte
field that may contain a IPv4 or IPv6 address.  When this field contains an
IPv4 value, it is stored as an IPv4-mapped IPv6 address.  That is, the most
significant 10 bytes are set to 0x00, with the next two bytes set to 0xFFFF
[RFC2373].  When this field contains an IPv6 value, the entire 16-byte field
is used.  If this field is not set, then in-band management through the IP
address of one of the Portals of the Network Entity is assumed.

Similarly, the text for section 7.3.1 describing the Portal IP address has
been
revised as follows:

7.3.1 Portal IP-Address

This attribute is the IP address of the Portal through which a Storage Node
can transmit and receive storage data.  The Portal IP Address is a 16-byte
field that may contain an IPv4 or IPv6 address.  When this field contains an
IPv4 address, it is stored as an IPv4-mapped IPv6 address.  That is, the
most significant 10 bytes are set to 0x00, with the next 2 bytes set to
0xFFFF [RFC2373].  When this field contains an IPv6 address, the entire
16-byte field is used.  The Portal IP Address along with the Portal TCP/UDP
Port number (see 7.3.2 below) uniquely identifies a Portal.

> iSCSI Node
> > 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

The following sentence has been added to section 7.2.7:

"Furthermore, Entity Index values for recently deregistered Network Entities
SHOULD NOT be reused in the short term."

The following sentence has been added to section 7.3.7:

"Furthermore, Portal Index values for recently deregistered Portals SHOULD
NOT be reused in the short term."

The following sentence has been added to section 7.4.5

"Furthermore, iSCSI Node Index values for recently deregistered iSCSI Nodes
SHOULD NOT be reused in the short term."