Last Call Review of draft-ietf-core-hop-limit-05
review-ietf-core-hop-limit-05-secdir-lc-perlman-2019-10-03-00

Request Review of draft-ietf-core-hop-limit
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-09-27
Requested 2019-09-13
Draft last updated 2019-10-03
Completed reviews Opsdir Last Call review of -05 by Scott Bradner (diff)
Genart Last Call review of -05 by Roni Even (diff)
Secdir Last Call review of -05 by Radia Perlman (diff)
Assignment Reviewer Radia Perlman
State Completed
Review review-ietf-core-hop-limit-05-secdir-lc-perlman-2019-10-03
Posted at https://mailarchive.ietf.org/arch/msg/secdir/N2cvdMOCXwWqsnqDCUgkl7pngUc
Reviewed rev. 05 (document currently at 06)
Review result Has Nits
Review completed: 2019-09-28

Review
review-ietf-core-hop-limit-05-secdir-lc-perlman-2019-10-03

   I have reviewed this document as part of the security directorate's
    ongoing effort to review all IETF documents being processed by the
    IESG.  These comments were written primarily for the benefit of the
    security area directors.  Document editors and WG chairs should treat
    these comments just like any other last call comments.

Summary:  This document is fine.

This document defines an option for preventing infinite loops of
Constrained Application Protocol (CoAP) proxies. The document says
that infinite forward loops is undesirable", which is a cute wording.

I'm very much in favor of hop count limits whenever things are
forwarded (I was always somewhat terrified of forwarding Ethernet
packets without a hop count).

If I have to make an editorial comment (to show I was awake when
reading this), I might comment about this text:

  "If no initial value is explicitly provided, the default initial
Hop-Limit value of
   16 MUST be used.  This value is chosen to be sufficiently large to
   guarantee that a CoAP request would not be dropped in networks when
   there were no loops, but not so large as to consume CoAP proxy
   resources when a loop does occur.

My quibble with that text is that if there were a value that would
always be sufficiently large that a request would never be prematurely
dropped, and not so large as to consume resources because of loops not
being detected soon enough, then it needn't be configurable...just
always use that value.

So, maybe the text should say "this value is chosen so that in the
majority of cases it is sufficiently large...but is still configurable
to accommodate unusual topologies.


Radia