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

From: Martin Björklund <[email-masked]>
Date: Wed, 01 Jul 2020 11:03:08 +0200 (CEST)

Hi,

<[email-masked]> wrote:
> Hi Jan, Martin, 
> 
> Thank you for the review. 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Martin Björklund [mailto:[email-masked]]
> > Envoyé : mardi 30 juin 2020 20:18
> > À : [email-masked]; [email-masked]
> > Cc : [email-masked]; [email-masked];
> > [email-masked]
> > Objet : Re: [yang-doctors] Yangdoctors early review of
> > draft-ietf-dots-
> > telemetry-09
> > 
> > Hi,
> > 
> > Jan Lindblad via Datatracker <[email-masked]> 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.
>

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 1 Jul 2020 11:23:26 +0200

Med,

I'm afraid you misunderstand my point. The YANG to dots-signal-channel protocol to YANG mapping information that I'm looking for is *not* in draft-ietf-dots-telemetry-09#section-10. That section maps types and CBOR sid:s, which is great, but far from enough for a protocol specification. 

If you look at the sections in the RESTCONF or NETCONF RFCs I pointed out, you might get a better understanding of what's still missing. The CoAP RFC provides zero operation semantics, there is no discussion about error handling, etc.

> 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.   

On the contrary, I believe there are very significant interoperability issues with the proposed model. In my opinion RFC 8782 needs to be reworked to be implementable. In its current form, it's unlikely that independent server and client implementations of RFC 8782 would interoperate.

Best Regards,
/jan

