[Dots] multiple values in the filter RE: DOTS telemetry Issues picked up in Interop Testing

[[e-mail]]

Re-,

If we want to allow for multiple values to be included, all what we need is to agree on the separator to be used for ranges and for distinct elements. We can get rid of [].

Cheers,
Med

De : Jon Shallow [mailto:[e-mail]]
Envoyé : mardi 21 avril 2020 12:56
À : BOUCADAIR Mohamed TGI/OLN; [e-mail]
Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing


De : Jon Shallow [mailto:[e-mail]]
Envoyé : mardi 21 avril 2020 10:59
À : BOUCADAIR Mohamed TGI/OLN; [e-mail]
Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing

Hi all,

A further thought on the use of Uri-Queries to clarify the AND/OR usage.

If you only allow one query per query type and put the match list in an array, then this will be an OR of the array list (the same as we do for the target* definitions right now.  E.G. :-

Uri-Query: target_prefix=[1.2.3.4/32,4.3.2.1/32]
Gives either 1.2.3.4 or 4.3.2.1 as a valid match.

And
Uri-Query: target-prefix=[1.2.3.4/32,4.3.2.1/32]
Uri-Query: lower-port=[80,443]
Gives (either 1.2.3.4 or 4.3.2.1) and (either port 80 or 443)

[] should not include spaces and comma used as a separator.

[Med] The issue I have with this is that we will need to handle cases where both lower-port and upper-port are present. Not sure what would be the benefit of allowing multiple key values, compact uris? If that's a concern, we may consider shortened names in the query (e.g., s/target-prefix/tp, s/lower-port/lp, ..).

Jon> fair point about lower and upper ports.  Uri-Query: target-port[80-85,443] works for me and covers both ranges and individual ports.

Jon> As this would be options on a GET request that has no body data, I don't think that I am too worried about using shortened names at this point.