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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Thu, 10 Oct 2019 23:41:01 -0700

É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 ?

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

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

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

== NITS ==

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

---

From: <[email-masked]>
Date: Fri, 11 Oct 2019 07:58:56 +0000

Hi Eric, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker [mailto:[email-masked]]
> Envoyé : vendredi 11 octobre 2019 08:41
> À : The IESG
> Cc : [email-masked]; Jaime Jimenez; core-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Éric Vyncke's No Objection on draft-ietf-core-hop-limit-06: (with
> COMMENT)
> 

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

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

> N.1) s/if a less value/if a smaller value/ ?

[Med] Fixed. Thank you.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 14 Oct 2019 14:20:25 +0000

Hello Mohamed,

Thank you for your reply.

Look inline for EVY> (and feel free to ignore)

-éric

On 11/10/2019, 09:59, "[email-masked]" <[email-masked]> wrote:

    Hi Eric, 

    Please see inline. 
    
    Cheers,
    Med

    

EVY> still looks like defeating the whole purpose because how one proxy would know FOR SURE that it is the last one?

    
EVY> LoL __ but a little unclear at first sight. Unsure whether other documents use a "0" or "." to specify 'not-set' ? My point is that this document should really align with others.

       Note that an

EVY> my bad, I should learn to read...

    
    ========

    
    [Med] Fixed. Thank you.

---

From: <[email-masked]>
Date: Tue, 15 Oct 2019 08:23:44 +0000

Hi Eric, 

Please see inline.

Cheers,
Med

> De : Eric Vyncke (evyncke) [mailto:[email-masked]]
> Envoyé : lundi 14 octobre 2019 16:20
> À : BOUCADAIR Mohamed TGI/OLN; The IESG
> [email-masked]; [email-masked]
> Objet : Re: Éric Vyncke's No Objection on draft-ietf-core-hop-limit-06:
> (with COMMENT)
> 
> Hello Mohamed,
> 
>     >    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.
> 
> EVY> still looks like defeating the whole purpose because how one proxy
> would know FOR SURE that it is the last one?
> 

[Med] This is known to the administrative entity managing the proxy; instructions are then passed to the proxy. Absent such instruction, the default behavior of a proxy is to maintain the option.  

>     [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.
> 
> EVY> LoL __ but a little unclear at first sight. Unsure whether other
> documents use a "0" or "." to specify 'not-set' ? My point is that this
> document should really align with others.

[Med] I got that. I confirm that the document is aligned with RFC7252. Will see how to make thing more clear.

>     > information when packet should become larger than the MTU of the next
> link,
>     > I
>     [Med] We used to have more normative language in that section but
> cleaned it as a result of this WGLC comment:
> 
>     ========
>     > [Med] It is not a protocol violation if the information is not
> included - hence the SHOULD. However it makes diagnosing the issue more
> difficult.
>