Subject: [Dots] Éric Vyncke's Discuss on draft-ietf-dots-telemetry-20: (with DISCUSS and COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 01 Feb 2022 03:01:12 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-dots-telemetry-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (probably easy to address as I am
not a YANG expert), some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Please also have a look at Ted Lemon's INT directorate review at
<https://datatracker.ietf.org/doc/review-ietf-dots-telemetry-19-intdir-lc-lemon-2022-01-23/>.
I share Ted's concern about have three independent topics in a single document
rather than in 3 documents.

Special thanks to Valery Smyslov for the shepherd's write-up including the
section about the WG consensus even if I had appreciated a justification for
the PS status.

I hope that this helps to improve the document,

Regards,

-éric

## Section 8.1.5 (and others)

Please note that I am not a YANG expert, but it seems to me that
"attack-detail* [vendor-id attack-id]" indicates that vendor-id & attack-id are
the keys to attack-detail, i.e., there can only have one attack-detail per pair
of vendor-id & attack-id. So, there is no way to have multiple
sequential/simultaneous attacks, i.e., should the start-time be also part of
the key?

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion; I really think that the
document would be improved with a change here, but can be convinced otherwise.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am ambivalent with respect to the amount of context introduction in each
(sub)-section: it is for sure good for a new reader, but it also lengthens the
read for a more knowledgeable one.

## Abstract

Should the abstract mention the presence of a YANG model ?

## Section 2

Should the text specifies that tsid and tmid are monotonically increasing
values and not just a mere opaque identifier ?

Ben Kaduk also pointed the IESG members' attention to the use of "PEN" or
"Enterprise Number". As there is a § in this section about "Enterprise Number",
this would be the right place to state that this document uses "Enterprise
Number" or "Private Enterprise Number" or "PEN" for the same concept through
the rest of the document and stick to one wording. My own taste prefers "PEN"
even if RFC 5612 uses "Enterprise Number" but it is a matter of taste.

## Section 4.3

Should there be some words about using one upstream 'pipe' to reach the DOTS
server protecting another 'pipe' ? Or is it too obvious ?

## Section 7.2

Possibly a bad reading the unit/capacity section of mine, but how can 1.0 and
1.499 be differentiated with this notation? I.e., both will be represented 1
with a 50% difference though...

## Section 7.3

Are the authors/WG expecting that all IP packets are equal ? I.e., that the
downstream devices can handle IPv4 and IPv6 at the same rate ? Or should the
baseline information be different based on IP protocol version ? Or will the
normal use use only one-address-family 'target-prefix' ? Then, of course how to
decide the sum of traffic to the same network but over IPv4 or IPv6?

I would have preferred to use 'next-header' rather than 'protocol' or is the
expected behaviour to parse the IPv6 extension header chain to find the
transport protocol ? Same comment for other use of 'protocol' as in section 8.1.

Quite often ICMP types (and codes) are used in ACL for the same purpose as
transport-layer ports, was the use of ICMP types/codes considered?

## Section 7.3.1

Nice to see IPv6-only examples :-)

## Section 8

Suggestion to add some words about the "attack-detail* [vendor-id attack-id]"
leaf early in the text without waiting for section 8.1.5

## Section 8.1.6

Should figure 34 use the example PEN ? I.e., 32473 rather than 345 ?

## Section 11.1

Is it really useful to have both "bits" and "bytes" as units ? One is easily
derived from the other and this would be easier for every application to only
have "bits".

Suggestion use "octet" rather than "byte".

---

From: <[email-masked]>
Date: Tue, 1 Feb 2022 13:20:26 +0000

