Internet Storage Name Service (iSNS)
draft-ietf-ips-isns-22

[Ballot comment]
Section 1.1
  All unused fields and bitmaps, including those that are RESERVED,
  SHOULD be set to zero.
Would probably be better to say
  All unused fields and bitmaps, including those that are RESERVED,
  SHOULD be set to zero when sending and SHOULD be ignored when
  received.

On page 16:
  The above diagram illustrates a second example of how iSNS records
  can be shared. This method uses an SNMP-based management station to
  manually download the desired record for "dev C", and then directly
  upload it to the local iSNS server. Once the record is transferred
  to the local iSNS server in Network A, "dev C" becomes visible and
  accessible (provided firewall boundaries can be negotiated) to other
  devices in Network A.
I understand what I think is intended. But the language used is pretty
foreign in SNMP terms. I wonder if the following would be better:
  The above diagram illustrates a second example of how iSNS records
  can be shared. This method uses an SNMP-based management station to
  (manually) retrieve (GET) the desired record for "dev C", and then
  directly store (SET) it on the local iSNS server. Once the record
  is transferred to the local iSNS server in Network A, "dev C"
  becomes visible and accessible (provided firewall boundaries can
  be negotiated) to other devices in Network A.

Section 2.8 has:
  determined through non-response to periodic echo messages (using
  iSNSP, SNMP, or other protocols).
But SNMP does not have something like an "echo message". In the SNMP
case, one would poll some MIB object to see if a response is still
received. Not that I cannot live with the text, but it sounds weird.

Page 28 shows for requests:
  RESERVED                                0x0200-0x8000
and for responses
  RESERVED                                0x8200-0xFFFF
So it seems to me that if request 0x8000 ever gets defined, then
you cannot define a logical answer!? In fact, scect 5.1.2 states
that if the leading bit is set that it is a response, so 0x8000
could never be a request.
Just a theoretical and not a practical issue I guess. Anyway,
Probably for requests, one should also resever value 0x0000 and
instead of 0x0200-0x8000 one should do 0200-0x0fff.
For responses, value 0x8000 should probably also be reserved.
Same for requests/responses on page 32.

Section 5.1.4.
  Since the FLAGS field is 16 bits long, it feels strange that
  the bit positions listed are 16-32. I can see/understand what
  is meant. But still? I think I would list them as position
  0-15.

Sect 5.6.5.13 page 56
  Would it not be usefull to say something about the size of the
  various fields? Or are the TLV fields, I don't get that impression.

Incorrect Author(s) for
  [RFC3411]  M. MacFaden, et al., An Architecture for Describing
              Simple Network Management Protocol (SNMP) Management
              Frameworks, RFC 3411, December 2002
But RFC-Editor will catch that I guess

Page 104 has:
  |                          |(or SNMP trap)    |                  |
I would rather call that SNMP notifiation.
Occurs a few more times on following pages.

I wonder of it is wise that IPv4 addresses are sometimes represented
as an IPv4-mapped IPv6 address (as per RFC2373), so 16 bytes with 10
leading zeroes, 0xFFFF and the IPv4 address.
At other times and IP v4 address is represented in 16 bytes with 12
leading zeroes and then the IPv4 address.

[Ballot comment]
Section 1.1
  All unused fields and bitmaps, including those that are RESERVED,
  SHOULD be set to zero.
Would probably be better to say
  All unused fields and bitmaps, including those that are RESERVED,
  SHOULD be set to zero when sending and SHOULD be ignored when
  received.

On page 16:
  The above diagram illustrates a second example of how iSNS records
  can be shared. This method uses an SNMP-based management station to
  manually download the desired record for "dev C", and then directly
  upload it to the local iSNS server. Once the record is transferred
  to the local iSNS server in Network A, "dev C" becomes visible and
  accessible (provided firewall boundaries can be negotiated) to other
  devices in Network A.
I understand what I think is intended. But the language used is pretty
foreign in SNMP terms. I wonder if the following would be better:
  The above diagram illustrates a second example of how iSNS records
  can be shared. This method uses an SNMP-based management station to
  (manually) retrieve (GET) the desired record for "dev C", and then
  directly store (SET) it on the local iSNS server. Once the record
  is transferred to the local iSNS server in Network A, "dev C"
  becomes visible and accessible (provided firewall boundaries can
  be negotiated) to other devices in Network A.

Section 2.8 has:
  determined through non-response to periodic echo messages (using
  iSNSP, SNMP, or other protocols).
But SNMP does not have something like an "echo message". In the SNMP
case, one would poll some MIB object to see if a response is still
received. Not that I cannot live with the text, but it sounds weird.

Page 28 shows for requests:
  RESERVED                                0x0200-0x8000
and for responses
  RESERVED                                0x8200-0xFFFF
So it seems to me that if request 0x8000 ever gets defined, then
you cannot define a logical answer!? In fact, scect 5.1.2 states
that if the leading bit is set that it is a response, so 0x8000
could never be a request.
Just a theoretical and not a practical issue I guess. Anyway,
Probably for requests, one should also resever value 0x0000 and
instead of 0x0200-0x8000 one should do 0200-0x0fff.
For responses, value 0x8000 should probably also be reserved.
Same for requests/responses on page 32.

