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

[Jan Lindblad <[e-mail]>]

Med,

> Great. Thanks.
> 
> Focusing now on #2.

[Janl] Very good.

> We are adhering to the base spec defined in RFC7252 with specifics defined in the DOTS documents. 
> 
> If we consider error handling for example, the general rule is:
> 
>   DOTS agents MUST support GET, PUT, and DELETE CoAP methods.  The
>   payload included in CoAP responses with 2.xx Response Codes MUST be
>   of content type "application/dots+cbor".  CoAP responses with 4.xx
>   and 5.xx error Response Codes MUST include a diagnostic payload
>   (Section 5.5.2 of [RFC7252]).  The diagnostic payload may contain
>   additional information to aid troubleshooting.

[Janl] This is good, but 7252 says nothing about operation semantics or how YANG comes into the picture. Let me exemplify what I mean by a few questions. I'll abbreviate the DOTS-signal-protocol "DSP" for now.

+ So the POST operation in CoAP is not used in DSP?
+ In a PUT message, what is the mapping between YANG paths and the target resource URI? CoAP does not define this, but the CoMI draft has some suggestions. Is that what you are planning to use?
+ Is a GET on the root resource a valid operation? If it is, will that return the entire data tree? If so, can that returned data tree be sent back in a PUT operation later?
+ Would such a that PUT operation (which contains a configuration that was valid at an earlier point) always succeed, or are there any situations in which the server would return an error when doing so? What errors?
+ Is there any way to only GET the configuration data?
+ Will a DELETE operation on a valid resource always succeed, or are there any conditions under which a deletion may be invalid?
+ If the target URI is already deleted (not present), is that considered an error, and if so what error code should be used? 
+ If a server has started sending back a response to a client request, but then hits an internal error, and is unable to filfil the request, what should it do? Is closing the connection a reasonable response?
+ YANG rpc, action, and notification statements have no mapping to DSP?

> We do have specific things such as the following in the telemetry draft:
> 
> ==
>   The DOTS server indicates the result of processing the PUT request
>   using the following response codes:
> 
>   o  If the request is missing a mandatory attribute, does not include
>      'cuid' or 'tsid' Uri-Path parameters, or contains one or more
>      invalid or unknown parameters, 4.00 (Bad Request) MUST be returned
>      in the response.
> 
>   o  If the DOTS server does not find the 'tsid' parameter value
>      conveyed in the PUT request in its configuration data and if the
>      DOTS server has accepted the configuration parameters, then a
>      response code 2.01 (Created) MUST be returned in the response.
> 
>   o  If the DOTS server finds the 'tsid' parameter value conveyed in
>      the PUT request in its configuration data and if the DOTS server
>      has accepted the updated configuration parameters, 2.04 (Changed)
>      MUST be returned in the response.
> 
>   o  If any of the enclosed configurable attribute values are not
>      acceptable to the DOTS server (Section 6.1.1), 4.22 (Unprocessable
>      Entity) MUST be returned in the response.
> 
>      The DOTS client may re-try and send the PUT request with updated
>      attribute values acceptable to the DOTS server.
> ==
> 
> Isn't this part of error handling? Or you are thinking about something else? 

[Janl] Yes, these bullets are certainly part of the answer. In a protocol specification, I would have expected a section specifically about error handling, which defines among other things how error responses would be formatted. Have a look at RFC 8040 section 7 as an example.

Specifying a protocol is never easy There are many aspects to consider. Even if the DSP protocol is somewhat limited in scope when compared to e.g. RESTCONF or CoMI, I'd suggest glancing at them for ideas about what aspects to include here.

Best Regards,
/jan



>> -----Message d'origine-----
>> De : Jan Lindblad [mailto:[e-mail]]
>> Envoyé : lundi 6 juillet 2020 09:46
>> À : BOUCADAIR Mohamed TGI/OLN
>> Cc : [e-mail]; [e-mail]; draft-ietf-dots-
>> [e-mail]
>> Objet : Re: Yangdoctors early review of draft-ietf-dots-telemetry-09
>> 
>> Med,
>> 
>>> Staring with #1 and #3.
>>> 
>>> I made changes to draft-ietf-dots-telemetry to comply with RFC8791. There
>> are few changes as it can be seen in this diff:
>>> https://github.com/boucadair/draft-dots-telemetry/blob/master/diff-
>> module-8791.pdf
>> 
>> [Janl] Very good, I think this approach will work well.
>> 
>>> The changes to the tree structure can be seen at:
>> https://github.com/boucadair/draft-dots-telemetry/blob/master/diff-tree-
>> 8791.pdf
>>> 
>>> Please note that these changes are made with the assumption that the YANG
>> module in RFC8782 is updated also to use sx:structure. We are working on an
>> update which can be seen at (https://github.com/boucadair/rfc8782-yang-
>> update)
>>> 
>>> Can you please let me know if these changes are in the good direction?
>> Any other comment on the updated draft-ietf-dots-telemetry module is
>> appreciated.
>> 
>> [Janl] Yes, this is definitely going a long way in the right direction.
>> Well done.
>> 
>> From a protocol definition pov, there are still undefined areas that need
>> to be filled in (#2), e.g. around operation semantics and error handling.
>> 
>> Best Regards,
>> /jan
>> 
>> 
>> 
>>>> -----Message d'origine-----
>>>> De : Jan Lindblad via Datatracker [mailto:[e-mail]]
>>>> Envoyé : mardi 30 juin 2020 17:43
>>>> À : [e-mail]
>>>> Cc : [e-mail]; [e-mail]
>>>> Objet : Yangdoctors early review of draft-ietf-dots-telemetry-09
>>>> 
>>>> 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.
>>>> 
>>>> 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. 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
>>>> 
>>>> 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.
>> 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
>>>> 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.
>>>> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>