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

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."

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.

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.

- Tom


On Thu, 2 Feb 2017, Gonzalo Camarillo wrote:

> Folks,
>
> I would like to start a WGLC on the following draft. This WGLC will
> end on February 19th:
>
> https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/
>
> Thanks,
>
> Gonzalo
>
> _______________________________________________
> Hipsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/hipsec
>