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

[[e-mail]]

Bonjour Éric, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker <[e-mail]>
> Envoyé : mardi 1 février 2022 12:01
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Objet : Éric Vyncke's Discuss on draft-ietf-dots-telemetry-20: (with
> DISCUSS and COMMENT)
> 
> É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?
> 

[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. 

> 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 ?

[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"
> even if RFC 5612 uses "Enterprise Number" but it is a matter of taste.

[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.

> ## 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...

[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.  

> 
> ## Section 7.3.1
> 
> Nice to see IPv6-only examples :-)

[Med] :-)

> 
> ## 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

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

> 
> ## Section 8.1.6
> 
> 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.