Re: [yang-doctors] Yangdoctors early review of draft-ietf-dots-telemetry-09

[Martin Björklund <[e-mail]>]

Hi,

<[e-mail]> wrote:
> Hi Jan, Martin, 
> 
> Thank you for the review. 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Martin Björklund [mailto:[e-mail]]
> > Envoyé : mardi 30 juin 2020 20:18
> > À : [e-mail]; [e-mail]
> > Cc : [e-mail]; [e-mail];
> > [e-mail]
> > Objet : Re: [yang-doctors] Yangdoctors early review of
> > draft-ietf-dots-
> > telemetry-09
> > 
> > Hi,
> > 
> > Jan Lindblad via Datatracker <[e-mail]> wrote:
> > > Reviewer: Jan Lindblad
> > > Review result: Not Ready
> > >
> > > This is the YD early review of draft-ietf-dots-telemetry as requested
> > > by
> > the
> > > DOTS WG.
> > >
> > > The ietf-dots-telemetry YANG module is not like other YANG modules. It
> > > specifically states that it does not pertain to NETCONF/RESTCONF
> > management,
> > > but is only meant to be mapped to a specific CoAP based protocol
> > > "dots-signal-channel" created by the DOTS WG. The draft-ietf-dots-
> > telemetry
> > > says in section 4.7:
> > >
> > >    The DOTS telemetry module (Section 9.1) is not intended to be used
> > >    via NETCONF/RESTCONF for DOTS server management purposes.  It serves
> > >    only to provide a data model and encoding, but not a management data
> > >    model.  DOTS servers are allowed to update the non-configurable 'ro'
> > >    entities in the responses of DOTS telemetry messages.
> > >
> 
> [Med] I confirm. We are using YANG for structuring the data that will
> be exchanged between the client and the server. We may think about
> this as some sort of service model as per RFC8309.
> 
> > > While this approach is highly uncommon, after giving it some thought,
> > > I
> > believe
> > > this approach could be useful to client and server
> > > implementors. However,
> > I
> > > find two fundamental problems in the particular way this has been done
> > > in
> > this
> > > case. I believe the problems are fixable, but may involve updating
> > existing
> > > DOTS RFCs.
> > >
> > > #1) YANG data declarations used as message bodies
> > >
> > > You can define your own message types with whatever content you desire
> > > in
> > YANG.
> > > Just use rpc/action and notification statements.
> > 
> > You may also want to look at RFC 8791, which defines a new YANG
> > extension statement "sx:structure".  This statement can be used to
> > define messages that are not intended to be generic rpcs or
> > notifications.
> > 
> > 
> 
> [Med] Thanks for the pointer, Martin.  
> 
> Importing ietf-yang-structure-ext + s/container
> dots-signal/sx:structure in ietf-dots-signal-channel (RFC8782) would
> be sufficient to define the structure as per RFC8791 but we will lose
> the "tagging" of parts of the structure/schema that applies only in
> the server to client direction.
> 
> We used rw/ro so that we can have a compact module/structure that can
> be used in both directions of the DOTS communication, rather than
> defining two structures.
> 
> The good news is that with both the current approach in RFC8782 and an
> updated one that strictly follows RFC 8791, we will have the same
> JSON/CBOR mappings that are authoritative for our spec (Section 6 of
> RFC8782).
> 
> Given that we don't have interoperability issues, would it be OK with
> you if we update draft-ietf-dots-telemetry to add a reference to
> inform the reader about RFC8791 and that we are not using it here
> because we are augmenting a module not using sx:structure?
> 
> If there is any RFC8782bis in the future, making changes to follow
> RFC8791 will be part of the things to be considered.

It seems that the YANG modules in RFC8782 were never reviewed by the
YANG doctors.  Please correct me if this was not the case.

So RFC 8782 seems to have the same fundamental problem as this draft.


/martin



