Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 13 Feb 2016 12:56:42 +0200

Hi,

I am resending Tom's comments to the list since he seems to have failed
to cc: the list on his email below. Thanks for your comments, Tom!

Cheers,

Gonzalo

On 12/02/2016 11:54 PM, Tom Henderson wrote:
> On 01/29/2016 02:32 PM, Gonzalo Camarillo wrote:
>> Hi,
>>
>> I would like to start a WGLC on the following draft. This WGLC will end
>> on February 12th:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/
>>
>> Please, send your comments to this list. 
> 
> 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?
> 
> ICE (RFC 5245) is also still listed as normative but it seems to me that it should also be informative in this draft.
> 
> 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. 
> 
> - Tom

---

From: Ari Keränen <[email-masked]>
Date: Tue, 16 Feb 2016 16:22:48 +0200

Thank you for the review Tom! Please see below.

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

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

Cheers,
Ari

---

From: Miika Komu <[email-masked]>
Date: Mon, 22 Feb 2016 17:41:13 +0200

Hi,

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

> - 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?