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

[Miika Komu <[e-mail]>]

Hi,

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

I am going to join the author list and help to improve the draft 
according the comments on the mailing list.

Another change we plan to do is to adjust the current specification to 
new ice-bis recommendations (smaller delays, for instance). This will 
cause some delays because it's not yet an RFC.