[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [NSIS] I-D Action:draft-ietf-nsis-ext-02.txt
Hello
I have read the -02 ext-draft. Predominantly it looks good to me. Only a
couple of small issues and a bunch of possible typos caught my eye.
The first issue is with the use of "MRMs" on page 6. The the abbreviation
MRM (or even the concept of different message routing methods) is not
explained anywhere earlier in the text. My suggestion is that, either
remove the "MRMs" and use rest of the bullet as is, or somehow change it
so that Message Routing Method is spelled out. Perhaps something like:
"Initial focus on path-coupled signaling: GIST transports messages towards
an identified unicast data flow destination based on the signaling
application request. This is called the Path Coupled Message Routing
Method (PC MRM). The framework also supports a "Loose-End" message routing
method (i.e. LE MRM) used to discover GIST nodes with particular
properties in the direction of a given address, for example the NAT/FW
NSLP uses this method to discover a NAT along the upstream data path. GIST
does not directly support path-decoupled signaling, e.g., QoS signaling to
a bandwidth broker or other off-path resource manager."
The second issue I have is with almost the whole section 8.6. The section
does point out many central issues in NSLP design and implementation, but
it is extremely vague. Many complicated concepts are only briefly
mentioned or hinted at. Some of the more vague points might cause more
confusion, than shed light. Finding a suitable level of abstraction for
the descriptions is admittedly very difficult. To create any new, more
than trivial, NSLP, I think one would have to understand large parts of
the GIST spec, like the API, the MRMs, the MRI and flow identification and
GIST peering.
I would change at least the third to last bullet, e.g. "Source IP address:
...". It could say something more like:
"MRI processing: It is sometimes challenging to find out at the NSLP, what
the source IP address in the MRI should be, especially when a node has
multiple interfaces. Moreover, the role of the source IP address may
differ if the node processing an NSLP message is the source of the
signaling flow, or an intermediate node on the signaling path. A node
processing a received NSLP message also needs to take into account the MRI
flow direction. So in many cases an NSLP application needs to be aware of
its position and role on the signaling path and have some (,external to
GIST,) means of finding out local IP addresses that are suitable for use
in the signaling."
Thanks to Lauri and Nuutti for their help on the new text.
The other possible errors or typos are less important, so Ill just list
them below:
Page 5, second paragraph: "This is achieved by routing signaling
massages.." refers to multiple messages, but later in the sentence and
paragraph a single message is described. I suggest using message or
messages consistently throughout the paragraph.
Page 7, second line: "request also" --> "also request"
Page 8, third paragraph: "requested by the new MA." Should this be
"requested by the new flow." or "required by the potential new MA."?
Page 8, last paragraph + page 9 first: The beginning of this paragraph is
one extremely long sentence. It looks like it could benefit from being two
or three separate ones. "Concerns were raised" clashes with "as well as
discovery of", at least in my ear. Could it be written as:
"Late in the development of GIST serious concerns were raised in the IETF
about the security risks and performance implications of extensive usage
of the RAO [I-D.rahman-rtg-router-alert-dangerous]. It was also discovered
that several existing implementations of RAO were inconsistent with the
standards and would not support the NSIS usage."
Page 9, fourth paragraph: "NSIS state is held both at the signaling
application layer and in the transport layer.." I would add "signaling"
before "transport layer", since it is used before the "application". Then
it becomes clearer, that the ntlp layer is the referred transport layer.
Page 10, last paragraph: should the "support of" bits be "support for"?
Page 12, fourth paragraph: "signalled" --> "signaled" (or change two other
signaled in the document to signalled"?)
Page 16, second bullet: The DCCP draft is mentioned, but not the SCTP one.
The SCTP draft is not even referenced in this document.
Page 17: is "interception scheme" the same as "interception class
mechanism" or "interception mechanism". Could one expression be used
consistently through the text describing interception schemes and classes?
Page 21, first paragraph: "Yet, on the other hand" --> "Yet" or "On the
other hand"
Page 21, second bullet: "than can from GIST" --> "that can arrive from
GIST"
Page 21, last bullet: "defines currently" --> "currently defines".
Page 22, bullet at top of page: "and prevent" --> "and to prevent"
Several places(page 6 and 15) in the text use the expression "in future".
I am not certain, but should it not be "in the future" in these contexts?
br,
Teemu
--
Teemu Huovila