Re: [core] Opsdir last call review of draft-ietf-core-hop-limit-05

["Scott O. Bradner" <[e-mail]>]

> On Sep 27, 2019, at 4:30 AM, [e-mail] 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