Subject: Re: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt

From: Xiaoming Fu <[email-masked]>
Date: Wed, 02 May 2007 00:33:10 +0200

Hi all,

I read thru the GIST_v13 doc, and agree that the spec is well written 
(indeed!). Besides protocol operations it contains solid rationales to 
explain the design options including their pros and cons.

Here are some comments/suggestions, primarily text/editorial ones:

In page 4 "This specification concentrates mainly on path-coupled 
signalling _controlling resources on network elements_"
--> In the sense of of signaling described earlier in this doc 
("monitoring of state which is managed by other mechanisms"), it is not 
"controlling" but "monitoring".

In Page 7,
    GIST Node:  Any node along the data path supporting GIST, regardless
       of what signalling applications it supports.
--> I think GIST Node should be independent on whether it is an on-path 
node or not, thus, "along the data path" could be removed.

In page 8,
... "unless otherwise _qualified_"
--> "unless otherwise _particularly specified_"?

In page 11,
"Extensions to the security
    or transport capabilities of D-mode can be provided equivalently by
    selecting a different protocol stack under the GIST messaging layer,
    which would then become another option within the overall C-mode
    framework. "
--> I am confused by "equivalently" here,
Do you mean C-mode in this case would be preferred.
Also, "overall _C-mode framework_" has not been introduced yet.

(BTW- This sentence contains too much different info to me as a 
non-native English speaker to follow).

"Note that
    downgrade attacks on such approach would need to be prevented by
    policy at the destination node, similar to the situation discussed in
    Section 8.6."
--> I may read it wrong... _downgrade_ attacks seem to be already 
mitigrating some attacks (good thing), why need "prevented".

"Indeed, it would be
    impossible for intermediate routers to carry out any processing on
    the messages without terminating the transport and security protocols
    used."
--> I suppose this is talking about TLS/cryptographically protected 
case, as normal TCP channels maybe still processed by e.g., certain 
routers acting as PEPs.

In page 12:
"   Predictive Routing:  Here, the intent is to signal along a path that
       the data flow may follow in the future.  Possible cases are pre-
       installation of state on the backup path that would be used in the
       event of a link failure, and predictive installation of state on
       the path that will be used after a mobile node handover."
--> This scenario seems not to be discussed in elsewhere in this doc

In page 14:
"However, if there are no security or transport requirements
    and no need for persistent reverse routing state, it can also be sent
    in the same way as the Query."
--> does this mean, that a DATA message has to include MRM in this case?

In page 15:
"An _exisiting_ peering relationship"
-->    An existing peering relationship

Page 24:
Return routability checking: when is this feature (as well as other 
security features) included? Current Transfer-Attribute concerning 
"Security" is given rather at a high level.

In page 37:
"(e.g. for which flow)"
--> maybe more accurately: "(e.g. for which session") ?

In page 55:
"Current MRMs define the use of a Router Alert Option [3] to assist
    the peer in intercepting the message depending on the NSLPID.  If the
    MRM defines the use of RAO, the sender MUST include it by default."
and in page 109:
  ... " multiple NSLPIDs MAY be associated with the same value. "
--> How many RAO values are suggested for GIST/NSIS? Supposedly 1, -- or 
"the same value" here means the value of "MRM"?

In page 56:
... "within the _networ_"
--> "within the network"

In page 88:
I maybe lost in the load splitting/sharing: is it so essential to be 
supported at GIST level?

Cheers,
Xiaoming

Martin Stiemerling wrote:
> Hi all,
> 
> Thanks for all getting their reviews done and/or discuss open items. 
> 
> The WGLC is extended for one week, as discussions have started late and 
> to give further opportunities for reviews. 
> 
> Thus, the WGLC runs now until **May 2nd**!
> 
> Thanks,
> 
>   Martin
> 
> Anfang der weitergeleiteten E-Mail:
> 
>> *Von: * Martin Stiemerling <[email-masked] 
>> <mailto:[email-masked]>>
>> *Datum: * 18. April 2007 11:37:22 MESZ
>> *An: * nsis <[email-masked] <mailto:[email-masked]>>
>> *Betreff: * *[NSIS] Reminder: WGLC for draft-ietf-nsis-ntlp-13.txt *
>>
>> Dear all,
>>
>> This is a friendly reminder for the currently running WGLC for GIST.
>>
>> Apparently, there have not been much reviews and/or comments on GIST. 
>> I interpret this as *nobody* has read the document. Consider also 
>> Magnus' email response to the original WGLC!
>>
>> In any case, I would like to encourage all WG memmbers and especially 
>> *all* implementers and NSLP authors to review GIST and to send their 
>> comments to the list.
>>
>> It is even good to send something along the lines "yes, I have read 
>> the document and it is fine with me."
>>
>> Thanks and looking forward to your reviews,
>>
>>   Martin
>>
>> Am 04.04.2007 um 00:31 schrieb Martin Stiemerling:
>>
>>> Dear all,
>>>
>>> We are starting an extended WGLC for GIST. The WGLC starts on April 
>>> 4th and will run for *three* weeks.
>>>
>>> Everybody of the NSIS WG should review GIST once again, especially 
>>> all **implementers** and **NSLP authors**.
>>>
>>> Thank you and looking forward to your reviews and comments
>>>
>>>   Martin
>>>

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 2 May 2007 10:04:18 +0200

[I'm writing as NATFW NSLP author.]

Hi all,

I have read the GIST draft and I'm fine with the draft. The draft  
contains an excellent written protocol specification and explains the  
overall protocol also in an excellent way.

There are some nits in the draft but those have been already covered  
by all the other people that did a review.

Good job! :)

   Martin

Am 20.04.2007 um 16:17 schrieb Martin Stiemerling:

> The WGLC is extended for one week, as discussions have started late  
> and to give further opportunities for reviews.
>
>> Von: Martin Stiemerling <[email-masked]>
>> Datum: 18. April 2007 11:37:22 MESZ
>> An: nsis <[email-masked]>
>> Betreff: [NSIS] Reminder: WGLC for draft-ietf-nsis-ntlp-13.txt
>>
>> Dear all,
>>
>> Apparently, there have not been much reviews and/or comments on  
>> GIST. I interpret this as *nobody* has read the document. Consider  
>> also Magnus' email response to the original WGLC!
>>
>> In any case, I would like to encourage all WG memmbers and  
>> especially *all* implementers and NSLP authors to review GIST and  
>> to send their comments to the list.
>>
>> It is even good to send something along the lines "yes, I have  
>> read the document and it is fine with me."
>>
>>> We are starting an extended WGLC for GIST. The WGLC starts on  
>>> April 4th and will run for *three* weeks.
>>>
>>> Everybody of the NSIS WG should review GIST once again,  
>>> especially all **implementers** and **NSLP authors**.
>>>
>>>> Von: <[email-masked]>
>>>> Datum: 3. April 2007 21:50:02 MESZ
>>>> An: <[email-masked]>
>>>> Kopie: <[email-masked]>
>>>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-13.txt
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>> This draft is a work item of the Next Steps in Signaling Working  
>>>> Group of the IETF.
>>>>
>>>> 	Title		: GIST: General Internet Signalling Transport
>>>> 	Author(s)	: H. Schulzrinne, R. Hancock
>>>> 	Filename	: draft-ietf-nsis-ntlp-13.txt
>>>> 	Pages		: 177
>>>> 	Date		: 2007-4-3
>>>> 	
>>>> This document specifies protocol stacks for the routing and  
>>>> transport
>>>>    of per-flow signalling messages along the path taken by that  
>>>> flow
>>>>    through the network.  The design uses existing transport and  
>>>> security
>>>>    protocols under a common messaging layer, the General Internet
>>>>    Signalling Transport (GIST), which provides a common service for
>>>>    diverse signalling applications.  GIST does not handle  
>>>> signalling
>>>>    application state itself, but manages its own internal state  
>>>> and the
>>>>    configuration of the underlying transport and security  
>>>> protocols to
>>>>    enable the transfer of messages in both directions along the  
>>>> flow
>>>>    path.  The combination of GIST and the lower layer transport and
>>>>    security protocols provides a solution for the base protocol
>>>>    component of the "Next Steps in Signalling" framework.
>>>>
>>>> A URL for this Internet-Draft is:
>>>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-13.txt
>>>>
>>>> To remove yourself from the I-D Announcement list, send a  
>>>> message to
>>>> [email-masked] with the word unsubscribe in the  
>>>> body of
>>>> the message.
>>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- 
>>>> announce
>>>> to change your subscription settings.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP. Login with the
>>>> username "anonymous" and a password of your e-mail address. After
>>>> logging in, type "cd internet-drafts" and then
>>>> "get draft-ietf-nsis-ntlp-13.txt".
>>>>
>>>> A list of Internet-Drafts directories can be found in
>>>> http://www.ietf.org/shadow.html
>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>
>>>> Internet-Drafts can also be obtained by e-mail.
>>>>
>>>> Send a message to:
>>>> 	[email-masked].
>>>> In the body type:
>>>> 	"FILE /internet-drafts/draft-ietf-nsis-ntlp-13.txt".
>>>> 	
>>>> NOTE:	The mail server at ietf.org can return the document in
>>>> 	MIME-encoded form by using the "mpack" utility.  To use this
>>>> 	feature, insert the command "ENCODING mime" before the "FILE"
>>>> 	command.  To decode the response(s), you will need "munpack" or
>>>> 	a MIME-compliant mail reader.  Different MIME-compliant mail  
>>>> readers
>>>> 	exhibit different behavior, especially when dealing with
>>>> 	"multipart" MIME messages (i.e. documents which have been split
>>>> 	up into multiple messages), so check your local documentation on
>>>> 	how to manipulate these messages.
>>>>
>>>> Below is the data which will enable a MIME compliant mail reader
>>>> implementation to automatically retrieve the ASCII version of the
>>>> Internet-Draft.
>>>> <ATT966628.TXT>
>>>> <draft-ietf-nsis-ntlp-13_URL.DEFANGED-0>
>>>> <ATT966629.txt>
>>>
>>>
>>>
>>> [email-masked]
>>> NEC Europe Limited |
>>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
>>> Registered in England 2832014
>>>
>>>
>>>
>> [email-masked]
>> NEC Europe Limited |
>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
>> Registered in England 2832014
>>
>>
>>
>>
> [email-masked]
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,  
> London W3 6BL | Registered in England 2832014
>
>

[email-masked]
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,  
London W3 6BL | Registered in England 2832014