> On Sep 27, 2019, at 4:30 AM, mohamed.boucadair@xxxxxxxxxx wrote: > > >> >> 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. > > [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 > > > 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. > > [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. 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
