NSIS Protocol Operation in Mobile Environments
RFC 5980

Note: This ballot was opened for revision 20 and is now closed.

(Lars Eggert) Yes

(Jari Arkko) No Objection

Comment (2010-07-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Review by Ari Keränen:

Just one somewhat technical comment:

4.3. NATFW NSLP

   In this process, the obsoleted state in the old path is not
   explicitly released because the state can be released by timer
   expiration.

This may have some mobility specific security implications that could be mentioned in the security considerations section.


Then nits and editorial issues:

NSIS abbreviation should be expanded in the abstract (but probably not in the title).


1. Introduction

   Each specific service has its own NSLP
   protocol; currently there two standardized NSLP protocols, the QoS

s/there/there are/


2. Requirements Notation and Terminology

   A Crossover Node is a node that for a given function is a merging
   point of two or more paths belong to flows of the same session along
   which states are installed.

s/belong/belonging/ ?


3. Challenges with Mobility

   application state, and removing any useless state, while localizing
   the signaling to only the affect part of the network.

s/to only the affect/only to the affected/ ?


4.2. QoS NSLP

   CRN in this document (setp(2) in Figure 1), where a state is

s/setp/step/


5. Interaction with Mobile IPv4/v6

   link properties, esp. additional overhead due to mobility header

s/esp./especially/ ?

   proper interface addresses in the NLI in order to ensure that a

Expand NLI

   include a combined NAT/FW message to cover both RTT and BU/BA

Expand RTT

   After that the NAT/FW procedure more likes QoS NSLP
   (perform another NAT/FW signaling after BU).

What does it mean when "NAT/FW procedure likes QoS NSLP"?

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2010-07-15)
No email
send info
This is an example of a well-written document that is sometimes hard to parse becuse of small issues with the use of English. I know that the RFC Editor will make a pass for this type of issue, but it would have been (could still be!) good to get a native speaker from the WG to take an editorial pass on the document. The risks associated with the RFC Editor correcting text without the knowledge of the technical details are considerable.

(Russ Housley) No Objection

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection