Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
draft-ietf-dots-rfc8782-bis-08

[Ballot comment]
I also only reviewed the diff to RFC 8782.  (I really love that feature.)

The shepherd writeup omits an answer to the question "Why is this the proper type of RFC?"  Fortunately it's obvious here, but it would be better to be clear about it generally.

In Section 3.1:

  The main changes to [RFC8782] are listed in Appendix A.  These
  modifications are made with the constraint to avoid changes to the
  mapping table defined in Table 5 of [RFC8782] (see also Section 6).

Section 6 of which document?

In Section 10.1: s/docuement/document/

[Ballot comment]
[S3] [comment]

* I don't know if it's really necessary to dredge up RFC 6296, but I
  understand the desire for completeness.

[S4.4.1.1] [question]

* For "lifetime" in the case where a "target-fqdn" was given, should the
  resolution library's knowledge of the DNS RR TTL value(s) be factored in?

  For example, what does lifetime=3600s mean for a hostname whose A/AAAA
  RRs have only 5 minute lifetimes?  Is the DOTS server/enforcer expected
  to continuously re-resolve every ${DNS_RR_TTL} and apply the policy for
  up to the full 3600 seconds, or is the DNS RR TTL ignored once the
  resolution has been confirmed to have succeeded or failed?

[Ballot comment]
Hi,

I only reviewed the delta from RFC 8782.  Just a couple of minor comments.

I think that the revision description in the ietf-dots-signal-channel YANG module should clearly indicate that it is a non-backwards compatible replacement of the previous module revision.

The description of the "dots-signal" structure and "message-type" choice makes no mention of the "heartbeat" case.  Is that intentional?

Thanks,
Rob

[Ballot comment]
Thank you for addressing Michael Tuexen's TSVART review.

As I did not review RFC8782, I'm taking this opportunity to review the entire document, rather than just the bis. I found numerous clarity issues:

(4.4.1.1) How do DOTS servers detect a CUID collision? I believe Sec. 7 explains this is based on client authentication, but mentioning it here would be helpful.

In the "mid" definition: s/no attack is detected/no attack is underway

In the "target_fqdn" definition. The text appears to assume a DNS resolution; is there a not a use case where the DOTS server would rely on e.g. SNI inspection and not defend an entire IP address that had multiple domains?

"lifetime" definition: The text says the DOTS server MAY reject unlimited lifetime, which implies that it MUST accept any finite lifetime. I presume you mean to say that DOTS servers are free to set a policy limit on the maximum allowable lifetime?

(4.4.1.2) "cdid" definition: The example in Fig. 9 does not have a cdid that matches the cuid. The text indicates that these might not match if a client-side gateway added the cdid, but then later says that "only the first on-path server-domain DOTS gateway can  insert a 'cdid' value." After reading this a few times, I think what you are saying is (a) clients MUST NOT add cdid; (b) client-side gateways SHOULD add them; (c) the first server-side gateway MUST strip them and then add their own; and (d) subsequent server side gateways MUST NOT change the cdid. Is this correct? Either way, it could be expressed less confusingly.

(4.4.1.3) Fig. 11: Where does the second cuid come from? Is this generated by the server on behalf of the client? If so, I recommend s/a new request with a new 'cuid'/a new request with a new, server-provided 'cuid'

When extending the lifetime, does the new lifetime field measure from the initial trigger or from the moment of extension? If the former, a change in the lifetime value is mandatory, not "potential." If the latter, how does the server distinguish this from a duplicate request?

(4.4.2) Fig. 14 uses a string to represent the status instead of one of the values in Table 3.

(4.4.3) Same with Fig. 16 and Table 4.

(4.4.2.1) If updates are non-confirmable, how does the client know if it's gotten out of sync on state updates?

(4.5.1) What is the unit of probing rate?

(8) s/should/SHOULD, s/must/MUST throughout.

[Ballot comment]
As I did not review RFC8782, I'm taking this opportunity to review the entire document, rather than just the bis. I found numerous clarity issues:

(4.4.1.1) How do DOTS servers detect a CUID collision? Is this based on client authentication or something else?

In the "mid" definition: s/no attack is detected/no attack is underway

In the "target_fqdn" definition. The text appears to assume a DNS resolution; is there a not a use case where the DOTS server would rely on e.g. SNI inspection and not defend an entire IP address that had multiple domains?

"lifetime" definition: The text says the DOTS server MAY reject unlimited lifetime, which implies that it MUST accept any finite lifetime. I presume you mean to say that DOTS servers are free to set a policy limit on the maximum allowable lifetime?

