Re: [Dots] Telemetry draft: Vendor Specific data reduction

[[e-mail]]

Hi Jon,

Agree.

I will updated the draft to reflect the outcome of this thread.

Cheers,
Med

De : Jon Shallow [mailto:[e-mail]]
Envoyé : mercredi 29 avril 2020 13:58
À : BOUCADAIR Mohamed TGI/OLN; [e-mail]
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction

Hi Med,

See inline Jon1>

Regards

Jon

From: Dots [mailto: [e-mail]] On Behalf Of [e-mail]
Sent: 29 April 2020 12:37
To: Jon Shallow; [e-mail]
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction

Re-,

The augment to the data channel would be:

  augment /ietf-data:dots-data/ietf-data:dots-client:
    +--rw vendor-mapping {dots-telemetry}?
       +--rw attack-detail* [vendor-id attack-id]
          +--rw vendor-id      uint32
          +--rw attack-id      string
          +--rw attack-name    string
  augment /ietf-data:dots-data/ietf-data:capabilities:
    +--ro vendor-mapping {dots-telemetry}?
       +--ro attack-detail* [vendor-id attack-id]
          +--ro vendor-id      uint32
          +--ro attack-id      string
          +--ro attack-name    string

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[e-mail]]
Envoyé : mercredi 29 avril 2020 12:46
À : BOUCADAIR Mohamed TGI/OLN; [e-mail]
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction

It is my belief that the client should share the mappings with the server as well, even though the server may actually have the mappings because the server is supplied by the same vendor.
[Med] Not sure to understand the last part of your sentence.

Jon1> If the server and client are provided by the same vendor, then they will both know the vendor-id specific mappings so for the client to send them (or the server to respond to respond with them) is not necessarily needed, but is useful for consistency across all vendors.


There is no harm on the server reporting any differences - there is the possibility that 2 clients have 2 different mitigator release versions though what the client does with the differences (other than log them), I am not sure.
[Med] The mapping is per client, not per domain. A diff can't be interpreted as a conflict.
Jon1> Good thinking - not an issue.  However, the client and server from the same vendor may be on different code releases (or attack matching details) and so there could be a difference (but I would have expected that one of the mappings is a superset of the other, not with any replacements, but there may be local modifications ....).  However, if the client tells the server, the server than updates its local, per client, mapping and only uses that mapping for any reporting etc.  Similarly,  when the client pulls back the server version of the mapping, it updates the active mapping table to use for telemetry being sent by the server, but continues to use the mapping tables it told the server for telemetry from client to server.
~Jon1


Regards

Jon

From: Dots [mailto: [e-mail]] On Behalf Of [e-mail]
Sent: 29 April 2020 11:29
To: Jon Shallow; [e-mail]
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction

Re-,

We need to agree if the client has to share its mappings with the server as well. The use of the data channel would make sense as id/name mapping is similar to the alias handling functionality.

Vendor-id should be a key too.

Cheers,
Med