> On 1 Jul 2020, at 08:41, [email-masked] wrote:
> 
> Hi Jan, Martin, 
> 
>> De : Martin Björklund [mailto:[email-masked] <mailto:[email-masked]>]
>> À : [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> Cc : [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;
>> [email-masked] <mailto:[email-masked]>
>> Objet : Re: [yang-doctors] Yangdoctors early review of draft-ietf-dots-
>> telemetry-09
>> 
>> Hi,
>> 
>>> This is the YD early review of draft-ietf-dots-telemetry as requested by
>> the
>>> DOTS WG.
>>> 
> [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
>>> You can define your own message types with whatever content you desire in
>> YANG.
> 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.   
> 
>> 
>>> 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
>>> YANG rpc/action and notification statements. The existing message bodies,
>> and
>>> 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
> [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
>>> may be that the draft authors are already planning to pull the protocol
>>> Currently, dots-signal-channel protocol specification (taken as the sum
>> of
>>> CoAP, CBOR and draft-ietf-core-yang-cbor-12) is missing information about
> [Med] Such details are discussed in the base CoAP spec, RFC8782, and error handling specifics are included in this draft.    
> 
> RFC
>> 8040
>>> Other than issues #1 and #2 above, the module seems to be in pretty good
>> shape.
> [Med] "config false" is used to tag nodes that must not appear in messages sent from the client to the server.
> 
> [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 <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;
> 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.

---

From: <[email-masked]>
Date: Wed, 1 Jul 2020 10:06:06 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 1 juillet 2020 11:03
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked]; [email-masked]; draft-ietf-dots-
> [email-masked]; [email-masked]

[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?

---

From: <[email-masked]>
Date: Fri, 3 Jul 2020 07:33:42 +0000

Hi Jan, all,

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 

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.  

Thank you. 

Cheers,
Med

> De : Jan Lindblad via Datatracker [mailto:[email-masked]]
> Envoyé : mardi 30 juin 2020 17:43
> À : [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Yangdoctors early review of draft-ietf-dots-telemetry-09
> 
> Reviewer: Jan Lindblad
> Review result: Not Ready
> 
> "dots-signal-channel" created by the DOTS WG. The draft-ietf-dots-telemetry
> says in section 4.7:
> 
> this approach could be useful to client and server implementors. However, I
> case. I believe the problems are fixable, but may involve updating existing
> DOTS RFCs.
> 
> Just use rpc/action and notification statements. This draft does not do
> that,
> YANG users, the meaning of statements like "config false" is suddenly most
> are based on structures imported from ietf-dots-signal-channel.yang, which
> is
> bis with an improved YANG action/notification based foundation. The number
> of
> encoding, with the draft-ietf-core-yang-cbor-12 addendum for how YANG data
> is
> specification up a notch, or I may have missed some piece(s) of the puzzle.
> In
> Currently, dots-signal-channel protocol specification (taken as the sum of
> operation semantics, operation encoding, error handling, for example. RFC
> 8040
> have been resolved. The module is both easy to read and conforms with IETF

---

From: Jan Lindblad <[email-masked]>
Date: Mon, 6 Jul 2020 09:46:23 +0200

Med,

> https://github.com/boucadair/draft-dots-telemetry/blob/master/diff-module-8791.pdf 

[Janl] Very good, I think this approach will work well.

> 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

---

From: <[email-masked]>
Date: Mon, 6 Jul 2020 12:59:31 +0000

Hi Jan, 

Great. Thanks.

Focusing now on #2. 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.

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? 

Thank you.

Cheers
Med

> De : Jan Lindblad [mailto:[email-masked]]
> Envoyé : lundi 6 juillet 2020 09:46
> Cc : [email-masked]; [email-masked]; draft-ietf-dots-
> [email-masked]
> 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:
> > 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.
> 
> 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
> 
> 
> 
> which
> puzzle.

---

From: Jan Lindblad <[email-masked]>
Date: Tue, 7 Jul 2020 15:06:53 +0200

Med,

> Focusing now on #2.

[Janl] Very good.

> We are adhering to the base spec defined in RFC7252 with specifics defined in the DOTS documents. 
> 

[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?

> 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

---

From: <[email-masked]>
Date: Tue, 7 Jul 2020 14:26:25 +0000

Hi Jan,

Thank you for the follow-up.

Please see inline.

Cheers,
Med

De : Jan Lindblad [mailto:[email-masked]]
Envoyé : mardi 7 juillet 2020 15:07
À : BOUCADAIR Mohamed TGI/OLN
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: Yangdoctors early review of draft-ietf-dots-telemetry-09

Med,

Great. Thanks.

Focusing now on #2.

[Janl] Very good.

[Janl] This is good, but 7252 says nothing about operation semantics or how YANG comes into the picture.
[Med] YANG is only used for DOTS as a descriptive language to define the structure of the messages. The structure is also defined as json schema that are provided in many places of the specs. We don’t provide the YANG module for the internal datastore used by the server. The WG may work on that in the future.

Let me exemplify what I mean by a few questions. I'll abbreviate the DOTS-signal-protocol "DSP" for now.
[Med] Thanks.

[Med] It is not.

+ 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?
[Med] We are relying on Uri-Paths and the rules in 7252. Here is an example of DOTS-supplied Uri-Paths.

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "mitigate"

     Uri-Path: "cdid=7eeaf349529eb55ed50113"

     Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: "mid=123"

The order is important as discussed in the spec:

   The order of the Uri-Path options is important as it defines the CoAP

   resource.  In particular, 'mid' MUST follow 'cuid'.

+ Is a GET on the root resource a valid operation?
[Med] Yes. For example,

   *  Figure 12 shows the example of a GET request to retrieve all DOTS

      mitigation requests signaled by a DOTS client.

If it is, will that return the entire data tree?
[Med] Yes, assuming all validation checks are OK.

If so, can that returned data tree be sent back in a PUT operation later?

[Med] No:

   Because of the complexity of handling partial failure cases, this

   specification does not allow the inclusion of multiple mitigation

   requests in the same PUT request.  Concretely, a DOTS client MUST NOT

   include multiple entries in the 'scope' array of the same PUT

   request.

+ 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?
[Med] This is covered in many places of the spec, e.g.,

   This PUT request MUST use the

   same 'mid' value, and it MUST repeat all the other parameters as sent

   in the original mitigation request apart from a possible change to

   the 'lifetime' parameter value.  In such a case, the DOTS server MAY

   update the mitigation request, and a 2.04 (Changed) response is

   returned to indicate a successful update of the mitigation request.

   If this is not the case, the DOTS server MUST reject the request with

   a 4.00 (Bad Request).

or

   The PUT request used for the efficacy update MUST include all the

   parameters used in the PUT request to carry the DOTS mitigation

   request (Section 4.4.1<https://tools.ietf.org/html/rfc8782#section-4.4.1>) unchanged apart from the 'lifetime' parameter

   value.  If this is not the case, the DOTS server MUST reject the

   request with a 4.00 (Bad Request).

[Med] Yes:

   The 'c' Uri-Query option is used to control selection of
   configuration and non-configuration data nodes.

+ Will a DELETE operation on a valid resource always succeed, or are there any conditions under which a deletion may be invalid?
[Med] Yes this is covered in many places in the spec, e.g.,

   If the DOTS server finds the 'mid' parameter value conveyed in the

   DELETE request in its configuration data for the DOTS client, then to

   protect against route or DNS flapping caused by a DOTS client rapidly

   removing a mitigation, and to dampen the effect of oscillating

   attacks, the DOTS server MAY allow mitigation to continue for a

   limited period after acknowledging a DOTS client's withdrawal of a

   mitigation request.  During this period, the DOTS server status

   messages SHOULD indicate that mitigation is active but terminating

   (Section 4.4.2<https://tools.ietf.org/html/rfc8782#section-4.4.2>).

Or

For example, the DOTS client

   may send a PUT request to convey an efficacy update to the DOTS

   server followed by a DELETE request to withdraw the mitigation

   request, but the DELETE request arrives at the DOTS server before the

   PUT request.  To handle out-of-order delivery of requests, if an If-

   Match Option is present in the PUT request and the 'mid' in the

   request matches a mitigation request from that DOTS client, the

   request is processed by the DOTS server.  If no match is found, the

   PUT request is silently ignored by the DOTS server.

+ If the target URI is already deleted (not present), is that considered an error, and if so what error code should be used?
[Med] That’s covered as follows:

   Once the request is validated, the DOTS server immediately

   acknowledges a DOTS client's request to withdraw the DOTS signal

   using 2.02 (Deleted) Response Code with no response payload.  A 2.02

   (Deleted) Response Code is returned even if the 'mid' parameter value

   conveyed in the DELETE request does not exist in its configuration

   data before the request.

+ 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?
[Med] We don’t have text as this is implementation-specific. That’s said I expect implementations to maintain the session alive as we are dealing with DDoS attack mitigation.

+ YANG rpc, action, and notification statements have no mapping to DSP?
[Med] These do not apply for the signal channel. I think that things are now clear with the use of sx:structure.

---

From: <[email-masked]>
Date: Wed, 8 Jul 2020 09:18:56 +0000

Jan,

Some clarifications about this one:

I thought that you were asking for a case where the server has accepted for example a (mitigation) request but then encounters an error. That case is implementation-specific.

FWIW, we do have the following:

·         If the server crashes, the connection will be closed. This will be detected by the client thanks to the use of heartbeats. The client will then re-establish the signal session.

·         For errors on the server side we do have the following:

   “The error Response Code 5.03 (Service Unavailable) is
   returned if the DOTS server has erred or is incapable of performing
   the mitigation.  As specified in [RFC7252<https://tools.ietf.org/html/rfc7252>], 5.03 uses Max-Age Option
   to indicate the number of seconds after which to retry."

Implementations can send 5.00, but how the client will react to the error code is implementation-specific.

Cheers,
Med

---

From: <[email-masked]>
Date: Wed, 8 Jul 2020 11:05:09 +0100

Hi Jan,

Further to what Med has said as a clarification for errors server side when sending back a response assuming it is not a server crash.

if the mitigation was accepted (all sanity checks must have passed at this point) by the DOTS server, but then the passing over to the DOTS mitigator choked for whatever reason and could not handle it, the following sequence happens.

The server would initially have sent back an “attack-mitigation-in-progress” in response to the mitigation request, but never moves on to updating the status to “attack-successfully-mitigated” which happens when the mitigator puts the DDoS mitigation into action and indicates this back to the  DOTS server.  See  RFC8782 : Figure 15: Notifications of Attack Mitigation Status.  The DOTS server would then go on to setting the status to “attack-mitigation-withdrawn” (RFC8782 : Table 3: Values of 'status' Parameter).

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 08 July 2020 10:19
To: Jan Lindblad
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dots] Yangdoctors early review of draft-ietf-dots-telemetry-09

Jan, 

   the mitigation.  As specified in [ <https://tools.ietf.org/html/rfc7252> RFC7252], 5.03 uses Max-Age Option

Cheers,

Med