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

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Jim Schaad [mailto:[e-mail]]
> Envoyé : mercredi 12 septembre 2018 16:52
> À : BOUCADAIR Mohamed IMT/OLN; [e-mail]
> Cc : 'core'; [e-mail]
> Objet : RE: Review Comments on draft-boucadair-core-hop-limit
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] <[e-mail]>
> > Sent: Wednesday, September 12, 2018 1:19 AM
> > To: Jim Schaad <[e-mail]>; draft-boucadair-core-hop-
> > [e-mail]
> > Cc: 'core' <[e-mail]>; [e-mail]
> > Subject: RE: Review Comments on draft-boucadair-core-hop-limit
> >
> > 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 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?

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

> 
> > >
> > > 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.
> 
> 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.
> >
> > 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.
> 
> That would be fine.

[Med] OK, thanks.

> 
> Jim
> 
>