Subject: iSNS: Last Call comments

From: Joshua Tseng <[email-masked]>
Date: Sun, 13 Oct 2002 09:51:44 -0700

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.

---

From: Joshua Tseng <[email-masked]>
Date: Tue, 22 Oct 2002 18:06:42 -0700

Hi Folks,

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

Regards,
Josh

> -----Original Message-----
> From: Joshua Tseng [mailto:[email-masked]]
> Sent: Sunday, October 13, 2002 9:52 AM
> To: [email-masked]
> Cc: 'Elizabeth Rodriguez'
> Subject: iSNS: Last Call comments
> 
> 
> Hi Folks,
> 

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.

> of other objects other than the next object, can be returned 

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.

> 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

> length is 4 bytes?  Recommend that the registration period 

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

> 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

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

> 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.

> 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.