Re: WGLC: draft-ietf-nsis-nslp-natfw-16.txt

Hi Teemu,


Am 19.12.2007 um 15:39 schrieb Teemu Huovila:

> Hello
>
> I have read the draft and I do not have any major objections. I  
> think it
> is very extensive and considers, in great detail,  all necessary  
> aspects
> of the protocol.
>
> I am very sorry, that my comments are overdue. I hope they can still
> be of some use for the working group. This was my first review of
> the draft and it took much longer to read, than I had estimated.

No problem, I also had trouble (w.r.t. time) to get to the NATFW NSLP.

>
> I have divided my comments into two categories. One group of  
> regular nits
> and another of more insignificant details. I include the comments  
> below.
>
> Before nits I will just add my 2 cents to the 5-tuple/policy rule
> discussion. As mentioned by Lauri, it is defined somewhat unclearly on
> page 20. It is, however, in my opinion defined more clearly on page  
> 10.
> It is also worth to note, that the first definition uses "and",  
> where the
> second uses '/'.

I hope it got better readable with Lauri's text.

>
> -----
> nits:
>
> * page 6, paragraph 2:
> "This message .... intercepts these messages," -> *this message*

Fixed.

>
> * page 7:
> "If the data receiver resides in a private addressing realm or
> firewall" --> *behind a* firewall ?

Yep, indeed. Fixed.

>
> * page 8:
> the second sentence in the definition of "Firewall" is superfluous.

Removed 2nd sentence.

>
> * page 9:
> In bullet about NATFW NSLP peer the term "NSIS adjacency" is vague.
> I suggest "NSLP adjacency" (or GIST/NTLP adjacency, if that was  
> intended). [2]
> defines GIST adjacency and "adjacent peer"

Fixed to NTLP adjacency.

>
> * page 25, 3.2.1, 3rd bullet:
> What are "inbound NATFW peers"? Does "inbound"
> here mean towards the NI?  (it became clear later, in section 3.7.5)

towards NI. But this inbound is wrong at that place,as NOTIFY can run  
in both directions. Removed 'inbound' at this occurrence.

>
> * page 30, 2nd paragraph:
> Error conditions are quite correctly defined for both
> too low and too high session lifetimes, but the text states:
>
> "The forwarders MUST accept the granted NATFW NSLP signaling  
> session lifetime,
> as long as this value is less than or equal to the acceptable value."
>
> later "lower or equal" is mentioned.
>
> Should these maybe be "if the lifetime value is within the  
> acceptable range",

Fixed to "if the lifetime value is within the acceptable range".

> or something similar? If not, I have great trouble understanding this.
>
> How are NFs on the path towards NR informed, if a node rejects the  
> lifetime
> suggested in the RESPONSE? A NOTIFY with the same error code?  Can  
> NOTIFY be
> sent towards NR? Page 66 says "The NOTIFY message is routed towards  
> the NI..."

I also have some doubts about this and started a separated thread  
about this (but with special focus to the error handling).

>
> Im very sorry, if I have overlooked some central detail about this.

No, you hit one remaining issues! :)

>
> * page 33, 5th bullet, sub-bullet:
> "If no matching reservation can be found, i.e. no reservation has  
> been made in
> advance, the NSLP MUST return an error RESPONSE of class 'Signaling  
> session
> failure' (0x6) with response code 'No reservation found matching  
> the MRI of the
> CREATE request' (0x03) MUST be generated."  --> "MUST be generated" is
> superfluous? (already "MUST return")

Fixed.

>
> * page 39-40:
> processing of EXT on NI(page 39) says: "When the data sender's IP  
> address is
> not known, the NI+ MUST NOT include a NATFW_DTINFO object."
>
> later, on page 40 it is stated:
> "The edge-NAT or any other NAT MUST reject EXT messages not carrying a
> NATFW_DTINFO object..."
>
> Was the "LE-MRM, DS unknown etc" case DTINFO object added by  
> somebody in the
> middle? A NAT before the edge-NAT? But arent those included in "or  
> any other
> NAT"?
>
> Also, NATFW_DTINFO is specified as mandatory, in 4.3.2 (page 64)  
> Maybe I have
> overlooked something here as well. The section, as Niklas  
> mentioned, is not
> very easy to read.

This part has been reworked, as there where multiple places  
contradicting each other.
Fixed.

>
> * page 46:
> "This proxy mode of operation must terminate the NATFW NSLP  
> signaling as
> topologically close to the terminal for which it is proxying and  
> proxy all
> messages."  --> *as possible* or something similar seems to be  
> missing from
> that sentence. (It only says "as close..." )

Replace it with "...signaling topologically-wise as close as possible  
to the terminal..."
This is typical editing error after x revisions. :)

>
> Also, what does this sentence mean? All proxy mode signaling is  
> terminated at
> the NI+/NI side edge-device, if I understood the section correctly.

Yes. However, there is some difficulty in saying where the proxies  
are located, as this depends on the system where this is implemented.  
Therefore this complicated sentence.

>
> ------------------------
> insignificant/uncertain:
>
> * page 7:
> "one or other" --> one or *the* other ?

Fixed.

>
> * page 9:
> The "SDA" did not become clear to me until page 36( with dr, dr+  
> etc). Though
> admittedly it is difficult to write a clear terminology section, if no
> knowledge can be expected from the reader, i.e. me. :)

But with page 36 it was clear? That's fair enough if it is clear at  
the point when it comes to importance.

>
> * page 11:
> "on the data path from... and the external network" "and" could be  
> *to*?
> (i.e. on the data path from ...to) or change "from" to *between*?

"and" is indeed "to". Fixed.

>
> * page 22, bullet 4:
> "Ni" -> *NI*

Fixed.

> * page 31, 3rd paragraph:
>   "NSLP MUST update its stored state accordingly, if permitted by  
> all security
>   checks (see Section 3.6), and stores"
>   --> *store*?

Fixed.

>
> * page 53:
> "The NSLP header is carried in all NATFW NSLP message and objects... "
> --> *messages*

Fixed. Again some editing bug...

>
> * page 63:
>   "Objects defined in this memo carry always the flag combination"
>   --> *always carry* ?

Fixed.

>
> * page 80:
>   "The rest of this section is giving"
>   --> *gives* ?

Fixed.

>
> * page 80:
>   "It necessary to differentiate" --> It *is*

Fixed.

Thanks!!!

   Martin


[email protected]

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 protected]
https://www1.ietf.org/mailman/listinfo/nsis