rfc9362xml2.original.xml		rfc9362.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">		<!DOCTYPE rfc [
	<?rfc toc="yes"?>		<!ENTITY nbsp "&#160;">
	<?rfc tocompact="yes"?>		<!ENTITY zwsp "&#8203;">
	<?rfc tocdepth="4"?>		<!ENTITY nbhy "&#8209;">
	<?rfc tocindent="yes"?>		<!ENTITY wj "&#8288;">
	<?rfc symrefs="yes"?>		]>
	<?rfc sortrefs="yes"?>
	<?rfc comments="yes"?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
	<?rfc inline="yes"?>		std" consensus="true" docName="draft-ietf-dots-robust-blocks-06" number="9362" i
	<?rfc compact="yes"?>		pr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDept
	<?rfc subcompact="no"?>		h="4" symRefs="true" sortRefs="true" version="3">
	<rfc category="std" docName="draft-ietf-dots-robust-blocks-06"
	ipr="trust200902">		<!-- xml2rfc v2v3 conversion 3.15.0 -->
	<front>		<front>
	<title abbrev="DOTS Robust Block Transmission">Distributed		<title abbrev="DOTS Robust Block Transmission">Distributed
	Denial-of-Service Open Threat Signaling (DOTS) Signal Channel		Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
	Configuration Attributes for Robust Block Transmission</title>		Configuration Attributes for Robust Block Transmission</title>
			<seriesInfo name="RFC" value="9362"/>
	<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">		<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
	<organization>Orange</organization>		<organization>Orange</organization>
	<address>		<address>
	<postal>		<postal>
	<street></street>		<street/>
	<city>Rennes</city>		<city>Rennes</city>
			<region/>
	<region></region>
	<code>35000</code>		<code>35000</code>
	<country>France</country>		<country>France</country>
	</postal>		</postal>
	<email>mohamed.boucadair@orange.com</email>		<email>mohamed.boucadair@orange.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Jon Shallow" initials="J." surname="Shallow">		<author fullname="Jon Shallow" initials="J." surname="Shallow">
	<organization></organization>		<organization/>
	<address>		<address>
	<postal>		<postal>
	<street></street>		<street/>
			<city/>
	<city></city>		<region/>
			<code/>
	<region></region>
	<code></code>
	<country>United Kingdom</country>		<country>United Kingdom</country>
	</postal>		</postal>
	<email>supjps-ietf@jpshallow.com</email>		<email>supjps-ietf@jpshallow.com</email>
	</address>		</address>
	</author>		</author>
			<date year="2023" month="February" />
	<date />		<area>sec</area>
			<workgroup>dots</workgroup>
	<workgroup>DOTS</workgroup>
	<keyword>Quick-Block</keyword>		<keyword>Quick-Block</keyword>
	<keyword>Robust-Block</keyword>		<keyword>Robust-Block</keyword>
	<keyword>R-Block</keyword>		<keyword>R-Block</keyword>
	<keyword>Tough-Block</keyword>		<keyword>Tough-Block</keyword>
	<keyword>Resilient-Block</keyword>		<keyword>Resilient-Block</keyword>
	<keyword>Fast-Block</keyword>		<keyword>Fast-Block</keyword>
	<keyword>Resilience</keyword>		<keyword>Resilience</keyword>
	<keyword>Filtering</keyword>		<keyword>Filtering</keyword>
	<keyword>Faster transmission</keyword>		<keyword>Faster transmission</keyword>
	<keyword>Large amounts of data</keyword>		<keyword>Large amounts of data</keyword>
	<keyword>Less packet interchange</keyword>		<keyword>Less packet interchange</keyword>
	<keyword>Fast recovery</keyword>		<keyword>Fast recovery</keyword>
	<abstract>		<abstract>
	<t>This document specifies new DDoS Open Threat Signaling (DOTS) signal		<t>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 Application P rotocol (CoAP) options. These
	options enable robust and faster transmission rates for large amounts of		options enable robust and faster transmission rates for large amounts of
	data with less packet interchanges as well as supporting faster recovery		data with less packet interchanges as well as support for faster recovery
	should any of the blocks get lost in transmission (especially, during		should any of the blocks get lost in transmission (especially during
	DDoS attacks).</t>		DDoS attacks).</t>
	<t>Also, this document defines a YANG data model for representing these		<t>Also, this document defines a YANG data model for representing these
	new DOTS signal channel configuration parameters. This model augments		new DOTS signal channel configuration parameters. This model augments
	the DOTS signal YANG module ("ietf-dots-signal-channel") defined in RFC		the DOTS signal YANG module ("ietf-dots-signal-channel") defined in RFC
	9132.</t>		9132.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction" title="Introduction">		<section anchor="introduction" numbered="true" toc="default">
	<t>The Constrained Application Protocol (CoAP) <xref		<name>Introduction</name>
	target="RFC7252"></xref>, although inspired by HTTP, was designed to use		<t>The Constrained Application Protocol (CoAP) <xref target="RFC7252" form
			at="default"/>, although inspired by HTTP, was designed to use
	UDP instead of TCP. The message layer of CoAP over UDP includes support		UDP instead of TCP. The message layer of CoAP over UDP includes support
	for reliable delivery, simple congestion control, and flow control. The		for reliable delivery, simple congestion control, and flow control. The
	block-wise transfer <xref target="RFC7959"></xref> introduced the CoAP		block-wise transfer <xref target="RFC7959" format="default"/> introduced t he CoAP
	Block1 and Block2 options to handle data records that cannot fit in a		Block1 and Block2 options to handle data records that cannot fit in a
	single IP packet, so not having to rely on IP fragmentation. The		single IP packet, to avoid having to rely on IP fragmentation. The
	block-wise transfer was further updated by <xref		block-wise transfer was further updated by <xref target="RFC8323" format="
	target="RFC8323"></xref> for use over TCP, TLS, and WebSockets.</t>		default"/> for use over TCP, TLS, and WebSockets.</t>
	<t>The CoAP Block1 and Block2 options work well in environments where		<t>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 previous		only ask for (or send) the next block when the request for the previous
	block has completed. Packet, and hence block transmission rate, is		block has completed. Packet rates, and hence block transmission rates, are
	controlled by Round-Trip Times (RTTs).</t>		controlled by Round-Trip Times (RTTs).</t>
	<t>There is a requirement for these blocks of data to be transmitted at		<t>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 is		transient packet loss (e.g., responses may get dropped). An example is
	when a network is subject to a Distributed Denial of Service (DDoS)		when a network is subject to a Distributed Denial of Service (DDoS)
	attack and there is a need for DDoS mitigation agents relying upon CoAP		attack and there is a need for DDoS mitigation agents relying upon CoAP
	to communicate with each other (e.g., <xref target="RFC9244"></xref>).		to communicate with each other (e.g., <xref target="RFC9244" format="defau
	As a reminder, <xref target="RFC7959"></xref> recommends the use of		lt"/>).
			As a reminder, <xref target="RFC7959" format="default"/> recommends the us
			e of
	Confirmable (CON) responses to handle potential packet loss. However,		Confirmable (CON) responses to handle potential packet loss. However,
	such a recommendation does not work with a flooded pipe DDoS situation		such a recommendation does not work with a "flooded pipe" DDoS situation
	because the returning ACK packets may not get through.</t>		because the returning ACK packets may not get through.</t>
			<t>The block-wise transfer specified in <xref target="RFC7959" format="def
	<t>The block-wise transfer specified in <xref target="RFC7959"></xref>		ault"/>
	covers the general case, but falls short in situations where packet loss		covers the general case but falls short in situations where packet loss
	is highly asymmetrical. The mechanism specified in <xref		is highly asymmetrical. The mechanism specified in <xref target="RFC9177"
	target="RFC9177"></xref> provides roughly similar features to the		format="default"/> provides features roughly similar to the
	Block1/Block2 options, but provides additional properties that are		Block1/Block2 options but also provides additional properties that are
	tailored towards the intended DDoS Open Threat Signaling (DOTS)		tailored towards the intended DDoS Open Threat Signaling (DOTS)
	transmission. Concretely, <xref target="RFC9177"></xref> primarily		transmission. Concretely, <xref target="RFC9177" format="default"/> primar ily
	targets applications such as DOTS that can't use Confirmable responses		targets applications such as DOTS that can't use Confirmable responses
	to handle potential packet loss and that support application-specific		to handle potential packet loss and that support application-specific
	mechanisms to assess whether the remote peer is able to handle the		mechanisms to assess whether the remote peer is able to handle the
	messages sent by a CoAP endpoint (e.g., DOTS heartbeats in Section 4.7		messages sent by a CoAP endpoint (e.g., DOTS heartbeats as discussed in <x
	of <xref target="RFC9132"></xref>).</t>		ref target="RFC9132" sectionFormat="of" section="4.7"/>).</t>
			<t><xref target="RFC9177" format="default"/> includes guards to prevent a
	<t><xref target="RFC9177"></xref> includes guards to prevent a CoAP		CoAP
	agent from overloading the network by adopting an aggressive sending		agent from overloading the network by adopting an aggressive sending
	rate. These guards are followed in addition to the existing CoAP		rate. These guards are followed in addition to the existing CoAP
	congestion control as specified in Section 4.7 of <xref		congestion control as specified in <xref target="RFC7252" sectionFormat="o
	target="RFC7252"></xref> (mainly, PROBING_RATE). Table 1 lists the		f" section="4.7"/> (mainly PROBING_RATE). <xref target="tab-1"/> lists the
	additional CoAP parameters that are used for the guards (Section 7.2 of		additional CoAP parameters that are used for the guards (<xref target="RFC
	<xref target="RFC9177"></xref>). Note that NON in this table refers to		9177" sectionFormat="of" section="7.2"/>). Note that NON in this table refers to
	Non-confirmable.</t>		Non-confirmable.</t>
	<t><figure align="center">		<table anchor="tab-1">
	<artwork align="center"><![CDATA[+---------------------+--------------		<name>Congestion Control Parameters</name>
	-----+		<thead>
	| Parameter Name | Default Value |		<tr>
	+=====================+===================+		<th>Parameter Name</th>
	| MAX_PAYLOADS | 10 |		<th>Default Value</th>
	| NON_MAX_RETRANSMIT | 4 |		</tr>
	| NON_TIMEOUT | 2 s |		</thead>
	| NON_TIMEOUT_RANDOM | between 2-3 s |		<tbody>
	| NON_RECEIVE_TIMEOUT | 4 s |		<tr>
	| NON_PROBING_WAIT | between 247-248 s |		<td>MAX_PAYLOADS</td>
	| NON_PARTIAL_TIMEOUT | 247 s |		<td>10</td>
	+---------------------+-------------------+		</tr>
			<tr>
	Table 1: Congestion Control Parameters]]></artwork>		<td>NON_MAX_RETRANSMIT</td>
	</figure></t>		<td>4</td>
			</tr>
			<tr>
			<td>NON_TIMEOUT</td>
			<td>2 s</td>
			</tr>
			<tr>
			<td>NON_TIMEOUT_RANDOM</td>
			<td>between 2-3 s</td>
			</tr>
			<tr>
			<td>NON_RECEIVE_TIMEOUT</td>
			<td>4 s</td>
			</tr>
			<tr>
			<td>NON_PROBING_WAIT</td>
			<td>between 247-248 s</td>
			</tr>
			<tr>
			<td>NON_PARTIAL_TIMEOUT</td>
			<td>247 s</td>
			</tr>
			</tbody>
			</table>
	<t>PROBING_RATE and other transmission parameters are negotiated between		<t>PROBING_RATE and other transmission parameters are negotiated between
	DOTS peers as discussed in Section 4.5.2 of <xref		DOTS peers as discussed in <xref target="RFC9132" sectionFormat="of" secti
	target="RFC9132"></xref>. Nevertheless, negotiating the parameters		on="4.5.2"/>. Nevertheless, negotiating the parameters
	listed in Table 1 is not supported in <xref target="RFC9132"></xref>.		listed in <xref target="tab-1"/> is not supported in <xref target="RFC9132
			" format="default"/>.
	This document defines new DOTS signal channel attributes, corresponding		This document defines new DOTS signal channel attributes, corresponding
	to the parameters in Table 1, that are used to customize the		to the parameters in <xref target="tab-1"/>, that are used to customize th e
	configuration of robust block transmission in a DOTS context.</t>		configuration of robust block transmission in a DOTS context.</t>
	</section>		</section>
			<section anchor="notation" numbered="true" toc="default">
	<section anchor="notation" title="Terminology">		<name>Terminology</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	"OPTIONAL" in this document are to be interpreted as described in BCP 14		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	<xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and		"<bcp14>SHOULD NOT</bcp14>",
	only when, they appear in all capitals, as shown here.</t>		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
			are to be interpreted as described in BCP&nbsp;14
			<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
			when, they appear in all capitals, as shown here.</t>
	<t>Readers should be familiar with the terms and concepts defined in		<t>Readers should be familiar with the terms and concepts defined in
	<xref target="RFC7252"></xref> and <xref target="RFC8612"></xref>.</t>		<xref target="RFC7252" format="default"/> and <xref target="RFC8612" forma
			t="default"/>.</t>
	<t>The terms "payload" and "body" are defined in <xref		<t>The terms "payload" and "body" are defined in <xref target="RFC7959" fo
	target="RFC7959"></xref>. The term "payload" is thus used for the		rmat="default"/>. The term "payload" is thus used for the
	content of a single CoAP message (i.e., a single block being		content of a single CoAP message (i.e., a single block being
	transferred), while the term "body" is used for the entire resource		transferred), while the term "body" is used for the entire resource
	representation that is being transferred in a block-wise fashion.</t>		representation that is being transferred in a block-wise fashion.</t>
			<t>The meanings of the symbols in YANG tree diagrams are defined in <xref
	<t>The meaning of the symbols in YANG tree diagrams are defined in <xref		target="RFC8340" format="default"/> and <xref target="RFC8791" format="default"/
	target="RFC8340"></xref> and <xref target="RFC8791"></xref>.</t>		>.</t>
	</section>		</section>
			<section anchor="new" numbered="true" toc="default">
	<section anchor="new"		<name>DOTS Attributes for Robust Block Transmission</name>
	title="DOTS Attributes for Robust Block Transmission">		<t><xref target="RFC9177" sectionFormat="of" section="7.2"/> defines the f
	<t>Section 7.2 of <xref target="RFC9177"></xref> defines the following		ollowing
	parameters that are used for congestion control purposes:<list		parameters that are used for congestion control purposes:</t>
	style="hanging">		<dl newline="false" spacing="normal">
	<t hangText="MAX_PAYLOADS:">is the maximum number of payloads that		<dt>MAX_PAYLOADS:</dt>
	can be transmitted at any one time.</t>		<dd>This parameter represents the maximum number of payloads that
			can be transmitted at any one time.</dd>
	<t hangText="NON_MAX_RETRANSMIT:">is the maximum number of times a		<dt>NON_MAX_RETRANSMIT:</dt>
			<dd>This parameter represents the maximum number of times a
	request for the retransmission of missing payloads can occur without		request for the retransmission of missing payloads can occur without
	a response from the remote peer. By default, NON_MAX_RETRANSMIT has		a response from the remote peer. By default, NON_MAX_RETRANSMIT has
	the same value as MAX_RETRANSMIT (Section 4.8 of <xref		the same value as MAX_RETRANSMIT (<xref target="RFC7252" sectionFormat
	target="RFC7252"></xref>).</t>		="of" section="4.8"/>).</dd>
			<dt>NON_TIMEOUT:</dt>
	<t hangText="NON_TIMEOUT:">is the maximum period of delay between		<dd>This parameter represents the maximum period of delay between
	sending sets of MAX_PAYLOADS payloads for the same body. NON_TIMEOUT		sending sets of MAX_PAYLOADS payloads for the same body. NON_TIMEOUT
	has the same value as ACK_TIMEOUT (Section 4.8 of <xref		has the same value as ACK_TIMEOUT (<xref target="RFC7252" sectionForma
	target="RFC7252"></xref>).</t>		t="of" section="4.8"/>).</dd>
			<dt>NON_TIMEOUT_RANDOM:</dt>
	<t hangText="NON_TIMEOUT_RANDOM:">is the initial actual delay		<dd>This parameter represents the initial actual delay
	between sending the first two MAX_PAYLOADS_SETs of the same body. It		between sending the first two MAX_PAYLOADS_SETs of the same body. It
	is a random duration between NON_TIMEOUT and (NON_TIMEOUT *		is a random duration between NON_TIMEOUT and (NON_TIMEOUT *
	ACK_RANDOM_FACTOR).</t>		ACK_RANDOM_FACTOR).</dd>
			<dt>NON_RECEIVE_TIMEOUT:</dt>
	<t hangText="NON_RECEIVE_TIMEOUT:">is the maximum time to wait for a		<dd>This parameter represents the maximum time to wait for a
	missing payload before requesting retransmission. By default,		missing payload before requesting retransmission. By default,
	NON_RECEIVE_TIMEOUT has a value of twice NON_TIMEOUT.</t>		NON_RECEIVE_TIMEOUT has a value of twice NON_TIMEOUT.</dd>
			<dt>NON_PROBING_WAIT:</dt>
	<t hangText="NON_PROBING_WAIT:">is used to limit the potential wait		<dd>This parameter is used to limit the potential wait
	needed when using PROBING_RATE.</t>		needed when using PROBING_RATE.</dd>
			<dt>NON_PARTIAL_TIMEOUT:</dt>
	<t hangText="NON_PARTIAL_TIMEOUT:">is used for expiring partially		<dd>This parameter is used for expiring partially
	received bodies.</t>		received bodies.</dd>
	</list></t>		</dl>
			<t>These parameters are used together with the PROBING_RATE parameter, whi
	<t>These parameters are used together with PROBING_RATE parameter which		ch
	in CoAP indicates the average data rate that must not be exceeded by a		in CoAP indicates the average data rate that must not be exceeded by a
	CoAP endpoint in sending to a peer endpoint that does not respond. The		CoAP endpoint in sending to a peer endpoint that does not respond. The
	single body of blocks will be subjected to PROBING_RATE (Section 4.7 of		single body of blocks will be subjected to PROBING_RATE (<xref target="RFC
	<xref target="RFC7252"></xref>), not the individual packets. If the wait		7252" sectionFormat="of" section="4.7"/>), not the individual packets. If the wa
			it
	time between sending bodies that are not being responded to based on		time between sending bodies that are not being responded to based on
	PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time is limited to		PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time is limited to
	NON_PROBING_WAIT.</t>		NON_PROBING_WAIT.</t>
	<t>This document augments the "ietf-dots-signal-channel" DOTS signal		<t>This document augments the "ietf-dots-signal-channel" DOTS signal
	YANG module defined in Section 5.3 of <xref target="RFC9132"></xref>		YANG module defined in <xref target="RFC9132" sectionFormat="of" section="
	with the following additional attributes that can be negotiated between		5.3"/> with the following additional attributes that can be negotiated between
	DOTS peers to enable robust and faster transmission:</t>		DOTS peers to enable robust and faster transmission:</t>
			<dl newline="false" spacing="normal">
	<t><list style="hanging">		<dt>max-payloads:</dt>
	<t hangText="max-payloads:">This attribute echoes the MAX_PAYLOADS		<dd>
	parameter in <xref target="RFC9177"></xref>.<vspace		<t>This attribute echoes the MAX_PAYLOADS
	blankLines="1" />This is an optional attribute. If the attribute is		parameter defined in <xref target="RFC9177" format="default"/>.</t>
	supplied in both &lsquo;idle-config&rsquo; and		<t>This is an optional attribute. If the attribute is
	&lsquo;mitigating-config&rsquo;, then it MUST convey the same value.		supplied in both 'idle-config' and
			'mitigating-config', then it <bcp14>MUST</bcp14> convey the same value
			.
	If the attribute is only provided as part of		If the attribute is only provided as part of
	&lsquo;idle-config&rsquo; (or &lsquo;mitigating-config&rsquo;), then		'idle-config' (or 'mitigating-config'), then
	the other definition (i.e., &lsquo;mitigating-config&rsquo; (or		the other definition (i.e., 'mitigating-config' (or
	&lsquo;idle-config&rsquo;)) MUST be updated to the same value.</t>		'idle-config')) <bcp14>MUST</bcp14> be updated to the same value.</t>
			</dd>
	<t hangText="non-max-retransmit:">This attribute echoes the		<dt>non-max-retransmit:</dt>
	NON_MAX_RETRANSMIT parameter in <xref target="RFC9177"></xref>. The		<dd>
			<t>This attribute echoes the
			NON_MAX_RETRANSMIT parameter defined in <xref target="RFC9177" format=
			"default"/>. The
	default value of this attribute is 'max-retransmit'. Note that DOTS		default value of this attribute is 'max-retransmit'. Note that DOTS
	uses a default value of '3' instead of '4' used for the generic CoAP		uses a default value of '3' instead of '4' (which is used
	use (Section 4.5.2 of <xref target="RFC9132"></xref>) for		generically by CoAP for 'max-transmit'; see <xref target="RFC9132" sec
	max-transmit. <vspace blankLines="1" />This is an optional		tionFormat="of" section="4.5.2"/> and <xref target="RFC7252" sectionFormat="of"
	attribute.</t>		section="4.8"/>).</t>
	<t hangText="non-timeout:">This attribute, expressed in seconds,		<t>This is an optional
	echoes the NON_TIMEOUT parameter in <xref target="RFC9177"></xref>.		attribute.</t>
	The default value of this attribute is 'ack-timeout'.<vspace		</dd>
	blankLines="1" />This attribute is also used to compute the		<dt>non-timeout:</dt>
	NON_TIMEOUT_RANDOM parameter.<vspace blankLines="1" />This is an		<dd>
			<t>This attribute, expressed in seconds,
			echoes the NON_TIMEOUT parameter defined in <xref target="RFC9177" for
			mat="default"/>.
			The default value of this attribute is 'ack-timeout'.</t>
			<t>This attribute is also used to compute the
			NON_TIMEOUT_RANDOM parameter.</t>
			<t>This is an
	optional attribute.</t>		optional attribute.</t>
			</dd>
	<t hangText="non-receive-timeout:">This attribute, expressed in		<dt>non-receive-timeout:</dt>
	seconds, echoes the NON_RECEIVE_TIMEOUT parameter in <xref		<dd>
	target="RFC9177"></xref>. The default value of this attribute is		<t>This attribute, expressed in
	twice 'non-timeout'.<vspace blankLines="1" />This is an optional		seconds, echoes the NON_RECEIVE_TIMEOUT parameter defined in <xref tar
			get="RFC9177" format="default"/>. The default value of this attribute is
			twice 'non-timeout'.</t>
			<t>This is an optional
	attribute.</t>		attribute.</t>
			</dd>
	<t hangText="non-probing-wait:">This attribute, expressed in		<dt>non-probing-wait:</dt>
	seconds, echoes the NON_PROBING_WAIT parameter in <xref		<dd>
	target="RFC9177"></xref>. <vspace blankLines="1" />This is an		<t>This attribute, expressed in
			seconds, echoes the NON_PROBING_WAIT parameter defined in <xref target
			="RFC9177" format="default"/>. </t>
			<t>This is an
	optional attribute.</t>		optional attribute.</t>
			</dd>
			<dt>non-partial-timeout:</dt>
			<dd>
			<t>This attribute, expressed in
			seconds, echoes the NON_PARTIAL_TIMEOUT parameter defined in <xref tar
			get="RFC9177" format="default"/>. The default value of this attribute is 247
			seconds.</t>
			<t>This is an optional attribute.</t>
			</dd>
			</dl>
			<t>The tree structure of the "ietf-dots-robust-trans" module (<xref target
			="module" format="default"/>) is shown in <xref target="tree" format="default"/>
			.</t>
	<t hangText="non-partial-timeout:">This attribute, expressed in		<figure anchor="tree">
	seconds, echoes the NON_PARTIAL_TIMEOUT parameter in <xref		<name>DOTS Fast Block Transmission Tree Structure</name>
	target="RFC9177"></xref>. The default value of this attribute is 247		<sourcecode name="" type="yangtree"><![CDATA[module: ietf-dots-robust-tr
	seconds.<vspace blankLines="1" />This is an optional attribute.</t>		ans
	</list></t>
	<t>The tree structure of the "ietf-dots-robust-trans" module (<xref
	target="module"></xref>) is shown in <xref target="tree"></xref>.</t>
	<t><figure anchor="tree"
	title="DOTS Fast Block Transmission Tree Structure">
	<artwork><![CDATA[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
	skipping to change at line 333 ¶		skipping to change at line 320 ¶
	| | +--:(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
			/dots-signal:idle-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
	skipping to change at line 372 ¶		skipping to change at line 360 ¶
	| | +--:(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
	]]></artwork>		]]></sourcecode>
	</figure></t>		</figure>
			<t>These attributes are mapped to Concise Binary Object Representation (CB
	<t>These attributes are mapped to CBOR types as specified in <xref		OR) types as specified in <xref target="maptab" format="default"/> and in <xref
	target="maptab"></xref> and Section 6 of <xref		target="RFC9132" sectionFormat="of" section="6"/>.</t>
	target="RFC9132"></xref>.</t>		<t>DOTS clients follow the procedure specified in <xref target="RFC9132" s
			ectionFormat="of" section="4.5"/> to negotiate, configure, and retrieve the DOTS
	<t>DOTS clients follow the procedure specified in Section 4.5 of <xref
	target="RFC9132"></xref> to negotiate, configure, and retrieve the DOTS
	signal channel session behavior (including Q-Block parameters) with DOTS		signal channel session behavior (including Q-Block parameters) with DOTS
	peers.</t>		peers.</t>
			<dl newline="false" spacing="normal">
	<t><list style="hanging">		<dt>Implementation Note 1:</dt>
	<t hangText="Implementation Note 1:">'non-probing-wait' ideally		<dd>'non-probing-wait' ideally
	should be left having some jitter and so should not be hard-coded		should be left having some jitter and so should not be hard-coded
	with an explicit value. It is suggested to use a base value (using		with an 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.</t>		checked.</dd>
			<dt>Implementation Note 2:</dt>
	<t hangText="Implementation Note 2:">If any of the signal channel		<dd>If any of the signal channel
	session configuration parameters is updated, the 'non-probing-wait'		session configuration parameters is updated, the 'non-probing-wait'
	and 'non-partial-timeout' values should be recalculated according to		and 'non-partial-timeout' values should be recalculated according to
	the definition algorithms in Section 7.2 of <xref		the definition algorithms provided in <xref target="RFC9177" sectionFo
	target="RFC9177"></xref> unless explicit values are provided as part		rmat="of" section="7.2"/> unless explicit values are provided as part
	of the negotiated configuration.</t>		of the negotiated configuration.</dd>
	</list></t>		</dl>
	<t>An example of a PUT message to configure Q-Block parameters is		<t>An example of a PUT message to configure Q-Block parameters is
	depicted in <xref target="put"></xref>. In this example, a non-default		depicted in <xref target="put" format="default"/>. In this example, a non- default
	value is configured for the 'max-payloads' attribute, while default		value is configured for the 'max-payloads' attribute, while default
	values are used for 'non-max-retransmit', 'non-timeout', and		values are used for 'non-max-retransmit', 'non-timeout', and
	'non-receive-timeout' in both idle and mitigation times. Given that		'non-receive-timeout' in both idle and mitigation times. Given that
	'non-probing-wait' and 'non-partial-wait' are not explicitly configured		'non-probing-wait' and 'non-partial-timeout' are not explicitly configured
	in this example, these attributes will be computed following the		in this example, these attributes will be computed following the
	algorithms in Section 7.2 of <xref target="RFC9177"></xref>. The meaning		algorithms provided in <xref target="RFC9177" sectionFormat="of" section="
	of the other attributes is detailed in Section 4.5 of <xref		7.2"/>. The meanings
	target="RFC9132"></xref>.</t>		of the other attributes are detailed in <xref target="RFC9132" sectionForm
			at="of" section="4.5"/>.</t>
	<t><figure align="center" anchor="put"		<figure anchor="put">
	title="Example of PUT to Convey the Configuration Parameters">		<name>Example of PUT to Convey the Configuration Parameters</name>
	<artwork align="left"><![CDATA[ Header: PUT (Code=0.03)		<sourcecode name="" type="http-message"><![CDATA[
			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": {
	"mitigating-config": {		"mitigating-config": {
	"heartbeat-interval": {		"heartbeat-interval": {
	skipping to change at line 487 ¶		skipping to change at line 467 ¶
	"current-value": 3		"current-value": 3
	},		},
	"ietf-dots-robust-trans:non-timeout": {		"ietf-dots-robust-trans:non-timeout": {
	"current-value-decimal": "2.00"		"current-value-decimal": "2.00"
	},		},
	"ietf-dots-robust-trans:non-receive-timeout": {		"ietf-dots-robust-trans:non-receive-timeout": {
	"current-value-decimal": "4.00"		"current-value-decimal": "4.00"
	}		}
	}		}
	}		}
	}]]></artwork>		}
	</figure></t>		]]></sourcecode>
			</figure>
	<t></t>		<t>The payload of the message depicted in <xref target="put" format="defau
			lt"/> is
	<t>The payload of the message depicted in <xref target="put"></xref> is
	CBOR-encoded as indicated by the Content-Format set to		CBOR-encoded as indicated by the Content-Format set to
	"application/dots+cbor" (Section 10.3 of <xref		"application/dots+cbor" (<xref target="RFC9132" sectionFormat="of" section
	target="RFC9132"></xref>). However, and for the sake of better		="10.4"/>). 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 <xref target="maptab"></xref> and Section		following the mapping tables in <xref target="maptab" format="default"/> a
	6 of <xref target="RFC9132"></xref>: use the JSON names and types		nd in <xref target="RFC9132" sectionFormat="of" section="6"/>: use the JSON name
	defined in <xref target="maptab"></xref>. These conventions are		s and types
	inherited from <xref target="RFC9132"></xref>.</t>		defined in <xref target="maptab" format="default"/>. These conventions are
			inherited from <xref target="RFC9132" format="default"/>.</t>
	</section>		</section>
			<section anchor="maptab" numbered="true" toc="default">
	<section anchor="maptab" title="YANG/JSON Mapping Parameters to CBOR">		<name>YANG/JSON Mapping Parameters to CBOR</name>
	<t>The YANG/JSON mapping parameters to CBOR are listed in Table 2.<list		<t>The YANG/JSON mapping parameters to CBOR are listed in <xref target="ta
	style="symbols">		b-2"/>.</t>
	<t>Note: Implementers must check that the mapping output provided by		<t indent="3">Note: Implementers must check that the mapping output prov
			ided 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.</t>		<xref target="tab-2"/>.</t>
	</list></t>
	<t><figure align="center">
	<artwork><![CDATA[+----------------------+------------+------+--------
	-------+--------+
	| Parameter Name | YANG | CBOR | CBOR Major | JSON |
	| | Type | Key | Type & | Type |
	| | | | Information | |
	+======================+============+======+===============+========+
	| ietf-dots-robust- | container | TBA1 | 5 map | Object |
	| trans:max-payloads | | | | |
	+----------------------+------------+------+---------------+--------+
	| ietf-dots-robust- | container | TBA2 | 5 map | Object |
	| trans:non-max- | | | | |
	| retransmit | | | | |
	+----------------------+------------+------+---------------+--------+
	| ietf-dots-robust- | container | TBA3 | 5 map | Object |
	| trans:non-timeout | | | | |
	+----------------------+------------+------+---------------+--------+
	| ietf-dots-robust- | container | TBA4 | 5 map | Object |
	| trans:non-receive- | | | | |
	| timeout | | | | |
	+----------------------+------------+------+---------------+--------+
	| ietf-dots-robust- | container | TBA5 | 5 map | Object |
	| trans:non-probing- | | | | |
	| wait | | | | |
	+----------------------+------------+------+---------------+--------+
	| ietf-dots-robust- | container | TBA6 | 5 map | Object |
	| trans:non-partial- | | | | |
	| wait | | | | |
	+----------------------+------------+------+---------------+--------+
	Table 2: YANG/JSON Mapping Parameters to CBOR		<table anchor="tab-2">
	]]></artwork>		<name>YANG/JSON Mapping Parameters to CBOR</name>
	</figure></t>		<thead>
			<tr>
			<th>Parameter Name</th>
			<th>YANG Type</th>
			<th>CBOR Key</th>
			<th>CBOR Major Type &amp; Information</th>
			<th>JSON Type</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>ietf-dots-robust-trans:max-payloads</td>
			<td>container</td>
			<td>32776</td>
			<td>5 map</td>
			<td>Object</td>
			</tr>
			<tr>
			<td>ietf-dots-robust-trans:non-max-retransmit</td>
			<td>container</td>
			<td>32777</td>
			<td>5 map</td>
			<td>Object</td>
			</tr>
			<tr>
			<td>ietf-dots-robust-trans:non-timeout</td>
			<td>container</td>
			<td>32778</td>
			<td>5 map</td>
			<td>Object</td>
			</tr>
			<tr>
			<td>ietf-dots-robust-trans:non-receive-timeout</td>
			<td>container</td>
			<td>32779</td>
			<td>5 map</td>
			<td>Object</td>
			</tr>
			<tr>
			<td>ietf-dots-robust-trans:non-probing-wait</td>
			<td>container</td>
			<td>32780</td>
			<td>5 map</td>
			<td>Object</td>
			</tr>
			<tr>
			<td>ietf-dots-robust-trans:non-partial-timeout</td>
			<td>container</td>
			<td>32781</td>
			<td>5 map</td>
			<td>Object</td>
			</tr>
			</tbody>
			</table>
	<t></t>
	</section>		</section>
			<section anchor="module" numbered="true" toc="default">
	<section anchor="module"		<name>DOTS Robust Block Transmission YANG Module</name>
	title="DOTS Robust Block Transmission YANG Module">		<t>This module uses the data structure extension defined in <xref target="
	<t>This module uses the data structure extension defined in <xref		RFC8791" format="default"/>.</t>
	target="RFC8791"></xref>.</t>		<sourcecode name="ietf-dots-robust-trans@2023-01-26.yang" type="yang" mark
			ers="true"><![CDATA[
	<t><figure>
	<artwork><![CDATA[<CODE BEGINS> file "ietf-dots-robust-trans@2022-01-0
	4.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 line 577 ¶		skipping to change at line 570 ¶
	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 line 665 ¶		skipping to change at line 658 ¶
	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 line 704 ¶		skipping to change at line 697 ¶
	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 line 748 ¶		skipping to change at line 741 ¶
	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 line 881 ¶		skipping to change at line 874 ¶
	sx:augment-structure "/dots-signal:dots-signal"		sx:augment-structure "/dots-signal:dots-signal"
	+ "/dots-signal:message-type"		+ "/dots-signal:message-type"
	+ "/dots-signal:signal-config"		+ "/dots-signal:signal-config"
	+ "/dots-signal:idle-config" {		+ "/dots-signal:idle-config" {
	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>]]></artwork>		]]></sourcecode>
	</figure></t>
	</section>		</section>
			<section anchor="IANA" numbered="true" toc="default">
	<section anchor="IANA" title="IANA Considerations">		<name>IANA Considerations</name>
	<section anchor="map" title="DOTS Signal Channel CBOR Mappings Registry">		<section anchor="map" numbered="true" toc="default">
			<name>Registry for DOTS Signal Channel CBOR Mappings</name>
	<t>This specification registers the following parameters in the IANA		<t>This specification registers the following parameters in the IANA
	"DOTS Signal Channel CBOR Key Values" registry <xref		"DOTS Signal Channel CBOR Key Values" registry <xref target="Key-Map" fo
	target="Key-Map"></xref>.</t>		rmat="default"/>.</t>
	<t><list style="symbols">
	<t>Note to the RFC Editor: Please replace TBA1-TBA6 with the CBOR
	keys that are assigned from the 32768-49151 range. Please update
	Table 2 accordingly.</t>
	</list></t>
	<t><figure align="center">
	<artwork><![CDATA[+------------------------+-------+-------+--------
	----+---------------+
	| 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 | | | | |
	+------------------------+-------+-------+------------+---------------+
	]]></artwork>		<table>
	</figure></t>		<name>DOTS Robust Block Transmission CBOR Mappings</name>
			<thead>
			<tr>
			<th>Parameter Name</th>
			<th>CBOR Key Value</th>
			<th>CBOR Major Type</th>
			<th>Change Controller</th>
			<th>Specification Document(s)</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>ietf-dots-robust-trans:max-payloads</td>
			<td>32776</td>
			<td>5</td>
			<td>IESG</td>
			<td>RFC 9362</td>
			</tr>
			<tr>
			<td>ietf-dots-robust-trans:non-max-retransmit</td>
			<td>32777</td>
			<td>5</td>
			<td>IESG</td>
			<td>RFC 9362</td>
			</tr>
			<tr>
			<td>ietf-dots-robust-trans:non-timeout</td>
			<td>32778</td>
			<td>5</td>
			<td>IESG</td>
			<td>RFC 9362</td>
			</tr>
			<tr>
			<td>ietf-dots-robust-trans:non-receive-timeout</td>
			<td>32779</td>
			<td>5</td>
			<td>IESG</td>
			<td>RFC 9362</td>
			</tr>
			<tr>
			<td>ietf-dots-robust-trans:non-probing-wait</td>
			<td>32780</td>
			<td>5</td>
			<td>IESG</td>
			<td>RFC 9362</td>
			</tr>
			<tr>
			<td>ietf-dots-robust-trans:non-partial-timeout</td>
			<td>32781</td>
			<td>5</td>
			<td>IESG</td>
			<td>RFC 9362</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
			<section anchor="yang-iana" numbered="true" toc="default">
	<section anchor="yang-iana"		<name>DOTS Robust Block Transmission YANG Module</name>
	title="DOTS Robust Block Transmission YANG Module">		<t>IANA has registered the following URI in the
	<t>This document requests IANA to register the following URI in the		"ns" subregistry within the "IETF XML Registry" <xref target="RFC3688" f
	"ns" subregistry within the "IETF XML Registry" <xref		ormat="default"/>:</t>
	target="RFC3688"></xref>:</t>		<dl newline="false" spacing="compact">
			<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans</dd>
	<t><figure>		<dt>Registrant Contact:</dt><dd>The IESG.</dd>
	<artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-dots-robus		<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
	t-trans		</dl>
	Registrant Contact: The IESG.		<t>IANA has registered the following YANG module
	XML: N/A; the requested URI is an XML namespace.		in the "YANG Module Names" subregistry <xref target="RFC6020" format="de
	]]></artwork>		fault"/>
	</figure></t>
	<t>This document requests IANA to register the following YANG module
	in the "YANG Module Names" subregistry <xref target="RFC6020"></xref>
	within the "YANG Parameters" registry.</t>		within the "YANG Parameters" registry.</t>
			<dl newline="false" spacing="compact">
	<t><figure>		<dt>Name:</dt><dd>ietf-dots-robust-trans</dd>
	<artwork><![CDATA[ Name: ietf-dots-robust-trans		<dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans</dd>
	Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans		<dt>Maintained by IANA?</dt><dd>N</dd>
	Maintained by IANA? N		<dt>Prefix:</dt><dd>dots-robust</dd>
	Prefix: dots-robust		<dt>Reference:</dt><dd>RFC 9362</dd>
	Reference: RFC XXXX		</dl>
	]]></artwork>
	</figure></t>
	</section>		</section>
	</section>		</section>
			<section anchor="security" numbered="true" toc="default">
	<section anchor="security" title="Security Considerations">		<name>Security Considerations</name>
	<t>The security considerations for the DOTS signal channel protocol are		<t>The security considerations for the DOTS signal channel protocol are
	discussed in Section 11 of <xref target="RFC9132"></xref>.</t>		discussed in <xref target="RFC9132" sectionFormat="of" section="11"/>.</t>
			<t>CoAP-specific security considerations are discussed in <xref target="RF
	<t>CoAP-specific security considerations are discussed in Section 11 of		C9177" sectionFormat="of" section="11"/>.</t>
	<xref target="RFC9177"></xref>.</t>		<t>Consistent with <xref target="RFC9132" sectionFormat="of" section="5"/>
			, the
	<t>Consistent with Section 5 of <xref target="RFC9132"></xref>, the
	"ietf-dots-robust-trans" module is not intended to be used via		"ietf-dots-robust-trans" module is not intended to be used via
	NETCONF/RESTCONF. It serves as an abstract representation in DOTS signal		NETCONF/RESTCONF. It serves as an abstract representation in DOTS signal
	channel messages. The "ietf-dots-robust-trans" module does not introduce		channel messages. The "ietf-dots-robust-trans" module does not introduce
	any new vulnerabilities beyond those specified above.</t>		any new vulnerabilities beyond those specified above.</t>
	</section>		</section>
			</middle>
			<back>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
			119.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			252.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			174.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			959.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			323.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			791.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			177.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			132.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
			020.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
			688.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			244.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			612.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			340.xml"/>
	<section anchor="ack" title="Acknowledgements">		<reference anchor="Key-Map" target="https://www.iana.org/assignments/dot
	<t>Thanks to Tiru Reddy, Meiling Chen, and Kaname Nishizuka for the		s/">
			<front>
			<title>DOTS Signal Channel CBOR Key Values</title>
			<author>
			<organization>IANA</organization>
			</author>
			<date/>
			</front>
			</reference>
			</references>
			</references>
			<section anchor="ack" numbered="false" toc="default">
			<name>Acknowledgements</name>
			<t>Thanks to <contact fullname="Tiru Reddy"/>, <contact fullname="Meiling
			Chen"/>, and <contact fullname="Kaname Nishizuka"/> for the
	review.</t>		review.</t>
			<t>Thanks to <contact fullname="Michal Vaško"/> for the yangdoctors review
	<t>Thanks to Michal Va&scaron;ko for the yangdoctors review.</t>		.</t>
			<t>Thanks to <contact fullname="Valery Smyslov"/> for shepherding the docu
	<t>Thanks to Valery Smyslov for shepherding the document, Paul Wouters		ment, <contact fullname="Paul Wouters"/>
	for the AD review, Paul Kyzivat for the artart directorate review, Tim		for the AD review, <contact fullname="Paul Kyzivat"/> for the artart direc
	Evens for the Gen-ART review, and Jean-Michel Combes for the int-dir		torate review, <contact fullname="Tim Evens"/> for the Gen-ART review, and <cont
			act fullname="Jean-Michel Combes"/> for the int-dir
	review.</t>		review.</t>
			<t>Thanks to <contact fullname="John Scudder"/>, <contact fullname="Lars E
	<t>Thanks to John Scudder, Lars Eggert, &Eacute;ric Vyncke, Roman		ggert"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Roman
	Danyliw, Rob Wilton, and Martin Duke for the comments during the IESG		Danyliw"/>, <contact fullname="Rob Wilton"/>, and <contact fullname="Marti
			n Duke"/> for their comments during the IESG
	review.</t>		review.</t>
	</section>		</section>
	</middle>
	<back>
	<references title="Normative References">
	<?rfc include='reference.RFC.2119'?>
	<?rfc include='reference.RFC.7252'?>
	<?rfc include='reference.RFC.8174'?>
	<?rfc include='reference.RFC.7959'?>
	<?rfc include='reference.RFC.8323'?>
	<?rfc include='reference.RFC.8791'?>
	<?rfc include='reference.RFC.9177'?>
	<?rfc include='reference.RFC.9132'?>
	<?rfc include='reference.RFC.6020'?>
	<?rfc include='reference.RFC.3688'?>
	</references>
	<references title="Informative References">
	<?rfc include="reference.RFC.9244"?>
	<?rfc include='reference.RFC.8612'?>
	<?rfc include='reference.RFC.8340'?>
	<reference anchor="Key-Map"
	target="https://www.iana.org/assignments/dots/dots.xhtml#dots-s
	ignal-channel-cbor-key-values">
	<front>
	<title>DOTS Signal Channel CBOR Key Values</title>
	<author fullname="IANA">
	<organization></organization>
	</author>
	<date />
	</front>
	</reference>
	</references>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 122 change blocks.
	460 lines changed or deleted		521 lines changed or added
This html diff was produced by rfcdiff 1.48.