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

[<[e-mail]>]

Hi Scott,

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Scott Bradner via Datatracker [mailto:[e-mail]]
> Envoyé : vendredi 27 septembre 2019 01:49
> À : [e-mail]
> Cc : [e-mail]; [e-mail]; [e-mail]
> Objet : Opsdir last call review of draft-ietf-core-hop-limit-05
> 
> 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.

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

> 
> 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. 


  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.


  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

[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
> 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.

  (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.

[Med] Thank you.

> 
> Scott