(4.4.1.2) "cdid" definition: The example in Fig. 9 does not have a cdid that matches the cuid. The text indicates that these might not match if a client-side gateway added the cdid, but then later says that "only the first on-path server-domain DOTS gateway can  insert a 'cdid' value." After reading this a few times, I think what you are saying is (a) clients MUST NOT add cdid; (b) client-side gateways SHOULD add them; (c) the first server-side gateway MUST strip them and then add their own; and (d) subsequent server side gateways MUST NOT change the cdid. Is this correct? Either way, it could be expressed less confusingly.

(4.4.1.3) Fig. 11: Where does the second cuid come from? Is this generated by the server on behalf of the client? If so, I recommend s/a new request with a new 'cuid'/a new request with a new, server-provided 'cuid'

When extending the lifetime, does the new lifetime field measure from the initial trigger or from the moment of extension? If the former, a change in the lifetime value is mandatory, not "potential." If the latter, how does the server distinguish this from a duplicate request?

(4.4.2) Fig. 14 uses a string to represent the status instead of one of the values in Table 3.

(4.4.3) Same with Fig. 16 and Table 4.

(4.4.2.1) If updates are non-confirmable, how does the client know if it's gotten out of sync on state updates?

(4.5.1) What is the unit of probing rate?

(8) "The DOTS server should support certificate-based client
  authentication.  The DOTS client should respond to the DOTS server's
  TLS CertificateRequest message with the PKIX certificate held by the
  DOTS client.  DOTS client certificate validation must be performed
  per [RFC5280], and the DOTS client certificate must conform to the
  [RFC5280] certificate profile.  If a DOTS client does not support TLS
  client certificate authentication, it must support client
  authentication based on pre-shared key or raw public key."

s/should/SHOULD, s/must/MUST

[Ballot comment]
As I did not review RFC8782, I'm taking this opportunity to review the entire document, rather than just the bis. I found numerous clarity issues:

(4.4.1.1) How do DOTS servers detect a CUID collision? Is this based on client authentication or something else?

In the "mid" definition: s/no attack is detected/no attack is underway

In the "target_fqdn" definition. The text appears to assume a DNS resolution; is there a not a use case where the DOTS server would rely on e.g. SNI inspection and not defend an entire IP address that had multiple domains?

"lifetime" definition: The text says the DOTS server MAY reject unlimited lifetime, which implies that it MUST accept any finite lifetime. I presume you mean to say that DOTS servers are free to set a policy limit on the maximum allowable lifetime?

(4.4.1.2) "cdid" definition: The example in Fig. 9 does not have a cdid that matches the cuid. The text indicates that these might not match if a client-side gateway added the cdid, but then later says that "only the first on-path server-domain DOTS gateway can  insert a 'cdid' value." After reading this a few times, I think what you are saying is (a) clients MUST NOT add cdid; (b) client-side gateways SHOULD add them; (c) the first server-side gateway MUST strip them and then add their own; and (d) subsequent server side gateways MUST NOT change the cdid. Is this correct? Either way, it could be expressed less confusingly.

(4.4.1.3) Fig. 11: Where does the second cuid come from? Is this generated by the server on behalf of the client? If so, I recommend s/a new request with a new 'cuid'/a new request with a new, server-provided 'cuid'

When extending the lifetime, does the new lifetime field measure from the initial trigger or from the moment of extension? If the former, a change in the lifetime value is mandatory, not "potential." If the latter, how does the server distinguish this from a duplicate request?

(4.4.2) Fig. 14 uses a string to represent the status instead of one of the values in Table 3.

(4.4.3) Same with Fig. 16 and Table 4.

(4.4.2.1) If updates are non-confirmable, how does the client know if it's gotten out of sync on state updates?

(8) "The DOTS server should support certificate-based client
  authentication.  The DOTS client should respond to the DOTS server's
  TLS CertificateRequest message with the PKIX certificate held by the
  DOTS client.  DOTS client certificate validation must be performed
  per [RFC5280], and the DOTS client certificate must conform to the
  [RFC5280] certificate profile.  If a DOTS client does not support TLS
  client certificate authentication, it must support client
  authentication based on pre-shared key or raw public key."

s/should/SHOULD, s/must/MUST

[Ballot comment]
Thank you for the work put into this document.

As I already reviewed the original RFC 8782, I have only review the diffs (thanks to RFCDIFF!).

Please find below some non-blocking COMMENT points (but replies would be appreciated).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 3.1 --
In "that follow the present specification", the use of "present" is ambiguous: does it mean current implementations of RFC 8782? or this specification (i.e., this I-D) ?

-- Section 4.4.1.3 --
I wonder why a port number can be used if the case of common/shared URI ? In "A list of port numbers may also be included if there is a common IP address, IP prefix, FQDN, URI, or alias."
       
-- Section 5.3 --
I am not a YANG module expert but using a union for 'lifetime' just to allow a -1 value to signal infinity looks a little weird to me. Could the value 0x7fffffff be used for 'infinity' and keeping a uint32 ?

In probing-rate.current-value, there is a default value of 5 byte/second. Is it useful to recommend such a default value ?

