Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
draft-ietf-dots-telemetry-25

[Ballot comment]
Thank you for the work on this document, which I found particularly well written and easy to read despite its length.

Many thanks to James Gruessing for the ART ART review: https://mailarchive.ietf.org/arch/msg/art/MbTX3xfg6tMeG6mieAsT7hA3gXs/, and to the authors for addressing James' comments.

To answer Ben's note - IMO the text about "enterprise numbers" and "Private Enterprise Numbers" is clear enough.

I will keep the DISCUSS text below for the record and for Ben's attention, but I am clearing it, given that the additions in v-21 mostly address 1-7. and 8. has precedent for it in 9132.

Francesca

# Previous DISCUSS (keeping for the record)

1. -----

  JSON encoding of YANG-modeled data is used to illustrate the various
  telemetry operations.

FP: There is an inconsistency between this text and the use of "application/dots+cbor" in the examples. Either the Content-Format should be changed, or all the examples should be adapted to JSON Content-Format (I am not sure about what Content-Format you should use then, you probably know better). My preference is to keep CBOR and keep the Content-Format. I went through all the examples and reported below the inconsistencies.

Section 7.1.2, Figure 4, 5,

FP: If in CBOR, the percentiles should be expressed with the tagged item Decimal fraction (represented as a tagged array).

2. -----

Section 7.2.1, Figure 11, 13, 15, 17

FP: Same comment as 1: unit and peak-g should be unsigned in CBOR.

3. -----

Section 7.3.1, Figure 19, 20

FP: Same comment as 1: capacity and unit should be unsigned in CBOR.

4. -----

Section 7.2.1, Figure 11, 13, 15, 17

FP: Same comment as 1: unit and peak-g should be unsigned in CBOR.

5. -----

Section 7.3.1, Figure 19, 20

FP: Same comment as 1: capacity and unit should be unsigned in CBOR.

6. -----

Figure 36, figure 43

FP: Same comment as 1: unit, mid-percentile-g, start-time and attack-severity should be unsigned in CBOR.

7. -----

Figure 45, 47

FP: attack-status, unit, mid-percentile-g, peak-g should be unsigned. I also note that some of the attributes defined in 9132 are used here and on previous examples and have for values the full spelled out meaning for readability, instead of the actual parameter (for example "status", that should have value 2 for "attack-successfully-mitigated"), and I think that should be at least noted in the text before the example, or if you want to be more precise the "attack-successfully-mitigated" could be a comment next to the value 2.

8. -----

Section 7.1.3

  client, it MUST respond with a 4.04 (Not Found) error Response Code.

FP: I have a preference to remove this MUST here - it is expected behavior that if a resource is not present the server responds with 4.04, so it is not necessary to add the requirement here, actually redefining the response code (although it is the expected one in this case) should be discouraged. I suggest replacing: s/it MUST respond/it responds. (Note that 7.1.4 has the text I would expect, describing the behavior but not adding any already existing requirements).

# Comment

9. -----

FP: Related to the DISCUSS point about encoding, it would be good to state somewhere in the text (possibly in section 5.6) that CBOR Key Values can be used instead of the parameter names (see section 13.1), but that for readability all examples use the full names.

10. -----

Section 7.1.2, tsid definition

        This is a mandatory attribute. 'tsid' MUST follow 'cuid'.

FP: I am not sure I understand the use of the term "follow" here. Also I am confused by the fact that tsid here is named as an "attribute" while instead it is defined as a Uri-Path parameter, and does not appear in the list of attributes of Figure 3.


11. -----

  Many of the pre-or-ongoing-mitigation telemetry data use a unit that
  falls under the unit class that is configured following the procedure
  described in Section 7.1.2.  When generating telemetry data to send

