Hi Scott, Thank you for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Scott Bradner via Datatracker [mailto:noreply@xxxxxxxx] > Envoyé : vendredi 27 septembre 2019 01:49 > À : ops-dir@xxxxxxxx > Cc : draft-ietf-core-hop-limit.all@xxxxxxxx; ietf@xxxxxxxx; core@xxxxxxxx > 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
