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

[[e-mail]]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Martin Björklund [mailto:[e-mail]]
> Envoyé : mercredi 1 juillet 2020 11:03
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [e-mail]; [e-mail]; draft-ietf-dots-
> [e-mail]; [e-mail]
> Objet : Re: [yang-doctors] Yangdoctors early review of draft-ietf-dots-
> telemetry-09
> 
> > >
> > > 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.
> 

[Med] RFC8782 is a complex doc that manipulates many pieces from various areas. We had to pay attention to many things. I don't remember we received a yangdoctors review as part of the IETF LC, though. 

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

[Med] We can't use RFC8791 in draft-ietf-dots-telemetry because : "since a YANG compiler or other tool is not required to understand the "structure" extension.". 

This is why I made the proposal to record this in the draft so that this can be scheduled for future bis work of 8782. Fundamentally, we will come up with close structure (less compact with 8791). 

Given the conventions set in the RFC and that we are clearly saying that the module is not intended for NETCONF/RESTCONF use, is there any interoperability issue that you foresee?


_________________________________________________________________________________________________________________________

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.