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

From: Miika Komu <[email-masked]>
Date: Wed, 29 Jun 2016 21:32:42 +0300

Hi Derek,

On 03/29/2016 02:51 AM, Derek Fawcus wrote:
> On Mon, Mar 07, 2016 at 02:35:07pm +0200, Gonzalo Camarillo wrote:
>> First he will look into adding clarifications to the existing draft
>> while still referencing the old RFC. If the group is not happy with the
>> readability after the editorial pass (or our AD does not finally let us
>> downref the old RFC), we can consider bringing material from the old RFC
>> directly into the new one.
>
> Sorry,  that I'm quite late in looking at these,  but have been doing
> so recently...
>
> I have to say that I find the it difficult to decode simply because
> of having to refer to 3 (the draft, 5770, 5245) plus possibly the
> STUN/TURN docs at once.
>
> I'd certainly find it easier to comprehend if the text from 5770 was
> incorporated (suitably modified to account for not doing STUN/TURN)
> within the draft.  That way the references to the significant pieces
> of 5245 text would be easier to nail down.

done!

> As it is,  I currently find it a bit like reading an Act of Parliament!
>
> e.g. $3.8 Connectivity Checks
>     refers to $4.6 of 5770 with some exceptions, $4.6 of 5770 refers to
> $5.7 of 5245 and $7 of 5245,  where the exceptions (use of UPDATE instead
> of STUN) have to be applied to that $7 referencing 5389,  so possibly
> I don't have to read 5389, since hopefully it would just be packet formats.
>
>> I would also like the group to comment on the following two proposals:
>>
>> 1) the draft will allow implementers to use HIP native relays only. In
>> addition, the use of STUN and TURN relays will be optional.
>
> I'd suggest the draft be native only,  but say with an appendix referencing
> 5770 for use of STUN/TURN,  maybe indicating which bits of the 5770
> to take heed of.

STUN is now optional, but just for determining the host's owns address 
candidates. Data relay must be used instead of TURN.

>> 2) in addition to covering the base exchange, the draft will also cover
>> the mobility readdressing exchange.
>
> Not having read that recently,  I can't really comment.

The mobility is now covered.

---

From: Miika Komu <[email-masked]>
Date: Wed, 29 Jun 2016 22:01:29 +0300

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.