Re: [Dots] Genart last call review of draft-ietf-dots-telemetry-19

[Benjamin Kaduk <[e-mail]>]

Hi Med, Robert,

I echo the thanks to Robert for the review.
A few notes inline (trimming as needed)...

On Mon, Jan 24, 2022 at 12:08:32PM +0000, [e-mail] wrote:
> Hi Robert, 
> 
> Many thanks for the careful review. 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Robert Sparks via Datatracker <[e-mail]>
> > Envoyé : samedi 22 janvier 2022 00:01
> > À : [e-mail]
> > Cc : [e-mail]; [e-mail]; last-
> > [e-mail]
> > Objet : Genart last call review of draft-ietf-dots-telemetry-19
> > 
[...]
> > In 6.1.2, I'm confused by the requirement that "'tsid' values MUST
> > increase monotonically when a new PUT is generated"
> 
> [Med] The full context is: 
> 
>       " (when a new PUT is generated
>         by a DOTS client to convey new configuration parameters for the
>         telemetry). "

I think I see how this causes Robert to be confused.
In particular, a PUT is just a single CoAP request, but what we really mean
here is the persistent configuration object on the server that's identified
by the 'tsid'.  So, we should impose the requirement not on a "new PUT"
being generated, but rather that when we allocate a new tsid value for a
new configuration object, we must make that allocation in the monotonic
manner.

>  combined with "If
> > the dot server finds the 'tsid' parameter value conveyed in the PUT
> > request in its configuration data and (it) has accepted the updated
> > configuration parameters, a 2.04 (Changed) MUST be returned".
> 
> [Med] this one is to cover updating the change of a parameter that was already configured:
> 
>   "DOTS clients update their
>    telemetry setup configuration upon change of a parameter that may
>    impact attack mitigation."
> 
>  What am I
> > missing that would allow a PUT with a tsid that's already in the
> > server's configuration data? Is there perhaps leftover tension here from
> > earlier designs that were changed?
> > 
[...]
> > In 7.2, you require a freshly rebooted client to send a GET request to
> > retrieve active 'tmid' values. Why?
> 
> [Med] This allows (amnesic) clients to recover state. Whether they maintain all or a subset of recovered entries is then local to the client (policy, sanity checks, etc.). 

To attempt to expound on this a bit more, the state that the client would
be recovering applies (in some cases) to the entire client domain and not
just the client itself.  There is assumed to be some internal (e.g.,
monitoring or state synchronization) protocol within the domain to identify
the resources needing protection and the corresponding type of state
expected at the DOTS layer.  Deleting all state at the DOTS layer is very
unlikely to be a useful response to a client reboot.  (Which does not
definitively force a strict prohibition on going straight to DELETE without
GET, but it's why I didn't have a problem with the specified behavior.)

-Ben

>  Why not let it just send a DELETE
> > with no 'tmid'
> > right away if that's what it would do after receiving the response to
> > the GET anyhow?
> >