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

Hi.

Thanks for the comments and apologies for the long delay in acking your
helpful review!

I was waiting for the outcome of the IESG discussiojns and then got tied
up in other work.  Anyway I have now submitted a new version (JIT!).

A couple of your comments have been OBE (back to RAO), but I trust my
fixes will suit.
Regards,
Elwyn

Nuutti Varis wrote:
> 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.
I fixed these up as I thought appropriate.. preferring NSIS protocol
suite and signaling application layer.  The NTLP/GIST one seemed mostly
OK to me.
>
> 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."
OK.. plus path -> part of path.
>
> also, "Two NSLP protocols are currently standardized: ..." -> "Two
> NSLP applications are currently being
> standardized ..."?
NO.. when this is finished they will be 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?
added capable to the second instance in the para.
>
> Page 5, third paragraph:
>
> "Unlike RSVP, signaling is normally ..." -> "Unlike RSVP, NSIS
> signaling is normally ..."?
Left this one alone.
>
> 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."
>
OK.  I did something close to this.
> 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"?
OK
>
>
> Page 9, second paragraph:
>
> s/recognised/recognized/ (whereas other places there are
> "standardized" "authorized" and so on)
This one is done both ways (especially in the UK.. I like s)
>
> 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.
The problem is the last part.. new version:  "GIST reuses already
established signaling relationships and messaging associations to next
hop peers if the signaling
transport attributes are the sane for the signalong flows."
>
> 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.
Added UDP and Query mesaage  Didn't action the second part.. seems too
detailed for this doc.
>
> 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/
OBE:  Completely new text in this section due to resurgence of RAO.
>
> Page 15, first paragraph:
>
> "GIST infrastructure" -> "NSIS infrastructure"
I think this is right as it stands,
>
> 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 ..."
>
OK
> Page 20, chapter 8.6
>
> "Designing a new NSLP is both challenging and easy." .. Some reasoning
> here would be good as to why?
>
.. that is what the rest of the section does (I think)!
> 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.
Previous fixes make this clearer I hope.
>
> 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."?
>
OK