Document: draft-ietf-nsis-ntlp-15.txt Reviewer: Suresh Krishnan [suresh.krishnan@ericsson.com] Review Date: 3/25/2008 IESG Telechat date: 3/27/2008 Summary: This draft is almost ready for publication but I have a few comments. Substantial =========== * Section 3.2 "Connection mode (C-mode): used for larger messages or where fast signalling application state setup in the face of packet loss is desirable, or where channel security is required." I do not see how connection oriented mode can be faster than simply sending a datagram packet and I do not see how it will help packet loss due to congestion either. Is it possible to expand a little bit on these claims or to reword this. * Section 6.1 " if (routing state can be created before receiving a Confirm) then // we should already have Responding-SM for it, // which would handle this message discard message send "No Routing State" error message " I do not understand the point of this rule. Why is a "No Routing State" error message sent for this? * Section 7.2.1 : Querying node outside the NAT "The Querying node MUST check the source address in the IP header with the NLI in the Response, and when it finds a mismatch it MUST terminate the handshake." Does it need to inform the responding node with an error message? State may have been created on the responder that needs to be cleaned up. * No reference to the IPv6 base specification (RFC2460) (especially since the draft refers to the routing and destination option extension headers) Minor ===== * Section 3.3 The following text is present in the definition of MRMs "Specifically, the MRI always includes a flag to distinguish between the two directions that signalling messages can take, denoted 'upstream' and 'downstream'." but the actual definition of the MRI in section 5.8.1.1 does not contain this flag. * The MRI definition in section 5.8.1.1 does not contain a flag specifying if translation is required. * Section 4.1.2 Some of the text in the Reliability section is hanging and it is not clear if it applies only when the flag is 'true'. e.g. The following text "If there is a chance that the message was not delivered (e.g. in the case of a transport layer error), an error MUST be indicated to the local signalling application identifying the routing information for the message in question." may be seen as universally applicable. I think it would be better to use a bulleted list for this. * Section 4.1.2 It is unclear what "better performance" means in the context of GIST as described in the following sentence. "A GIST implementation MAY deliver messages with better performance than strictly required by the attributes given." e.g. The way I see it, not using security gives me better performance, but I doubt that this is what the authors intended to convey. * Section 4.3.1 "Any message with a GIST hop count of zero MUST be rejected with a "Hop Limit Exceeded" error message (Appendix A.4.4.2); note that a correct GIST implementation will never send such a message." This sentence is ambiguous since it is not clear WHICH message a correct implementation would never send (the 0 hop count message or the corresponding error message). I recommend rephrasing to "Any message with a GIST hop count of zero MUST be rejected with a "Hop Limit Exceeded" error message (Appendix A.4.4.2). Note that a correct GIST implementation will never send a message with a GIST hop count of zero." * Section 4.3.3 "Although the GIST hop count is only intended to control message looping at the GIST level, the GIST API (Appendix B) provides the incoming hop count to the NSLPs, which can preserve it on outgoing messages as they are forwarded further along the path." It is unclear if the "incoming hop count" mentioned in the above sentence refers to the hop count before the receive side processing (i.e. X) or after (i.e. X-1). I would assume the latter but this needs to be clarified. * Section 4.3.4 "1. A message contains an RAO value which is relevant to NSIS,..." How would an implementation make this determination? Is it planned to set aside a range of RAO values for NSIS? * Section 4.4.3 "4. Both elements of the NLI object match" When will this be reached? Won't this be handled by the previous fork ("The exact match")? Meta question ============= * The datagram and header format pictures (Appendix A) are separated from their actual definition. Is there a particular reason for this? I, for one, would have preferred it if they were together * The protocol described in the document is fairly complex and requires significant amount of code change on routers. Has there been any implementation commitment from any major router vendors? Editorial ========= * Section 5.3.2.2 Replace "It is RECOMMENDED that a node bases" with "It is RECOMMENDED that a node base" Replace "any extension headers other than routing options or destination options" with "any extension headers other than routing or destination options" * References I think at least [27] and maybe [28] need to be normative references. Maybe you have heard this comment before, but symbolic references would have made this document much easier to read, since I had to jump to the references section every time I saw a reference. * Informative References draft-pashalidis-nsis-gimps-nattraversal-05 has expired. This means that the references to this document have to be cleaned up and new text added instead.