Bonjour Éric, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker <[email-masked]>
> Envoyé : mardi 1 février 2022 12:01
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Objet : Éric Vyncke's Discuss on draft-ietf-dots-telemetry-20: (with
> DISCUSS and COMMENT)
> 
> Please find below one blocking DISCUSS points (probably easy to address
> as I am not a YANG expert), some non-blocking COMMENT points (but
> replies would be appreciated even if only for my own education).
> 
> I share Ted's concern about have three independent topics in a single
> document rather than in 3 documents.
> 
> Special thanks to Valery Smyslov for the shepherd's write-up including
> the section about the WG consensus even if I had appreciated a
> justification for the PS status.
> 
> "attack-detail* [vendor-id attack-id]" indicates that vendor-id &
> attack-id are the keys to attack-detail, i.e., there can only have one
> attack-detail per pair of vendor-id & attack-id. So, there is no way to
> have multiple sequential/simultaneous attacks, i.e., should the start-
> time be also part of the key?
> 

[Med] Multiple attacks can be signaled as distinct attack-ids can be used for that case. I guess your question is more about when some "pause" periods are observed for the same attack. Such "pause" is an indication that the attack didn't cease at the first place, so end-time can't be used to refer to the attack between "pause" periods. One vendor-id & attack-id entry will be sufficient to report such attack patterns. 

> DISCUSS ballot is a request to have a discussion; I really think that
> the document would be improved with a change here, but can be convinced
> otherwise.
> 
> 
> (sub)-section: it is for sure good for a new reader, but it also
> lengthens the read for a more knowledgeable one.
> 
> ## Abstract
> 

[Med] Fait point. We don't mention it in the same way that the models weren't mentioned in the abstracts of RFC9132 and RFC8783. 

> 
> ## Section 2
> 
> Should the text specifies that tsid and tmid are monotonically
> increasing values and not just a mere opaque identifier ?

[Med] Because we are using the normative language for that aspect in, e.g., 7.1.2, we prefer to not state it here. Added "See Section 7.1.2 for more details."

> 
> Ben Kaduk also pointed the IESG members' attention to the use of "PEN"
> or "Enterprise Number". As there is a § in this section about
> "Enterprise Number", this would be the right place to state that this
> document uses "Enterprise Number" or "Private Enterprise Number" or
> "PEN" for the same concept through the rest of the document and stick to
> one wording. My own taste prefers "PEN"

[Med] Thanks. We do currently have:

   The document uses IANA-assigned Enterprise Numbers.  These numbers
   are also known as "Private Enterprise Numbers" and "SMI (Structure of
   Management Information) Network Management Private Enterprise Codes"
   [Private-Enterprise-Numbers].

+ 

use Private Enterprise Number in the text except when we point to RFC5612:

   The examples use the Enterprise Number 32473 defined for
   documentation use [RFC5612]. 

> 
> ## Section 4.3
> 
> Should there be some words about using one upstream 'pipe' to reach the
> DOTS server protecting another 'pipe' ? Or is it too obvious ?
> 

[Med] We don't zoom into this part as multi-homing is out of scope. Thanks.

> 1.499 be differentiated with this notation? I.e., both will be
> represented 1 with a 50% difference though...

[Med] Are you referring to this part? 

   The DOTS client MUST auto-scale so
   that the appropriate unit is used.  That is, for a given unit class,
   the DOTS client uses the largest unit that gives a value greater than
   one.  As such, only one unit per unit class is allowed.

> 
> ## Section 7.3
> 
> Are the authors/WG expecting that all IP packets are equal ? I.e., that
> the downstream devices can handle IPv4 and IPv6 at the same rate ? Or
> should the baseline information be different based on IP protocol
> version ? Or will the normal use use only one-address-family 'target-
> prefix' ? Then, of course how to decide the sum of traffic to the same
> network but over IPv4 or IPv6?

[Med] The information is bound to a target resource that is identified by a set of IP addresses/prefixes. If distinct baselines are to be reported for IPv4 and IPv6, then two baseline ids will be used to report each address family set. That is deployment specific.  

> 
> I would have preferred to use 'next-header' rather than 'protocol' or is
> the expected behaviour to parse the IPv6 extension header chain to find
> the transport protocol ? Same comment for other use of 'protocol' as in
> section 8.1.

