Re: [Dots] AD review of draft-ietf-dots-telemetry-16 (Sections 11-16)

[[e-mail]]

Hi Ben, 

Thank you for the detailed review. Much appreciated as usual. 

You can track the changes at: https://tinyurl.com/dots-telemetry-latest.

Please see inline for more context for Section 11 to 16. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots <[e-mail]> De la part de Benjamin Kaduk
> Envoyé : mercredi 24 novembre 2021 23:42
> À : [e-mail]
> Cc : [e-mail]
> Objet : [Dots] AD review of draft-ietf-dots-telemetry-16
> 
> Hi all,
> 
...
> 
> Section 11, 12.1
> 
> A handful of the entries in the tables still have an "ietf-dots-
> telemetry:" prefix, and I don't understand why only some of the entries
> would need it but not others.

[Med] This is because of the prefix conventions set in RFC7951:

   The name of a module determines the namespace of all data node names
   defined in that module.
   ...
   A namespace-qualified member name MUST be used for all members of a
   top-level JSON object and then also whenever the namespaces of the
   data node and its parent node are different.  In all other cases, the
   simple form of the member name MUST be used.

> 
> In particular, there seems to be an entry for both "total-traffic" and
> "ietf-dots-telemetry:total-traffic", and I don't understand how they are
> different.  (I did not check if there are other "duplicate"s like that.)

[Med] As a general rule: A telemetry attribute that is included in a mitigation request has to be prefixed with "ietf-dots-telemetry:", but it does not when it is included in a telemetry message.

> 
> Section 11
> 
>   | telemetry            | container   |TBA2  | 5 map         | Object |
> 
> I see both a "list telemetry" and a "case telemetry" in the YANG module,
> but I'm not sure which of them is supposed to correspond to the YANG type
> "container".
> https://datatracker.ietf.org/doc/html/rfc7950#section-7.9.2 does not
> really give me the impression that there is an implicit container of this
> name.
> 
>   | baseline             | container   |TBA49 | 5 map         | Object |
> 
> Similarly, I see a 'baseline' that's a list, as the only content of a
> "case baseline" statement.

[Med] Argh. We spent many cycles with Jon checking the tables. The type should be list. 

> 
> Section 12.1
> 
>    Note that 'lower-type' and 'upper-type' are also requested for
>    assignment in the call-home I-D.  Both I-Ds should be sync'ed as
>    depending the one that will make it first to the IANA.
> 
> (I think we tweaked call-home already to account for the registration
> requests being from different ranges between the two documents, but
> mention it just in case I'm misremembering.)

[Med] We don't have this note in -16.

> 
> Section 12.3
> 
>             URI: urn:ietf:params:xml:ns:yang:ietf-dots-mapping
>             Registrant Contact: The IESG.
>             XML: N/A; the requested URI is an XML namespace.
> 
> I wonder if this (module) name is perhaps somewhat more generic than the
> functionality it provides.
> 

[Med] We thought about other alternatives but all are very long (e.g., ietf-dots-vendor-attack-mapping, ietf-dots-attack-mapping) or do not hint what the module is about (e.g., ietf-dots-vam, ietf-dots-vendor-map). We prefer to keep this one. Thanks. 


> Section 13
> 
> Should we mention the security considerations for the blockwise transfer
> technologies?

[Med] We don't have any mention of blockwise because this is not specific to the telemetry spec and is already used in RFC9132. 

> 
> Looking through the YANG tree, the only thing that really sticks out as
> potentially worth mentioning here is the server-originated-telemetry
> option.  But even for that, I'm not sure that there's much to say.

[Med] Agree, especially that it relies upon the status update defined in 9132. 

> 
>    The DOTS telemetry information includes DOTS client network topology,
>    DOTS client domain pipe capacity, normal traffic baseline and
>    connections capacity, and threat and mitigation information.  Such
>    information is sensitive; it MUST be protected at rest by the DOTS
>    server domain to prevent data leakage.
> 
> I'd consider adding a sentence or two here noting that even though this
> data is sensitive, sending it explicitly to the DOTS server does not
> introduce any new significant considerations (other than the need for
> protection at rest) because the DOTS server is already trusted to have
> access to that kind of information by being in the position to mitigate
> (and observe) attacks.

[Med] Good suggestion. Added the following: 

NEW: 
   Note that sharing this
   sensitive data with a trusted DOTS server does not introduce any new
   significant considerations other that the need for the aforementioned
   protection.  Such a DOTS server is already trusted to have access to
   that kind of information by being in the position to observe and
   mitigate attacks.

> 
> Section 16.1
> 
> A normative reference on draft-ietf-dots-signal-filter-control will cause
> a document cluster, delaying publication until that document is ready to
> be an RFC. 

[Med] This was already published as RFC9133, but ...

 It's not clear to me that such a dependency is needed in this
> case, since there is only one citation to that document and it seems more
> descriptive than imposing a strong dependency.

[Med] you are right. it does not need to be cited as normative. Fixed. 

> 
> Similarly, we seem to cite RFC 7641 just as a statement of fact (clients
> can use CoAP OBSERVE), which may not require it to be classified as a
> normative reference.

[Med] ACK. observe is needed for asynchronous telemetry notification. Added this explicit statement to Section 5:

NEW:
  DOTS implementations MUST support the Observe Option for 'tm'.

> 
> Section 16.2
> 
> The current state of this document doesn't really include enough detail
> about percentiles and their calculation to be implementable without
> referring to RFC 2330, currently listed only as a normative reference.

[Med] I guess you meant informative. 

> I would prefer to add more text to this document rather than promote
> 2330 to a normative refrence, though I think we would need more text than
> I suggested above in order to achieve that effect.

[Med] I don't think we need to cite 2330 as normative. Made this change: 

OLD:
   o  Percentile-related measurement parameters.  

NEW:
   o  Percentile-related measurement parameters.  In particular,
      'measurement-interval' defines the period on which percentiles are
      computed, while 'measurement-sample' defines the time distribution
      for measuring values that are used to compute percentiles.
      Section 11.3 of [RFC2330] includes more details about computing
      percentiles.
 
> 
> We say we assume familiarity with RFC 8612 at least for terminology, which
> may indicate that it is best classified as a normative reference.
> 

[Med] I prefer to keep it as informative to be consistent with 8782, 8783, 9132, etc. Thanks.  

_________________________________________________________________________________________________________________________

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.