More generically, I wonder whether measuring in octets/second is more suitable than in bits/second.

The 'alt-server' is now better typed as 'inet:domain-name' but I now wonder whether relying solely on DNS in a case of DoS is sensible.

[Ballot comment]
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 4.3, paragraph 2, nit:
-    connectionless and connection-oriented protocols.  As such, the DOTS
+    connection-less and connection-oriented protocols.  As such, the DOTS
+              +

Section 4.4.1.1, paragraph 39, nit:
-      The use of FQDNs may be suboptimal because:
+      The use of FQDNs may be suboptimal, because:
+                                        +

Section 5.3, paragraph 26, nit:
-                Ths is is a mandatory attribute when a client
-                  --
+                This is a mandatory attribute when a client

Section 10.1, paragraph 3, nit:
-    assigned to this docuement:
-                        -
+    assigned to this document:

Section 1, paragraph 5, nit:
> lient. The DOTS server may or may not not be co-located with the DOTS mitiga
>                                  ^^^^^^^
Double negatives are discouraged in standard English. Can you reformulate this
phrase or is a comma missing?

Section 4.4.1.1, paragraph 3, nit:
> ys MUST handle 'cuid' collision directly and it is RECOMMENDED that 'cuid' c
>                                ^^^^^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

Section 4.4.3, paragraph 6, nit:
> DOTS client will send a Reset | message so it does not receive any more retra
>                                ^^^^^^^^^^
Use a comma before 'so' if it connects two independent clauses (unless they are
closely connected and short).

Section 4.5.1, paragraph 22, nit:
> rtbeat frequency. It is NOT RECOMMENDED to return a Max-Age Option set to 0.
>                            ^^^^^^^^^^^^^^^^^^^^^
The verb 'RECOMMENDED' is used with the gerund form: "RECOMMENDED returning".

Section 6, paragraph 5, nit:
> S server when the Content-Format is used but the request is not formatted as
>                                    ^^^^
Use a comma before 'but' if it connects two independent clauses (unless they
are closely connected and short).

Section 6, paragraph 5, nit:
> ' URI IANA is requested to update the the 'dots' well-known URI (Table 6) en
>                                  ^^^^^^^
Possible typo: you repeated a word

Obsolete reference to RFC5246, obsoleted by RFC8446.

Document references draft-ietf-dots-multihoming-05, but -06 is the latest
available revision.

Document references draft-ietf-dots-telemetry-15, but -16 is the latest
available revision.

Document references draft-ietf-dots-use-cases, but that has been published as
RFC8903.

These URLs in the document can probably be converted to HTTPS:
* http://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml
* http://www.iana.org/assignments/media-types
* http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats
* http://www.iana.org/assignments/protocol-numbers

[Ballot comment]
In Section 4.4.1.3, the description of 'conflict-scope' for the case of
conflicting requests from different clients has lost the "a list of
prefixes" item as a possible scope.  (The analogous text for the
"conflicting with a different 'mid' case does still list prefixes as
possible.)

I see that there was some discussion in the genart thread about whether
the "conflict-information" tree is really "optional" in certain cases.
However, in going from the -04 to the -06, we also lost the marking that
it "must only be used for responses", and I didn't quite follow why that
change was needed.  (I am not sure that we need to change the text, but
please help me understand whether the node can be present in requests as
well.)


The genart reviewer also remarked:

>  Also, you need to specify whether
> the connection to the alternate server is a new session (with
> independent state) or whether it is expected to be a continuation of
> the existing session (carrying the same state).

to which Med responds "This is covered here:

  When the DOTS client receives a 5.03 response with an alternate
  server included, it considers the current request to have failed, but
  it SHOULD try resending the request to the alternate DOTS server."

This wording seems to imply that the session state is preserved, but I
think it would be beneficial to be explicit about it.


From the secdir thread, in Section 7.3, we may not need a new normative
requirement that essentially duplicates what's already stated in RFC
6347.  Since RFC 6347 already has a "MUST fit"
requirement, we could just rely on that and avoid using new normative
language, perhaps as:

  To avoid DOTS signal message fragmentation and the subsequent
  decreased probability of message delivery, the DLTS records need to
  fit within a single datagram [RFC6347].

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

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

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

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

First, in the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

the registration for port number 4646 for both UDP and TCP will be changed from RFC8782 to [ RFC-to-be ].

Second, in the Well-Known URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

the existing registration for URI Suffix dots will be changed from RFC8782 to [ RFC-to-be ].

Third, in the application registration space on the Media Types registry page located at:

http://www.iana.org/assignments/media-types/

the existing registration for dots+cbor will be changed from RFC8782 to [ RFC-to-be ]. The template for this registration is in Section 10.3 of [ RFC-to-be ].

Fourth, in the CoAP Content-Formats registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

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

