RE: iSNS: Last Call comments

[Joshua Tseng <jtseng@NishanSystems.com>]

Hi Folks,

Here is the resolution of the technical comments that I posted
for iSNS.

Regards,
Josh

> -----Original Message-----
> From: Joshua Tseng [mailto:jtseng@NishanSystems.com]
> Sent: Sunday, October 13, 2002 9:52 AM
> To: ips@ece.cmu.edu
> Cc: 'Elizabeth Rodriguez'
> Subject: iSNS: Last Call comments
> 
> 
> Hi Folks,
> 
> Here is a summary of technical last call comments against the 
> iSNS spec -13:
> 
> 1)  There needs to be a way to scope the DevGetNext message.  
> Recommend
> that non-zero-length TLV's may be included as the first 
> operating attributes
> of the DevGetNext message.  They would be used to scope the DevGetNext
> message.  Zero-length TLV's that follow would specify the attributes
> of the next object that need to be returned in the response 
> message.  If
> there are no non-zero-length TLV attributes, then the 
> DevGetNext message
> is unscoped, as specified in previous iSNS spec revisions.

The following text has been added to section 6.6.5.3 to allow scoping
of DevGetNext messages:

Non-zero-length TLV attributes in the Operating Attributes are used to scope
the DevGetNext message.  Only the next object with attribute values that
match the non-zero-length TLV attributes SHALL be returned in the DevGetNext
response message.

Zero-length TLV attributes MUST be listed after non-zero-length attributes
in the operating attributes of the DevGetNext request message.  Zero-length
TLV attributes specify the attributes of the next object that are to be
returned in the DevGetNext response message.

> 
> Also for the DevGetNext message, it is ambiguous as to 
> whether attributes
> of other objects other than the next object, can be returned 
> in the message.

The following text has been added to section 6.6.5.3 to remove this
ambiguity.  Only attributes of the object specified by the Message Key
may be listed in the operating attributes.

The Operating Attributes can be used specify the scope of the DevGetNext
request, and specify the attributes of the next object that are to be
returned in the DevGetNext response message.  All operating attributes MUST
be attributes of the object type identified by the Message Key.  For
example, if the Message Key is an Entity_ID attribute, then the operating
attributes MUST NOT contain attributes of Portals.

> 
> 2)  In order to better integrate with SNMP, we need a method to query
> for the next available index attribute.  Recommend a virtual 
> attribute for
> Entity, Portal, and iSCSI Node that always returns the value 
> of the next
> available "Index" attribute for that object.  This virtual attribute
> would only be used for queries, and it would be an error to attempt to
> register a value for this attribute.

The following "virtual" attributes have been added with the corresponding
tag values:

Entity Next Index         8
Portal Next Index        24
iSCSI Node Next Index    38

> 
> 3)  Why is the registration period only 2 bytes, when the attribute
> length is 4 bytes?  Recommend that the registration period 
> use all 4 bytes,
> not just 2 bytes. 

The spec has been changed so that all four bytes are used for the
Registration Period.

> 
> 5)  Spec needs to say that the iSNS server may reject iSNS messages
> with incompatible message version numbers in the iSNS message header.

The following sentence has been added to section 6.1.1.

The iSNS server MAY reject messages for iSNSP version numbers that it does
not support.

> 
> 6)  Section 7.l2.5 should clarify that "Protocol Version" refers to
> block storage protocols.

The first sentence of 7.2.5 now refers to "block storage protocols".

> 
> 7)  Clarify that if a query requests an attribute for which the iSNS
> server has no value, then the server SHALL not return the requested
> attribute in the query response.  Such query and response messages
> SHALL NOT be considered to be in error.

The following text has been added to section 6.6.5.2:

If a DevAttrQry message requests an attribute for which the iSNS server has
no value, then the server SHALL NOT return the requested attribute in the
query response.  Such query and response messages SHALL NOT be considered to
be in error.

> 
> 8)  The format of the DevAttrRegRsp message in section 6.7.5.1 seems
> inconsistent.  The message key attributes seems to contain the same
> thing as the operating attributes.  The message key should contain the
> same attribute as the original registration message.
> 

The second paragraph of section 6.7.5.1 has been replaced with the
following:

The Message Key in the DevAttrRegRsp message SHALL return the Message Key in
the original registration message.  If the iSNS server assigned the Entity
Identifier for a network entity, then the Message Key Attribute field SHALL
contain the assigned Entity Identifier.