Subject: [Dots] Robert Wilton's No Objection on draft-ietf-dots-telemetry-21: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 03 Feb 2022 03:26:05 -0800

Robert Wilton has entered the following ballot position for
draft-ietf-dots-telemetry-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this document.  I have no major comments, but do have a few minor
ones.

1. I wonder if the abstract/introduction can be clearer that this is an
extension to the data channel as well as the signal channel, although I
appreciate that the vast majority of this document is about telemetry
communicated via the signal channel.

2. I found the text in section 7.1.2 related to tsids to be somewhat unclear. 
When I first read this paragraph:

   tsid:  Telemetry Setup Identifier is an identifier for the DOTS
        telemetry setup configuration data represented as an integer.
        This identifier MUST be generated by DOTS clients.  'tsid'
        values MUST increase monotonically (when a new PUT is generated
        by a DOTS client to convey new configuration parameters for the
        telemetry).

and

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

It gave me the impression that a new PUT request with a new tsid completely
replaces all configuration provided by any lower tsid, but I don't think that
is is the intent.  Perhaps this could be made clearer?

3.
   *  If the DOTS server finds the 'tsid' parameter value conveyed in
      the PUT request in its configuration data and if the DOTS server
      has accepted the updated configuration parameters, 2.04 (Changed)
      MUST be returned in the response.

I was wondering why not error this case and not except the config change
(presumably this is a simple error if the client has used the same tsid)?

4. The YANG is obviously being used in a different way here than for regular
network device configuration, but this still means that you end up with
descriptions of various properties in two places in the document, once in the
main part of the text and once in the YANG data model, which makes the document
both somewhat more verbose and also runs the risk of discrepancies between what
is in the YANG vs what is described earlier in the document.  For regular YANG
data models, the preferred approach is try and have the full normative
definitions in the YANG module, and keeps the text outside of the model to be
more informative/descriptive of the expected behavior, partly because of the
expectation to be able to generate user documentation from the description
statements.  I don't know if you would ever be expected to generate a UI
description from the YANG module for DOTS telemetry, but you might want to
double check that have you the right balance between whether the text in the
YANG module of the main description is definitive and whether there should be
any statement in the document to indicate which text is regarded as definitive
if there is any discrepancy between the two descriptions.

5. I agree with Warren's comments regarding whether allowing a choice of units
and scaling causes additional complexity that could perhaps be avoided.

Regards,
Rob

---

From: <[email-masked]>
Date: Thu, 3 Feb 2022 14:01:02 +0000

Hi Rob, 

Many thanks for the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Robert Wilton via Datatracker <[email-masked]>
> Envoyé : jeudi 3 février 2022 12:26
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Robert Wilton's No Objection on draft-ietf-dots-telemetry-21:
> (with COMMENT)
> 
> Thanks for this document.  I have no major comments, but do have a few
> minor ones.
> 

[Med] Sure. We added this NEW text to the abstract of -21: "It also specifies a second YANG module to share the attack mapping details over the DOTS data channel."

Added this NEW to the introduction:

   Also, the document specifies a YANG module (Section 11.2) that
   augments the DOTS data channel [RFC8783] with attack details
   information.  Sharing such details during 'idle' time is meant to
   optimize the data exchanged over the DOTS signal channel.

> It gave me the impression that a new PUT request with a new tsid
> completely replaces all configuration provided by any lower tsid, but I
> don't think that is is the intent.

[Med] That’s the intent for PUT requests that  ** carry telemetry configuration data **. I think the last sentence is clear enough. 

The text repeats "telemetry configuration data" as we have the following: 

   In reference to Figure 1, a DOTS telemetry setup message MUST include
   only telemetry-related configuration parameters (Section 7.1) or
   information about DOTS client domain pipe capacity (Section 7.2) or
   telemetry traffic baseline (Section 7.3).  As such, requests that
   include a mix of telemetry configuration, pipe capacity, and traffic
   baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request).

+ specific tsid behavior for the other two cases, e.g.,: 

      The relative order of two PUT requests carrying DOTS client domain
      pipe attributes from a DOTS client is determined by comparing
      their respective 'tsid' values.  If such two requests have
      overlapping 'link-id' and 'unit', the PUT request with higher
      numeric 'tsid' value will override the request with a lower
      numeric 'tsid' value.  The overlapped lower numeric 'tsid' MUST be
      automatically deleted and no longer be available.

  Perhaps this could be made clearer?
> (presumably this is a simple error if the client has used the same

[Med] because we accept to "update" values of already communicated configuration without having to include all other parameters in the "update" request. Otherwise, the client will need to include all the parameters each time it generates a new tsid. if not, the server will use default values for parameters that are not present. 

> 
> 4. The YANG is obviously being used in a different way here than for
> regular network device configuration, but this still means that you end
> up with descriptions of various properties in two places in the
> document, once in the main part of the text and once in the YANG data
> model, which makes the document both somewhat more verbose and also runs
> the risk of discrepancies between what is in the YANG vs what is
> described earlier in the document.  For regular YANG data models, the
> preferred approach is try and have the full normative definitions in the
> YANG module, and keeps the text outside of the model to be more
> informative/descriptive of the expected behavior, partly because of the
> expectation to be able to generate user documentation from the
> description statements.  I don't know if you would ever be expected to
> generate a UI description from the YANG module for DOTS telemetry, but
> you might want to double check that have you the right balance between
> whether the text in the YANG module of the main description is
> definitive and whether there should be any statement in the document to
> indicate which text is regarded as definitive if there is any
> discrepancy between the two descriptions.
> 

[Med] We do already have the following: 

   The authoritative reference for validating telemetry messages
   exchanged over the DOTS signal channel are Sections 7, 8, and 9
   together with the mapping table established in Section 12.

> 5. I agree with Warren's comments regarding whether allowing a choice of
> units and scaling causes additional complexity that could perhaps be
> avoided.
> 
> Regards,
> Rob
> 
> 

_________________________________________________________________________________________________________________________

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.