the existing registration for ID: 271, Media Type application/dots+cbor will have its reference changed to [ RFC-to-be ].

Fifth, in the Concise Binary Object Representation (CBOR) Tags registry located at:

https://www.iana.org/assignments/cbor-tags/

the existing registration for Tag 271 will be changed as follows:

Tag: 271
Data Item: DDoS Open Threat Signaling (DOTS) signal channel object
Semantics: DDoS Open Threat Signaling (DOTS) signal channel object, as defined in [ RFC-to-be ].
Reference: [ RFC-to-be ]

Sixth, 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/

the registration procedures (via RFC 8126) are to be changed as follows:

OLD:
+-------------+-------------------------+------------------------+
| Range | Registration Procedures | Note |
+=============+=========================+========================+
| 1-16383 | IETF Review | comprehension-required |
| 16384-32767 | Specification Required | comprehension-optional |
| 32768-49151 | IETF Review | comprehension-optional |
| 49152-65535 | Private Use | comprehension-optional |
+-------------+-------------------------+------------------------+
NEW:
+-------------+-------------------------+------------------------+
| Range | Registration Procedures | Note |
+=============+=========================+========================+
| 1-127 | IETF Review | comprehension-required |
| 128-255 | IETF Review | comprehension-optional |
| 256-16383 | IETF Review | comprehension-required |
| 16384-32767 | Specification Required | comprehension-optional |
| 32768-49151 | IETF Review | comprehension-optional |
| 49152-65535 | Private Use | comprehension-optional |
+-------------+-------------------------+------------------------+

In addition, a note will be made in the registry that registration requests for the 16384-32767 range are evaluated after a three-week review period on the dots-signal-reg-review@ietf.org mailing list.

Seventh, also 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/

the registry is to be updated to the following:

+---------------------+------------+-----+----------+---------------+
| Parameter Name | CBOR Key |CBOR | Change | Specification |
| | Value |Major|Controller| Document(s) |
| | |Type | | |
+=====================+============+=====+==========+===============+
| Reserved | 0 | | | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| ietf-dots-signal- | 1 | 5 | IESG | [ RFC-to-be ] |
| channel:mitigation- | | | | |
| scope | | | | |
+---------------------+------------+-----+----------+---------------+
| scope | 2 | 4 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| cdid | 3 | 3 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| cuid | 4 | 3 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| mid | 5 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| target-prefix | 6 | 4 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| target-port-range | 7 | 4 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| lower-port | 8 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| upper-port | 9 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| target-protocol | 10 | 4 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| target-fqdn | 11 | 4 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| target-uri | 12 | 4 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| alias-name | 13 | 4 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| lifetime | 14 | 0/1 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| mitigation-start | 15 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| status | 16 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
|conflict-information | 17 | 5 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| conflict-status | 18 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| conflict-cause | 19 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| retry-timer | 20 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| conflict-scope | 21 | 5 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| acl-list | 22 | 4 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| acl-name | 23 | 3 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| acl-type | 24 | 3 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| bytes-dropped | 25 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| bps-dropped | 26 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| pkts-dropped | 27 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| pps-dropped | 28 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| attack-status | 29 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
|ietf-dots-signal- | 30 | 5 | IESG | [ RFC-to-be ] |
|channel:signal-config| | | | |
+---------------------+------------+-----+----------+---------------+
| sid | 31 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| mitigating-config | 32 | 5 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| heartbeat-interval | 33 | 5 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| min-value | 34 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| max-value | 35 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| current-value | 36 | 0 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| missing-hb-allowed | 37 | 5 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| max-retransmit | 38 | 5 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| ack-timeout | 39 | 5 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| ack-random-factor | 40 | 5 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| min-value-decimal | 41 |6tag4| IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| max-value-decimal | 42 |6tag4| IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
|current-value-decimal| 43 |6tag4| IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| idle-config | 44 | 5 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| trigger-mitigation | 45 | 7 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| ietf-dots-signal- | 46 | 5 | IESG | [ RFC-to-be ] |
| channel:redirected- | | | | |
| signal | | | | |
+---------------------+------------+-----+----------+---------------+
| alt-server | 47 | 3 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| alt-server-record | 48 | 4 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| ietf-dots-signal- | 49 | 5 | IESG | [ RFC-to-be ] |
| channel:heartbeat | | | | |
+---------------------+------------+-----+----------+---------------+
| probing-rate | 50 | 5 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| peer-hb-status | 51 | 7 | IESG | [ RFC-to-be ] |
+---------------------+------------+-----+----------+---------------+
| Unassigned | 52-49151 | | | |
+---------------------+------------+-----+----------+---------------+
|Reserved for Private |49152-65535 | | | [ RFC-to-be ] |
| Use | | | | |
+---------------------+------------+-----+----------+---------------+

