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

[Robert Wilton via Datatracker <[e-mail]>]

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