[Gen-art] Gen-ART review of draft-ietf-nsis-ntlp-15.txt

[Suresh Krishnan <[e-mail]>]

I am the assigned Gen-ART reviewer for
draft-ietf-nsis-ntlp-15.txt

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments
you may receive.

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.


Cheers
Suresh


_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art