IANA Question --> The DOTS Signal Channel CBOR Key Values Registry has two registrations from [RFC-ietf-dots-signal-filter-control-07] as follows:

Name: activation-type
CBOR Key Value: 52
CBOR Major Type: 0
Change controller: IESG

Name: ietf-dots-signal-control:acl-list
CBOR Key Value: 553
CBOR Major Type: 4
Change controller: IESG

Should these two registrations be carried into the revision of the registry?

Eighth, in the DOTS Signal Channel Status 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/

all of the registrations that currently have references for RFC8782 will have those references changed to [ RFC-to-be ].

Ninth, in the DOTS Signal Channel Conflict Status 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/

all of the registrations that currently have references for RFC8782 will have those references changed to [ RFC-to-be ].

Tenth, 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/

all of the registrations that currently have references for RFC8782 will have those references changed to [ RFC-to-be ].

Eleventh, in the DOTS Signal Channel Attack Status 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/

all of the registrations that currently have references for RFC8782 will have those references changed to [ RFC-to-be ].

Twelveth, in the ns registration space on the IETF XML registry located at:

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

the references for the following namespaces will be changed from RFC8782 to [ RFC-to-be ]:

URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel
URI: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel

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

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

the references for the following YANG Modules will be changed from RFC8782 to [ RFC-to-be ]:

ietf-dots-signal-channel
iana-dots-signal-channel

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

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

the note for the iana-dots-signal-channel YANG module is to be changed to the following text:

Status, conflict status, conflict cause, and attack status values must not be directly added to the iana-dots-signal-channel YANG module. They must instead be respectively added to the "DOTS Status Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause Codes", and "DOTS Attack Status Codes" registries.

Fifteenth, in four DOTS registries:

DOTS Status Codes
DOTS Conflict Status Codes
DOTS Conflict Cause Codes
DOTS Attack Status Codes

the following note is to be added to each registry:

When this registry is modified, the YANG module iana-dots-signal-channel must be updated as defined in [ RFC-to-be ].

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
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-03-22):

From: The IESG
To: IETF-Announce
CC: dots-chairs@ietf.org, dots@ietf.org, draft-ietf-dots-rfc8782-bis@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) Signal Channel Specification) 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) Signal
  Channel Specification'
  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 2021-03-22. 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 specifies the Distributed Denial-of-Service Open Threat
  Signaling (DOTS) signal channel, a protocol for signaling the need
  for protection against Distributed Denial-of-Service (DDoS) attacks
  to a server capable of enabling network traffic mitigation on behalf
  of the requesting client.

  A companion document defines the DOTS data channel, a separate
  reliable communication layer for DOTS management and configuration
  purposes.

  This document obsoletes RFC 8782.




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



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7918: Transport Layer Security (TLS) False Start (Informational - IETF stream)