Section 5.1.4.
  Since the FLAGS field is 16 bits long, it feels strange that
  the bit positions listed are 16-32. I can see/understand what
  is meant. But still? I think I would list them as position
  0-15.

Sect 5.6.5.13 page 56
  Would it not be usefull to say something about the size of the
  various fields? Or are the TLV fields, I don't get that impression.

Incorrect Author(s) for
  [RFC3411]  M. MacFaden, et al., An Architecture for Describing
              Simple Network Management Protocol (SNMP) Management
              Frameworks, RFC 3411, December 2002
But RFC-Editor will catch that I guess

Page 104 has:
  |                          |(or SNMP trap)    |                  |
I would rather call that SNMP notifiation.
Occurs a few more times on following pages.

I wonder of it is wise that IPv4 addresses are sometimes represented
as an IPv4-mapped IPv6 address (as per RFC2373), so 16 bytes with 10
leading zeroes, 0xFFFF and the IPv4 address.
At other times and IP v4 address is represented in 16 bytes with 12
leading zeroes and then the IPv4 address.

they are represented in a 16 byte field with 12 leading

[Ballot comment]
Section 1.1
  All unused fields and bitmaps, including those that are RESERVED,
  SHOULD be set to zero.
Would probably be better to say
  All unused fields and bitmaps, including those that are RESERVED,
  SHOULD be set to zero when sending and SHOULD be ignored when
  received.

On page 16:
  The above diagram illustrates a second example of how iSNS records
  can be shared. This method uses an SNMP-based management station to
  manually download the desired record for "dev C", and then directly
  upload it to the local iSNS server. Once the record is transferred
  to the local iSNS server in Network A, "dev C" becomes visible and
  accessible (provided firewall boundaries can be negotiated) to other
  devices in Network A.
I understand what I think is intended. But the language used is pretty
foreign in SNMP terms. I wonder if the following would be better:
  The above diagram illustrates a second example of how iSNS records
  can be shared. This method uses an SNMP-based management station to
  (manually) retrieve (GET) the desired record for "dev C", and then
  directly store (SET) it on the local iSNS server. Once the record
  is transferred to the local iSNS server in Network A, "dev C"
  becomes visible and accessible (provided firewall boundaries can
  be negotiated) to other devices in Network A.

Section 2.8 has:
  determined through non-response to periodic echo messages (using
  iSNSP, SNMP, or other protocols).
But SNMP does not have something like an "echo message". In the SNMP
case, one would poll some MIB object to see if a response is still
received. Not that I cannot live with the text, but it sounds weird.

[Ballot discuss]
Page 20 has this text:
  SNMP uses an Object Identifier (OID) for object identification.  The
  size of each OID is restricted to a maximum of 128 characters or
  less.  Both the iSCSI and iFCP protocol contain identifiers, such as
  the iSCSI Name, that are greater the 128 characters in length.  In
And it is not correct to claim/suggest that OIDs exist of "characters".
Better text would be:
  SNMP uses an Object Identifier (OID) for object identification.  The
  size of each OID is restricted to a maximum of 128 sub-identifiers or
  less.  Both the iSCSI and iFCP protocol contain identifiers, such as
  the iSCSI Name, that are greater the 128 characters in length. Using
  such Names as an index would result in more that 128 sub-identifiers
  per OID. In

Could be addressed with an RFC-Editor note.

I need to do some more checking on the doc. Hope to get to it later today
(Thur 20th of Nov). Will update this text when I am done.

[Ballot comment]
Just a nit:

  [RFC2373]  Hinden, R., IP Version 6 Addressing Architecture,
              RFC2373, July 1998

This has been updated by RFC 3513.

[Ballot discuss]
Section 5.5 says:
 
    ... this field contains the binary ASN.1 encoding of output
    values from the DSA with SHA-1 signature calculation.

This is not sufficient detail to write interoperable code.  I suggest a normative reference to RFC 279, section 2.2.2.  Also, references to DSA and SHA-1 seem desirable.  The  selction of these algorithms imposes some requirements on the certificats associated with the validation of the signatures.  These are not discussed in the certificate-related sections.

Why does this document reference X.509 instead of RFC 3280?  What feature of X.509 that is not supported in RFC 3280 is needed by this protocol?  If none, please reference RFC 3280.

Further, there are several entities that might have certificates, but no guidance is provided about the proper way to populate the subject field and the subjectAltName extension in the certificates.  Without this guidance, how does the certificate validator know that the certificate is appropriate for this use?

[Ballot comment]
Please delete the last paragraph of the Abstract.

Section 1.1 says:
  iSNS refers to the framework consisting of the storage network model
  and associated services.
This begs for a reference.  Does an approriate RFC exist?

In section 5.5, 3rd parahraph:
  s/X.509 certificate authority/X.509 Certification Authority (CA)/

[Ballot discuss]
Section 5.5:

Do you really want an 8-byte field for an integer number of seconds?

More seriously -- the description of the authentication block is inadequate to permit implementation.  It says "if a PKI is available...", but doesn't say what to do if a PKI is not available.  I *think* that what you mean is "calculate the authentication block as described in RFC 2608 9.2.2", but even that leaves unclear exactly what to feed into SHA-1.