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

Hi all, 

The change proposed by Thomas is sensible. 

Since no objection was raised, we will implement the following change in -07:

OLD:
    CoAP proxies that do not have specific knowledge that proxy
    forwarding loops are avoided in some other way, MUST
    implement this option and have it enabled by default.

NEW:
    New CoAP proxies MUST implement this option and have it
    enabled by default.

Cheers,
Med

> -----Message d'origine-----
> De : core [mailto:core-bounces@ietf.org] De la part de
> mohamed.boucadair@orange.com
> Envoyé : jeudi 3 octobre 2019 08:10
> À : Thomas Fossati; Carsten Bormann
> Cc : core@ietf.org
> Objet : Re: [core] Opsdir last call review of draft-ietf-core-hop-limit-05
> 
> Hi Thomas, all,
> 
> Now that the WG went for a "MUST", I think that your proposed wording is
> much better.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : core [mailto:core-bounces@ietf.org] De la part de Thomas Fossati
> > Envoyé : mercredi 2 octobre 2019 18:31
> > À : Carsten Bormann
> > Cc : core@ietf.org
> > Objet : Re: [core] Opsdir last call review of draft-ietf-core-hop-limit-
> 05
> >
> > Hi Carsten,
> >
> > [trimming the CC list to CoRE only]
> >
> > On 02/10/2019, 16:47, "core on behalf of Carsten Bormann" <core-
> > bounces@ietf.org on behalf of cabo@tzi.org> wrote:
> > > In the CoRE Virtual Interim we just had (minutes to be posted), we
> > > said that the WG wouldn’t have a problem with changing the “are
> > > expected to” (implement and default-enable) in Section 1.1 into a
> > > stronger MUST.  This would still leave the option for a Proxy operator
> > > to turn off the use of the Option, i.e., a receiver cannot rely on
> > > actually receiving it.  Let’s wait for the ADs to chime in on that…
> >
> > Having thought a bit more on the specific change that was discussed
> > during the interim:
> >
> >    CoAP proxies that do not have specific knowledge that proxy
> >    forwarding loops are avoided in some other way, MUST
> >    implement this option and have it enabled by default.
> >
> > I think this should be tweaked further.
> >
> > How I read the sentence is: "You can't deploy a proxy box that can
> > potentially be part of a forwarding loop, if that box is not able to
> > understand and process the option."
> >
> > Trouble is that the conditional clause looks implausible in general - it
> > seems to presume divination skills.
> >
> > If we want this option to be part of the future CoAP ecosystem (which I
> > think is a good thing), we should just say something like:
> >
> >    Newly deployed CoAP proxies MUST implement this option and have it
> >    enabled by default.
> >
> > One of the good properties about this option IIUC is that even one
> > implementer can make a difference -- i.e., you don't need fork-lift
> > upgrades to start getting some benefit.
> >
> > Cheers, t
> >
> >
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> > confidential and may also be privileged. If you are not the intended
> > recipient, please notify the sender immediately and do not disclose the
> > contents to any other person, use it for any purpose, or store or copy
> the
> > information in any medium. Thank you.
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core