FP: Section 7.1.2 does not describe the procedure to configure the unit (which at this point in the text I can't find anywhere). All 7.1.2 says is:

  DOTS clients can also configure the unit class(es) to be used for
  traffic-related telemetry data among the following supported unit
  classes: packets per second, bits per second, and bytes per second.
  Supplying both bits per second and bytes per second unit-classes is
  allowed for a given telemetry data.  However, receipt of conflicting
  values is treated as invalid parameters and rejected with 4.00 (Bad
  Request).

what am I missing?

12. -----

Figure 33

FP: Please either add the Reponse header (HTTP/1.1 200 OK \ Content-Type: /yang-data+json + any other header field) (this is my preferred option) or change the caption to indicate that this is only the response content.

13. -----

Section 8.2

        This is a mandatory attribute. 'tmid' MUST follow 'cuid'.

FP: Same question as 10.


14. -----

Section 8.1.6

FP: Suggestion to add a sentence reminding the reader that this exchange happens over the data channel and that's why HTTP and JSON are used. (As Ben made me notice, this is very clearly explained in section 4.1, but I had forgotten by the time I got to this point in the text).

15. -----

FP: question for my understanding that comes from my low experience with YANG: I see that connection-all and connection-percentile-and-peak are groups of the exact same containers. Do they both need to be defined because the description (and hence the use) is different?

[Ballot comment]
Authors: thank you for the clarifying language in Section 4.4 explaining how the design of mapping YANG into CBOR

Thank you for addressing my DISCUSS and select COMMENTs

** Section 8.1.6.  An attack type appears to be characterized by a vendor-id, vendor-name, last-updated, attack-id and attack-description.  Would an additional field of attack-id-revision (or attack-id-version) be beneficial too?  I’m imagining a workflow where a vendor’s definition of an attack (and the associated detection rule/logic) changes overtime and it might be useful to version that – akin to the snort/suricata’s “rev:” field.  A vendor could of course assign a new attack-id but this might impact down-stream analysis.

[Ballot comment]
Hi,

Thanks for this document.  I have no major comments, but do have a few minor ones.

1. I wonder if the abstract/introduction can be clearer that this is an extension to the data channel as well as the signal channel, although I appreciate that the vast majority of this document is about telemetry communicated via the signal channel.

2. I found the text in section 7.1.2 related to tsids to be somewhat unclear.  When I first read this paragraph:

  tsid:  Telemetry Setup Identifier is an identifier for the DOTS
        telemetry setup configuration data represented as an integer.
        This identifier MUST be generated by DOTS clients.  'tsid'
        values MUST increase monotonically (when a new PUT is generated
        by a DOTS client to convey new configuration parameters for the
        telemetry).

and

  A PUT request with a higher numeric 'tsid' value overrides the DOTS
  telemetry configuration data installed by a PUT request with a lower
  numeric 'tsid' value.  To avoid maintaining a long list of 'tsid'
  requests for requests carrying telemetry configuration data from a
  DOTS client, the lower numeric 'tsid' MUST be automatically deleted
  and no longer be available at the DOTS server.

It gave me the impression that a new PUT request with a new tsid completely replaces all configuration provided by any lower tsid, but I don't think that is is the intent.  Perhaps this could be made clearer?

3.
  *  If the DOTS server finds the 'tsid' parameter value conveyed in
      the PUT request in its configuration data and if the DOTS server
      has accepted the updated configuration parameters, 2.04 (Changed)
      MUST be returned in the response.

I was wondering why not error this case and not except the config change (presumably this is a simple error if the client has used the same tsid)?

4. The YANG is obviously being used in a different way here than for regular network device configuration, but this still means that you end up with descriptions of various properties in two places in the document, once in the main part of the text and once in the YANG data model, which makes the document both somewhat more verbose and also runs the risk of discrepancies between what is in the YANG vs what is described earlier in the document.  For regular YANG data models, the preferred approach is try and have the full normative definitions in the YANG module, and keeps the text outside of the model to be more informative/descriptive of the expected behavior, partly because of the expectation to be able to generate user documentation from the description statements.  I don't know if you would ever be expected to generate a UI description from the YANG module for DOTS telemetry, but you might want to double check that have you the right balance between whether the text in the YANG module of the main description is definitive and whether there should be any statement in the document to indicate which text is regarded as definitive if there is any discrepancy between the two descriptions.

5. I agree with Warren's comments regarding whether allowing a choice of units and scaling causes additional complexity that could perhaps be avoided.

Regards,
Rob

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

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

[Ballot discuss]
Thank you for the work on this document, which I found particularly well written and easy to read despite its length.

Many thanks to James Gruessing for the ART ART review: https://mailarchive.ietf.org/arch/msg/art/MbTX3xfg6tMeG6mieAsT7hA3gXs/, and to the authors for addressing James' comments.

To answer Ben's note - IMO the text about "enterprise numbers" and "Private Enterprise Numbers" is clear enough.

I will keep this DISCUSS as a placeholder to discuss my concerns with the responsible AD during the telechat, but expect to remove it afterward, given that the additions in v-21 mostly address 1-7 and 8 has precedent for it in 9132.

Francesca

[Ballot comment]
# Previous DISCUSS (keeping for the record until the telechat)

1. -----

  JSON encoding of YANG-modeled data is used to illustrate the various
  telemetry operations.

FP: There is an inconsistency between this text and the use of "application/dots+cbor" in the examples. Either the Content-Format should be changed, or all the examples should be adapted to JSON Content-Format (I am not sure about what Content-Format you should use then, you probably know better). My preference is to keep CBOR and keep the Content-Format. I went through all the examples and reported below the inconsistencies.

Section 7.1.2, Figure 4, 5,

FP: If in CBOR, the percentiles should be expressed with the tagged item Decimal fraction (represented as a tagged array).

2. -----

Section 7.2.1, Figure 11, 13, 15, 17

FP: Same comment as 1: unit and peak-g should be unsigned in CBOR.

3. -----

Section 7.3.1, Figure 19, 20

FP: Same comment as 1: capacity and unit should be unsigned in CBOR.

4. -----

Section 7.2.1, Figure 11, 13, 15, 17

FP: Same comment as 1: unit and peak-g should be unsigned in CBOR.

5. -----

Section 7.3.1, Figure 19, 20

FP: Same comment as 1: capacity and unit should be unsigned in CBOR.

6. -----

Figure 36, figure 43

FP: Same comment as 1: unit, mid-percentile-g, start-time and attack-severity should be unsigned in CBOR.

7. -----

Figure 45, 47

FP: attack-status, unit, mid-percentile-g, peak-g should be unsigned. I also note that some of the attributes defined in 9132 are used here and on previous examples and have for values the full spelled out meaning for readability, instead of the actual parameter (for example "status", that should have value 2 for "attack-successfully-mitigated"), and I think that should be at least noted in the text before the example, or if you want to be more precise the "attack-successfully-mitigated" could be a comment next to the value 2.

8. -----

Section 7.1.3

  client, it MUST respond with a 4.04 (Not Found) error Response Code.

FP: I have a preference to remove this MUST here - it is expected behavior that if a resource is not present the server responds with 4.04, so it is not necessary to add the requirement here, actually redefining the response code (although it is the expected one in this case) should be discouraged. I suggest replacing: s/it MUST respond/it responds. (Note that 7.1.4 has the text I would expect, describing the behavior but not adding any already existing requirements).

# Comment

9. -----

FP: Related to the DISCUSS point about encoding, it would be good to state somewhere in the text (possibly in section 5.6) that CBOR Key Values can be used instead of the parameter names (see section 13.1), but that for readability all examples use the full names.

10. -----

Section 7.1.2, tsid definition

        This is a mandatory attribute. 'tsid' MUST follow 'cuid'.

FP: I am not sure I understand the use of the term "follow" here. Also I am confused by the fact that tsid here is named as an "attribute" while instead it is defined as a Uri-Path parameter, and does not appear in the list of attributes of Figure 3.


11. -----

  Many of the pre-or-ongoing-mitigation telemetry data use a unit that
  falls under the unit class that is configured following the procedure
  described in Section 7.1.2.  When generating telemetry data to send

FP: Section 7.1.2 does not describe the procedure to configure the unit (which at this point in the text I can't find anywhere). All 7.1.2 says is:

  DOTS clients can also configure the unit class(es) to be used for
  traffic-related telemetry data among the following supported unit
  classes: packets per second, bits per second, and bytes per second.
  Supplying both bits per second and bytes per second unit-classes is
  allowed for a given telemetry data.  However, receipt of conflicting
  values is treated as invalid parameters and rejected with 4.00 (Bad
  Request).

what am I missing?

12. -----

Figure 33

FP: Please either add the Reponse header (HTTP/1.1 200 OK \ Content-Type: /yang-data+json + any other header field) (this is my preferred option) or change the caption to indicate that this is only the response content.

13. -----

Section 8.2

        This is a mandatory attribute. 'tmid' MUST follow 'cuid'.

FP: Same question as 10.


14. -----

Section 8.1.6

FP: Suggestion to add a sentence reminding the reader that this exchange happens over the data channel and that's why HTTP and JSON are used. (As Ben made me notice, this is very clearly explained in section 4.1, but I had forgotten by the time I got to this point in the text).

15. -----

FP: question for my understanding that comes from my low experience with YANG: I see that connection-all and connection-percentile-and-peak are groups of the exact same containers. Do they both need to be defined because the description (and hence the use) is different?

[Ballot comment]
[S12, elsewhere; question]

* For the CBOR Major & Type representation of "inet:ip-prefix"es (e.g.
  "source-prefix") have you considered using the representations from
  RFC 9164?

  https://www.rfc-editor.org/rfc/rfc9164.html#name-iana-considerations

[Ballot discuss]
Please note: This really is just a DISCUSSion - I'm happy to be educated / wrong, but I do think that it is important enough that it gets addressed.

The 'unit-class' and 'unit' enumerations seems like they add a large amount of complexity for (AFAICT) very little gain.
Do you really need:
            "Packets per second (pps).";
            "Bits per Second (bps).";
            "Bytes per second (Bps).";
            "Kilo packets per second (kpps).";
            "Kilobits per second (kbps).";
            "Kilobytes per second (kBps).";
            "Mega packets per second (Mpps).";
            "Megabytes per second (MBps).";
            "Giga packets per second (Gpps).";
            "Gigabits per second (Gbps).";
            "Gigabytes per second (GBps).";
            "Tera packets per second (Tpps).";
            "Terabits per second (Tbps).";
            "Terabytes per second (TBps).";
            "Peta packets per second (Ppps).";
            "Petabits per second (Pbps).";
            "Petabytes per second (PBps).";
            "Exa packets per second (Epps).";
            "Exabits per second (Ebps).";
            "Exabytes per second (EBps).";
            "Zetta packets per second (Zpps).";
            "Zettabits per second (Zbps).";
            "Zettabytes per second (ZBps)."
when just Packets Per Second and Bits Per Second would work? Yes, you might have to have a really large number in BPS, but that seems much much less likely to lead to errors than having parsers have to deal with this. When a user enters a number their glass would presumably allow them to use a more convenient unit, but having it encoded and decoded into this seems needlessly complex.

I did look through the document and list to try and find discussions on this point - I'm happy to be pointed at a place where it was discussed and agreed.

[Ballot comment]
Thank you for the work put into this document. Based on Med Boucadair’s reply, I have cleared my DISCUSS.

Please find below one blocking DISCUSS points (kept for archiving), 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 . 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

# Previous DISCUSS kept for archiving only

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

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

[Ballot discuss]
Thank you for the work on this document, which I found particularly well written and easy to read despite its length.

Many thanks to James Gruessing for the ART ART review: https://mailarchive.ietf.org/arch/msg/art/MbTX3xfg6tMeG6mieAsT7hA3gXs/, and to the authors for addressing James' comments.

I have an easy to fix DISCUSS concerning the examples, and a point about a MUST which should not be there IMO. I also have a number of comments and question that I hope will help improving the document (or my understanding of it).

I support Roman's DISCUSS, see https://trac.ietf.org/trac/art/wiki/TypicalARTAreaIssues#LanguageTags.

To answer Ben's note - IMO the text about "enterprise numbers" and "Private Enterprise Numbers" is clear enough.

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.

Francesca

1. -----

  JSON encoding of YANG-modeled data is used to illustrate the various
  telemetry operations.

FP: There is an inconsistency between this text and the use of "application/dots+cbor" in the examples. Either the Content-Format should be changed, or all the examples should be adapted to JSON Content-Format (I am not sure about what Content-Format you should use then, you probably know better). My preference is to keep CBOR and keep the Content-Format. I went through all the examples and reported below the inconsistencies.

Section 7.1.2, Figure 4, 5,

FP: If in CBOR, the percentiles should be expressed with the tagged item Decimal fraction (represented as a tagged array).

2. -----

Section 7.2.1, Figure 11, 13, 15, 17

FP: Same comment as 1: unit and peak-g should be unsigned in CBOR.

3. -----

Section 7.3.1, Figure 19, 20

FP: Same comment as 1: capacity and unit should be unsigned in CBOR.

4. -----

Section 7.2.1, Figure 11, 13, 15, 17

FP: Same comment as 1: unit and peak-g should be unsigned in CBOR.

5. -----

Section 7.3.1, Figure 19, 20

FP: Same comment as 1: capacity and unit should be unsigned in CBOR.

6. -----

Figure 36, figure 43

FP: Same comment as 1: unit, mid-percentile-g, start-time and attack-severity should be unsigned in CBOR.

7. -----

Figure 45, 47

FP: attack-status, unit, mid-percentile-g, peak-g should be unsigned. I also note that some of the attributes defined in 9132 are used here and on previous examples and have for values the full spelled out meaning for readability, instead of the actual parameter (for example "status", that should have value 2 for "attack-successfully-mitigated"), and I think that should be at least noted in the text before the example, or if you want to be more precise the "attack-successfully-mitigated" could be a comment next to the value 2.

8. -----

Section 7.1.3

  client, it MUST respond with a 4.04 (Not Found) error Response Code.

FP: I have a preference to remove this MUST here - it is expected behavior that if a resource is not present the server responds with 4.04, so it is not necessary to add the requirement here, actually redefining the response code (although it is the expected one in this case) should be discouraged. I suggest replacing: s/it MUST respond/it responds. (Note that 7.1.4 has the text I would expect, describing the behavior but not adding any already existing requirements).

[Ballot comment]

9. -----

FP: Related to the DISCUSS point about encoding, it would be good to state somewhere in the text (possibly in section 5.6) that CBOR Key Values can be used instead of the parameter names (see section 13.1), but that for readability all examples use the full names.

10. -----

Section 7.1.2, tsid definition

        This is a mandatory attribute. 'tsid' MUST follow 'cuid'.

FP: I am not sure I understand the use of the term "follow" here. Also I am confused by the fact that tsid here is named as an "attribute" while instead it is defined as a Uri-Path parameter, and does not appear in the list of attributes of Figure 3.


11. -----

  Many of the pre-or-ongoing-mitigation telemetry data use a unit that
  falls under the unit class that is configured following the procedure
  described in Section 7.1.2.  When generating telemetry data to send

FP: Section 7.1.2 does not describe the procedure to configure the unit (which at this point in the text I can't find anywhere). All 7.1.2 says is:

  DOTS clients can also configure the unit class(es) to be used for
  traffic-related telemetry data among the following supported unit
  classes: packets per second, bits per second, and bytes per second.
  Supplying both bits per second and bytes per second unit-classes is
  allowed for a given telemetry data.  However, receipt of conflicting
  values is treated as invalid parameters and rejected with 4.00 (Bad
  Request).

what am I missing?

12. -----

Figure 33

FP: Please either add the Reponse header (HTTP/1.1 200 OK \ Content-Type: /yang-data+json + any other header field) (this is my preferred option) or change the caption to indicate that this is only the response content.

13. -----

Section 8.2

        This is a mandatory attribute. 'tmid' MUST follow 'cuid'.

FP: Same question as 10.


14. -----

Section 8.1.6

FP: Suggestion to add a sentence reminding the reader that this exchange happens over the data channel and that's why HTTP and JSON are used. (As Ben made me notice, this is very clearly explained in section 4.1, but I had forgotten by the time I got to this point in the text).

15. -----

FP: question for my understanding that comes from my low experience with YANG: I see that connection-all and connection-percentile-and-peak are groups of the exact same containers. Do they both need to be defined because the description (and hence the use) is different?

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

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

[Ballot discuss]
** Sections 8.1.5 and 9.1. These sections describe a human readable text field, “attack-description”.  Per Section 4.2 of BCP 18, “[p]rotocols that transfer text MUST provide for carrying information about the language of that text.”.  Practically, can a field to list a language tag field (RFC 5646 and https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry) be added in all places that “attack-description” is defined or at the top level?

[Ballot comment]
Authors: thank you for the clarifying language in Section 4.4 explaining how the design of mapping YANG into CBOR

** Section 4.4.  Per “Server deviations are strongly discouraged …”, what kind of “deviations” are being referenced here?  Is it the use of NETCONF/RESTCONF?

** Section 8.1.6.  An attack type appears to be characterized by a vendor-id, vendor-name, last-updated, attack-id and attack-description.  Would an additional field of attack-id-revision (or attack-id-version) be beneficial too?  I’m imagining a workflow where a vendor’s definition of an attack (and the associated detection rule/logic) changes overtime and it might be useful to version that – akin to the snort/suricata’s “rev:” field.  A vendor could of course assign a new attack-id but this might impact down-stream analysis. 

A few editorial suggestions to consider:

** Section 1.  Editorial.  s/more complex and hard to/more complex and harder to/

** Section 1.  Editorial
These attacks are assembled from dynamic attack vectors
  (Network/Application) and tactics.  As such, multiple attack vectors
  formed by multiple attack types and volumes are launched
  simultaneously towards a victim. 

What is the difference between the first and the second sentence?

** Section 1.  Per “The conclusion derived from these real scenarios is that modern …”, what are these “real” scenarios?

** Section 2.  Typo. s/whike/while/

** Section 2.  Typo. s/to be considered to be/considered to be/

** Section 3.1.  It seems like much of this information is a re-statement of what was said in Section 1.  Does it need to be said twice?

** Section 3.1.  “Machine learning approaches …”, do you mean statistical and artificial intelligence algorithms? ML is only a particular approach.

** Section 4.1.  Per “Telemetry information has aspects …”, this sentence if very long and difficult to parse.  Could it be split up for improved readability?

** Section 8.1.4.  typo.  s/subattributes/sub-attributes/

** Section 11.1.  Typo. s/extremly/extremely/

[Ballot comment]
IESG members are encouraged to provide further input on whether
the document should refer to "enterprise numbers" or
"Private Enterprise Numbers"; see last-call review thread at
https://mailarchive.ietf.org/arch/msg/dots/ADAPijIjyZ-2vkcE-k16oIf-fx4/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dots-telemetry-19. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the DOTS Signal Channel CBOR Key Values registry on the Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel registry page located at:

https://www.iana.org/assignments/dots/

eighty-four (84) new values are to be registered in the 128-255 range of the registry as follows:

+----------------------+-------+-------+------------+---------------+
| Parameter Name | CBOR | CBOR | Change | Specification |
| | Key | Major | Controller | Document(s) |
| | Value | Type | | |
+======================+=======+=======+============+===============+
| tsid | TBA1 | 0 | IESG | [ RFC-to-be ] |
| telemetry | TBA2 | 4 | IESG | [ RFC-to-be ] |
| low-percentile | TBA3 | 6tag4 | IESG | [ RFC-to-be ] |
| mid-percentile | TBA4 | 6tag4 | IESG | [ RFC-to-be ] |
| high-percentile | TBA5 | 6tag4 | IESG | [ RFC-to-be ] |
| unit-config | TBA6 | 4 | IESG | [ RFC-to-be ] |
| unit | TBA7 | 0 | IESG | [ RFC-to-be ] |
| unit-status | TBA8 | 7 | IESG | [ RFC-to-be ] |
| total-pipe-capacity | TBA9 | 4 | IESG | [ RFC-to-be ] |
| link-id | TBA10 | 3 | IESG | [ RFC-to-be ] |
| pre-or-ongoing- | TBA11 | 4 | IESG | [ RFC-to-be ] |
| mitigation | | | | |
| total-traffic-normal | TBA12 | 4 | IESG | [ RFC-to-be ] |
| low-percentile-g | TBA13 | 0 | IESG | [ RFC-to-be ] |
| mid-percentile-g | TBA14 | 0 | IESG | [ RFC-to-be ] |
| high-percentile-g | TBA15 | 0 | IESG | [ RFC-to-be ] |
| peak-g | TBA16 | 0 | IESG | [ RFC-to-be ] |
| total-attack-traffic | TBA17 | 4 | IESG | [ RFC-to-be ] |
| total-traffic | TBA18 | 4 | IESG | [ RFC-to-be ] |
| total-connection- | TBA19 | 4 | IESG | [ RFC-to-be ] |
| capacity | | | | |
| connection | TBA20 | 0 | IESG | [ RFC-to-be ] |
| connection-client | TBA21 | 0 | IESG | [ RFC-to-be ] |
| embryonic | TBA22 | 0 | IESG | [ RFC-to-be ] |
| embryonic-client | TBA23 | 0 | IESG | [ RFC-to-be ] |
| connection-ps | TBA24 | 0 | IESG | [ RFC-to-be ] |
| connection-client-ps | TBA25 | 0 | IESG | [ RFC-to-be ] |
| request-ps | TBA26 | 0 | IESG | [ RFC-to-be ] |
| request-client-ps | TBA27 | 0 | IESG | [ RFC-to-be ] |
| partial-request-max | TBA28 | 0 | IESG | [ RFC-to-be ] |
| partial-request- | TBA29 | 0 | IESG | [ RFC-to-be ] |
| client-max | | | | |
| total-attack- | TBA30 | 5 | IESG | [ RFC-to-be ] |
| connection | | | | |
| connection-c | TBA31 | 5 | IESG | [ RFC-to-be ] |
| embryonic-c | TBA32 | 5 | IESG | [ RFC-to-be ] |
| connection-ps-c | TBA33 | 5 | IESG | [ RFC-to-be ] |
| request-ps-c | TBA34 | 5 | IESG | [ RFC-to-be ] |
| attack-detail | TBA35 | 4 | IESG | [ RFC-to-be ] |
| id | TBA36 | 0 | IESG | [ RFC-to-be ] |
| attack-id | TBA37 | 0 | IESG | [ RFC-to-be ] |
| attack-description | TBA38 | 3 | IESG | [ RFC-to-be ] |
| attack-severity | TBA39 | 0 | IESG | [ RFC-to-be ] |
| start-time | TBA40 | 0 | IESG | [ RFC-to-be ] |
| end-time | TBA41 | 0 | IESG | [ RFC-to-be ] |
| source-count | TBA42 | 5 | IESG | [ RFC-to-be ] |
| top-talker | TBA43 | 5 | IESG | [ RFC-to-be ] |
| spoofed-status | TBA44 | 7 | IESG | [ RFC-to-be ] |
| partial-request-c | TBA45 | 5 | IESG | [ RFC-to-be ] |
| total-attack- | TBA46 | 4 | IESG | [ RFC-to-be ] |
| connection-protocol | | | | |
| baseline | TBA49 | 4 | IESG | [ RFC-to-be ] |
| current-config | TBA50 | 5 | IESG | [ RFC-to-be ] |
| max-config-value | TBA51 | 5 | IESG | [ RFC-to-be ] |
| min-config-values | TBA52 | 5 | IESG | [ RFC-to-be ] |
|supported-unit-classes| TBA53 | 5 | IESG | [ RFC-to-be ] |
| server-originated- | TBA54 | 7 | IESG | [ RFC-to-be ] |
| telemetry | | | | |
| telemetry-notify- | TBA55 | 0 | IESG | [ RFC-to-be ] |
| interval | | | | |
| tmid | TBA56 | 0 | IESG | [ RFC-to-be ] |
| measurement-interval | TBA57 | 0 | IESG | [ RFC-to-be ] |
| measurement-sample | TBA58 | 0 | IESG | [ RFC-to-be ] |
| talker | TBA59 | 4 | IESG | [ RFC-to-be ] |
| source-prefix | TBA60 | 3 | IESG | [ RFC-to-be ] |
| mid-list | TBA61 | 4 | IESG | [ RFC-to-be ] |
| source-port-range | TBA62 | 4 | IESG | [ RFC-to-be ] |
| source-icmp-type- | TBA63 | 4 | IESG | [ RFC-to-be ] |
| range | | | | |
| target | TBA64 | 5 | IESG | [ RFC-to-be ] |
| capacity | TBA65 | 0 | IESG | [ RFC-to-be ] |
| protocol | TBA66 | 0 | IESG | [ RFC-to-be ] |
| total-traffic- | TBA67 | 4 | IESG | [ RFC-to-be ] |
| normal-per-protocol | | | | |
| total-traffic- | TBA68 | 4 | IESG | [ RFC-to-be ] |
| normal-per-port | | | | |
| total-connection- | TBA69 | 4 | IESG | [ RFC-to-be ] |
| capacity-per-port | | | | |
| total-traffic- | TBA70 | 4 | IESG | [ RFC-to-be ] |
| protocol | | | | |
| total-traffic-port | TBA71 | 4 | IESG | [ RFC-to-be ] |
| total-attack- | TBA72 | 4 | IESG | [ RFC-to-be ] |
| traffic-protocol | | | | |
| total-attack- | TBA73 | 4 | IESG | [ RFC-to-be ] |
| traffic-port | | | | |
| total-attack- | TBA74 | 4 | IESG | [ RFC-to-be ] |
| connection-port | | | | |
| port | TBA75 | 0 | IESG | [ RFC-to-be ] |
| supported-query-type | TBA76 | 4 | IESG | [ RFC-to-be ] |
| vendor-id | TBA77 | 0 | IESG | [ RFC-to-be ] |
| ietf-dots-telemetry: | TBA78 | 5 | IESG | [ RFC-to-be ] |
| telemetry-setup | | | | |
| ietf-dots-telemetry: | TBA79 | 4 | IESG | [ RFC-to-be ] |
| total-traffic | | | | |
| ietf-dots-telemetry: | TBA80 | 4 | IESG | [ RFC-to-be ] |
| total-attack-traffic | | | | |
| ietf-dots-telemetry: | TBA81 | 5 | IESG | [ RFC-to-be ] |
| total-attack- | | | | |
| connection | | | | |
| ietf-dots-telemetry: | TBA82 | 4 | IESG | [ RFC-to-be ] |
| attack-detail | | | | |
| ietf-dots-telemetry: | TBA83 | 5 | IESG | [ RFC-to-be ] |
| telemetry | | | | |
| current-g | TBA84 | 0 | IESG | [ RFC-to-be ] |
+----------------------+-------+-------+------------+---------------+

Second, in the DOTS Signal Channel Conflict Cause Codes registry also on the Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel registry page located at:

https://www.iana.org/assignments/dots/

a new registration is to be made as follows:

Code: [ TBD-at-Registration ]
Label: overlapping-pipes
Description: Overlapping pipe scope
Reference: [ RFC-to-be ]

Third, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

two new namespaces will be registered as follows:

ID: yang:ietf-dots-telemetry
URI: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-dots-mapping
URI: urn:ietf:params:xml:ns:yang:ietf-dots-mapping
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Fourth, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

two new YANG modules will be registered as follows:

Name: ietf-dots-telemetry
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry
Prefix: dots-telemetry
Module:
Reference: [ RFC-to-be ]

Name: ietf-dots-mapping
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping
Prefix: dots-mapping
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-01-24):

From: The IESG
To: IETF-Announce
CC: dots-chairs@ietf.org, dots@ietf.org, draft-ietf-dots-telemetry@ietf.org, kaduk@mit.edu, valery@smyslov.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry) to Proposed Standard


The IESG has received a request from the DDoS Open Threat Signaling WG (dots)
to consider the following document: - 'Distributed Denial-of-Service Open
Threat Signaling (DOTS) Telemetry'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-01-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document aims to enrich the DOTS signal channel protocol with
  various telemetry attributes, allowing for optimal Distributed
  Denial-of-Service (DDoS) attack mitigation.  It specifies the normal
  traffic baseline and attack traffic telemetry attributes a DOTS
  client can convey to its DOTS server in the mitigation request, the
  mitigation status telemetry attributes a DOTS server can communicate
  to a DOTS client, and the mitigation efficacy telemetry attributes a
  DOTS client can communicate to a DOTS server.  The telemetry
  attributes can assist the mitigator to choose the DDoS mitigation
  techniques and perform optimal DDoS attack mitigation.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/



No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? 

  Proposed Standard as indicated on the title page header and in the datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 
Technical Summary:

  This document aims to enrich DOTS signal channel protocol with
  various telemetry attributes allowing optimal Distributed Denial-of-
  Service attack mitigation.  It specifies the normal traffic baseline
  and attack traffic telemetry attributes a DOTS client can convey to
  its DOTS server in the mitigation request, the mitigation status
  telemetry attributes a DOTS server can communicate to a DOTS client,
  and the mitigation efficacy telemetry attributes a DOTS client can
  communicate to a DOTS server.  The telemetry attributes can assist
  the mitigator to choose the DDoS mitigation techniques and perform
  optimal DDoS attack mitigation.

Working Group Summary:

  The first version of the document was published as individual draft in mid 2019.
  In December 2019 the draft was adopted as a working group document.
  The draft was widely discussed in DOTS WG during 2020, attracting
  most active WG members.

Document Quality:

  Document authors are also co-authors of core DOTS documents (signal channel, data channel etc.)
  The draft was reviewed by YANG Doctors (twice) and by Ops Directorate.
  There are at least two interoperable implementations of the draft,
  one of which participated in IETF 106 Hackathon.

Personnel:

  Valery Smyslov (shepherd)
  Benjamin Kaduk (AD)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. 

  I have reviewed the document and found it ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 

  No. The document was a subject of several reviews in the WG and by external experts (YANG Doctors).

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. 

  The document augments DOTS signal channel protocol with telemetry attributes,
  so that DOTS signal channel YANG module is extended to allow transferring various telemetry information.
  The document was thoroughly reviewed by YANG Doctors: two reviews were performed - an Early Review and a Last Call Review.
  In addition an Early Review has beed performed by Ops Directorate.
  I personally don't think that more reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

  None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

  All authors and contributors confirmed that they are not aware of any IPR related to this draft.

  ** Mohamed Boucadair -- https://mailarchive.ietf.org/arch/msg/dots/o1lRVT6oGe567UDBN9sz_A_fFuk/
  ** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/o7pGwf6oxe_lcMfuhyDEHIIA4ME/
  ** Ehud Doron -- https://mailarchive.ietf.org/arch/msg/dots/j79e88F-4mqKBDbT9mkGIh8vkUk/
  ** Meiling Chen -- https://mailarchive.ietf.org/arch/msg/dots/GqU-y4alFdWDs20UIf5VQxusdPY/
  ** Jon Shallow -- https://mailarchive.ietf.org/arch/msg/dots/JGlv7ksyAICWcPbHpP6UNwVzz8Y/
  ** Li Su -- https://mailarchive.ietf.org/arch/msg/dots/bcMqVOGYMW1N2OPyz3TqAOg9sAU/
  ** Pan Wei -- https://mailarchive.ietf.org/arch/msg/dots/uB7N3USFVoH-FPL9FVXLTdHhS0I/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 

  No IPR disclosure has been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 

  The WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) 

  No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 

  idnits reports a few warnings, all of them are erroneous: weird spacing (in YANG module tree structure) and missing reference to [RFCXXXX] (not a real reference).

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 

  The document contains a YANG module; it was thoroughly reviewed by YANG Doctors.

