Re: [Dots] AD review of draft-ietf-dots-telemetry-16

[[e-mail]]

Re-,

Please find below some follow-up replies.

Cheers,
Med

> -----Message d'origine-----
> De : Dots <[e-mail]> De la part de Benjamin Kaduk
> Envoyé : mardi 28 décembre 2021 16:41
> À : tirumal reddy <[e-mail]>
> Cc : [e-mail]; [e-mail]
> Objet : Re: [Dots] AD review of draft-ietf-dots-telemetry-16
> 
> Hi Tiru,
> 
> Thanks for these (and thanks Med as well for the additional follow-up; I
> don't think I have any replies to that part).
> A few comments inline...
> 
...
> > >
> > > It looks like we have to use backslash continuation markers for
> several of
> > > the CoAP request target resources in the examples; do we want to
> reference
> > > RFC 8792 folding and use its specific note text about line wrapping?
> > >
> > > There are a few places where we say something like "the DOTS client
> MUST
> > > auto-scale so that the appropriate unit is used".  (1) We don't
> > > specifically
> > > say what the goal of this automatic behavior is (I guess, use the
> "largest
> > > unit" that gives a value greater than one?), and (2) it seems that we
> are
> > > in
> > > part relying on this behavior to ensure that the client only specifies
> one
> > > measure in a given unit class.  That is, I didn't see anything else
> that
> > > would prevent a client from sending (say) both Mbps and Gbps values,
> that
> > > could of course be in conflict with each other -- if there's a
> potential
> > > for
> > > conflict we'd need to say how to resolve the conflict.
> > >
> > > Relatedly, there seems to *also* be potential for conflict in that we
> allow
> > > both bit/second and Byte/second as unit-classes.  What is to happen if
> I
> > > say
> > > that something is both 2 bit/second and 2 Byte/second?
> 
> Med's follow-up implies that we are to just treat that as "invalid
> parameters".  I'd prefer to be more explicit about that, e.g., with a
> statement like "at most one of the bit/second and Byte/second unit-class
> entries can be present; if such conflicting values are received the
> combination is treated as specifying an illegal parameter and rejected
> with
> 4.00 (Bad Request)".

[Med] Added this NEW text: 

"Supplying both bits per second and bytes per second unit-classes is allowed for a given telemetry data. However, receipt of conflicting values is treated as invalid parameters and rejected with 4.00 (Bad Request)."

> 
> > > We have a lot of examples that use the same 'cuid' of
> > > dz6pHjaADkaFTbjr0JGBpw, which is fine and representative of normal
> > > operation.  Do we want to curate the 'tsid' and 'tmid' values used by
> that
> > > client?  I see some reuse, which I think is not prohibited (at least
> for
> > > 'tsid'), but may merit checking, and the values are not monotonically
> > > increasing throughout the course of the document, which may or may not
> be
> > > desirable.
> 
> Did you have any thoughts on this part?

[Med] The reuse of some ids is normal as this is done to retrieve or to delete an entry. Made some changes to monotonically increase ids (https://tinyurl.com/dots-telemetry-latest).  

...
> > >
> > > Section 6
> > >
> > >    Telemetry setup configuration is bound to a DOTS client domain.
> DOTS
> > >    servers MUST NOT expect DOTS clients to send regular requests to
> > >    refresh the telemetry setup configuration.  Any available telemetry
> > >    setup configuration has a validity timeout of the DOTS association
> > >    with a DOTS client domain.  [...]
> > >
> > > The term "DOTS association" does not seem to have been used previously
> > > (in RFC 9132 we discuss the "DOTS session" heavily, though).  Also, I
> 
> Are we planning to keep the "DOTS association" phrasing?

[Med] Changed to: "Any available telemetry setup configuration is valid till the DOTS server ceases to service a DOTS client domain."

> 
> > > don't remember any previous requirement to keep state on the server
> for
> > > the duration of anything scoped to the entire client *domain*, just
> > > individual DOTS sessions.  We do mention detecting
> conflicts/overlapping
> > > requests within the scope of a client domain, in RFC 9132, but as far
> as
> > > I can tell that only holds when all the DOTS sessions involved in the
> > > conflict are still active.
> > >
> > > Perhaps related, this discussion (at least so far) is not clear to me
> > > about what level of coordination/consistency is expected between
> clients
> > > in the same domain.  I believe that stock DOTS works fine with no such
> > > coordination amongst clients within a domain, so if we are introducing
> such
> > > a requirement we should say prominently that it's a change.
> > >
> >
> > Yes, telemetry configuration is not specific to the client. For example,
> > the pipe capacity is specific to the site.
> 
> So what happens if there are two clients in a site and they are reporting
> different values for pipe-capacity?

[Med] This is covered in this part:

   A DOTS server may detect conflicts between requests conveying pipe
   and baseline information received from DOTS clients of the same DOTS
   client domain. 'conflict-information' is used to report the conflict
   to the DOTS client following similar conflict handling discussed in
   Section 4.4.1 of [RFC9132].

> 
> I think I'm just generally unsure what the expected division of work is
> between multiple clients in a domain, so my questions involve a lot of
> speculating and I don't have a good suggestion for changes to the text
> yet.
> 
> >
> > >
> > > Section 6.1.1
> > >
> > >    Upon receipt of such request, and assuming no error is encountered
> by
> > >    processing the request, the DOTS server replies with a 2.05
> (Content)
> > >    response that conveys the current and telemetry parameters
> acceptable
> > >    by the DOTS server.  [...]
> > >
> >
> > NEW:
> >
> > Upon receipt of such request, and assuming no error is encountered by
> >
> > processing the request, the DOTS server replies with a 2.05 (Content)
> >
> > response that conveys the telemetry parameters acceptable by the DOTS
> > server
> >
> > and the current baseline information maintained by the DOTS server.
> >
> >
> > >
> > > (editorial) Something seems off, here (around "current and telemetry
> > > parameters acceptable").  Is it returning current configuration,
> acceptable
> > > parameter values, or some combination thereof?
> > >
> > >           |  |     +-- query-type*            query-type
> > >
> > > Since this is a leaf-list of supported query types, should the list
> name
> > > include the word "supported" or similar?
> > >
> > > Section 6.1.2
> > >
> > >    The PUT request with a higher numeric 'tsid' value overrides the
> DOTS
> > >    telemetry configuration data installed by a PUT request with a
> lower
> > >    numeric 'tsid' value.  To avoid maintaining a long list of 'tsid'
> > >    requests for requests carrying telemetry configuration data from a
> > >    DOTS client, the lower numeric 'tsid' MUST be automatically deleted
> > >    and no longer be available at the DOTS server.
> > >
> > > The way this is phrased with "the lower" and "higher" (vs "highest")
> > > assumes
> > > or implies that there is only one "lower" 'tsid' value, perhaps
> leaving
> > > some
> > > ambiguity if there is actually more than one.  We might make a
> statement
> > > about how there is only at most one active 'tsid' per 'cuid'+'cdid' at
> a
> > > time other than during a config change (if that's the intent), or
> > > alternatively to qualify that the requirement to remove is only
> incurred in
> > > the event of a conflict (as is done for other types of config, later).
> > >
> >
> > We can have multiple tsids for the same client for pipe/baseline
> > information. This is why we have:
> >
> 
> Ok.  Should we say something like "when telemetry configuration data is
> received that has overlapping scope with existing telemetry configuration,
> the PUT request with higher numeric 'tsid' value [...]"?
> 

[Med] Actually, there is only one tsid in the context of 6.1.2. I don't think a change is needed to the OLD text. Of course, multiple tsids are allowed for pipe/baseline but that is covered in 6.2.1/6.3.1.

Thank you. 

> The rest of this looks good; thanks again for all the updates.
> 
> -Ben

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.