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

[Miika Komu <[e-mail]>]

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.