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

From: Elwyn Davies <[email-masked]>
Date: Mon, 13 Jul 2009 16:30:15 +0100

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

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 13 Jul 2009 17:59:24 +0100

Hi.

I have just submitted a new version of the extensibility draft which I
hope addresses all these comments, and has also been resynched with the
RAO story as per mtlp version 20.

Thanks for the helpful review.

Not sure if this will need another WGLC due to RAO changes.

Regards,
Elwyn

Magnus Westerlund wrote:
> Hi,
>
> I have reviewed the document and have some comments.
>
> 1. First of all I wonder if all the WG history really need to be in this
> document. I don't see a purpose for it in most cases.
>
> 2. The introduction could be more explicit about the purpose of this
> document.
>
> 3. I think the topic of RAO could be a bit more clear about the issues
> with deploying it, due to adminstrative filtering at domain borders etc.
> Also the suggestions that RAO might be used, should probably
> informatively reference the draft for RAO with NSIS. In addition be
> clear on that this is likely only for limited deployements.
>
> 4. Section 6.1. Are you really certain that there will be need for
> hardware replacement to implement GIST with UDP port filtering to
> capture query packets. It seems that on a number of platforms this is
> likely not needed. So I think a balanced view here that it might, or
> might not be needed depending on the actual hardware in place is the
> right message.
>
> 5. I think especially section 8 could use some work on the layout. The
> text is very dense. I do understand why bullets are used, but I think
> forcing some line breaks between them could make it more readable.
>
> Cheers
>
> Magnus
>
> Martin Stiemerling skrev:
>   
>> 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-masked]
>>
>> 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-masked]
>> https://www.ietf.org/mailman/listinfo/nsis
>>
>>     
>
>
>