Subject: [core] Review Comments on draft-boucadair-core-hop-limit

From: Jim Schaad <[email-masked]>
Date: Wed, 22 Aug 2018 21:19:26 -0700

Section 3 - para 2 - It would be clearer to me to say that the Hop-Limit
value is between 0 and 255 inclusive rather than talk about the length of
the option because I don't know if that includes all of the option encoding
bytes or not.

Section 3 - para 4 - Probably does not matter, but the current algorithm
wastes one bit.  Check for 0 and then decrement would give one addition
possible field.  It would also compress down the size of the encoded option
faster.

Section 3 - I don't know that you only want to have a proxy information
appearing once.  If it appears multiple times then you can easily spot the
loop.  No real option one way or the other.

Section 3 - Last paragraph - I presume that a border proxy could remove
rather than re-write the option as well.  This would be esp. true if for
example it was changing transports.

Section 4.2 - Someplace there needs to be a discussion on why the values of
C, U and N

I would have expected the values to be
- Critical - no
- Unsafe - no - a proxy which does not understand the option should still
forward it on.  At worst you will get the same behavior as if the option was
not included. 
- NoCacheKey - yes - If you get two gets for the same resource with
different hop counts the proxy should still be able to return the currently
cached value.

Section 5 - There is a potential privacy consideration that may need to be
covered.  The return value is going to provide an eavesdropper a large
amount of information on the configuration of the network.  Is there value
to configuring so that the error but not the trace stack is provided?