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

[[e-mail]]

Hi Rob, 

Many thanks for the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Robert Wilton via Datatracker <[e-mail]>
> Envoyé : jeudi 3 février 2022 12:26
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Robert Wilton's No Objection on draft-ietf-dots-telemetry-21:
> (with COMMENT)
> 
> 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.

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

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

[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?
> 
> 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)?

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