Re: [Dots] DOTS Telemetry: Interop Clarification #1

[[e-mail]]

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[e-mail]]
Envoyé : lundi 29 juin 2020 13:41
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; [e-mail]
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

Hi Med,

I'm still confused - could be that we are talking cross purposes here.

See inline Jon>

Regards

Jon

From: Dots [mailto: [e-mail]] On Behalf Of [e-mail]
Sent: 29 June 2020 11:45
To: Jon Shallow; kaname nishizuka; [e-mail]
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1

Hi Jon,

It is the other way around: the server will filter out the data it will return to match the filters conveyed in GET.
Jon> That filtering I agree with.
[Med] OK.
  It just is what is the data source used for the server GET response.

So,

·         if we refer to your case (1), the PUT used for efficacy update does not interfere with the handling of GET to retrieve the server's status.
Jon> Figure 45 PUT includes
           "ietf-dots-telemetry:total-attack-traffic": [
             {
               "ietf-dots-telemetry:unit": "megabit-ps",
               "ietf-dots-telemetry:mid-percentile-g": "900"
             }
           ]
Jon>  What does the DOTS server respond with for a GET - the value "900 megabit-ps" or what the DOTS server (as told by DOTS mitigator etc.) thinks is actually happening - e.g. "11 gigabit-ps" because a lot of attack traffic is being dropped by the DOTS mitigators?  Just to be absolutely sure - the server is getting its status from multiple sources - which status does it report on in the GET.
[Med] The server will report the status it is seeing (reported from mitigators), not the one inferred from the efficacy update from the client. We are not changing the behavior we have in the base spec.


·         if we refer to your case (2), the PUT in Figure 36 sets the target (telemetry) scope. So for any telemetry-related GET, the server will only return data that is bound to the target as set in the PUT. These data is further filtered out based of any uri-query in the GET.
Jon> Figure 36 PUT goes beyond defining the target (alias-name in this case) and includes
           "attack-detail": [
             {
               "vendor-id": 1234,
               "attack-id": 77,
               "start-time": "1957811234",
               "attack-severity": "high"
             }
           ]
Jon> So what is returned in the GET for this target - this attack detail or the attack detail that the DOTS server is being told by the DOTS mitigators - which could include the same vendor-id + attack-id (but maybe with a different start time)?
[Med] Like above, the status that will be reported is the one from mitigators.

~Jon

Cheers,
Med

De : Jon Shallow [mailto:[e-mail]]
Envoyé : lundi 29 juin 2020 11:13
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; [e-mail]
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

Hi Med,

So for absolute clarity, the DOTS server will return the values it has internally determined (from DOTS mitigator etc.), not those provided by the DOTS client using a PUT, as modified by the GET Query filters.

Regards

Jon

From: Dots [mailto: [e-mail]] On Behalf Of [e-mail]
Sent: 29 June 2020 07:38
To: Jon Shallow; kaname nishizuka; [e-mail]
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1

Hi Jon, all,

The server will return the data that match the filters included in the GET that triggered the response.

Cheers,
Med

De : Jon Shallow [mailto:[e-mail]]
Envoyé : vendredi 26 juin 2020 14:11
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; [e-mail]
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

Hi Med,

I think that this refers several places.


1.       Efficacy updates.  E.g.  Figure 45: An Example of Mitigation Efficacy Update with Telemetry  Attributes. Here we do an efficacy update of what the client is seeing happen to a specific resource.  If the client now does a GET against the same resource - what is returned - the last efficacy update or the current state of mitigation as seen by the DOTS server?


2.       Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry allows the client to update the tmid with some information.  This includes an attack-detail.  When the client wants to see what is happening with this "tmid", it does a Figure 40: GET to Subscribe to Telemetry Asynchronous Notifications for a Specific 'tmid'.  Which attack-detail is returned - the one from the PUT or the ongoing situation?

Regards

Jon

From: Dots [mailto: [e-mail]] On Behalf Of [e-mail]
Sent: 25 June 2020 20:29
To: kaname nishizuka
Cc: [e-mail]
Subject: [Dots] DOTS Telemetry: Interop Clarification #1

Hi Kaname,

We discussed this issue in the interim:

==
Current Uri-Path can't distinguish telemetry resources posted by the client or created by the server.
-Those are totally different resources.
For example, Uri-Query won't be applicable to the telemetry resources posted by the client.
==

Can you please identify precisely which parts of the text need to be updated?

Thank you

Cheers,
Med



_________________________________________________________________________________________________________________________

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.