[Med] I hear you, but we are following the same conventions as in RFC9132 and RFC8782. Also, please note that we point to https://www.iana.org/assignments/protocol-numbers/ which says explicitly: 

"In the Internet Protocol version 4 (IPv4) [RFC791] there is a field
called "Protocol" to identify the next level protocol.  This is an 8
bit field.  In Internet Protocol version 6 (IPv6) [RFC8200], this field 
is called the "Next Header" field."

> 
> Quite often ICMP types (and codes) are used in ACL for the same purpose
> as transport-layer ports, was the use of ICMP types/codes considered?

[Med] Yes, both 1 and 58 are valid protocol values. We do have specific attributes for ICMP types (e.g., source-icmp-type-range) in other sections of the document.  

> Nice to see IPv6-only examples :-)

[Med] :-)

> leaf early in the text without waiting for section 8.1.5

[Med] Will see what we can do, but 8.1.5 is the section where attack-detail tree is expanded. 

> Should figure 34 use the example PEN ? I.e., 32473 rather than 345 ?

[Med] We don't use it here because the example is about a client vendor != server vendor (32473) in Figure 33:

   If the DOTS client concludes that the DOTS server does not have any
   reference to the specific vendor attack mapping details, the DOTS
   client uses a POST request to install its vendor attack mapping
   details.

> 
> ## Section 11.1
> 
> Is it really useful to have both "bits" and "bytes" as units ? One is
> easily derived from the other and this would be easier for every
> application to only have "bits".
> 

[Med] We included support for both to simplify the processing during attack times. Also, it is up the agents to decide about which one(s) to pick. 

> Suggestion use "octet" rather than "byte".

[Med] I hear your comment, but we are inheriting some terms (e.g., "bytes-dropped") from RFC9132. 

_________________________________________________________________________________________________________________________

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: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 2 Feb 2022 07:48:58 +0000

Bonjour Med,

Thank you for your prompt reply. See below for EV> (points where we agree have been removed)

As you know, the authors are free to ignore the non-blocking COMMENT points.

Bien à toi

-éric

On 01/02/2022, 14:20, "[email-masked]" <[email-masked]> wrote:

    Bonjour Éric, 

    Please see inline. 

    Cheers,
    Med

    > -----Message d'origine-----
   
...%<....%<....

...%<....%<....

EV> actually, I misunderstood the semantic of attack-id due to the presence of vendor-id => I read it as "signature ID" (like a CVE) and not as an "event ID". I will clear my DISCUSS shortly.

EV> true, this should have been done as well in the previous YANG DOTS document. Up to the authors

EV> correct, hence my question 

EV> I was referring to an hypothetical case where the IPv6 capacity is 50% of the IPv4 one, so, for a 10 Gbps pipe, the baseline could be:
- IPv6: 5 Gbps, IPv4: 0 Gbps
- IPv6: 0 Gbps, IPv4: 10 Gbps
- IPv6: 3.3 Gbps, IPv4: 3.3 Gbps
How to express this baseline ?

Unsure though whether this corner is worth to be supported.

EV> let's be consistent with existing DOTS RFC then :-(

EV> sure but then why not in the baseline part ?

EV> making their tasks difficult as they need to handle both ;-)

---

From: <[email-masked]>
Date: Wed, 2 Feb 2022 09:11:55 +0000

Bonjour Éric, 

Thank you for the follow-up. 

Please see inline. 

Cheers,
Med