(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 specifies the Distributed Denial-of-Service Open Threat
  Signaling (DOTS) signal channel, a protocol for signaling the need
  for protection against Distributed Denial-of-Service (DDoS) attacks
  to a server capable of enabling network traffic mitigation on behalf
  of the requesting client.

  This document obsoletes RFC 8782.

Working Group Summary:

  Shortly after RFC 8782 was published in May 2020 a problem with a YANG module defined in it was discovered.
  The WG decided to publish a -bis document to fix the problem. The -00 version of the draft was prepared
  fairly quickly (in June 2020) and the document was adopted in August 2020 (with a good WG support for adoption).
  The draft has been widely discussed and reviewed.

Document Quality:

  This draft is a -bis document for RFC 8782, its main purpose is to fix YANG module. In addition it provides more
  comprehensive description of error handling and makes minor changes to DOTS CBOR Key Values allocation.
  This document doesn't change the DOTS Signal Channel protocol itself, in particular it doesn't change bits on the wire.
  DOTS Signal Channel protocol was thoroughly discussed and reviewed. There are at least two interoperable implementations of this protocol.
  The updated YANG module has been reviewed by YANG Doctors, who confirmed that they don't have problems with it.

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. 

  This document doesn't change the DOTS Signal Channel protocol, defined in RFC 8782, which was thoroughly reviewed
  by TSV experts. The document updates YANG module describing data structures, so that it is more in line with YANG specification.
  The updated YANG module has been reviewed by YANG Doctors twice - an Early Review and a Last Call Review.
  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/-lbAm-E02-OgUZSFYJn5CdU6L8M/
  ** Jon Shallow -- https://mailarchive.ietf.org/arch/msg/dots/wP5kheyWwgXbEfISsjFWWV3DBGw/
  ** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/9n4n_U1nOxyIIy6IVufK8DGDMyc/

(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 issues with this document, all of them are erroneous: weird spacing (in YANG module tree structure), missing reference to [RFCXXXX] (not a real reference), referencing TLS 1.2 (done on purpose) and downward normative reference to RFC 7918 (described below).

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

  This document contains a normative reference to Informational RFC 7918.

  The authors believe it's important to keep this reference because using RFC 7918 allows to deliver dots signal messages sooner
  and avoid extra delays that will jeopardize the mitigation. Note that RFC 8782 contained this downward normative reference too.

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

  This document obsoletes RFC8782. This is indicated in the title page header, listed in the Abstract and is discussed in the Introduction.
  The document also contains summary of changes from RFC 8782.

(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 requests IANA to update a number of records previously created by RFC 8782.
  Most update requests simply change references from "RFC8782" to "RFCXXXX".
  IANA is also requested to update prefixes for the YANG modules in the  "YANG Module Names" subregistry
  within the "YANG Parameters" registry from "signal" to "dots-signal" and from "iana-signal" to "iana-dots-signal".

  The only more substantial request to IANA is to update the "DOTS Signal Channel CBOR Key Values" from
  the "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel" IANA Registry, that was created by RFC 8782.
  The request is to reserve a range of one-octet CBOR Key Values for "comprehension-optional" keys.
  The registration policy for this range is IETF Review.

  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 or warnings.

(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 or warnings were found.

(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 specifies the Distributed Denial-of-Service Open Threat
  Signaling (DOTS) signal channel, a protocol for signaling the need
  for protection against Distributed Denial-of-Service (DDoS) attacks
  to a server capable of enabling network traffic mitigation on behalf
  of the requesting client.

  This document obsoletes RFC 8782.

Working Group Summary:

  Shortly after RFC 8782 was published in May 2020 a problem with a YANG module defined in it was discovered.
  The WG decided to publish a -bis document to fix the problem. The -00 version of the draft was prepared
  fairly quickly (in June 2020) and the document was adopted in August 2020 (with a good WG support for adoption).
  The draft has been widely discussed and reviewed.

Document Quality:

  This draft is a -bis document for RFC 8782, its main purpose is to fix YANG module. In addition it provides more
  comprehensive description of error handling and makes minor changes to DOTS CBOR Key Values allocation.
  This document doesn't change the DOTS Signal Channel protocol itself, in particular it doesn't change bits on the wire.
  DOTS Signal Channel protocol was thoroughly discussed and reviewed. There are at least two interoperable implementations of this protocol.
  The updated YANG module has been reviewed by YANG Doctors, who confirmed that they don't have problems with it.

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. 

  This document doesn't change the DOTS Signal Channel protocol, defined in RFC 8782, which was thoroughly reviewed
  by TSV experts. The document updates YANG module describing data structures, so that it is more in line with YANG specification.
  The updated YANG module has been reviewed by YANG Doctors twice - an Early Review and a Last Call Review.
  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 other than have been filed.

  ** Mohamed Boucadair -- https://mailarchive.ietf.org/arch/msg/dots/-lbAm-E02-OgUZSFYJn5CdU6L8M/
  ** Jon Shallow -- https://mailarchive.ietf.org/arch/msg/dots/wP5kheyWwgXbEfISsjFWWV3DBGw/
  ** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/9n4n_U1nOxyIIy6IVufK8DGDMyc/

(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 issues with this document, all of them are erroneous: weird spacing (in YANG module tree structure), missing reference to [RFCXXXX] (not a real reference), referencing TLS 1.2 (done on purpose) and downward normative reference to RFC 7918 (described below).

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

  This document contains a normative reference to Informational RFC 7918.

  The authors believe it's important to keep this reference because using RFC 7918 allows to deliver dots signal messages sooner
  and avoid extra delays that will jeopardize the mitigation. Note that RFC 8782 contained this downward normative reference too.

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

  This document obsoletes RFC8782. This is indicated in the title page header, listed in the Abstract and is discussed in the Introduction.
  The document also contains summary of changes from RFC 8782.

(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 requests IANA to update a number of records previously created by RFC 8782.
  Most update requests simply change references from "RFC8782" to "RFCXXXX".
  IANA is also requested to update prefixes for the YANG modules in the  "YANG Module Names" subregistry
  within the "YANG Parameters" registry from "signal" to "dots-signal" and from "iana-signal" to "iana-dots-signal".

  The only more substantial request to IANA is to update the "DOTS Signal Channel CBOR Key Values" from
  the "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel" IANA Registry, that was created by RFC 8782.
  The request is to reserve a range of one-octet CBOR Key Values for "comprehension-optional" keys.
  The registration policy for this range is IETF Review.

  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 or warnings.

(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 or warnings were found.

(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 specifies the Distributed Denial-of-Service Open Threat
  Signaling (DOTS) signal channel, a protocol for signaling the need
  for protection against Distributed Denial-of-Service (DDoS) attacks
  to a server capable of enabling network traffic mitigation on behalf
  of the requesting client.

  This document obsoletes RFC 8782.

Working Group Summary:

  Shortly after RFC 8782 was published in May 2020 a problem with a YANG module defined in it was discovered.
  The WG decided to publish a -bis document to fix the problem. The -00 version of the draft was prepared
  fairly quickly (in June 2020) and the document was adopted in August 2020 (with a good WG support for adoption).
  The draft has been widely discussed and reviewed.

Document Quality:

  This draft is a -bis document for RFC 8782, its main purpose is to fix YANG module. In addition it provides more
  comprehensive description of error handling and makes minor changes to DOTS CBOR Key Values allocation.
  This document doesn't change the DOTS Signal Channel protocol itself, in particular it doesn't change bits on the wire.
  DOTS Signal Channel protocol was thoroughly discussed and reviewed. There are at least two interoperable implementations of this protocol.
  The updated YANG module has been reviewed by YANG Doctors, who confirmed that they don't have problems with it.

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. 

  This document doesn't change the DOTS Signal Channel protocol, defined in RFC 8782, which was thoroughly reviewed
  by TSV experts. The document updates YANG module describing data structures, so that it is more in line with YANG specification.
  The updated YANG module has been reviewed by YANG Doctors twice - an Early Review and a Last Call Review.
  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 other than have been filed.

  ** Mohamed Boucadair -- https://mailarchive.ietf.org/arch/msg/dots/-lbAm-E02-OgUZSFYJn5CdU6L8M/
  ** Jon Shallow -- https://mailarchive.ietf.org/arch/msg/dots/wP5kheyWwgXbEfISsjFWWV3DBGw/
  ** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/9n4n_U1nOxyIIy6IVufK8DGDMyc/

(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 issues with this document, all of them are erroneous: weird spacing (in YANG module tree structure), missing reference to [RFCXXXX] (not a real reference), referencing TLS 1.2 (done on purpose) and downward normative reference to RFC 7918 (described below).

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

  This document contains a normative reference to Informational RFC 7918.

  The authors believe it's important to keep this reference because using RFC 7918 allows to deliver dots signal messages sooner
  and avoid extra delays that will jeopardize the mitigation. Note that RFC 8782 contained this downward normative reference too.

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

  This document obsoletes RFC8782. This is indicated in the title page header, listed in the Abstract and is discussed in the Introduction.
  The document also contains summary of changes from RFC 8782.

(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 requests IANA to update a number of records previously created by RFC 8782.
  Most update requests simply change references from "RFC8782" to "RFCXXXX".
  IANA is also requested to update prefixes for the YANG modules in the  "YANG Module Names" subregistry
  within the "YANG Parameters" registry from "signal" to "dots-signal" and from "iana-signal" to "iana-dots-signal".

  The only more substantial request to IANA is to update the "DOTS Signal Channel CBOR Key Values" from
  the "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel" IANA Registry, that was created by RFC 8782.
  The request is to reserve a range of one-octet CBOR Key Values for "comprehension-optional" keys.
  The registration policy for this range is IETF Review.

  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 or warnings.

(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 or warnings were found.

(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 specifies the Distributed Denial-of-Service Open Threat
  Signaling (DOTS) signal channel, a protocol for signaling the need
  for protection against Distributed Denial-of-Service (DDoS) attacks
  to a server capable of enabling network traffic mitigation on behalf
  of the requesting client.

  This document obsoletes RFC 8782.

Working Group Summary:

  Shortly after RFC 8782 was published in May 2020 a problem with a YANG module defined in it was discovered.
  The WG decided to publish a -bis document to fix the problem. The -00 version of the draft was prepared
  fairly quickly (in June 2020) and the document was adopted in August 2020 (with a good WG support for adoption).
  The draft has been widely discussed and reviewed.

Document Quality:

  This draft is a -bis document for RFC 8782, its main purpose is to fix YANG module. In addition it provides more
  comprehensive description of error handling and makes minor changes to DOTS CBOR Key Values allocation.
  This document doesn't change the DOTS Signal Channel protocol itself, in particular it doesn't change bits on the wire.
  DOTS Signal Channel protocol was thoroughly discussed and reviewed. There are at least two interoperable implementations of this protocol.
  The updated YANG module has been reviewed by YANG Doctors, who confirmed that they don't have problems with it.

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. 

  This document doesn't change the DOTS Signal Channel protocol, defined in RFC 8782, which was thoroughly reviewed
  by TSV experts. The document updates YANG module describing data structures, so that it is more in line with YANG specification.
  The updated YANG module has been reviewed by YANG Doctors twice - an Early Review and a Last Call Review.
  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 other than have been filed.

  ** Mohamed Boucadair -- https://mailarchive.ietf.org/arch/msg/dots/-lbAm-E02-OgUZSFYJn5CdU6L8M/
  ** Jon Shallow -- https://mailarchive.ietf.org/arch/msg/dots/wP5kheyWwgXbEfISsjFWWV3DBGw/
  ** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/9n4n_U1nOxyIIy6IVufK8DGDMyc/

(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 issues with this document, all of them are erroneous: weird spacing (in YAND module tree structure), missing reference to [RFCXXXX] (not a real reference), referencing TLS 1.2 (done on purpose) and downward normative reference to RFC 7918 (described below).

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

  This document contains a normative reference to Informational RFC 7918.

  The authors believe it's important to keep this reference because using RFC 7918 allows to deliver dots signal messages sooner
  and avoid extra delays that will jeopardize the mitigation. Note that RFC 8782 contained this downward normative reference too.

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

  This document obsoletes RFC8782. This is indicated in the title page header, listed in the Abstract and is discussed in the Introduction.
  The document also contains summary of changes from RFC 8782.

(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 requests IANA to update a number of records previously created by RFC 8782.
  Most update requests simply change references from "RFC8782" to "RFCXXXX".
  IANA is also requested to update prefixes for the YANG modules in the  "YANG Module Names" subregistry
  within the "YANG Parameters" registry from "signal" to "dots-signal" and from "iana-signal" to "iana-dots-signal".

  The only more substantial request to IANA is to update the "DOTS Signal Channel CBOR Key Values" from
  the "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel" IANA Registry, that was created by RFC 8782.
  The request is to reserve a range of one-octet CBOR Key Values for "comprehension-optional" keys.
  The registration policy for this range is IETF Review.

  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 or warnings.

(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 or warnings were found.

(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 specifies the Distributed Denial-of-Service Open Threat
  Signaling (DOTS) signal channel, a protocol for signaling the need
  for protection against Distributed Denial-of-Service (DDoS) attacks
  to a server capable of enabling network traffic mitigation on behalf
  of the requesting client.

  This document obsoletes RFC 8782.

Working Group Summary:

  Shortly after RFC 8782 was published in May 2020 a problem with a YANG module defined in it was discovered.
  The WG decided to publish a -bis document to fix the problem. The -00 version of the draft was prepared
  fairly quickly (in June 2020) and the document was adopted in August 2020 (with a good WG support for adoption).
  The draft has been widely discussed and reviewed.

Document Quality:

  This draft is a -bis document for RFC 8782, its main purpose is to fix YANG module. In addition it provides more
  comprehensive description of error handling and makes minor changes to DOTS CBOR Key Values allocation.
  This document doesn't change the DOTS Signal Channel protocol itself, in particular it doesn't change bits on the wire.
  DOTS Signal Channel protocol was thoroughly discussed and reviewed. There are at least two interoperable implementations of this protocol.
  The updated YANG module has been reviewed by YANG Doctors, who confirmed that they don't have problems with it.

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. 

  This document doesn't change the DOTS Signal Channel protocol, defined in RFC 8782, which was thoroughly reviewed
  by TSV experts. The document updates YANG module describing data structures, so that it is more in line with YANG specification.
  The updated YANG module has been reviewed by YANG Doctors twice - an Early Review and a Last Call Review.
  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 other than have been filed.

  ** Mohamed Boucadair -- https://mailarchive.ietf.org/arch/msg/dots/-lbAm-E02-OgUZSFYJn5CdU6L8M/
  ** Jon Shallow -- https://mailarchive.ietf.org/arch/msg/dots/wP5kheyWwgXbEfISsjFWWV3DBGw/
  ** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/9n4n_U1nOxyIIy6IVufK8DGDMyc/

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

  No real ID nits were found by idnits tool except for referencing old versions of some active I-Ds, that can easily be fixed during publication.
  Note, that idnits tool reports an error of the following type: the abstract contains references [RFCXXXX]. In fact the text they encounter in is a note for RFC Editor and will be removed during publication.

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

  This document contains a normative reference to Informational RFC 7918.

  The authors believe it's important to keep this reference because using RFC 7918 allows to deliver dots signal messages sooner
  and avoid extra delays that will jeopardize the mitigation. Note that RFC 8782 contained this downward normative reference too.

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

  This document obsoletes RFC8782. This is indicated in the title page header, listed in the Abstract and is discussed in the Introduction.
  The document also contains summary of changes from RFC 8782.

(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 requests IANA to update a number of records previously created by RFC 8782.
  Most update requests simply change references from "RFC8782" to "RFCXXXX".
  IANA is also requested to update prefixes for the YANG modules in the  "YANG Module Names" subregistry
  within the "YANG Parameters" registry from "signal" to "dots-signal" and from "iana-signal" to "iana-dots-signal".

  The only more substantial request to IANA is to update the "DOTS Signal Channel CBOR Key Values" from
  the "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel" IANA Registry, that was created by RFC 8782.
  The request is to reserve a range of one-octet CBOR Key Values for "comprehension-optional" keys.
  The registration policy for this range is IETF Review.

  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 or warnings.

(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 or warnings were found.