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.
- 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
Cheers,
Med
De : Andy Bierman [mailto:andy@xxxxxxxxxxxxx]
Envoyé : jeudi 26 novembre 2020 18:46
À : Jan Lindblad <janl@xxxxxxxxxx>
Cc : YANG Doctors <yang-doctors@xxxxxxxx>; last-call@xxxxxxxx; draft-ietf-dots-telemetry.all@xxxxxxxx; dots@xxxxxxxx
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 <noreply@xxxxxxxx> 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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
