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

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.

Just a nit:

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

This has been updated by RFC 3513.

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)/