Re: [core] Éric Vyncke's No Objection on draft-ietf-core-hop-limit-06: (with COMMENT)

[<[e-mail]>]

Hi Eric, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker [mailto:[e-mail]]
> Envoyé : vendredi 11 octobre 2019 08:41
> À : The IESG
> Cc : [e-mail]; Jaime Jimenez; core-
> [e-mail]; [e-mail]; [e-mail]
> Objet : Éric Vyncke's No Objection on draft-ietf-core-hop-limit-06: (with
> COMMENT)
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-core-hop-limit-06: 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-core-hop-limit/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document. I have a couple of COMMENTs
> (that I would appreciate to see a reply of yours) and one NIT.
> 
> Regards,
> 
> -éric
> 
> == DISCUSS ==
> 
> == COMMENTS ==
> 
> -- Section 3 --
> C.1) "Because forwarding errors may occur if inadequate Hop-Limit values
>    are used, proxies at the boundaries of an administrative domain MAY
>    be instructed to remove or rewrite the value of Hop-Limit carried in
>    received messages" Isn't this remove all usefulness of the Hop-Limit
> option ?

[Med] This is warranted in the next sentence: "This modification should be done with caution in case proxy-forwarded traffic repeatedly crosses the administrative domain boundary in a loop and so Hop-Limit detection gets broken."

Basically, the decision will be deployment-specific. E.g., if the boundary proxy is the only proxy to be invoked before reaching the ultimate CoAP endpoint, striping the option may be OK. 

> 
> C.2) table 1, suggest to state the value of the C, U, N, R properties

[Med] The option is elective, safe-to-forward, part of the cache, and not repeatable. So, none of C, U, N, R is marked with "x" in the table. 

> 
> -- Section 4 --
> C.3) while I understand why a proxy should not add its own diagnostic
> information when packet should become larger than the MTU of the next link,
> I
> wonder what will happen downstream when the MTU will be exceeded...

[Med] The behavior of the proxy will take into account the "Path" MTU not the link MTU:

   Note that an
   intermediate proxy prepends its information only if there is enough
   space as determined by the Path MTU (Section 4.6 of [RFC7252]).
                              ^^^^^^^^  

With that assumption, I don't see any MTU issue when forwarding the packet downstream. No?

> 
> C.4) suggest to use normative language (uppercase MAY, MUST, ...)
> 

[Med] We used to have more normative language in that section but cleaned it as a result of this WGLC comment:

========
> > 3. "To ease debugging and troubleshooting, the CoAP proxy which
> > detects a loop SHOULD include its information ... Each intermediate
> > proxy involved in relaying a TBA1 (Hop Limit Reached) error message
> > SHOULD prepend its own information" - Is it really a protocol
> > violation if I want to configure my proxy not to include any
> > information?
> >
>
> [Med] It is not a protocol violation if the information is not included - hence the SHOULD. However it makes diagnosing the issue more difficult.

We briefly discussed this in the interim yesterday and came to the
conclusion that having a normative requirement here isn't needed. It
seems more like a suggestion for a good quality of implementation. I
propose to remove any use of KEYWORDs here.
==========

> == NITS ==
> 
> -- Section 3 --
> N.1) s/if a less value/if a smaller value/ ?

[Med] Fixed. Thank you.