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 <jaime@xxxxxx> wrote: > > 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: >> >> >>> On Sep 27, 2019, at 4:30 AM, mohamed.boucadair@xxxxxxxxxx wrote: >>> >>> >>>> (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. >>> >>> [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 >> >> _______________________________________________ >> core mailing list >> core@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/core > >