> 
> > 
> > > This draft does not do that,
> > > but instead defines message bodies as if they were top level YANG
> > > config
> > > elements. This obviously violates the aras of YANG that speak about
> > > data
> > > stores, accessible data trees, and what not. Apart from confusing
> > experienced
> > > YANG users, the meaning of statements like "config false" is suddenly
> > most
> > > unclear when the foundations of YANG are disregarded.
> > >
> > > In my opinion the top level of the module needs to be rewritten to use
> > proper
> > > YANG rpc/action and notification statements. The existing message
> > > bodies,
> > and
> > > the way they are augmented, could all work very well. It's just the
> > framework
> > > around them that isn't sound.
> > >
> > > Unfortunately the problematic top level structures of draft-ietf-dots-
> > telemetry
> > > are based on structures imported from ietf-dots-signal-channel.yang,
> > which is
> > > already published in DOTS RFC 8782. I have not been able to find any
> > > YD
> > review
> > > of this module, so I would suspect none were ever performed. To make
> > > the
> > DOTS
> > > signal-channel framework usable, I would suggest obsoleting RFC8782
> > > and
> > write a
> > > bis with an improved YANG action/notification based foundation. The
> > number of
> > > changed lines in the YANG can probably be kept rather small.
> > >
> > > #2) Missing pieces in YANG to dots-signal-channel protocol mapping
> > >
> 
> [Med] What is key for the mapping is listed in
> draft-ietf-dots-telemetry-09#section-10. All the foundations are
> already specified in RFC8782. Section 3 of that RFC describes the
> rationale.
> 
> > > The draft-ietf-dots-telemetry references CoAP RFC 7959, which defines
> > > a
> > number
> > > of basic management operations (GET, PUT, POST, ...), and CBOR RFC
> > > 7049
> > content
> > > encoding, with the draft-ietf-core-yang-cbor-12 addendum for how YANG
> > data is
> > > to be encoded in CBOR. Unfortunately, a protocol specification that
> > consists of
> > > these three references is not quite complete. Since this is an early
> > review, it
> > > may be that the draft authors are already planning to pull the
> > > protocol
> > > specification up a notch, or I may have missed some piece(s) of the
> > puzzle. In
> > > any case, a protocol specification on par with what is available for
> > RESTCONF
> > > or NETCONF would be required.
> > >
> > > The dots-signal-channel specification in RFC 8782 makes an Informative
> > > Reference to draft specification for a protocol called CoMI
> > > (draft-ietf-core-comi-09), which attempts to take on the YANG to CoAP
> > mapping.
> > > One way of filling in the blanks for dots-signal-channel might be to
> > leverage
> > > the CoMI work. Fixing #1 would be required to leverage CoMI.
> > >
> > > Currently, dots-signal-channel protocol specification (taken as the
> > > sum
> > of
> > > CoAP, CBOR and draft-ietf-core-yang-cbor-12) is missing information
> > > about
> > > operation semantics, operation encoding, error handling, for example.
> 
> [Med] Such details are discussed in the base CoAP spec, RFC8782, and
> error handling specifics are included in this draft.
> 
>  RFC
> > 8040
> > > sections 5, 6, 7 or RFC 6241 sections 4, 7, 8 contain the sort of
> > information
> > > I'm looking for.
> > >
> > > #3) Other than that, probably good
> > >
> > > Other than issues #1 and #2 above, the module seems to be in pretty
> > > good
> > shape.
> > > Some content is hard to judge since the intended meaning of config
> > true/false
> 
> [Med] "config false" is used to tag nodes that must not appear in
> messages sent from the client to the server.
> 
> > > for example is unclear, so a new review will be required after the
> > fundamentals
> > > have been resolved. The module is both easy to read and conforms with
> > IETF
> > > standards except as noted above, staying on the clean and simple side.
> > >
> 
> [Med] Thanks. FWIW, we fixed some issues in the examples. The latest
> version of the spec is available at:
> https://github.com/boucadair/draft-dots-telemetry.
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>