Re: [Last-Call] [yang-doctors] Yangdoctors last call review of draft-ietf-dots-telemetry-14

[Andy Bierman <[e-mail]>]

On Thu, Nov 26, 2020 at 10:22 PM <[e-mail]> wrote:

> Hi Andy, all
>
>
>
> Thanks.
>
>
>
> One clarification in reference to this comment:
>
>
>
> « But you are raising an important point -- it is difficult to review
> groupings without any context.
>
> (Without any "uses"). »
>
>
>
> Please note that all defined groupings are used in this draft.
>
>
>

I meant "visible" uses-stmt.

   - The sx:structure statement is external to the YANG language. It is
   (literally) not part of YANG.
   - The mapping of YANG restrictions in the description-stmt for this
   structure is intentionally vague.
   - There is no mapping to NMDA or any concept of a datastore
   - There is no mapping to any YANG defined content for NETCONF or RESTCONF
   - There is no mapping to NACM or any concept of access control

Jan is assuming that this YANG module needs to be reviewed within the
context of specific
(standard) management protocols. I don't think YANG Doctors ever discussed
the guidelines
and review requirements for standard structures. IMO structure-only
documents are OK
and can be reviewed for YANG correctness, consistency, and maintainability.

I would expect any protocol that uses the structure extension to address
all the missing mappings
listed above.


Cheers,
>
> Med
>


Andy


>
>
> *De :* Andy Bierman [mailto:[e-mail]]
> *Envoyé :* jeudi 26 novembre 2020 18:46
> *À :* Jan Lindblad <[e-mail]>
> *Cc :* YANG Doctors <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *Objet :* Re: [yang-doctors] Yangdoctors last call review of
> draft-ietf-dots-telemetry-14
>
>
>
>
>
>
>
> On Thu, Nov 26, 2020 at 3:36 AM Jan Lindblad via Datatracker <
> [e-mail]> wrote:
>
> Reviewer: Jan Lindblad
> Review result: Almost Ready
>
> Dear Dots Authors, NETMOD WG,
>
> This is my YD LC review of draft-ietf-dots-telemetry-14. This draft
> contains
> two YANG modules, ietf-dots-telemetry and module ietf-dots-mapping. Both
> modules are unusual from a YANG perspective in that they consist of solely
> typedefs, groupings and sx:structures, and that their purpose is to define
> message bodies for a domain specific management protocol.
>
>
>
>
>
> This is consistent with the intent of RFC 8791.
>
>
>
> People have realized that a formal message definition that can be
> integrated
>
> into the tool chain is much better than 100 pages of ASCII art.  Augments,
>
> annotations, and deviations are not only possible, but critical to
> deployment.
>
>
>
> But you are raising an important point -- it is difficult to review
> groupings without any context.
>
> (Without any "uses").
>
>
>
> Since my previous review of this module (-09, June 2020) the underpinnings
> of
> the modules have changed significantly with a new RFC in the works,
> addressing
> the fundamental issues pointed out at that time. Very good & impressive. I
> still think there are important issues to resolve, so I will call the
> current
> state of -14 "Almost Ready".
>
> Links to previous relevant reviews:
>
> https://datatracker.ietf.org/doc/review-ietf-dots-rfc8782-bis-00-yangdoctors-early-aries-2020-09-23/
>
> https://datatracker.ietf.org/doc/review-ietf-dots-telemetry-09-yangdoctors-early-lindblad-2020-06-30/
>
> Because of this hitherto unusual application of YANG, the usual YD review
> procedures are not really applicable. Whoever reads this should feel free
> to
> comment on which perspectives should be included (or not) in an YD review
> of a
> YANG module defining a new protocol.
>
> I think the YD review should not be expected to cover the
> usability/interoperability of the newly defined protocol as a whole. E.g.
> which
> messages are sent when, what is the relevant/reasonable content in each
> message, are there any races or scalability issues, etc. IMO, such an
> analysis
> is essential, but too much work for an YD review (and outside my area of
> expertise). I have placed my review focus on the clear interpretation of
> the
> YANG modules, since that will be key to interoperability.
>
>
>
>
>
> Agreed.  The protocol document review is a separate matter.
>
>
>
>
>
> When YANG is mapped to NETCONF or RESTCONF, there are entire RFCs devoted
> to
> describing how that mapping is done, from what "mandatory" actually means
> in
> the protocol and how keys are sent, all the way to how the XML or JSON
> payloads
> are constructed and potential error messages. A lot more of that mapping
> is now
> present in this document, but I still find many aspects that are
> undefined/unclear.
>
>
>
> But this is related to the message encoding, not the YANG definitions.
>
> YANG is (trying to be) encoding-independent, and the YANG to CBOR and SID
> drafts explain
>
> how to encode any type of YANG data in CBOR.
>
>
>
>
>
>
>
> Andy
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>