Re: WGLC for Using and Extending the NSIS Protocol Family (draft-ietf-nsis-ext-02)

Read the draft, comments below.

Overall, there are some issues that I feel should be resolved in the  
draft (see comments below). Also note that I skipped the parts that I  
am not familiar with, i.e. the Qos and NAT/FW NSLP parts of the draft.


General:

It seems to me that there are various terms used when talking about  
NSIS related entities, for example:

For the NSIS framework as a whole, we have: "NSIS", "NSIS suite",  
"NSIS protocol suite", "protocol suite",
"NSIS framework", "NSIS protocols"

For the signaling application layer, we have : "signaling layer",  
"application layer", "signaling application
layer", "NSLP layer", "service layer"

And for the transport layer, we have: "transport layer", "NTLP (GIST)  
layer", "GIST layer"

Finding some coherency between the three separate entities might be a  
good idea, as people new to the NSIS
world may not be able to instantly recognize varied terms relating to  
the same entity.

Other things:

Page 4,5:

Second paragraph has a long sentence: "While GIST is only concerned  
with transporting NSLP messages hop-by-hop
between pairs of signalling nodes, the end-to-end signaling  
functionality is provided by the NSLP protocols if
needed - not all NSLP protocols need to perform end-to-end signaling,  
even the current protocols have features
to confine the signaling to a limited path."

also, "Two NSLP protocols are currently standardized: ..." -> "Two  
NSLP applications are currently being
standardized ..."?

Page 5, second paragraph:

The paragraph first talks about "NSIS capable nodes", but then drops  
the capable later on. Should this be
added in to make it clear that we are still talking about the NSIS  
capable nodes, or is it clear without the
distinction?

Page 5, third paragraph:

"Unlike RSVP, signaling is normally ..." -> "Unlike RSVP, NSIS  
signaling is normally ..."?

Page 6, chapter 3, first paragraph:

"Applications can indicate the desired reliability, ..."

Should that use "transport attributes" instead of "reliability",  
something like:

"Applications can indicate the desired transport attributes for the  
signaling flow, which causes GIST to
select the appropriate transport protocol(s) for the flow. By default,  
GIST specifies UDP for unreliable, TCP
for reliable and TLS on top of TCP for secure (and reliable) signaling  
flows."

Page 8, second paragraph:

"When an NSLP application wants to send a message to its next  
peer ..." -> "When an NSLP application wants to
send a message towards a flow endpoint"?

Page 9, second paragraph:

s/recognised/recognized/ (whereas other places there are  
"standardized" "authorized" and so on)

Page 10, bullet 2:

"GIST reuses already established signaling relationships and messaging  
associations to peers if the signaling
flows traverse the same next signaling hop."

What does the "already established signaling relationships" mean in  
this multiplexing context? As far as I
understand, GIST only multiplexes messaging associations between  
signaling flows that traverse between the
same peers.

Page 10, bullet 6:

Should it be clarified here that the MTU restriction (and thus, the  
GIST message size restriction) only
affects unreliable signaling flows? Also, the automatic elevation to a  
reliable flow can not be originated
from the responding node.

Page 13, Chapter 6.1, first paragraph:

"However, the removal of dependence on RAO makes it more likely that  
NSIS Query packets can be forwarded
through nodes that are not NSIS aware." -> s/NSIS Query/GIST Query/

Page 15, first paragraph:

"GIST infrastructure" -> "NSIS infrastructure"

Page 15, third paragraph:

"Nodes that do not (yet) support the application will forward it  
without complaint ..." -> "Nodes that do not
(yet) support the application will forward it's signaling messages  
without complaint ..."

Page 20, chapter 8.6

"Designing a new NSLP is both challenging and easy." .. Some reasoning  
here would be good as to why?

Page 21, bullet 2:

"GIST-NSLP API" is referenced earlier as a "service layer API", which  
may not be obvious to someone new to
NSIS that they mean the same thing.

Page 21, bullet 5:

"... is the source of the signaling flow, or an intermediate node on  
the signaling." -> "... is the source of
the signaling flow, or an intermediate node on the signaling path."?


On Apr 2, 2009, at 11:54 AM, Martin Stiemerling wrote:

> Dear all,
>
> The draft draft-ietf-nsis-ext-02 seems to be ready for WGLC.
>
> We start a WGLC today for two weeks, i.e., until April 17, 2009.
>
> Please read the draft and send your comments about it.
>
> Comments includes, but are not limited to (just as a reminder):
> - what's wrong
> - what's right
> - stating that the draft ready for sending it to the IESG
> - stating that the draft is not ready for sending it to the IESG and  
> why it is not.
>
> Martin
>
> [email protected]
>
> NEC Laboratories Europe - Network Research Division
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,  
> London W3 6BL | Registered in England 2832014
>
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nsis
>

BR, Nuutti