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

From: "Martin Stiemerling" <[email-masked]>
Date: Thu, 2 Apr 2009 10:54:54 +0200

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 2 Apr 2009 10:59:24 +0200

Hi all

In my opinion the draft draft-ietf-nsis-ext-02 
is ready for sending it to the IESG 

Best regards,
Georgios

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Martin Stiemerling
> Sent: donderdag 2 april 2009 10:55
> To: [email-masked]
> Subject: [NSIS] WGLC for Using and Extending the NSIS 
> Protocol Family(draft-ietf-nsis-ext-02)
> 
> Dear all,
> 
> 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
>

---

From: Nuutti Varis <[email-masked]>
Date: Thu, 2 Apr 2009 16:50:56 +0300

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:

> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,  
> London W3 6BL | Registered in England 2832014
>

BR, Nuutti

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 03 Apr 2009 13:35:40 +0200

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

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------