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

[[e-mail]]

Hi Jan,

Thank you for the follow-up.

Please see inline.

Cheers,
Med

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

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

+ So the POST operation in CoAP is not used in DSP?
[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).


+ Is there any way to only GET the configuration data?
[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.

_________________________________________________________________________________________________________________________

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.