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

[<[e-mail]>]

Hi Jim, all, 

Thank you for sharing the comments.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Jim Schaad [mailto:[e-mail]]
> Envoyé : jeudi 23 août 2018 06:19
> À : [e-mail]
> Cc : 'core'
> Objet : Review Comments on draft-boucadair-core-hop-limit
> 
> 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.
> 

[Med] Done in my local copy. 

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

[Med] We had that restrictions for two reasons:
- ease correlation between hop count and the information recorded in the body.
- maintain a reasonable message size. 

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

[Med] Yes, fixed in my local copy. 

> 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

[Med] Agree. 

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

[Med] We set it to "Unsafe - yes" for the DOTS case because the proxies are under the control of the same entity and we wanted to have something reliable. I do agree that for the general CoAP case, we can relax that to "Unsafe - no"

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

[Med] Will add some text to explain the rationale for setting the C/U/N values. Thanks. 

> 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?
> 
> 

[Med] Good point. There is still a value in returning the error even without the trace as this allows a peer to know why a request failed. Proxies at boundaries are supposed to generate alarms to administrators.

We can consider adding the following: 
- a proxy which is located at the boundary of an administrative domain may be instructed to strip the diagnostic payload or part of it before forwarding 5.06 upstream.