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

Hi,

On 02/16/2016 04:22 PM, Ari Keränen wrote:
> Thank you for the review Tom! Please see below.
>
>> On 12/02/2016 11:54 PM, Tom Henderson wrote:
>>> Gonzalo and all,
>>>
>>> My understanding is that the WG reached consensus several years ago
>>> that the standards-track NAT traversal variant would be the native
>>> NAT traversal and not the RFC5770-based ICE/STUN/TURN version.
>>>
>>> I reviewed the above draft and noticed that it still contains
>>> normative references to RFC5770 (pointers to material found only in
>>> RFC5770) throughout, and contains RFC5770 as a normative reference
>>> in Section 8.1.  It seems to me that the WG ought to produce a
>>> specification that can stand alone from RFC5770, because as it
>>> stands now, it seems to me that someone implementing it would need
>>> to consult both drafts and may be uncertain about what is still
>>> applicable from RFC5770.  For example, is the UDP-ENCAPSULATION
>>> mode still valid?
>
> Indeed this variant is the standards-track solution, but I think it
> makes sense to not obsolete the RFC5770. For example, in some scenario
> the STUN based solution could be better than native HIP based. And also
> the UDP-ENCAPSULATION mode should be still valid.

I think the main benefit of the STUN-based solution is the available 
infrastructure. From a protocol engineering perspective, RFC5770 is more 
complex to implement.

>>> ICE (RFC 5245) is also still listed as normative but it seems to me
>>> that it should also be informative in this draft.
>
> The details of e.g., how ICE checklists are used are defined in RFC5245
> so I think it needs to be normative.
>
>>> I think it would be appropriate to just reference 5770 in the
>>> Introduction, stating that this specification replaces RFC 5770
>>> with a different mechanism than ICE/STUN/TURN, and then try to
>>> avoid referencing 5770 from then on.
>
> Avoiding RFC 5770 altogether would require lots of editorial work with
> this draft for a questionable amount of benefit, so I think it's better
> if we simply have it as normative reference. The maturity level of 5770
> (experimental) is an issue, but I think it is possible - and makes sense
> - to make an exception here.

If it is not a problem from the viewpoint of IETF process, I would 
suggest to keep the native NAT traversal mode as a delta to RFC5770 but 
add more introductory text. Reworking the draft as a replacement for 
RFC5770 would require quite much extra effort. Tom are you volunteering?

_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec