Subject: Opsdir last call review of draft-ietf-core-hop-limit-05

From: Scott Bradner via Datatracker <[email-masked]>
Date: Thu, 26 Sep 2019 16:48:50 -0700

Reviewer: Scott Bradner
Review result: Has Issues

This ID proposes to add a hop-limit field to the Constrained Application
Protocol (CoAP) (RFC 7252).  This seems like a extremely logical thing to do –
so logical that it is baffling as to why the original protocol specification
did not include such a feature.  Section 5.10.2 of RFC 7252 puts the
responsibility of loop avoidance on the proxies (this seems to be the only
place loops are discussed in the RFC) – I did not review the working group
discussions to see why the WG did not use the very well known hop-limit concept
instead of relying on the perfect configuration of proxies.  If the original WG
had some reason it would be good to include a discussion of that reason in this
draft even to say that the hop-limit method avoids potential configuration
issues and thus is a more reliable way of ensuring quick termination of looping
behavior.

It seems to me that this ID should be seen as an update to RFC 7252 and thus it
should say so in the header and introduction.  If there is a reason that all
RFC 7252 implementations should not include the hop-limit feature this ID
should explain why an implementation should not.  Section 3 says that the hop
limit is an elective option but does not explain why it should not always be
turned on (since it would be ignored by older implementations that do not
understand it).

I agree with the comment that Roni made in his review about section 6.2 (that
the IANA registry does not include the option categories)  and would suggest
that section 6.2 specifically refer back to section 5.10 of RFC 7252 and say
that it is an extension of the table in the RFC.  (side note, seems to me that
the IANA registry should include the option categories)

As far as operational impact, this addition seems likely to minimize
operational issues (if it is actually used, which is what it seems to be that
it should be a required part of all implementations)

Other than the above observations, this ID seems ready to publish on the
standards track.

Scott

---

From: <[email-masked]>
Date: Fri, 27 Sep 2019 08:30:31 +0000

Hi Scott,

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Scott Bradner via Datatracker [mailto:[email-masked]]
> Envoyé : vendredi 27 septembre 2019 01:49
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; [email-masked]
> Objet : Opsdir last call review of draft-ietf-core-hop-limit-05
> 
> Reviewer: Scott Bradner

[Med] I will leave this one to the chairs as the authors don't have records to share. 

> should say so in the header and introduction.

[Med] We didn't include an "Updates" tag because basically we don't change any text from 7252. I hope the guidelines will be better in the future with draft-kuehlewind-update-tag. 

  If there is a reason that
> all
> should explain why an implementation should not.

[Med] The WG discussed these options: "Is hop-limit something that is (a) specific to DOTS, something that (b) it would now be reasonable to expect a proxy to add, or (c) something that every CoAP implementation should do?"

The conclusion of the WG is recorded in the draft: 

   The Hop-Limit option has originally been designed for a specific use
   case [I-D.ietf-dots-signal-channel].  However, its intended usage is
   general: CoAP proxies that do not have specific knowledge that proxy
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   
   forwarding loops are avoided in some other way, are expected to
   implement this option and have it enabled by default.

  Section 3 says that the
> hop
> I agree with the comment that Roni made in his review about section 6.2

[Med] Noted. We already made changes to address the comment from Roni. FWIW, the updated version is available at: https://github.com/boucadair/draft-hop-limit/blob/master/draft-ietf-core-hop-limit-06.txt (a diff is also available under the same repo).  

> (that
> that it is an extension of the table in the RFC.

[Med] No need to mention this is an "extension" of the table in 7252. The IANA registry is used to maintain the updated table.

  (side note, seems to me
> that

[Med] Thank you.

---

From: "Scott O. Bradner" <[email-masked]>
Date: Fri, 27 Sep 2019 06:59:34 -0400

> On Sep 27, 2019, at 4:30 AM, [email-masked] wrote:
> 
> 
>> (that

not quite the case - the IANA maintains a list of options - the table includes additional information not maintained by the IANA
(but maybe should be)

Scott

---

From: Jaime Jiménez <[email-masked]>
Date: Fri, 27 Sep 2019 14:49:46 +0300

Hi,

I do not know of the rationale for not adding the CUNR information for
each option, I'd assume that the respective RFC is enough for that.
Maybe Carsten or others can shed some light to that.

Ciao!

On Fri, Sep 27, 2019 at 06:59:34AM -0400, Scott O. Bradner wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: <[email-masked]>
Date: Fri, 27 Sep 2019 11:55:02 +0000

Re-,

Yes, you are right. 

But, this was fixed in the updated version I shared (https://github.com/boucadair/draft-hop-limit/blob/master/draft-ietf-core-hop-limit-06.txt): the structure of the table in the IANA section is aligned with the one in the IANA registry. 

The OLD table was moved into the core text. 

Cheers,
Med

> De : Scott O. Bradner [mailto:[email-masked]]
> Envoyé : vendredi 27 septembre 2019 13:00
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Objet : Re: Opsdir last call review of draft-ietf-core-hop-limit-05
> 
> 
> 
> >> that section 6.2 specifically refer back to section 5.10 of RFC 7252
> and
> >> say
> > [Med] No need to mention this is an "extension" of the table in 7252.
> The IANA registry is used to maintain the updated table.
> 
> not quite the case - the IANA maintains a list of options - the table
> includes additional information not maintained by the IANA
> (but maybe should be)
> 
> Scott

---

From: "Scott O. Bradner" <[email-masked]>
Date: Fri, 27 Sep 2019 07:56:03 -0400

> [Med] We didn't include an "Updates" tag because basically we don't change any text from 7252. I hope the guidelines will be better in the future with draft-kuehlewind-update-tag. 

that seems to be the wrong concept to me - your ID extends the technology in the RFC - to me that is an update

>   general: CoAP proxies that do not have specific knowledge that proxy

that seems rather well hidden - & maybe backward - the only place that the extension should not be used is where there is absolute
knowledge that the proxy does the job - that seems like a null case for software developer who can not know every situation
where the software will be used 

i.e. - to me
	1/ this option must be included in all new implementations
	2/ the option must be enabled by default 
	3/ the option may be turned off in a particular deployment if it is known that the proxy does the job

but even with #3 - what is the disadvantage of always using the option?

in any case there seems to be no downside to having a fuller discussion of when the option should be implemented & when it should be used (or not used)

Scott

---

From: "Scott O. Bradner" <[email-masked]>
Date: Fri, 27 Sep 2019 07:56:45 -0400

OK

> On Sep 27, 2019, at 7:55 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Re-,
> 
> Yes, you are right. 
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Sep 2019 14:24:39 +0200

Hi Jaime,

On the option registration scheme, Scott raises some good points that we should have had in mind in 2011..13 when all this was designed.  

CoAP’s main extension point is the “Option”, i.e. a TLV item (in a highly efficient encoding) that can be added to a request or response.  Options are maintained in a registry, which coordinates the code point space (Option number) and points to a spec.

Options have a number of properties/flags, which are typically shown in the specification that defines the option using a table like Table 4 of RFC 7252.
The Option number itself encodes a number of properties of an option, specifically the “C” (critical), “U” (proxy-unsafe), and “N” (not-a-cache-key) flags, so those three properties are available to any system processing the Option, whether the Option is known to it or not.
In other words, if you look closer, these three flags are captured in the registry because the Option number is.

The R flag (repeatable), the data type (format), the length range, and the default (if any) are not captured in the registry; these need to be taken from the Option specification.

This may not be the brightest way to run a registry (among other things, it relies heavily on the designated expert knowing about C/U/N and making sure that the option number encodes this properly, and it leads to squatters like ITU-T invariably choosing broken option numbers), but it is what we have been using for a while already.  So that part of the comments may be nudging us to reconsider our ways managing the CoAP Option registry, but is not specifically a comment on hop-limit.

The other question was why the hop-limit option isn’t made mandatory.  Med has already pointed out that the text of the draft does recommend its use in specific situations (i.e., where proxies are involved).  The transition strategy is somewhat mild, as proxies today don’t know the option, so its interpretation by a receiving instance is elective (i.e., not critical).
Application domains that do make use of complicated proxying structures (which is not the norm today for CoAP), such as DOTS, might make more stringent requirements.  Generally, we don’t use “updates” for specifications that merely exercise an extension point, so I don’t think hop-limit “updates” RFC 7252, but the “updates” label is in active discussion already anyway.

Grüße, Carsten

> On Sep 27, 2019, at 13:49, Jaime Jiménez <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Scott O. Bradner" <[email-masked]>
Date: Fri, 27 Sep 2019 08:32:43 -0400

> On Sep 27, 2019, at 8:24 AM, Carsten Bormann <[email-masked]> wrote:
> 
> .  Generally, we don’t use “updates” for specifications that merely exercise an extension point, so I don’t think hop-limit “updates” RFC 7252, but the “updates” label is in active discussion already anyway.

a major advantage of listing something like this as an update is that the implementor will know about it - if there is no hint in the index entry for the old RFC that there is a related RFC it would be
very easy to overlook 

Scott

---

From: <[email-masked]>
Date: Fri, 27 Sep 2019 12:35:35 +0000

Re-,

That's fair. This is supposed to be fixed in the future with "Extends/Extended by" tag in draft-kuehlewind-update-tag. 

I'm afraid that we can't do much for hop-limit. 

Cheers,
Med

> De : core [mailto:[email-masked]] De la part de Scott O. Bradner
> Envoyé : vendredi 27 septembre 2019 14:33
> À : Carsten Bormann
> Cc : [email-masked]; [email-masked];
> Objet : Re: [core] Opsdir last call review of draft-ietf-core-hop-limit-05
> 
> 
> 
> > .  Generally, we don’t use “updates” for specifications that merely
> exercise an extension point, so I don’t think hop-limit “updates” RFC
> 7252, but the “updates” label is in active discussion already anyway.
> 
> a major advantage of listing something like this as an update is that the
> implementor will know about it - if there is no hint in the index entry
> for the old RFC that there is a related RFC it would be
> very easy to overlook
> 
> Scott
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Sep 2019 14:39:22 +0200

> a major advantage of listing something like this as an update is that the implementor will know about it - if there is no hint in the index entry for the old RFC that there is a related RFC it woul…

True.  For a while, we had a “roadmap” draft for CoRE (https://tools.ietf.org/html/draft-bormann-core-roadmap-05 was the last update); maybe it’s time to resurrect this and provide a big picture for what is out there now and how it should be used.  
(Now, do I get a “roadmapped-by” tag on the original RFC?)

Grüße, Carsten