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
