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

Am 21.12.2007 um 16:57 schrieb Ali Fessi:

> Dear Martin and NATFW NSLP co-authors,
>
>
> I have read the draft and have only few comments:
>
> - First, I think the draft needs some editorial polishing and needs  
> to become a bit more reader-friendly where possible. As already  
> mentioned in some emails before, some sections are difficult to  
> understand even with background knowledge in NATFW NSLP. Some more  
> cross references to different sections within the draft itself or  
> to sections in other drafts considered as background knowledge,  
> e.g. GIST, could be helpful to make life easier for the reader.

Good to know that there are some parts which are hard to read.  
However, this is a WG document and all people are invited to propose  
new text for replacing existing text.
It is quite hard for me as a document editor to judge which parts are  
hard to read and which are not. Furthermore, text is usually written  
in the writer's style and only real replacement text can improve  
readability.

>
> - The solution described for the scenario "2.6 Both End Hosts  
> Behind Same NAT" is not efficient. I guess you know what I am  
> talking about here. All the traffic will go through the external  
> gateway. I remember we had some discussions with Cedric about 4  
> years ago about using something like ICE (at that time ICE was  
> pretty new, I think) in order to discover whether the peer is  
> within the same network in order to perform direct signaling and  
> route the traffic directly between the peers.

There has been an AD decision (back in Alison's days) to not go into  
ICE specifics.
Technically you are completely write, but protocol wise I would  
assume that interworking with ICE would require a new document, e.g.  
applicability statement.

>
> - The text in "C.4.  NSLP Handling of Twice-NAT" is a bit  
> confusing. e.g. "The dynamic configuration of twice-NATs requires  
> application level
>    support, as stated in Section 2.5.  The NATFW NSLP cannot be  
> used for
>    configuring twice-NATs if application level support is needed."
>
> does this mean that the NATFW NSLP does not supports twice-NATs and  
> it is left to application layer support?

Twice-NAT configuration is not supported, as twice-NAT is marked as  
historic (RFC 4966).

>
> or "The NSLP is probably able to traverse the twice-NAT" (I guess  
> with "probably" here, you mean it depends on whether the twice-NAT  
> is NATFW NSLP aware or not. This could be clarified better).

It is meant as, whenever people do consider twice-NATs and they are  
implementing the NATFW NSLP, they should at least take care that IP  
addresses are exchanged in a proper way. However, there is no text  
here which defines the standard way of doing so. The reason for this  
is the current status of twice-NAT (NAT-PT) in the IETF (RFC 4966).


>
> - The text about CMS in the security section is a bit confusing:
>
> "Additionally, security protection of certain
>    payloads may be required between non-neighboring signaling entities
>    and the Cryptographic Message Syntax (CMS) [14] might be a  
> potential
>    solution.  Payload protection using CMS is not described in this
>    document."
>
> This sounds like: "you could use CMS, but we are not sure if it  
> will solve your problems, or we don't know even how to use it here,  
> and which message parts you will need to protect".
>
> I am not sure here, but I think that if you use CMS, you will use  
> it to protect the authorizations tokens, so the use of CMS could be  
> moved the NSLP authorization draft. What do you think?

I'm fine with removing it, as it really reads shaky...

>
> Otherwise, I hope that the effort of several years will be fruiful  
> and that we will have a successful protocol! :-)

Thanks! :)

[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