rfc9362.original   rfc9362.txt 
DOTS M. Boucadair Internet Engineering Task Force (IETF) M. Boucadair
Internet-Draft Orange Request for Comments: 9362 Orange
Intended status: Standards Track J. Shallow Category: Standards Track J. Shallow
Expires: 9 April 2023 6 October 2022 ISSN: 2070-1721 February 2023
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Configuration Attributes for Robust Block Transmission Channel Configuration Attributes for Robust Block Transmission
draft-ietf-dots-robust-blocks-06
Abstract Abstract
This document specifies new DDoS Open Threat Signaling (DOTS) signal This document specifies new DDoS Open Threat Signaling (DOTS) signal
channel configuration parameters that can be negotiated between DOTS channel configuration parameters that can be negotiated between DOTS
peers to enable the use of Q-Block1 and Q-Block2 CoAP options. These peers to enable the use of Q-Block1 and Q-Block2 Constrained
options enable robust and faster transmission rates for large amounts Application Protocol (CoAP) options. These options enable robust and
of data with less packet interchanges as well as supporting faster faster transmission rates for large amounts of data with less packet
recovery should any of the blocks get lost in transmission interchanges as well as support for faster recovery should any of the
(especially, during DDoS attacks). blocks get lost in transmission (especially during DDoS attacks).
Also, this document defines a YANG data model for representing these Also, this document defines a YANG data model for representing these
new DOTS signal channel configuration parameters. This model new DOTS signal channel configuration parameters. This model
augments the DOTS signal YANG module ("ietf-dots-signal-channel") augments the DOTS signal YANG module ("ietf-dots-signal-channel")
defined in RFC 9132. defined in RFC 9132.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 9 April 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9362.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. DOTS Attributes for Robust Block Transmission . . . . . . . . 4 3. DOTS Attributes for Robust Block Transmission
4. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 10 4. YANG/JSON Mapping Parameters to CBOR
5. DOTS Robust Block Transmission YANG Module . . . . . . . . . 11 5. DOTS Robust Block Transmission YANG Module
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations
6.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 18 6.1. Registry for DOTS Signal Channel CBOR Mappings
6.2. DOTS Robust Block Transmission YANG Module . . . . . . . 19 6.2. DOTS Robust Block Transmission YANG Module
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 21 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252], although The Constrained Application Protocol (CoAP) [RFC7252], although
inspired by HTTP, was designed to use UDP instead of TCP. The inspired by HTTP, was designed to use UDP instead of TCP. The
message layer of CoAP over UDP includes support for reliable message layer of CoAP over UDP includes support for reliable
delivery, simple congestion control, and flow control. The block- delivery, simple congestion control, and flow control. The block-
wise transfer [RFC7959] introduced the CoAP Block1 and Block2 options wise transfer [RFC7959] introduced the CoAP Block1 and Block2 options
to handle data records that cannot fit in a single IP packet, so not to handle data records that cannot fit in a single IP packet, to
having to rely on IP fragmentation. The block-wise transfer was avoid having to rely on IP fragmentation. The block-wise transfer
further updated by [RFC8323] for use over TCP, TLS, and WebSockets. was further updated by [RFC8323] for use over TCP, TLS, and
WebSockets.
The CoAP Block1 and Block2 options work well in environments where The CoAP Block1 and Block2 options work well in environments where
there are no or minimal packet losses. These options operate there are no or minimal packet losses. These options operate
synchronously where each individual block has to be requested and can synchronously where each individual block has to be requested and can
only ask for (or send) the next block when the request for the only ask for (or send) the next block when the request for the
previous block has completed. Packet, and hence block transmission previous block has completed. Packet rates, and hence block
rate, is controlled by Round-Trip Times (RTTs). transmission rates, are controlled by Round-Trip Times (RTTs).
There is a requirement for these blocks of data to be transmitted at There is a requirement for these blocks of data to be transmitted at
higher rates under network conditions where there may be asymmetrical higher rates under network conditions where there may be asymmetrical
transient packet loss (e.g., responses may get dropped). An example transient packet loss (e.g., responses may get dropped). An example
is when a network is subject to a Distributed Denial of Service is when a network is subject to a Distributed Denial of Service
(DDoS) attack and there is a need for DDoS mitigation agents relying (DDoS) attack and there is a need for DDoS mitigation agents relying
upon CoAP to communicate with each other (e.g., [RFC9244]). As a upon CoAP to communicate with each other (e.g., [RFC9244]). As a
reminder, [RFC7959] recommends the use of Confirmable (CON) responses reminder, [RFC7959] recommends the use of Confirmable (CON) responses
to handle potential packet loss. However, such a recommendation does to handle potential packet loss. However, such a recommendation does
not work with a flooded pipe DDoS situation because the returning ACK not work with a "flooded pipe" DDoS situation because the returning
packets may not get through. ACK packets may not get through.
The block-wise transfer specified in [RFC7959] covers the general The block-wise transfer specified in [RFC7959] covers the general
case, but falls short in situations where packet loss is highly case but falls short in situations where packet loss is highly
asymmetrical. The mechanism specified in [RFC9177] provides roughly asymmetrical. The mechanism specified in [RFC9177] provides features
similar features to the Block1/Block2 options, but provides roughly similar to the Block1/Block2 options but also provides
additional properties that are tailored towards the intended DDoS additional properties that are tailored towards the intended DDoS
Open Threat Signaling (DOTS) transmission. Concretely, [RFC9177] Open Threat Signaling (DOTS) transmission. Concretely, [RFC9177]
primarily targets applications such as DOTS that can't use primarily targets applications such as DOTS that can't use
Confirmable responses to handle potential packet loss and that Confirmable responses to handle potential packet loss and that
support application-specific mechanisms to assess whether the remote support application-specific mechanisms to assess whether the remote
peer is able to handle the messages sent by a CoAP endpoint (e.g., peer is able to handle the messages sent by a CoAP endpoint (e.g.,
DOTS heartbeats in Section 4.7 of [RFC9132]). DOTS heartbeats as discussed in Section 4.7 of [RFC9132]).
[RFC9177] includes guards to prevent a CoAP agent from overloading [RFC9177] includes guards to prevent a CoAP agent from overloading
the network by adopting an aggressive sending rate. These guards are the network by adopting an aggressive sending rate. These guards are
followed in addition to the existing CoAP congestion control as followed in addition to the existing CoAP congestion control as
specified in Section 4.7 of [RFC7252] (mainly, PROBING_RATE). specified in Section 4.7 of [RFC7252] (mainly PROBING_RATE). Table 1
Table 1 lists the additional CoAP parameters that are used for the lists the additional CoAP parameters that are used for the guards
guards (Section 7.2 of [RFC9177]). Note that NON in this table (Section 7.2 of [RFC9177]). Note that NON in this table refers to
refers to Non-confirmable. Non-confirmable.
+---------------------+-------------------+
| Parameter Name | Default Value |
+=====================+===================+ +=====================+===================+
| MAX_PAYLOADS | 10 | | Parameter Name | Default Value |
| NON_MAX_RETRANSMIT | 4 | +=====================+===================+
| NON_TIMEOUT | 2 s | | MAX_PAYLOADS | 10 |
| NON_TIMEOUT_RANDOM | between 2-3 s | +---------------------+-------------------+
| NON_RECEIVE_TIMEOUT | 4 s | | NON_MAX_RETRANSMIT | 4 |
+---------------------+-------------------+
| NON_TIMEOUT | 2 s |
+---------------------+-------------------+
| NON_TIMEOUT_RANDOM | between 2-3 s |
+---------------------+-------------------+
| NON_RECEIVE_TIMEOUT | 4 s |
+---------------------+-------------------+
| NON_PROBING_WAIT | between 247-248 s | | NON_PROBING_WAIT | between 247-248 s |
| NON_PARTIAL_TIMEOUT | 247 s | +---------------------+-------------------+
| NON_PARTIAL_TIMEOUT | 247 s |
+---------------------+-------------------+ +---------------------+-------------------+
Table 1: Congestion Control Parameters Table 1: Congestion Control Parameters
PROBING_RATE and other transmission parameters are negotiated between PROBING_RATE and other transmission parameters are negotiated between
DOTS peers as discussed in Section 4.5.2 of [RFC9132]. Nevertheless, DOTS peers as discussed in Section 4.5.2 of [RFC9132]. Nevertheless,
negotiating the parameters listed in Table 1 is not supported in negotiating the parameters listed in Table 1 is not supported in
[RFC9132]. This document defines new DOTS signal channel attributes, [RFC9132]. This document defines new DOTS signal channel attributes,
corresponding to the parameters in Table 1, that are used to corresponding to the parameters in Table 1, that are used to
customize the configuration of robust block transmission in a DOTS customize the configuration of robust block transmission in a DOTS
context. context.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers should be familiar with the terms and concepts defined in Readers should be familiar with the terms and concepts defined in
[RFC7252] and [RFC8612]. [RFC7252] and [RFC8612].
The terms "payload" and "body" are defined in [RFC7959]. The term The terms "payload" and "body" are defined in [RFC7959]. The term
"payload" is thus used for the content of a single CoAP message "payload" is thus used for the content of a single CoAP message
(i.e., a single block being transferred), while the term "body" is (i.e., a single block being transferred), while the term "body" is
used for the entire resource representation that is being transferred used for the entire resource representation that is being transferred
in a block-wise fashion. in a block-wise fashion.
The meaning of the symbols in YANG tree diagrams are defined in The meanings of the symbols in YANG tree diagrams are defined in
[RFC8340] and [RFC8791]. [RFC8340] and [RFC8791].
3. DOTS Attributes for Robust Block Transmission 3. DOTS Attributes for Robust Block Transmission
Section 7.2 of [RFC9177] defines the following parameters that are Section 7.2 of [RFC9177] defines the following parameters that are
used for congestion control purposes: used for congestion control purposes:
MAX_PAYLOADS: is the maximum number of payloads that can be MAX_PAYLOADS: This parameter represents the maximum number of
transmitted at any one time. payloads that can be transmitted at any one time.
NON_MAX_RETRANSMIT: is the maximum number of times a request for the NON_MAX_RETRANSMIT: This parameter represents the maximum number of
retransmission of missing payloads can occur without a response times a request for the retransmission of missing payloads can
from the remote peer. By default, NON_MAX_RETRANSMIT has the same occur without a response from the remote peer. By default,
value as MAX_RETRANSMIT (Section 4.8 of [RFC7252]). NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT
(Section 4.8 of [RFC7252]).
NON_TIMEOUT: is the maximum period of delay between sending sets of NON_TIMEOUT: This parameter represents the maximum period of delay
MAX_PAYLOADS payloads for the same body. NON_TIMEOUT has the same between sending sets of MAX_PAYLOADS payloads for the same body.
value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). NON_TIMEOUT has the same value as ACK_TIMEOUT (Section 4.8 of
[RFC7252]).
NON_TIMEOUT_RANDOM: is the initial actual delay between sending the NON_TIMEOUT_RANDOM: This parameter represents the initial actual
first two MAX_PAYLOADS_SETs of the same body. It is a random delay between sending the first two MAX_PAYLOADS_SETs of the same
duration between NON_TIMEOUT and (NON_TIMEOUT * body. It is a random duration between NON_TIMEOUT and
ACK_RANDOM_FACTOR). (NON_TIMEOUT * ACK_RANDOM_FACTOR).
NON_RECEIVE_TIMEOUT: is the maximum time to wait for a missing NON_RECEIVE_TIMEOUT: This parameter represents the maximum time to
payload before requesting retransmission. By default, wait for a missing payload before requesting retransmission. By
NON_RECEIVE_TIMEOUT has a value of twice NON_TIMEOUT. default, NON_RECEIVE_TIMEOUT has a value of twice NON_TIMEOUT.
NON_PROBING_WAIT: is used to limit the potential wait needed when NON_PROBING_WAIT: This parameter is used to limit the potential wait
using PROBING_RATE. needed when using PROBING_RATE.
NON_PARTIAL_TIMEOUT: is used for expiring partially received bodies. NON_PARTIAL_TIMEOUT: This parameter is used for expiring partially
received bodies.
These parameters are used together with PROBING_RATE parameter which These parameters are used together with the PROBING_RATE parameter,
in CoAP indicates the average data rate that must not be exceeded by which in CoAP indicates the average data rate that must not be
a CoAP endpoint in sending to a peer endpoint that does not respond. exceeded by a CoAP endpoint in sending to a peer endpoint that does
The single body of blocks will be subjected to PROBING_RATE not respond. The single body of blocks will be subjected to
(Section 4.7 of [RFC7252]), not the individual packets. If the wait PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets.
time between sending bodies that are not being responded to based on If the wait time between sending bodies that are not being responded
PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time is limited to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time
to NON_PROBING_WAIT. is limited to NON_PROBING_WAIT.
This document augments the "ietf-dots-signal-channel" DOTS signal This document augments the "ietf-dots-signal-channel" DOTS signal
YANG module defined in Section 5.3 of [RFC9132] with the following YANG module defined in Section 5.3 of [RFC9132] with the following
additional attributes that can be negotiated between DOTS peers to additional attributes that can be negotiated between DOTS peers to
enable robust and faster transmission: enable robust and faster transmission:
max-payloads: This attribute echoes the MAX_PAYLOADS parameter in max-payloads: This attribute echoes the MAX_PAYLOADS parameter
[RFC9177]. defined in [RFC9177].
This is an optional attribute. If the attribute is supplied in This is an optional attribute. If the attribute is supplied in
both 'idle-config' and 'mitigating-config', then it MUST convey both 'idle-config' and 'mitigating-config', then it MUST convey
the same value. If the attribute is only provided as part of the same value. If the attribute is only provided as part of
'idle-config' (or 'mitigating-config'), then the other definition 'idle-config' (or 'mitigating-config'), then the other definition
(i.e., 'mitigating-config' (or 'idle-config')) MUST be updated to (i.e., 'mitigating-config' (or 'idle-config')) MUST be updated to
the same value. the same value.
non-max-retransmit: This attribute echoes the NON_MAX_RETRANSMIT non-max-retransmit: This attribute echoes the NON_MAX_RETRANSMIT
parameter in [RFC9177]. The default value of this attribute is parameter defined in [RFC9177]. The default value of this
'max-retransmit'. Note that DOTS uses a default value of '3' attribute is 'max-retransmit'. Note that DOTS uses a default
instead of '4' used for the generic CoAP use (Section 4.5.2 of value of '3' instead of '4' (which is used generically by CoAP for
[RFC9132]) for max-transmit. 'max-transmit'; see Section 4.5.2 of [RFC9132] and Section 4.8 of
[RFC7252]).
This is an optional attribute. This is an optional attribute.
non-timeout: This attribute, expressed in seconds, echoes the non-timeout: This attribute, expressed in seconds, echoes the
NON_TIMEOUT parameter in [RFC9177]. The default value of this NON_TIMEOUT parameter defined in [RFC9177]. The default value of
attribute is 'ack-timeout'. this attribute is 'ack-timeout'.
This attribute is also used to compute the NON_TIMEOUT_RANDOM This attribute is also used to compute the NON_TIMEOUT_RANDOM
parameter. parameter.
This is an optional attribute. This is an optional attribute.
non-receive-timeout: This attribute, expressed in seconds, echoes non-receive-timeout: This attribute, expressed in seconds, echoes
the NON_RECEIVE_TIMEOUT parameter in [RFC9177]. The default value the NON_RECEIVE_TIMEOUT parameter defined in [RFC9177]. The
of this attribute is twice 'non-timeout'. default value of this attribute is twice 'non-timeout'.
This is an optional attribute. This is an optional attribute.
non-probing-wait: This attribute, expressed in seconds, echoes the non-probing-wait: This attribute, expressed in seconds, echoes the
NON_PROBING_WAIT parameter in [RFC9177]. NON_PROBING_WAIT parameter defined in [RFC9177].
This is an optional attribute. This is an optional attribute.
non-partial-timeout: This attribute, expressed in seconds, echoes non-partial-timeout: This attribute, expressed in seconds, echoes
the NON_PARTIAL_TIMEOUT parameter in [RFC9177]. The default value the NON_PARTIAL_TIMEOUT parameter defined in [RFC9177]. The
of this attribute is 247 seconds. default value of this attribute is 247 seconds.
This is an optional attribute. This is an optional attribute.
The tree structure of the "ietf-dots-robust-trans" module (Section 5) The tree structure of the "ietf-dots-robust-trans" module (Section 5)
is shown in Figure 1. is shown in Figure 1.
module: ietf-dots-robust-trans module: ietf-dots-robust-trans
augment-structure /dots-signal:dots-signal/dots-signal:message-type augment-structure /dots-signal:dots-signal/dots-signal:message-type
/dots-signal:signal-config /dots-signal:signal-config
/dots-signal:mitigating-config: /dots-signal:mitigating-config:
+-- max-payloads +-- max-payloads
| +-- (direction)? | +-- (direction)?
| | +--:(server-to-client-only) | | +--:(server-to-client-only)
| | +-- max-value? uint16 | | +-- max-value? uint16
| | +-- min-value? uint16 | | +-- min-value? uint16
| +-- current-value? uint16 | +-- current-value? uint16
+-- non-max-retransmit +-- non-max-retransmit
| +-- (direction)? | +-- (direction)?
| | +--:(server-to-client-only) | | +--:(server-to-client-only)
| | +-- max-value? uint16 | | +-- max-value? uint16
| | +-- min-value? uint16 | | +-- min-value? uint16
| +-- current-value? uint16 | +-- current-value? uint16
+-- non-timeout +-- non-timeout
| +-- (direction)? | +-- (direction)?
| | +--:(server-to-client-only) | | +--:(server-to-client-only)
| | +-- max-value-decimal? decimal64 | | +-- max-value-decimal? decimal64
| | +-- min-value-decimal? decimal64 | | +-- min-value-decimal? decimal64
| +-- current-value-decimal? decimal64 | +-- current-value-decimal? decimal64
+-- non-receive-timeout +-- non-receive-timeout
| +-- (direction)? | +-- (direction)?
| | +--:(server-to-client-only) | | +--:(server-to-client-only)
| | +-- max-value-decimal? decimal64 | | +-- max-value-decimal? decimal64
| | +-- min-value-decimal? decimal64 | | +-- min-value-decimal? decimal64
| +-- current-value-decimal? decimal64 | +-- current-value-decimal? decimal64
+-- non-probing-wait +-- non-probing-wait
| +-- (direction)? | +-- (direction)?
| | +--:(server-to-client-only) | | +--:(server-to-client-only)
| | +-- max-value-decimal? decimal64 | | +-- max-value-decimal? decimal64
| | +-- min-value-decimal? decimal64 | | +-- min-value-decimal? decimal64
| +-- current-value-decimal? decimal64 | +-- current-value-decimal? decimal64
+-- non-partial-wait: +-- non-partial-timeout:
+-- (direction)? +-- (direction)?
| +--:(server-to-client-only) | +--:(server-to-client-only)
| +-- max-value-decimal? decimal64 | +-- max-value-decimal? decimal64
| +-- min-value-decimal? decimal64 | +-- min-value-decimal? decimal64
+-- current-value-decimal? decimal64 +-- current-value-decimal? decimal64
augment-structure /dots-signal:dots-signal/dots-signal:message-type augment-structure /dots-signal:dots-signal/dots-signal:message-type
/dots-signal:signal-config/dots-signal:idle-config: /dots-signal:signal-config
+-- max-payloads /dots-signal:idle-config:
| +-- (direction)? +-- max-payloads
| | +--:(server-to-client-only) | +-- (direction)?
| | +-- max-value? uint16 | | +--:(server-to-client-only)
| | +-- min-value? uint16 | | +-- max-value? uint16
| +-- current-value? uint16 | | +-- min-value? uint16
+-- non-max-retransmit | +-- current-value? uint16
| +-- (direction)? +-- non-max-retransmit
| | +--:(server-to-client-only) | +-- (direction)?
| | +-- max-value? uint16 | | +--:(server-to-client-only)
| | +-- min-value? uint16 | | +-- max-value? uint16
| +-- current-value? uint16 | | +-- min-value? uint16
+-- non-timeout | +-- current-value? uint16
| +-- (direction)? +-- non-timeout
| | +--:(server-to-client-only) | +-- (direction)?
| | +-- max-value-decimal? decimal64 | | +--:(server-to-client-only)
| | +-- min-value-decimal? decimal64 | | +-- max-value-decimal? decimal64
| +-- current-value-decimal? decimal64 | | +-- min-value-decimal? decimal64
+-- non-receive-timeout | +-- current-value-decimal? decimal64
| +-- (direction)? +-- non-receive-timeout
| | +--:(server-to-client-only) | +-- (direction)?
| | +-- max-value-decimal? decimal64 | | +--:(server-to-client-only)
| | +-- min-value-decimal? decimal64 | | +-- max-value-decimal? decimal64
| +-- current-value-decimal? decimal64 | | +-- min-value-decimal? decimal64
+-- non-probing-wait | +-- current-value-decimal? decimal64
| +-- (direction)? +-- non-probing-wait
| | +--:(server-to-client-only) | +-- (direction)?
| | +-- max-value-decimal? decimal64 | | +--:(server-to-client-only)
| | +-- min-value-decimal? decimal64 | | +-- max-value-decimal? decimal64
| +-- current-value-decimal? decimal64 | | +-- min-value-decimal? decimal64
+-- non-partial-wait: | +-- current-value-decimal? decimal64
+-- (direction)? +-- non-partial-timeout:
| +--:(server-to-client-only) +-- (direction)?
| +-- max-value-decimal? decimal64 | +--:(server-to-client-only)
| +-- min-value-decimal? decimal64 | +-- max-value-decimal? decimal64
+-- current-value-decimal? decimal64 | +-- min-value-decimal? decimal64
+-- current-value-decimal? decimal64
Figure 1: DOTS Fast Block Transmission Tree Structure Figure 1: DOTS Fast Block Transmission Tree Structure
These attributes are mapped to CBOR types as specified in Section 4 These attributes are mapped to Concise Binary Object Representation
and Section 6 of [RFC9132]. (CBOR) types as specified in Section 4 and in Section 6 of [RFC9132].
DOTS clients follow the procedure specified in Section 4.5 of DOTS clients follow the procedure specified in Section 4.5 of
[RFC9132] to negotiate, configure, and retrieve the DOTS signal [RFC9132] to negotiate, configure, and retrieve the DOTS signal
channel session behavior (including Q-Block parameters) with DOTS channel session behavior (including Q-Block parameters) with DOTS
peers. peers.
Implementation Note 1: 'non-probing-wait' ideally should be left Implementation Note 1: 'non-probing-wait' ideally should be left
having some jitter and so should not be hard-coded with an having some jitter and so should not be hard-coded with an
explicit value. It is suggested to use a base value (using explicit value. It is suggested to use a base value (using
NON_TIMEOUT instead of NON_TIMEOUT_RANDOM) and, then, the jitter NON_TIMEOUT instead of NON_TIMEOUT_RANDOM); the jitter
(ACK_RANDOM_FACTOR - 1) is added to each time the value is (ACK_RANDOM_FACTOR - 1) is then added to each time the value is
checked. checked.
Implementation Note 2: If any of the signal channel session Implementation Note 2: If any of the signal channel session
configuration parameters is updated, the 'non-probing-wait' and configuration parameters is updated, the 'non-probing-wait' and
'non-partial-timeout' values should be recalculated according to 'non-partial-timeout' values should be recalculated according to
the definition algorithms in Section 7.2 of [RFC9177] unless the definition algorithms provided in Section 7.2 of [RFC9177]
explicit values are provided as part of the negotiated unless explicit values are provided as part of the negotiated
configuration. configuration.
An example of a PUT message to configure Q-Block parameters is An example of a PUT message to configure Q-Block parameters is
depicted in Figure 2. In this example, a non-default value is depicted in Figure 2. In this example, a non-default value is
configured for the 'max-payloads' attribute, while default values are configured for the 'max-payloads' attribute, while default values are
used for 'non-max-retransmit', 'non-timeout', and 'non-receive- used for 'non-max-retransmit', 'non-timeout', and 'non-receive-
timeout' in both idle and mitigation times. Given that 'non-probing- timeout' in both idle and mitigation times. Given that 'non-probing-
wait' and 'non-partial-wait' are not explicitly configured in this wait' and 'non-partial-timeout' are not explicitly configured in this
example, these attributes will be computed following the algorithms example, these attributes will be computed following the algorithms
in Section 7.2 of [RFC9177]. The meaning of the other attributes is provided in Section 7.2 of [RFC9177]. The meanings of the other
detailed in Section 4.5 of [RFC9132]. attributes are detailed in Section 4.5 of [RFC9132].
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "config" Uri-Path: "config"
Uri-Path: "sid=123" Uri-Path: "sid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
skipping to change at page 10, line 14 skipping to change at line 455
"current-value-decimal": "4.00" "current-value-decimal": "4.00"
} }
} }
} }
} }
Figure 2: Example of PUT to Convey the Configuration Parameters Figure 2: Example of PUT to Convey the Configuration Parameters
The payload of the message depicted in Figure 2 is CBOR-encoded as The payload of the message depicted in Figure 2 is CBOR-encoded as
indicated by the Content-Format set to "application/dots+cbor" indicated by the Content-Format set to "application/dots+cbor"
(Section 10.3 of [RFC9132]). However, and for the sake of better (Section 10.4 of [RFC9132]). However, and for the sake of better
readability, the example uses JSON encoding of YANG-modeled data readability, the example uses JSON encoding of YANG-modeled data
following the mapping table in Section 4 and Section 6 of [RFC9132]: following the mapping tables in Section 4 and in Section 6 of
use the JSON names and types defined in Section 4. These conventions [RFC9132]: use the JSON names and types defined in Section 4. These
are inherited from [RFC9132]. conventions are inherited from [RFC9132].
4. YANG/JSON Mapping Parameters to CBOR 4. YANG/JSON Mapping Parameters to CBOR
The YANG/JSON mapping parameters to CBOR are listed in Table 2. The YANG/JSON mapping parameters to CBOR are listed in Table 2.
* Note: Implementers must check that the mapping output provided by Note: Implementers must check that the mapping output provided by
their YANG-to-CBOR encoding schemes is aligned with the content of their YANG-to-CBOR encoding schemes is aligned with the content of
Table 2. Table 2.
+----------------------+------------+------+---------------+--------+ +====================+===========+=======+=================+========+
| Parameter Name | YANG | CBOR | CBOR Major | JSON | | Parameter Name | YANG Type | CBOR | CBOR Major Type | JSON |
| | Type | Key | Type & | Type | | | | Key | & Information | Type |
| | | | Information | | +====================+===========+=======+=================+========+
+======================+============+======+===============+========+ | ietf-dots-robust- | container | 32776 | 5 map | Object |
| ietf-dots-robust- | container | TBA1 | 5 map | Object | | trans:max- | | | | |
| trans:max-payloads | | | | | | payloads | | | | |
+----------------------+------------+------+---------------+--------+ +--------------------+-----------+-------+-----------------+--------+
| ietf-dots-robust- | container | TBA2 | 5 map | Object | | ietf-dots-robust- | container | 32777 | 5 map | Object |
| trans:non-max- | | | | | | trans:non-max- | | | | |
| retransmit | | | | | | retransmit | | | | |
+----------------------+------------+------+---------------+--------+ +--------------------+-----------+-------+-----------------+--------+
| ietf-dots-robust- | container | TBA3 | 5 map | Object | | ietf-dots-robust- | container | 32778 | 5 map | Object |
| trans:non-timeout | | | | | | trans:non-timeout | | | | |
+----------------------+------------+------+---------------+--------+ +--------------------+-----------+-------+-----------------+--------+
| ietf-dots-robust- | container | TBA4 | 5 map | Object | | ietf-dots-robust- | container | 32779 | 5 map | Object |
| trans:non-receive- | | | | | | trans:non- | | | | |
| timeout | | | | | | receive-timeout | | | | |
+----------------------+------------+------+---------------+--------+ +--------------------+-----------+-------+-----------------+--------+
| ietf-dots-robust- | container | TBA5 | 5 map | Object | | ietf-dots-robust- | container | 32780 | 5 map | Object |
| trans:non-probing- | | | | | | trans:non- | | | | |
| wait | | | | | | probing-wait | | | | |
+----------------------+------------+------+---------------+--------+ +--------------------+-----------+-------+-----------------+--------+
| ietf-dots-robust- | container | TBA6 | 5 map | Object | | ietf-dots-robust- | container | 32781 | 5 map | Object |
| trans:non-partial- | | | | | | trans:non- | | | | |
| wait | | | | | | partial-timeout | | | | |
+----------------------+------------+------+---------------+--------+ +--------------------+-----------+-------+-----------------+--------+
Table 2: YANG/JSON Mapping Parameters to CBOR Table 2: YANG/JSON Mapping Parameters to CBOR
5. DOTS Robust Block Transmission YANG Module 5. DOTS Robust Block Transmission YANG Module
This module uses the data structure extension defined in [RFC8791]. This module uses the data structure extension defined in [RFC8791].
<CODE BEGINS> file "ietf-dots-robust-trans@2022-01-04.yang" <CODE BEGINS> file "ietf-dots-robust-trans@2023-01-26.yang"
module ietf-dots-robust-trans { module ietf-dots-robust-trans {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans";
prefix dots-robust; prefix dots-robust;
import ietf-dots-signal-channel { import ietf-dots-signal-channel {
prefix dots-signal; prefix dots-signal;
reference reference
"RFC 9132: Distributed Denial-of-Service Open Threat "RFC 9132: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
skipping to change at page 12, line 15 skipping to change at line 527
reference reference
"RFC 8791: YANG Data Structure Extensions"; "RFC 8791: YANG Data Structure Extensions";
} }
organization organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group"; "IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/dots/> "WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org> WG List: <mailto:dots@ietf.org>
Author: Mohamed Boucadair Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>; <mailto:mohamed.boucadair@orange.com>;
Author: Jon Shallow Author: Jon Shallow
<mailto:ietf-supjps@jpshallow.com>"; <mailto:ietf-supjps@jpshallow.com>";
description description
"This module contains YANG definitions for the configuration "This module contains YANG definitions for the configuration
of parameters that can be negotiated between a DOTS client of parameters that can be negotiated between a DOTS client
and a DOTS server for robust block transmission. and a DOTS server for robust block transmission.
Copyright (c) 2022 IETF Trust and the persons identified as Copyright (c) 2023 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9362; see the
the RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2022-01-04 { revision 2023-01-26 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC 9362: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Configuration Attributes Signaling (DOTS) Configuration Attributes
for Robust Block Transmission"; for Robust Block Transmission";
} }
grouping robust-transmission-attributes { grouping robust-transmission-attributes {
description description
"A set of DOTS signal channel session configuration "A set of DOTS signal channel session configuration
that are negotiated between DOTS agents when parameters that are negotiated between DOTS agents when
making use of Q-Block1 and Q-Block2 options."; making use of Q-Block1 and Q-Block2 options.";
container max-payloads { container max-payloads {
description description
"Indicates the maximum number of payloads that "Indicates the maximum number of payloads that
can be transmitted at any one time."; can be transmitted at any one time.";
choice direction { choice direction {
description description
"Indicates the communication direction in which the "Indicates the communication direction in which the
data nodes can be included."; data nodes can be included.";
case server-to-client-only { case server-to-client-only {
description description
"These data nodes appear only in a message sent "These data nodes appear only in a message sent
from the server to the client."; from the server to the client.";
leaf max-value { leaf max-value {
type uint16; type uint16;
description description
"Maximum acceptable max-payloads value."; "Maximum acceptable 'max-payloads' value.";
} }
leaf min-value { leaf min-value {
type uint16; type uint16;
description description
"Minimum acceptable max-payloads value."; "Minimum acceptable 'max-payloads' value.";
} }
} }
} }
leaf current-value { leaf current-value {
type uint16; type uint16;
default "10"; default "10";
description description
"Current max-payloads value."; "Current 'max-payloads' value.";
reference reference
"RFC 9177: Constrained Application Protocol (CoAP) "RFC 9177: Constrained Application Protocol (CoAP)
Block-Wise Transfer Options Supporting Block-Wise Transfer Options Supporting
Robust Transmission, Section 7.2"; Robust Transmission, Section 7.2";
} }
} }
container non-max-retransmit { container non-max-retransmit {
description description
"Indicates the maximum number of times a request "Indicates the maximum number of times a request
for the retransmission of missing payloads can for the retransmission of missing payloads can
skipping to change at page 14, line 4 skipping to change at line 612
for the retransmission of missing payloads can for the retransmission of missing payloads can
occur without a response from the remote peer."; occur without a response from the remote peer.";
choice direction { choice direction {
description description
"Indicates the communication direction in which the "Indicates the communication direction in which the
data nodes can be included."; data nodes can be included.";
case server-to-client-only { case server-to-client-only {
description description
"These data nodes appear only in a message sent "These data nodes appear only in a message sent
from the server to the client."; from the server to the client.";
leaf max-value { leaf max-value {
type uint16; type uint16;
description description
"Maximum acceptable non-max-retransmit value."; "Maximum acceptable 'non-max-retransmit' value.";
} }
leaf min-value { leaf min-value {
type uint16; type uint16;
description description
"Minimum acceptable non-max-retransmit value."; "Minimum acceptable 'non-max-retransmit' value.";
} }
} }
} }
leaf current-value { leaf current-value {
type uint16; type uint16;
default "3"; default "3";
description description
"Current non-max-retransmit value."; "Current 'non-max-retransmit' value.";
reference reference
"RFC 9177: Constrained Application Protocol (CoAP) "RFC 9177: Constrained Application Protocol (CoAP)
Block-Wise Transfer Options Supporting Block-Wise Transfer Options Supporting
Robust Transmission, Section 7.2"; Robust Transmission, Section 7.2";
} }
} }
container non-timeout { container non-timeout {
description description
"Indicates the maximum period of delay between "Indicates the maximum period of delay between
sending sets of MAX_PAYLOADS payloads for the same sending sets of MAX_PAYLOADS payloads for the same
skipping to change at page 14, line 47 skipping to change at line 654
case server-to-client-only { case server-to-client-only {
description description
"These data nodes appear only in a message sent "These data nodes appear only in a message sent
from the server to the client."; from the server to the client.";
leaf max-value-decimal { leaf max-value-decimal {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
units "seconds"; units "seconds";
description description
"Maximum ack-timeout value."; "Maximum 'ack-timeout' value.";
} }
leaf min-value-decimal { leaf min-value-decimal {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
units "seconds"; units "seconds";
description description
"Minimum ack-timeout value."; "Minimum 'ack-timeout' value.";
} }
} }
} }
leaf current-value-decimal { leaf current-value-decimal {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
units "seconds"; units "seconds";
default "2.00"; default "2.00";
description description
"Current ack-timeout value."; "Current 'ack-timeout' value.";
reference reference
"RFC 9177: Constrained Application Protocol (CoAP) "RFC 9177: Constrained Application Protocol (CoAP)
Block-Wise Transfer Options Supporting Block-Wise Transfer Options Supporting
Robust Transmission, Section 7.2"; Robust Transmission, Section 7.2";
} }
} }
container non-receive-timeout { container non-receive-timeout {
description description
"Indicates the time to wait for a missing payload "Indicates the time to wait for a missing payload
before requesting retransmission."; before requesting retransmission.";
skipping to change at page 15, line 42 skipping to change at line 698
case server-to-client-only { case server-to-client-only {
description description
"These data nodes appear only in a message sent "These data nodes appear only in a message sent
from the server to the client."; from the server to the client.";
leaf max-value-decimal { leaf max-value-decimal {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
units "seconds"; units "seconds";
description description
"Maximum non-receive-timeout value."; "Maximum 'non-receive-timeout' value.";
} }
leaf min-value-decimal { leaf min-value-decimal {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
units "seconds"; units "seconds";
description description
"Minimum non-receive-timeout value."; "Minimum 'non-receive-timeout' value.";
} }
} }
} }
leaf current-value-decimal { leaf current-value-decimal {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
units "seconds"; units "seconds";
default "4.00"; default "4.00";
description description
"Current non-receive-timeout value."; "Current 'non-receive-timeout' value.";
reference reference
"RFC 9177: Constrained Application Protocol (CoAP) "RFC 9177: Constrained Application Protocol (CoAP)
Block-Wise Transfer Options Supporting Block-Wise Transfer Options Supporting
Robust Transmission, Section 7.2"; Robust Transmission, Section 7.2";
} }
} }
container non-probing-wait { container non-probing-wait {
description description
"Is used to limit the potential wait needed when "Used to limit the potential wait needed when
using probing-rate."; using 'probing-rate'.";
choice direction { choice direction {
description description
"Indicates the communication direction in which the "Indicates the communication direction in which the
data nodes can be included."; data nodes can be included.";
case server-to-client-only { case server-to-client-only {
description description
"These data nodes appear only in a message sent "These data nodes appear only in a message sent
from the server to the client."; from the server to the client.";
leaf max-value-decimal { leaf max-value-decimal {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
units "seconds"; units "seconds";
description description
"Maximum non-probing-wait value."; "Maximum 'non-probing-wait' value.";
} }
leaf min-value-decimal { leaf min-value-decimal {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
units "seconds"; units "seconds";
description description
"Minimum non-probing-wait value."; "Minimum 'non-probing-wait' value.";
} }
} }
} }
leaf current-value-decimal { leaf current-value-decimal {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
units "seconds"; units "seconds";
description description
"Current non-probing-wait value."; "Current 'non-probing-wait' value.";
reference reference
"RFC 9177: Constrained Application Protocol (CoAP) "RFC 9177: Constrained Application Protocol (CoAP)
Block-Wise Transfer Options Supporting Block-Wise Transfer Options Supporting
Robust Transmission, Section 7.2"; Robust Transmission, Section 7.2";
} }
} }
container non-partial-wait { container non-partial-timeout {
description description
"Is used for expiring partially received bodies."; "Used for expiring partially received bodies.";
choice direction { choice direction {
description description
"Indicates the communication direction in which the "Indicates the communication direction in which the
data nodes can be included."; data nodes can be included.";
case server-to-client-only { case server-to-client-only {
description description
"These data nodes appear only in a message sent "These data nodes appear only in a message sent
from the server to the client."; from the server to the client.";
leaf max-value-decimal { leaf max-value-decimal {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
units "seconds"; units "seconds";
description description
"Maximum non-partial-wait value."; "Maximum 'non-partial-timeout' value.";
} }
leaf min-value-decimal { leaf min-value-decimal {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
units "seconds"; units "seconds";
description description
"Minimum non-partial-wait value."; "Minimum 'non-partial-timeout' value.";
} }
} }
} }
leaf current-value-decimal { leaf current-value-decimal {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
units "seconds"; units "seconds";
default "247.00"; default "247.00";
description description
"Current non-partial-wait value."; "Current 'non-partial-timeout' value.";
reference reference
"RFC 9177: Constrained Application Protocol (CoAP) "RFC 9177: Constrained Application Protocol (CoAP)
Block-Wise Transfer Options Supporting Block-Wise Transfer Options Supporting
Robust Transmission, Section 7.2"; Robust Transmission, Section 7.2";
} }
} }
} }
sx:augment-structure "/dots-signal:dots-signal" sx:augment-structure "/dots-signal:dots-signal"
+ "/dots-signal:message-type" + "/dots-signal:message-type"
skipping to change at page 18, line 36 skipping to change at line 835
description description
"Indicates DOTS configuration parameters to use for "Indicates DOTS configuration parameters to use for
robust transmission when no mitigation is active."; robust transmission when no mitigation is active.";
uses robust-transmission-attributes; uses robust-transmission-attributes;
} }
} }
<CODE ENDS> <CODE ENDS>
6. IANA Considerations 6. IANA Considerations
6.1. DOTS Signal Channel CBOR Mappings Registry 6.1. Registry for DOTS Signal Channel CBOR Mappings
This specification registers the following parameters in the IANA This specification registers the following parameters in the IANA
"DOTS Signal Channel CBOR Key Values" registry [Key-Map]. "DOTS Signal Channel CBOR Key Values" registry [Key-Map].
* Note to the RFC Editor: Please replace TBA1-TBA6 with the CBOR +===================+==========+=======+============+===============+
keys that are assigned from the 32768-49151 range. Please update | Parameter Name | CBOR | CBOR | Change | Specification |
Table 2 accordingly. | | Key | Major | Controller | Document(s) |
| | Value | Type | | |
+===================+==========+=======+============+===============+
| ietf-dots-robust- | 32776 | 5 | IESG | RFC 9362 |
| trans:max- | | | | |
| payloads | | | | |
+-------------------+----------+-------+------------+---------------+
| ietf-dots-robust- | 32777 | 5 | IESG | RFC 9362 |
| trans:non-max- | | | | |
| retransmit | | | | |
+-------------------+----------+-------+------------+---------------+
| ietf-dots-robust- | 32778 | 5 | IESG | RFC 9362 |
| trans:non-timeout | | | | |
+-------------------+----------+-------+------------+---------------+
| ietf-dots-robust- | 32779 | 5 | IESG | RFC 9362 |
| trans:non- | | | | |
| receive-timeout | | | | |
+-------------------+----------+-------+------------+---------------+
| ietf-dots-robust- | 32780 | 5 | IESG | RFC 9362 |
| trans:non- | | | | |
| probing-wait | | | | |
+-------------------+----------+-------+------------+---------------+
| ietf-dots-robust- | 32781 | 5 | IESG | RFC 9362 |
| trans:non- | | | | |
| partial-timeout | | | | |
+-------------------+----------+-------+------------+---------------+
+------------------------+-------+-------+------------+---------------+ Table 3: DOTS Robust Block Transmission CBOR Mappings
| Parameter Name | CBOR | CBOR | Change | Specification |
| | Key | Major | Controller | Document(s) |
| | Value | Type | | |
+========================+=======+=======+============+===============+
| ietf-dots-robust-trans:| TBA1 | 5 | IESG | [RFCXXXX] |
| max-payloads | | | | |
+------------------------+-------+-------+------------+---------------+
| ietf-dots-robust-trans:| TBA2 | 5 | IESG | [RFCXXXX] |
| non-max-retransmit | | | | |
+------------------------+-------+-------+------------+---------------+
| ietf-dots-robust-trans:| TBA3 | 5 | IESG | [RFCXXXX] |
| non-timeout | | | | |
+------------------------+-------+-------+------------+---------------+
| ietf-dots-robust-trans:| TBA4 | 5 | IESG | [RFCXXXX] |
| non-receive-timeout | | | | |
+------------------------+-------+-------+------------+---------------+
| ietf-dots-robust-trans:| TBA5 | 5 | IESG | [RFCXXXX] |
| non-probing-wait | | | | |
+------------------------+-------+-------+------------+---------------+
| ietf-dots-robust-trans:| TBA6 | 5 | IESG | [RFCXXXX] |
| non-partial-wait | | | | |
+------------------------+-------+-------+------------+---------------+
6.2. DOTS Robust Block Transmission YANG Module 6.2. DOTS Robust Block Transmission YANG Module
This document requests IANA to register the following URI in the "ns" IANA has registered the following URI in the "ns" subregistry within
subregistry within the "IETF XML Registry" [RFC3688]: the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans URI: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in IANA has registered the following YANG module in the "YANG Module
the "YANG Module Names" subregistry [RFC6020] within the "YANG Names" subregistry [RFC6020] within the "YANG Parameters" registry.
Parameters" registry.
Name: ietf-dots-robust-trans Name: ietf-dots-robust-trans
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans
Maintained by IANA? N Maintained by IANA? N
Prefix: dots-robust Prefix: dots-robust
Reference: RFC XXXX Reference: RFC 9362
7. Security Considerations 7. Security Considerations
The security considerations for the DOTS signal channel protocol are The security considerations for the DOTS signal channel protocol are
discussed in Section 11 of [RFC9132]. discussed in Section 11 of [RFC9132].
CoAP-specific security considerations are discussed in Section 11 of CoAP-specific security considerations are discussed in Section 11 of
[RFC9177]. [RFC9177].
Consistent with Section 5 of [RFC9132], the "ietf-dots-robust-trans" Consistent with Section 5 of [RFC9132], the "ietf-dots-robust-trans"
module is not intended to be used via NETCONF/RESTCONF. It serves as module is not intended to be used via NETCONF/RESTCONF. It serves as
an abstract representation in DOTS signal channel messages. The an abstract representation in DOTS signal channel messages. The
"ietf-dots-robust-trans" module does not introduce any new "ietf-dots-robust-trans" module does not introduce any new
vulnerabilities beyond those specified above. vulnerabilities beyond those specified above.
8. Acknowledgements 8. References
Thanks to Tiru Reddy, Meiling Chen, and Kaname Nishizuka for the
review.
Thanks to Michal Vasko for the yangdoctors review.
Thanks to Valery Smyslov for shepherding the document, Paul Wouters
for the AD review, Paul Kyzivat for the artart directorate review,
Tim Evens for the Gen-ART review, and Jean-Michel Combes for the int-
dir review.
Thanks to John Scudder, Lars Eggert, Eric Vyncke, Roman Danyliw, Rob
Wilton, and Martin Duke for the comments during the IESG review.
9. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 21, line 35 skipping to change at line 956
"Distributed Denial-of-Service Open Threat Signaling "Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification", RFC 9132, (DOTS) Signal Channel Specification", RFC 9132,
DOI 10.17487/RFC9132, September 2021, DOI 10.17487/RFC9132, September 2021,
<https://www.rfc-editor.org/info/rfc9132>. <https://www.rfc-editor.org/info/rfc9132>.
[RFC9177] Boucadair, M. and J. Shallow, "Constrained Application [RFC9177] Boucadair, M. and J. Shallow, "Constrained Application
Protocol (CoAP) Block-Wise Transfer Options Supporting Protocol (CoAP) Block-Wise Transfer Options Supporting
Robust Transmission", RFC 9177, DOI 10.17487/RFC9177, Robust Transmission", RFC 9177, DOI 10.17487/RFC9177,
March 2022, <https://www.rfc-editor.org/info/rfc9177>. March 2022, <https://www.rfc-editor.org/info/rfc9177>.
9.2. Informative References 8.2. Informative References
[Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values",
<https://www.iana.org/assignments/dots/dots.xhtml#dots- <https://www.iana.org/assignments/dots/>.
signal-channel-cbor-key-values>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
Threat Signaling (DOTS) Requirements", RFC 8612, Threat Signaling (DOTS) Requirements", RFC 8612,
DOI 10.17487/RFC8612, May 2019, DOI 10.17487/RFC8612, May 2019,
<https://www.rfc-editor.org/info/rfc8612>. <https://www.rfc-editor.org/info/rfc8612>.
[RFC9244] Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M., [RFC9244] Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M.,
and J. Shallow, "Distributed Denial-of-Service Open Threat and J. Shallow, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry", RFC 9244, Signaling (DOTS) Telemetry", RFC 9244,
DOI 10.17487/RFC9244, June 2022, DOI 10.17487/RFC9244, June 2022,
<https://www.rfc-editor.org/info/rfc9244>. <https://www.rfc-editor.org/info/rfc9244>.
Acknowledgements
Thanks to Tiru Reddy, Meiling Chen, and Kaname Nishizuka for the
review.
Thanks to Michal Vaško for the yangdoctors review.
Thanks to Valery Smyslov for shepherding the document, Paul Wouters
for the AD review, Paul Kyzivat for the artart directorate review,
Tim Evens for the Gen-ART review, and Jean-Michel Combes for the int-
dir review.
Thanks to John Scudder, Lars Eggert, Éric Vyncke, Roman Danyliw, Rob
Wilton, and Martin Duke for their comments during the IESG review.
Authors' Addresses Authors' Addresses
Mohamed Boucadair Mohamed Boucadair
Orange Orange
35000 Rennes 35000 Rennes
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Jon Shallow Jon Shallow
United Kingdom United Kingdom
 End of changes. 94 change blocks. 
330 lines changed or deleted 336 lines changed or added

This html diff was produced by rfcdiff 1.48.