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

Hi,

On 02/23/2016 04:08 PM, Tom Henderson wrote:
>
>
> On 02/16/2016 06:22 AM, 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.
>>
>>>> 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.
>
> Ari, I have thought about this and it seems to me that there are two
> issues to discuss.
>
> There is a technical issue to resolve, which is whether the WG wants
> to keep RFC5770 solutions as non-obsolete, and how to express these
> options to future implementers.  I had thought that the WG position
> was to drop support for STUN-based solutions, but you are suggesting
> now to keep it active, perhaps as a MAY implement?   It seems to me
> that the basic UDP-ENCAPSULATION mode should still be kept mandatory
> since it is the basis for the other approach and is useful by
> itself.
 >
> Then there is the editorial issue about how to meet IETF guidelines
> on how things are cross-referenced and use of informative/normative
> references, which seems to me risky at the moment (i.e., I am
> anticipating a downstream reviewer expressing this same concern).
> Plus there is the goal of making it clearer to implementers.

trying to recap your complete opinion... do you think the 
UDP-ENCAPSULATION should be MUST and ICE-HIP-UDP SHOULD? And RFC5770 
MAY? Or do you think the draft should just deprecate RFC5770?

Btw, RFC5770 is still a normative reference because we are redundantly 
explaining some parts of the RFC in the draft.

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