Re: 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