(13) Have all references within this document been identified as either normative or informative? 

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 

  No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. 

  No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. 

  No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). 

  This document registers a large number of DOTS telemetry attributes in the "DOTS Signal Channel CBOR Key Values" registry.
  It also registers a new cause code in the "DOTS Signal Channel Conflict Cause Codes" registry.
  In addition the document requests IANA to register two new URIs in the "ns" subregistry within the "IETF XML Registry" and
  to register two YANG modules in the "YANG Module Names" subregistry within the "YANG Parameters" registry.

  Requests to IANA are consistent with document's body.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. 

  No new registries are defined by this document.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

  The automated checks of YANG module done via datatracker showed no validation errors. pyang 2.4.0 shows warning "imported module "ietf-dots-signal-channel" not used",
  while in fact this module is used. Authors believe this is a bug in pyang and raised an issue: https://github.com/mbj4668/pyang/issues/719

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

  The YANG module was checked with pyang (2.4.0) and yanglint (1.6.7) tools; no validation errors were found (but see (19)).

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? 

  Proposed Standard as indicated on the title page header and in the datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 
Technical Summary:

  This document aims to enrich DOTS signal channel protocol with
  various telemetry attributes allowing optimal Distributed Denial-of-
  Service attack mitigation.  It specifies the normal traffic baseline
  and attack traffic telemetry attributes a DOTS client can convey to
  its DOTS server in the mitigation request, the mitigation status
  telemetry attributes a DOTS server can communicate to a DOTS client,
  and the mitigation efficacy telemetry attributes a DOTS client can
  communicate to a DOTS server.  The telemetry attributes can assist
  the mitigator to choose the DDoS mitigation techniques and perform
  optimal DDoS attack mitigation.

