iSNS: Last Call comments

[Joshua Tseng <jtseng@NishanSystems.com>]

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.

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.

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.

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. 

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

6)  Section 7.l2.5 should clarify that "Protocol Version" 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.

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.