Subject: [Dots] Lars Eggert's Discuss on draft-ietf-dots-telemetry-21: (with DISCUSS and COMMENT)

From: Lars Eggert via Datatracker <[email-masked]>
Date: Thu, 03 Feb 2022 01:58:32 -0800

Lars Eggert has entered the following ballot position for
draft-ietf-dots-telemetry-21: 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:
----------------------------------------------------------------------

The protocol uses traffic capacities in various ways (for pipe, baseline and
connection capacity, etc.) but doesn't indicate at what layer these capacities
are to be interpreted? L2? L3? (L1??) Would the difference in header overhead
cause issues when senders and receivers use different interpretations here?

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

Thanks to Robert Sparks for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/hTMaURDAcbvHbR1TQ52GA_fJOzk).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2. , paragraph 10, nit:
> igation service effectiveness. Bi-directional feedback between DOTS agents i
>                                ^^^^^^^^^^^^^^^
This word is normally spelled as one.

Section 2. , paragraph 13, nit:
> ents as hints and cannot completely rely or trust the attack details conveye
>                                     ^^^^
The verb "rely" requires the preposition "on" (or "upon").

Section 3.1. , paragraph 4, nit:
> sides, can use DOTS telemetry as a feedback to automate various control and
>                                  ^^^^^^^^^^
The noun "feedback" is uncountable and doesn't require an article.

Section 3.1. , paragraph 7, nit:
> raffic from attacker traffic on a per packet basis is complex. For example, a
>                                   ^^^^^^^^^^
In this context, "per-packet" forms an adjective and is spelled with a hyphen.

Section 4.3. , paragraph 2, nit:
> son for not including these keys is because they are not included in the mes
>                                  ^^^^^^^^^^
The word "because" means "for the reason that" and thus introduces redundancy.

Section 7.1.2. , paragraph 1, nit:
>  percentile (10th percentile), mid percentile (50th percentile), high percen
>                                ^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 7.2.1. , paragraph 12, nit:
>  appropriate unit is used. Total connections capacity: If the target is susce
>                                  ^^^^^^^^^^^
An apostrophe may be missing.

Section 8.1.5. , paragraph 17, nit:
> lue of the 'target-fqdn' parameter in an Uri-Query option. DOTS clients may a
>                                       ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 9. , paragraph 7, nit:
>  default "50.00"; description "Mid percentile. If set to the same value as l
>                                ^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 9. , paragraph 7, nit:
> ype yang:gauge64; description "Mid percentile value."; } leaf high-percentil
>                                ^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 9. , paragraph 20, nit:
> ty-protocol { description "Total connections capacity per protocol. These dat
>                                  ^^^^^^^^^^^
An apostrophe may be missing.

Section 9. , paragraph 22, nit:
> Various details that describe the on-going attacks that need to be mitigated
>                                   ^^^^^^^^
Did you mean "ongoing"?

Section 11.1. , paragraph 6, nit:
>  an IP resource. An IP resource can be be a router, a host, an IoT object, a
>                                     ^^^^^
Possible typo: you repeated a word.

Section 11.1. , paragraph 46, nit:
>  DOTS telemetry for its IP addresses but a DDoS mitigator can exchange DOTS
>                                     ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

---

From: <[email-masked]>
Date: Thu, 3 Feb 2022 12:06:19 +0000

Hi Lars, 

Thank you for the comment. 

> The protocol uses traffic capacities in various ways (for pipe, baseline
> and connection capacity, etc.) but doesn't indicate at what layer these
> capacities are to be interpreted? L2? L3? (L1??) Would the difference in
> header overhead cause issues when senders and receivers use different
> interpretations here?

We do have this precision in text: "...which is the level of traffic the DOTS client domain can absorb from its upstream network", which is handled as a "physical" link capacity. 

Will add an additional if you think that the existing text is not sufficient. 

Cheers,
Med

> -----Message d'origine-----
> De : Lars Eggert via Datatracker <[email-masked]>
> Envoyé : jeudi 3 février 2022 10:59
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Lars Eggert's Discuss on draft-ietf-dots-telemetry-21: (with
> DISCUSS and COMMENT)
> 
> The protocol uses traffic capacities in various ways (for pipe, baseline
> and connection capacity, etc.) but doesn't indicate at what layer these
> capacities are to be interpreted? L2? L3? (L1??) Would the difference in
> header overhead cause issues when senders and receivers use different
> interpretations here?
> 
> 
> Thanks to Robert Sparks for their General Area Review Team (Gen-ART)
> review (https://mailarchive.ietf.org/arch/msg/gen-
> art/hTMaURDAcbvHbR1TQ52GA_fJOzk).
> 
> All comments below are about very minor potential issues that you may
> choose to address in some way - or ignore - as you see fit. Some were
> flagged by automated tools (via https://github.com/larseggert/ietf-
> reviewtool), so there will likely be some false positives. There is no
> need to let me know what you did with these suggestions.
> 
> Use "a" instead of "an" if the following word doesn't start with a vowel
> sound, e.g. "a sentence", "a university".
> 
> Use a comma before "but" if it connects two independent clauses (unless
> they are closely connected and short).
> 
> 

_________________________________________________________________________________________________________________________

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: Lars Eggert <[email-masked]>
Date: Thu, 3 Feb 2022 15:43:14 +0200

Hi,

> Will add an additional if you think that the existing text is not sufficient.

I think making this more clear would be good - I read this sentence but was still unclear about whether this is L2 or L3 or what.

Thanks,
Lars

---

From: <[email-masked]>
Date: Thu, 3 Feb 2022 14:37:17 +0000

Re-,

OK. We went with this update:

OLD; 
   In this case, it can be valuable to DOTS clients to signal to DOTS
   servers the total pipe capacity, which is the level of traffic the
   DOTS client domain can absorb from its upstream network.

NEW:
   In this case, it can be valuable to DOTS clients to signal to DOTS
   servers the total pipe capacity, which is the level of traffic the
   DOTS client domain can absorb from its upstream network.  This
   usually is the circuit size which includes all the packet overheads.

Cheers,
Med

> De : Lars Eggert <[email-masked]>
> Envoyé : jeudi 3 février 2022 14:43
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : The IESG <[email-masked]>; [email-masked]; dots-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Re: Lars Eggert's Discuss on draft-ietf-dots-telemetry-21: (with
> DISCUSS and COMMENT)
> 
> Hi,
> 
> >> The protocol uses traffic capacities in various ways (for pipe,
> >> baseline and connection capacity, etc.) but doesn't indicate at what
> >> layer these capacities are to be interpreted? L2? L3? (L1??) Would
> >> the difference in header overhead cause issues when senders and
> >> receivers use different interpretations here?
> >
> > We do have this precision in text: "...which is the level of traffic
> the DOTS client domain can absorb from its upstream network", which is
> handled as a "physical" link capacity.
> >
> I think making this more clear would be good - I read this sentence but
> was still unclear about whether this is L2 or L3 or what.
> 
> Thanks,
> Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 3 Feb 2022 16:38:12 +0200

>   usually is the circuit size which includes all the packet overheads.

WFM, thanks!

Lars