Working Group Summary:

  The first version of the document was published as individual draft in mid 2019.
  In December 2019 the draft was adopted as a working group document.
  The draft was widely discussed in DOTS WG during 2020, attracting
  most active WG members.

Document Quality:

  Document authors are also co-authors of core DOTS documents (signal channel, data channel etc.)
  The draft was reviewed by YANG Doctors (twice) and by Ops Directorate.
  There are at least two interoperable implementations of the draft,
  one of which participated in IETF 106 Hackathon.

Personnel:

  Valery Smyslov (shepherd)
  Benjamin Kaduk (AD)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. 

  I have reviewed the document and found it ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 

  No. The document was a subject of several reviews in the WG and by external experts (YANG Doctors).

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. 

  The document augments DOTS signal channel protocol with telemetry attributes,
  so that DOTS signal channel YANG module is extended to allow transferring various telemetry information.
  The document was thoroughly reviewed by YANG Doctors: two reviews were performed - an Early Review and a Last Call Review.
  In addition an Early Review has beed performed by Ops Directorate.
  I personally don't think that more reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

  None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

  All authors and contributors confirmed that they are not aware of any IPR related to this draft.

  ** Mohamed Boucadair -- https://mailarchive.ietf.org/arch/msg/dots/o1lRVT6oGe567UDBN9sz_A_fFuk/
  ** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/o7pGwf6oxe_lcMfuhyDEHIIA4ME/
  ** Ehud Doron -- https://mailarchive.ietf.org/arch/msg/dots/j79e88F-4mqKBDbT9mkGIh8vkUk/
  ** Meiling Chen -- https://mailarchive.ietf.org/arch/msg/dots/GqU-y4alFdWDs20UIf5VQxusdPY/
  ** Jon Shallow -- https://mailarchive.ietf.org/arch/msg/dots/JGlv7ksyAICWcPbHpP6UNwVzz8Y/
  ** Li Su -- https://mailarchive.ietf.org/arch/msg/dots/bcMqVOGYMW1N2OPyz3TqAOg9sAU/
  ** Pan Wei -- https://mailarchive.ietf.org/arch/msg/dots/uB7N3USFVoH-FPL9FVXLTdHhS0I/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 

  No IPR disclosure has been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 

  The WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) 

  No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 

  idnits reports a few warnings, all of them are erroneous: weird spacing (in YANG module tree structure) and missing reference to [RFCXXXX] (not a real reference).

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 

  The document contains a YANG module; it was thoroughly reviewed by YANG Doctors.

(13) Have all references within this document been identified as either normative or informative? 

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 

  No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. 

  No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. 

  No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). 

  This document registers a large number of DOTS telemetry attributes in the "DOTS Signal Channel CBOR Key Values" registry.
  It also registers a new cause code in the "DOTS Signal Channel Conflict Cause Codes" registry.
  In addition the document requests IANA to register two new URIs in the "ns" subregistry within the "IETF XML Registry" and
  to register two YANG modules in the "YANG Module Names" subregistry within the "YANG Parameters" registry.

  Requests to IANA are consistent with document's body.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. 

  No new registries are defined by this document.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

  The automated checks of YANG module done via datatracker showed no validation errors. pyang 2.4.0 shows warning "imported module "ietf-dots-signal-channel" not used",
  while in fact this module is used. Authors believe this is a bug in pyang and raised an issue: https://github.com/mbj4668/pyang/issues/719

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

  The YANG module was checked with pyang (2.4.0) and yanglint (1.6.7) tools; no validation errors were found (but see (19)).