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

From: <[email-masked]>
Date: Wed, 12 Sep 2018 08:19:01 +0000

Hi Jim, all, 

Thank you for sharing the comments.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Jim Schaad [mailto:[email-masked]]
> Envoyé : jeudi 23 août 2018 06:19
> À : [email-masked]
> 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.

---

From: Jim Schaad <[email-masked]>
Date: Wed, 12 Sep 2018 07:52:20 -0700

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: Wednesday, September 12, 2018 1:19 AM
> To: Jim Schaad <[email-masked]>; draft-boucadair-core-hop-
> [email-masked]
> Cc: 'core' <[email-masked]>; [email-masked]
> Subject: RE: Review Comments on draft-boucadair-core-hop-limit
> 
> Hi Jim, all,
> 
> > De : Jim Schaad [mailto:[email-masked]] Envoyé : jeudi 23 août
> > 2018 06:19 À : [email-masked]
> > Cc : 'core'
> > 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.

Did you miss this?

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

Looks like I was half asleep - should have been no real opinion either way.
This is fine.  You may want to comment on that but I don't really care.

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

That would be fine.

Jim

---

From: <[email-masked]>
Date: Wed, 12 Sep 2018 15:06:04 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 12 septembre 2018 16:52
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Cc : 'core'; [email-masked]
> Objet : RE: Review Comments on draft-boucadair-core-hop-limit
> 
> 
> 

[Med] Actually, no. I discussed with my co-authors. Tiru proposed this change: 

"CoAP messages MUST NOT be forwarded if the Hop-Limit option is set to '0' before decrement." 

But I'm not sure this is superior to what we had already in the draft which allows to detect the loop earlier in the forwarding path. 

Please let us know if we missed your point. 

> > instructed to strip the diagnostic payload or part of it before forwarding

[Med] OK, thanks.