Re: WGLC: draft-ietf-hip-native-nat-traversal-15

Hi,

a preliminary version here:

http://mkomu.kapsi.fi/temp/draft-hip-native-nat-traversal-19.txt

Not yet on IETF site since I missed the cut-off deadline.

On 02/19/2017 05:18 PM, Tom Henderson wrote:
> Hello, I have read the latest (-17) draft and sent some purely editorial
> comments to Miika.  I had a few non-editorial questions and comments.
>
> 1) In appendix D, it states:
>
>    o  A minimal implementation would conform only to Section 4.7.1 or
>       Section 4.7.2, thus merely tunneling HIP control and data traffic
>       over UDP.  The drawback here is that it works only in the limited
>       cases where the Responder has a public address.
>
> However, in section 5.4, it states:
>
>    Implementations conforming to this specification MUST implement both
>    UDP-ENCAPSULATION and ICE-HIP-UDP modes.
>
> The contradictory text should be resolved.  In my opinion,
> implementations that want to support only the UDP-ENCAPSULATION mode
> (and its restricted set of use cases) should be allowed.  However, I
> don't know what might need to be done to avoid a situation where a
> product claims RFC compliance but only implements one of the two modes.
> It could perhaps be avoided by a statement that states "Implementations
> that choose to only support the UDP-ENCAPSULATION mode should clarify
> this point when any claims of <RFC-to-be> compliance are made."

now it says:

"Implementations conforming to this specification MUST implement UDP-
ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes."

I can also add some other wording if it is really necessary (and common 
in RFC specifications). Btw, while ICE lite is not really the same as 
ICE-HIP-UDP, ICE lite vs full ICE is not really enforced in the 
specification.

> 2) Appendix C states:
>
>    o  The considerations on Diffserv Codepoint markings in ICE are not
>       applicable to HIP since Diffserv is not used in HIP.
>
> Why wouldn't the same issues arise in HIP as in ICE on this matter?
> Should this draft instead copy or reference the RFC 5245 recommendation:
>
>    If the agent is using Diffserv Codepoint markings [RFC2475] in its
>    media packets, it SHOULD apply those same markings to its
>    connectivity checks.
>
> Also, I don't think that the HIP control plane should be excluded from
> using diffserv.

done.

> 3) In section 4.10 (NAT keepalives), it states:
>
>    Both a registered client and relay server SHOULD
>    send a HIP NOTIFY packets to each other every 15 seconds (the so-
>    called Tr value in ICE) unless they have exchange some other traffic
>    over the used UDP ports.
>
> However, I couldn't find an explanation anywhere (also in RFC 5770)
> about how to code this NOTIFY.  Would it make sense to define also a
> "NAT_KEEPALIVE" NOTIFY message type for this purpose?
>
> Once these issues are resolved, I think that the draft would be ready to
> publish.

done.

P.S. The new version of the draft also includes some nits from Alex Elsayed.