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

[Scott Bradner via Datatracker <[e-mail]>]

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.

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