> De : Eric Vyncke (evyncke) <[email-masked]>
> Envoyé : mercredi 2 février 2022 08:49
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; The IESG
> <[email-masked]>
> [email-masked]; [email-masked]; [email-masked]
> Objet : Re: Éric Vyncke's Discuss on draft-ietf-dots-telemetry-20: (with
> DISCUSS and COMMENT)
> 
> Bonjour Med,
> 
>     [Med] Multiple attacks can be signaled as distinct attack-ids can be
> used for that case. I guess your question is more about when some
> "pause" periods are observed for the same attack. Such "pause" is an
> indication that the attack didn't cease at the first place, so end-time
> can't be used to refer to the attack between "pause" periods. One
> vendor-id & attack-id entry will be sufficient to report such attack
> patterns.
> 
> EV> actually, I misunderstood the semantic of attack-id due to the
> presence of vendor-id => I read it as "signature ID" (like a CVE) and
> not as an "event ID". I will clear my DISCUSS shortly.
> 
>     > I am ambivalent with respect to the amount of context introduction
> in
>     > each
>     [Med] Fait point. We don't mention it in the same way that the
> models weren't mentioned in the abstracts of RFC9132 and RFC8783.
> 

[Med] Added this NEW text to the abstract: 

"This document specifies a YANG module for representing DOTS telemetry message types. It also specifies a second YANG module to share the attack mapping details over the DOTS data channel."

> 
>     > ## Section 7.2
>     >
>     > Possibly a bad reading the unit/capacity section of mine, but how
> can
>     > 1.0 and

[Med]  The goal of the auto-scaling rule is to have compact encoding. For example, a DOTS agent that wants to share a capacity of 5000000 bit-ps will have to auto-scale to use the largest unit. It won't use either ("capacity": "5000", "unit": "megabit-ps") but ("capacity": "5", "unit": "gigabit-ps"). There is no confusion when auto-scaling because the ratio between successive units is 1000.  

>     [Med] The information is bound to a target resource that is
> identified by a set of IP addresses/prefixes. If distinct baselines are
> to be reported for IPv4 and IPv6, then two baseline ids will be used to
> report each address family set. That is deployment specific.
> 
> EV> I was referring to an hypothetical case where the IPv6 capacity is
> 50% of the IPv4 one, so, for a 10 Gbps pipe, the baseline could be:

[Med] A baseline is bound to target resources (IP addresses/prefixes, to put it simple). For the cases you listed, two baselines can be included as a function of the address family traffic distribution, e.g.,   

{
  "ietf-dots-telemetry:telemetry-setup": {
    "telemetry": [
      {
        "baseline": [
          {
            "id": 1,
            "target-prefix": [
              "2001:db8::/32"
            ],
            "total-traffic-normal": [
              {
                "unit": "gigabit-ps",
                "peak-g": "my_ipv6_specific_value"
              }
            ]
          },
          {
            "id": 2,
            "target-prefix": [
              "1.2.3.4/32"
            ],
            "total-traffic-normal": [
              {
                "unit": "gigabit-ps",
                "peak-g": "my_ipv4_specific_value"
              }
            ]
          }
        ]
      }
    ]
  }
}

>     [Med] I hear you, but we are following the same conventions as in
> RFC9132 and RFC8782. Also, please note that we point to
> https://www.iana.org/assignments/protocol-numbers/ which says
> explicitly:
> 
>     [Med] Yes, both 1 and 58 are valid protocol values. We do have
> specific attributes for ICMP types (e.g., source-icmp-type-range) in
> other sections of the document.
> 

[Med] If one is able to build/share a baseline per icmp/type, it also want to do the same for tcp/flags, and so on. The design choice for this version was to restrict the baseline to per-protocol aggregate.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 3 Feb 2022 07:01:19 +0000

Rebonjour Med,

Thanks for your reply, I think we still do not agree on a dual-stack baseline per my examples, but this is really a corner case probably not worth continuing the discussion.

I am fine with your other replies.

Bien à toi

-éric

