Re: [Hipsec] Mirja Kühlewind's No Objection on draft-ietf-hip-native-nat-traversal-30: (with COMMENT)

[Miika Komu <[e-mail]>]

Hi Mirja,

ke, 2020-02-26 kello 09:11 -0800, Mirja Kühlewind via Datatracker
kirjoitti:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-hip-native-nat-traversal-30: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
> this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/
> 
> 
> 
> -------------------------------------------------------------------
> ---
> COMMENT:
> -------------------------------------------------------------------
> ---
> 
> Thanks for addressing my discuss points and most of my other
> comments. I
> believe the following comments from my previous ballot are still
> valid:
> 
> I agree with other ADs that it is not clear to me why this mechanism
> is needed
> in addition RFC5770. This is a use case for ICE and I would think
> that re-using
> existing code and library would make implementation easier, faster
> and less
> error-prone. I especially agree to the comments from Adam!

I have argumented this in earlier discussions, so I won't repeat it
here. Adam changed his ballot to "No objection".

> Other comments:
> 
> 4) sec 4.8: "When a host does not receive
>    acknowledgments, e.g., to an UPDATE or CLOSE packet after a
> timeout
>    based on local policies, a host SHOULD resend the packet through
> the
>    associated Data Relay Server of the peer (if the peer listed it in
>    its LOCATOR_SET parameter in the base exchange."
> I did not really find anything about this in section 5.10 of RFC5770.
> In think
> the timeout needs to be further specified.

the timeout mechanisms are specified in the RFC7401 state machine
specification, so I added a reference there instead of repeating it
here:
   A. 
   When a host does not receive acknowledgments, e.g., to an UPDATE or
   CLOSE packet after a timeout based on local policies, a host SHOULD
   resend the packet through the associated Data Relay Server of the 
   peer (if the peer listed it in its LOCATOR_SET parameter in the base
   exchange *according the rules specified in section 4.4.2 in
   [RFC7401]*.