Skip to main content

Last Call Review of draft-ietf-core-hop-limit-05
review-ietf-core-hop-limit-05-opsdir-lc-bradner-2019-09-26-00

Request Review of draft-ietf-core-hop-limit
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2019-09-27
Requested 2019-09-13
Authors Mohamed Boucadair , Tirumaleswar Reddy.K , Jon Shallow
Draft last updated 2019-09-26
Completed reviews Opsdir Last Call review of -05 by Scott O. Bradner (diff)
Genart Last Call review of -05 by Roni Even (diff)
Secdir Last Call review of -05 by Radia Perlman (diff)
Assignment Reviewer Scott O. Bradner
State Completed
Review review-ietf-core-hop-limit-05-opsdir-lc-bradner-2019-09-26
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/PrLw2AqqGNMrsiQ2mdkJTncbB_w
Reviewed revision 05 (document currently at 07)
Result Has Issues
Completed 2019-09-26
review-ietf-core-hop-limit-05-opsdir-lc-bradner-2019-09-26-00
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.

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

Scott