Internet Storage Name Service (iSNS)
Note: This ballot was opened for revision 22 and is now closed.
(Allison Mankin) Yes
(Harald Alvestrand) No Objection
(Steven Bellovin) (was Discuss) No Objection
(Margaret Cullen) No Objection
Comment (2003-11-19 for -** No value found for 'p.get_dochistory.rev' **)
Just a nit: [RFC2373] Hinden, R., IP Version 6 Addressing Architecture, RFC2373, July 1998 This has been updated by RFC 3513.
(Bill Fenner) No Objection
(Ned Freed) No Objection
(Ted Hardie) No Objection
(Russ Housley) (was Discuss, No Objection) No Objection
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)/
(Thomas Narten) No Objection
(Jon Peterson) No Objection
(Bert Wijnen) (was Discuss) No Objection
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 18.104.22.168 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.