On 02/02/2022, 10:12, "[email-masked]" <[email-masked]> wrote:

    Bonjour Éric, 

    Please see inline. 

    Cheers,
    Med

    {

---

From: <[email-masked]>
Date: Thu, 3 Feb 2022 07:38:00 +0000

Bonjour Eric, 

I thought your question is about how to describe per-address-family baseline not just providing an aggregate of both.  

Apologies if I missed your point. 

Cheers,
Med

> Envoyé : jeudi 3 février 2022 08:01
> Thanks for your reply, I think we still do not agree on a dual-stack
> baseline per my examples, but this is really a corner case probably not
> worth continuing the discussion.
> 
>     > Thank you for your prompt reply. See below for EV> (points where
> we
>     > agree have been removed)
>     >
>     > As you know, the authors are free to ignore the non-blocking
> COMMENT
>     > points.
>     >
>     > Bien à toi
>     >
>     > -éric
>     >
>     >     > ------------------------------------------------------------
> ------
>     > ----
>     >     > DISCUSS:
>     >     > ------------------------------------------------------------
> ------
>     > ----
>     >     >
>     >
>     > ...%<....%<....
>     >
>     >     > attack-id are the keys to attack-detail, i.e., there can
> only have
>     > one
>     >     > attack-detail per pair of vendor-id & attack-id. So, there
> is no
>     > way to
>     >     > have multiple sequential/simultaneous attacks, i.e., should
> the
>     > start-
>     >     > DISCUSS ballot is a request to have a discussion; I really
> think
>     > that
>     >     > the document would be improved with a change here, but can
> be
>     > convinced
>     >     > otherwise.
>     >     >
>     >     >
>     >     > ------------------------------------------------------------
> ------
>     > ----
>     >     > COMMENT:
>     >     > ------------------------------------------------------------
> ------
>     > ----
>     >     >
>     > EV> true, this should have been done as well in the previous YANG
> DOTS
>     > document. Up to the authors
> 
>     "This document specifies a YANG module for representing DOTS
> telemetry message types. It also specifies a second YANG module to share
> the attack mapping details over the DOTS data channel."
> 
>     >
>     >     > ## Section 7.2
>     >     >
>     >        that the appropriate unit is used.  That is, for a given
> unit
>     > class,
>     >        the DOTS client uses the largest unit that gives a value
> greater
>     > than
>     [Med]  The goal of the auto-scaling rule is to have compact
> encoding. For example, a DOTS agent that wants to share a capacity of
> 5000000 bit-ps will have to auto-scale to use the largest unit. It won't
> use either ("capacity": "5000", "unit": "megabit-ps") but ("capacity":
> "5", "unit": "gigabit-ps"). There is no confusion when auto-scaling
> because the ratio between successive units is 1000.
> 
>     >     >
>     >     > ## Section 7.3
>     >     >
>     >     > Are the authors/WG expecting that all IP packets are equal ?
> I.e.,
>     > that
>     >     > the downstream devices can handle IPv4 and IPv6 at the same
> rate ?
>     > Or
>     >     > prefix' ? Then, of course how to decide the sum of traffic
> to the
>     > same
>     [Med] A baseline is bound to target resources (IP
> addresses/prefixes, to put it simple). For the cases you listed, two
> baselines can be included as a function of the address family traffic
> distribution, e.g.,
> 
>     {
>     >     > I would have preferred to use 'next-header' rather than
> 'protocol'
>     > or is
>     >     > the expected behaviour to parse the IPv6 extension header
> chain to
>     > find
>     >     > the transport protocol ? Same comment for other use of
> 'protocol'
>     > as in
>     >     > section 8.1.
>     >
>     >     bit field.  In Internet Protocol version 6 (IPv6) [RFC8200],
> this
>     > field
>     >     > Quite often ICMP types (and codes) are used in ACL for the
> same
>     > purpose
>     [Med] If one is able to build/share a baseline per icmp/type, it
> also want to do the same for tcp/flags, and so on. The design choice for
> this version was to restrict the baseline to per-protocol aggregate.
> 
> 
> 
> ________________________________________________________________________
> _________________________________________________
> 
>     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,
>     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.
>