Re: [Dots] Francesca Palombini's Discuss on draft-ietf-dots-telemetry-20: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Francesca,

Please see inline for the diagnostic notation comment.

Cheers,
Med

De : Dots <[e-mail]> De la part de Francesca Palombini
Envoyé : mercredi 2 février 2022 14:57
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; The IESG <[e-mail]>
Cc : [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: [Dots] Francesca Palombini's Discuss on draft-ietf-dots-telemetry-20: (with DISCUSS and COMMENT)

Hi Med,

Answers inline.

Thanks,
Francesca

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
...


Thank you for the careful review. The changes can be tracked at: https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-90283074e9eba628&q=1&e=a4b1b643-167e-4fad-bbea-997afe323130&u=https%3A%2F%2Ftinyurl.com%2Fdots-telemetry-latest

Please see inline for more context.

Cheers,
Med

> -----Message d'origine-----
...
> 1. -----
>
>    JSON encoding of YANG-modeled data is used to illustrate the various
>    telemetry operations.
>
> FP: There is an inconsistency between this text and the use of
> "application/dots+cbor" in the examples. Either the Content-Format
> should be changed

[Med] The content format "application/dots+cbor" is correct.
FP: Thank you for confirming that application/dots+cbor is the correct format. The inconsistency I noted is that in all the examples, instead of using CBOR diagnostic notation (which I expected for an example in CBOR), you use the JSON encoding for the CoAP payload. I also understand that it is for readability purposes ("status": "attack-successfully-mitigated" is more readable than "status": 2), but that can be easily mitigated by adding comments, instead of reporting the examples body in JSON when they should be CBOR. So for example:

OLD:            "status": "attack-successfully-mitigated",

NEW:           "status": 2,      ; "attack-successfully-mitigated",



By the way most of these changes are very simple: for example "start-time": "1608336568" would become "start-time": 1608336568



[Med] We used to consider that when developing 8782/9132 but preferred the current approach that we called at the time "JSON diagnostic notation". That notation was followed then by other RFCs such as 9133 and 9066. We prefer to use the same notation in this document as well. We made this change to hopefully clarify the usage:



OLD:

   JSON encoding of YANG-modeled data is used to illustrate the various

    telemetry operations.

NEW:

   JSON encoding of YANG-modeled data is used to illustrate the various

   telemetry operations.  To ease readability, parameter names and their

   JSON types are, thus, used in the examples rather than their CBOR key

   values and CBOR types following the mappings in Section 12.  These

    conventions are inherited from [RFC9132].

, or all the examples should be adapted to JSON
> Content-Format (I am not sure about what Content-Format you should use
> then, you probably know better).

[Med] We are actually using the convention/notation introduced in RFC9132 to ease the readability of the bodies. RFC9132 includes an example to illustrate the CBOR equivalent (Figure 8).
FP: Just to be clear, I don't think it is necessary to illustrate the examples in CBOR encoding (so the equivalent of Fig 8 in 9132), but I do think it is worth using CBOR diagnostic notation instead of JSON. Also because with no note about this, one could interpret the example to be CBOR diagnostic notation with all the types wrong (string every time it's something else).
[Med] This is a fair comment. I hope this is addressed with the proposed change above. 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.