rfc9034v2.xml		rfc9034.xml
	skipping to change at line 36 ¶		skipping to change at line 36 ¶
	https://www.rfc-editor.org/rfc9034-postapproval-rfcdiff.html		https://www.rfc-editor.org/rfc9034-postapproval-rfcdiff.html
	Note: -06 was provided by the author in October 2019; it is not in the Datatrack er.		Note: -06 was provided by the author in October 2019; it is not in the Datatrack er.
	For the purpose of AUTH48, the .original for this file is -05		For the purpose of AUTH48, the .original for this file is -05
	(the approved draft), so these changes are also viewable in the various		(the approved draft), so these changes are also viewable in the various
	diff files provided.		diff files provided.
	-->		-->
	<front>		<front>
	<!-- [rfced] FYI, the title of the document has been updated as
	follows to expand the abbreviation. Please review.
	Current:
	Packet Delivery Deadline Time in the 6LoWPAN Routing Header
	Perhaps:
	Packet Delivery Deadline Time in the Routing Header for
	IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
	<!-- [rfced] FYI, the authors' comments in the XML file have been
	marked with [auth]. Please let us know if any updates are needed
	based on those comments; if not, they will be removed.
	<title abbrev="6lo Delivery Deadline Time">		<title abbrev="6lo Delivery Deadline Time">
	Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Pow er Wireless Personal Area Networks (6LoWPANs)</title>		Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Pow er Wireless Personal Area Networks (6LoWPANs)</title>
	<seriesInfo name="RFC" value="9034"/>		<seriesInfo name="RFC" value="9034"/>
	<!-- [rfced] We have updated Lijo Thomas's address. Please
	let us know if other changes are necessary.
	Original:
	Lijo Thomas
	C-DAC
	Centre for Development of Advanced Computing (C-DAC), Vellayambalam
	Trivandrum 695033
	India
	Current (The organization abbreviation (C-DAC) is given in the header):
	Lijo Thomas
	Centre for Development of Advanced Computing
	Vellayambalam
	Trivandrum 695033
	India
	<author fullname="Lijo Thomas" initials="L." surname="Thomas">		<author fullname="Lijo Thomas" initials="L." surname="Thomas">
	<organization abbrev="C-DAC">Centre for Development of Advanced Computing< /organization>		<organization abbrev="C-DAC">Centre for Development of Advanced Computing< /organization>
	<address>		<address>
	<postal>		<postal>
	<street>Vellayambalam</street>		<street>Vellayambalam</street>
	<city>Trivandrum</city>		<city>Trivandrum</city>
	<code>695033</code>		<code>695033</code>
	<country>India</country>		<country>India</country>
	</postal>		</postal>
	<email>lijo@cdac.in</email>		<email>lijo@cdac.in</email>
	skipping to change at line 98 ¶		skipping to change at line 66 ¶
	<address>		<address>
	<postal>		<postal>
	<street>Amaravati Campus</street>		<street>Amaravati Campus</street>
	<city>Amaravati, Andhra Pradesh</city>		<city>Amaravati, Andhra Pradesh</city>
	<code>522 502</code>		<code>522 502</code>
	<country>India</country>		<country>India</country>
	</postal>		</postal>
	<email>satishnaidu80@gmail.com</email>		<email>satishnaidu80@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<!-- [rfced] Please review the following changes for accuracy
	of these authors' names.
	Original: <author fullname="Lijo Thomas" initials="" surname="Lijo Thomas">
	Current: <author fullname="Lijo Thomas" initials="L." surname="Thomas">
	Original: <author fullname="S.V.R Anand" initials="" surname="S.V.R.Anand">
	Current: <author fullname="S.V.R. Anand" initials="S.V.R." surname="Anand">
	Original: <author fullname="Malati Hegde" initials="" surname="Malati Hegde">
	Current: <author fullname="Malati Hegde" initials="M." surname="Hegde">
	<!-- [Author Resp] OK. The suggested changes are acceptable.
	<author fullname="S.V.R. Anand" initials="S.V.R." surname="Anand">		<author fullname="S.V.R. Anand" initials="S.V.R." surname="Anand">
	<organization>Indian Institute of Science</organization>		<organization>Indian Institute of Science</organization>
	<address>		<address>
	<postal>		<postal>
	<city>Bangalore</city>		<city>Bangalore</city>
	<code>560012</code>		<code>560012</code>
	<country>India</country>		<country>India</country>
	</postal>		</postal>
	<!-- [Author Resp] email address updated to anandsvr@iisc.ac.in.
	<email>anandsvr@iisc.ac.in</email>		<email>anandsvr@iisc.ac.in</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Malati Hegde" initials="M." surname="Hegde">		<author fullname="Malati Hegde" initials="M." surname="Hegde">
	<organization>Indian Institute of Science</organization>		<organization>Indian Institute of Science</organization>
	<address>		<address>
	<postal>		<postal>
	<city>Bangalore</city>		<city>Bangalore</city>
	<code>560012</code>		<code>560012</code>
	<country>India</country>		<country>India</country>
	</postal>		</postal>
	<!-- [Author Resp] email address updated to malati@iisc.ac.in.
	<email>malati@iisc.ac.in</email>		<email>malati@iisc.ac.in</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Charles E. Perkins" initials="C." surname="Perkins">		<author fullname="Charles E. Perkins" initials="C." surname="Perkins">
	<!-- [Author Resp] Updated affiliation and address
	<organization>Lupin Lodge</organization>		<organization>Lupin Lodge</organization>
	<address>		<address>
	<postal>		<postal>
	<street>20600 Aldercroft Heights Rd.</street>		<street>20600 Aldercroft Heights Rd.</street>
	<city>Los Gatos</city>		<city>Los Gatos</city>
	<region>CA</region>		<region>CA</region>
	<code>95033</code>		<code>95033</code>
	<country>United States of America</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>charliep@computer.org</email>		<email>charliep@computer.org</email>
	skipping to change at line 166 ¶		skipping to change at line 112 ¶
	</author>		</author>
	<date year="2021" month="May" />		<date year="2021" month="May" />
	<area>Internet</area>		<area>Internet</area>
	<workgroup>6lo</workgroup>		<workgroup>6lo</workgroup>
	<keyword>Routing header</keyword>		<keyword>Routing header</keyword>
	<keyword>Timestamp</keyword>		<keyword>Timestamp</keyword>
	<abstract>		<abstract>
	<!-- [rfced] May this sentence be updated as follows? IoT and M2M
	seem redundant here; we suggest choosing one.
	Current:
	The deadline time enables forwarding and scheduling decisions
	for time-critical Internet of Things (IoT) machine-to-machine (M2M)
	applications that operate within time-synchronized networks that agree
	on the meaning of the time representations used for the deadline
	time values.
	Perhaps (and "Internet of Things" can be added to the keywords):
	The deadline time enables forwarding and scheduling decisions
	for time-critical, machine-to-machine applications that operate
	within time-synchronized networks that agree on the time
	representations used for the deadline time values.
	<!-- [Author Resp] M2M applications are not necessarily IP enabled.
	We modified the text slightly.
	<t>		<t>
	This document specifies a new Type for the Elective 6LoWPAN Routing Heade r (6LoRHE)		This document specifies a new Type for the Elective 6LoWPAN Routing Heade r (6LoRHE)
	that contains the deadline time for data packets and is designed for use over		that contains the deadline time for data packets and is designed for use over
	constrained networks. The deadline time enables forwarding and		constrained networks. The deadline time enables forwarding and
	scheduling decisions for time-critical machine-to-machine (M2M)		scheduling decisions for time-critical machine-to-machine (M2M)
	applications running on Internet-enabled devices		applications running on Internet-enabled devices
	within time-synchronized networks that agree		within time-synchronized networks that agree
	on the meaning of the time representations used for the deadline		on the meaning of the time representations used for the deadline
	time values.		time values.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="Intro" numbered="true" toc="default">		<section anchor="Intro" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<!-- [rfced] In the sentence below, would "service guarantees"
	be a better fit than "delay guarantees"?
	Current:
	Low-power and Lossy Networks (LLNs) are likely to be deployed for
	real-time industrial applications requiring end-to-end
	delay guarantees [RFC8578].
	<!-- [Author Resp] The original text to be retained. "service guarantees" is a
	generic term that covers wide range of QoS parameters
	beyond delay guarantees, whereas this document
	specifically considers only "delay guarantees".
	<t>		<t>
	Low-power and Lossy Networks (LLNs) are likely to be deployed for		Low-power and Lossy Networks (LLNs) are likely to be deployed for
	real-time industrial applications requiring end-to-end		real-time industrial applications requiring end-to-end
	delay guarantees <xref target="RFC8578" format="default"/>.		delay guarantees <xref target="RFC8578" format="default"/>.
	A Deterministic Network ("DetNet") typically requires some data packets		A Deterministic Network ("DetNet") typically requires some data packets
	to reach their receivers within strict time bounds.		to reach their receivers within strict time bounds.
	Intermediate nodes use the deadline information to make		Intermediate nodes use the deadline information to make
	appropriate packet forwarding and scheduling decisions to meet the		appropriate packet forwarding and scheduling decisions to meet the
	time bounds.		time bounds.
	</t>		</t>
	<!-- [rfced] Could the following sentence be made more concise?
	Current:
	[RFC8138] specifies the 6LoWPAN Routing Header (6LoRH),
	compression schemes for RPL (Routing Protocol for Low-Power and
	Lossy Networks) routing (source routing) operation [RFC6554],
	header compression of RPL packet information [RFC6553], and
	IP-in-IP encapsulation.
	Perhaps:
	[RFC8138] specifies the 6LoWPAN Routing Header (6LoRH),
	compression schemes for RPL (Routing Protocol for Low-Power and
	Lossy Networks) source routing [RFC6554], header compression of
	RPL packet information [RFC6553], and IP-in-IP encapsulation.
	<!-- [Author Resp] OK. The suggested change is acceptable.
	<t>		<t>
	This document specifies a new Type for the Elective 6LoWPAN Routing		This document specifies a new Type for the Elective 6LoWPAN Routing
	Header (6LoRHE), Deadline-6LoRHE, so that the deadline time (i.e., the ti me of latest		Header (6LoRHE), Deadline-6LoRHE, so that the deadline time (i.e., the ti me of latest
	acceptable delivery) of data		acceptable delivery) of data
	packets can be included within the 6LoRHE.		packets can be included within the 6LoRHE.
	<xref target="RFC8138" format="default"/> specifies the 6LoWPAN Routing H eader (6LoRH),		<xref target="RFC8138" format="default"/> specifies the 6LoWPAN Routing H eader (6LoRH),
	compression schemes for RPL (Routing Protocol for Low-Power and Lossy Net works) source routing <xref target="RFC6554" format="default"/>, header compress ion of RPL packet		compression schemes for RPL (Routing Protocol for Low-Power and Lossy Net works) source routing <xref target="RFC6554" format="default"/>, header compress ion of RPL packet
	information <xref target="RFC6553" format="default"/>, and IP-in-IP encap sulation.		information <xref target="RFC6553" format="default"/>, and IP-in-IP encap sulation.
	This document also specifies the handling of the deadline		This document also specifies the handling of the deadline
	time when packets traverse time-synchronized networks		time when packets traverse time-synchronized networks
	operating in different time zones or distinct reference clocks.		operating in different time zones or distinct reference clocks.
	Time-synchronization techniques are outside the scope of this		Time-synchronization techniques are outside the scope of this
	document. There are a number of standards available for this		document. There are a number of standards available for this
	purpose, including IEEE 1588 <xref target="IEEE.1588.2008" format="defaul t"/>,		purpose, including IEEE 1588 <xref target="IEEE.1588.2008" format="defaul t"/>,
	IEEE 802.1AS <xref target="IEEE.802.1AS.2011" format="default"/>,		IEEE 802.1AS <xref target="IEEE.802.1AS.2011" format="default"/>,
	IEEE 802.15.4-2015 Time-Slotted Channel Hopping (TSCH) <xref target="IEEE .802.15.4" format="default"/>, and more.		IEEE 802.15.4-2015 Time-Slotted Channel Hopping (TSCH) <xref target="IEEE .802.15.4" format="default"/>, and more.
	</t>		</t>
	<!-- [rfced] We have expanded "6lo" here, but perhaps "6LoWPAN" is
	meant?
	Current:
	The Deadline-6LoRHE can be used in any time-synchronized 6lo
	(IPv6 over Networks of Resource-constrained Nodes) network.
	<!-- [Author Resp] OK. The suggested change is acceptable.
	<t>		<t>
	The Deadline-6LoRHE can be used in any time-synchronized 6LoWPAN network.		The Deadline-6LoRHE can be used in any time-synchronized 6LoWPAN network.
	A 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4) network is used to de scribe the implementation of the		A 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4) network is used to de scribe the implementation of the
	Deadline-6LoRHE, but this does not preclude its use in scenarios other		Deadline-6LoRHE, but this does not preclude its use in scenarios other
	than 6TiSCH. For instance, there is a growing interest in using 6LoWPAN		than 6TiSCH. For instance, there is a growing interest in using 6LoWPAN
	over a Bluetooth Low Energy (BLE) mesh network <xref target="I-D.ietf-6lo -blemesh" format="default"/> in		over a Bluetooth Low Energy (BLE) mesh network <xref target="I-D.ietf-6lo -blemesh" format="default"/> in
	industrial IoT (Internet of Things) <xref target="IEEE-BLE-MESH" format=" default"/>. BLE mesh time		industrial IoT (Internet of Things) <xref target="IEEE-BLE-MESH" format=" default"/>. BLE mesh time
	synchronization is being explored by the Bluetooth		synchronization is being explored by the Bluetooth
	community. There are also cases under consideration in Wi-SUN		community. There are also cases under consideration in Wi-SUN
	<xref target="PHY-SPEC" format="default"/> <xref target="Wi-SUN" format=" default"/>.		<xref target="PHY-SPEC" format="default"/> <xref target="Wi-SUN" format=" default"/>.
	skipping to change at line 507 ¶		skipping to change at line 390 ¶
	the field in hex digits, minus one.		the field in hex digits, minus one.
	</dd>		</dd>
	<dt>OTL (3 bits):		<dt>OTL (3 bits):
	</dt>		</dt>
	<dd><t>Length of the OTD field as an unsigned 3-bit integer,		<dd><t>Length of the OTD field as an unsigned 3-bit integer,
	encoding the length of the field in hex digits. If OTL == 0, the OTD field is		encoding the length of the field in hex digits. If OTL == 0, the OTD field is
	not present. The value of OTL <bcp14>MUST NOT</bcp14> exceed the value of DTL		not present. The value of OTL <bcp14>MUST NOT</bcp14> exceed the value of DTL
	plus one.		plus one.
	</t>		</t>
	<!-- [rfced] We have made the following changes in Section 5 to improve
	readability. Please let us know if any other changes are necessary.
	Original:
	* For example, DTL = 0b0000 means the deadline time in the 6LoRHE
	is 1 hex digit (4 bits) long. OTL = 0b111 means the
	origination time is 7 hex digits (28 bits) long.
	Current:
	For example, DTL = 0b0000 means the DT field in the 6LoRHE
	is 1 hex digit (4 bits) long. OTL = 0b111 means the
	OTD field is 7 hex digits (28 bits) long.
	<!-- [Author Resp] OK. The suggested change is acceptable.
	<t>For example, DTL = 0b0000 means the DT field in the		<t>For example, DTL = 0b0000 means the DT field in the
	6LoRHE is 1 hex digit (4 bits) long. OTL = 0b111 means the		6LoRHE is 1 hex digit (4 bits) long. OTL = 0b111 means the
	OTD field is 7 hex digits (28 bits) long.</t>		OTD field is 7 hex digits (28 bits) long.</t>
	</dd>		</dd>
	<dt>BinaryPt (6 bits):		<dt>BinaryPt (6 bits):
	</dt>		</dt>
	<dd><t>If zero, the number of bits of the integer part		<dd><t>If zero, the number of bits of the integer part
	the DT is equal to the number of bits of the fractional part of the DT. If		the DT is equal to the number of bits of the fractional part of the DT. If
	nonzero, the BinaryPt is a signed integer determining the position of the		nonzero, the BinaryPt is a signed integer determining the position of the
	binary point within the value for the DT:</t>		binary point within the value for the DT:</t>
	skipping to change at line 582 ¶		skipping to change at line 450 ¶
	</t>		</t>
	<t indent="3">		<t indent="3">
	DTL = ((N_bits - 1) / 4)		DTL = ((N_bits - 1) / 4)
	</t>		</t>
	<t>		<t>
	The number of bits determined by DTL allows the counting of any number of		The number of bits determined by DTL allows the counting of any number of
	fractional time units in the range of interest determined by DT and the		fractional time units in the range of interest determined by DT and the
	OT. Denote this number of fractional time units to		OT. Denote this number of fractional time units to
	be Epoch_Range(DTL) (i.e., Epoch_Range is a function of DTL):		be Epoch_Range(DTL) (i.e., Epoch_Range is a function of DTL):
	</t>		</t>
	<!-- [rfced] We have formatted equations with superscript and subscript.
	Please review.
	For example (Section 5):
	Epoch_Range(DTL) = (2^(4*(DTL+1))
	Current:
	[same in the text file; please see HTML and PDF]
	For another example (Section 8 of -06):
	t_0 = [current_time - (current_time mod (2^(4*(DTL+1))))]
	Current:
	[same in the text file; please see HTML and PDF]
	<!-- [Author Resp] OK. The suggested change is acceptable.
	<t indent="3">		<t indent="3">
	Epoch_Range(DTL) = 2<sup>4*(DTL+1)</sup>		Epoch_Range(DTL) = 2<sup>4*(DTL+1)</sup>
	</t>		</t>
	<t>		<t>
	Each point of time between OT and DT is represented by a time unit and		Each point of time between OT and DT is represented by a time unit and
	a fractional time unit; in this section, this combined representation		a fractional time unit; in this section, this combined representation
	is called a rational time unit (RTU). 1 RTU measures the smallest		is called a rational time unit (RTU). 1 RTU measures the smallest
	fractional time that can be represented between two points of time		fractional time that can be represented between two points of time
	in the epoch (i.e., within the range of interest).		in the epoch (i.e., within the range of interest).
	</t>		</t>
	<!-- [rfced] We have made the following change to improve readability.
	Please let us know if other changes are necessary.
	Original:
	A low value of
	DTL leads to a small Epoch_Range; if DTL = 0, there will only be 16
	RTUs within the Epoch_Range (DTL) = 16^1 (for any time unit TU).
	Current:
	A low value of
	DTL leads to a small Epoch_Range; if DTL = 0, there will only be 16
	RTUs within the Epoch_Range (i.e., Epoch_Range(DTL) = 16^1) for any
	TU.
	<!-- [Author Resp] OK. The suggested change is acceptable.
	<t>		<t>
	DT - OT cannot exceed 2<sup>4*(DTL+1)</sup> == 16<sup>DTL+1</sup>. A low value of DTL		DT - OT cannot exceed 2<sup>4*(DTL+1)</sup> == 16<sup>DTL+1</sup>. A low value of DTL
	leads to a small Epoch_Range; if DTL = 0, there will only be 16 RTUs		leads to a small Epoch_Range; if DTL = 0, there will only be 16 RTUs
	within the Epoch_Range (i.e., Epoch_Range(DTL) = 16<sup>1</sup>) for any TU. The		within the Epoch_Range (i.e., Epoch_Range(DTL) = 16<sup>1</sup>) for any TU. The
	values that can be represented in the current epoch are in the range		values that can be represented in the current epoch are in the range
	[0, (Epoch_Range(DTL) - 1)].</t>		[0, (Epoch_Range(DTL) - 1)].</t>
	<t>		<t>
	Assuming wraparound does not occur, OT is represented by the value (OT m od Epoch_Range),		Assuming wraparound does not occur, OT is represented by the value (OT m od Epoch_Range),
	and DT is represented by the value (DT mod Epoch_Range). All arithmetic is		and DT is represented by the value (DT mod Epoch_Range). All arithmetic is
	to be performed modulo (Epoch_Range(DTL)), yielding only positive		to be performed modulo (Epoch_Range(DTL)), yielding only positive
	skipping to change at line 845 ¶		skipping to change at line 679 ¶
	</section>		</section>
	</section>		</section>
	<section anchor="iana" numbered="true" toc="default">		<section anchor="iana" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>		<t>
	This document defines a new Elective 6LoWPAN Routing Header Type,		This document defines a new Elective 6LoWPAN Routing Header Type,
	and IANA has assigned the value 7 from the 6LoWPAN		and IANA has assigned the value 7 from the 6LoWPAN
	Dispatch Page 1 number space for this purpose.		Dispatch Page 1 number space for this purpose.
	<!-- [auth] New: Donald E. Eastlake comments -> Modified writings . -->
	</t>		</t>
	<table anchor="iana_reg">		<table anchor="iana_reg">
	<name>Entry in the Elective 6LoWPAN Routing Header Type Registry</name>		<name>Entry in the Elective 6LoWPAN Routing Header Type Registry</name>
	<thead>		<thead>
	<tr>		<tr>
	<th>Value</th>		<th>Value</th>
	<th>Description</th>		<th>Description</th>
	<th>Reference</th>		<th>Reference</th>
	</tr>		</tr>
	skipping to change at line 936 ¶		skipping to change at line 768 ¶
	and BinaryPt == 0, the epoch is (by default) January 1,		and BinaryPt == 0, the epoch is (by default) January 1,
	1900, at 00:00 UTC. The resolution is then 2<sup>-32</sup> seconds,		1900, at 00:00 UTC. The resolution is then 2<sup>-32</sup> seconds,
	which is the maximum possible.		which is the maximum possible.
	This time format wraps around every 2<sup>32</sup> seconds, which is		This time format wraps around every 2<sup>32</sup> seconds, which is
	roughly 136 years.		roughly 136 years.
	</t>		</t>
	<t>		<t>
	For TU = 0b10, the time units are ASNs. The start time is relative,		For TU = 0b10, the time units are ASNs. The start time is relative,
	and updated by a mechanism that is out of scope for this document.		and updated by a mechanism that is out of scope for this document.
	With 10 ms slots, DTL = 15, and BinaryPt == 0, it would take over		With 10 ms slots, DTL = 15, and BinaryPt == 0, it would take over
	a year for the ASN to wrap around.		a year for the ASN to wrap around. Typically, the number of hex
	<!-- [auth] CEP: The number of years is 4294967296 / 3155760000 -->
	Typically, the number of hex
	digits allocated for TU = 0b10 would be less than 15.		digits allocated for TU = 0b10 would be less than 15.
	</t>		</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	The security considerations of		The security considerations of
	<xref target="RFC4944" section="13" sectionFormat="parens" format="defau lt"/>,		<xref target="RFC4944" section="13" sectionFormat="parens" format="defau lt"/>,
	<xref target="RFC6282" section="6" sectionFormat="parens" format="default "/>, and		<xref target="RFC6282" section="6" sectionFormat="parens" format="default "/>, and
	skipping to change at line 978 ¶		skipping to change at line 808 ¶
	</t>		</t>
	<t>		<t>
	The security considerations of DetNet architecture		The security considerations of DetNet architecture
	<xref target="RFC8655" section="5" sectionFormat="parens" format="default "/> mostly apply to		<xref target="RFC8655" section="5" sectionFormat="parens" format="default "/> mostly apply to
	this document as well, as follows. To secure the request and control		this document as well, as follows. To secure the request and control
	of resources allocated for tracks, authentication and authorization		of resources allocated for tracks, authentication and authorization
	can be used for each device and network controller devices.		can be used for each device and network controller devices.
	In the case of distributed control protocols, security is expected		In the case of distributed control protocols, security is expected
	to be provided by the security properties of the protocols in use.		to be provided by the security properties of the protocols in use.
	</t>		</t>
	<!-- [rfced] We're having difficulty parsing the following sentence.
	Does the suggested text convey the intended meaning?
	Current:
	When deadline-bearing flows are identified on a per-flow basis, which
	may provide attackers with additional information about the data
	flows, when compared to networks that do not include per-flow
	identification.
	Perhaps:
	The identification of deadline-bearing flows on a per-flow basis
	may provide attackers with additional information about the data
	flows compared to networks that do not include per-flow
	identification.
	<!-- [Author Resp] OK. The suggested change is acceptable.
	<t>		<t>
	The identification of deadline-bearing flows on a per-flow basis		The identification of deadline-bearing flows on a per-flow basis
	may provide attackers with additional information about the data		may provide attackers with additional information about the data
	flows compared to networks that do not include per-flow		flows compared to networks that do not include per-flow
	identification. The security implications of disclosing that additiona l		identification. The security implications of disclosing that additiona l
	information deserve consideration when implementing this deadline		information deserve consideration when implementing this deadline
	specification.		specification.
	</t>		</t>
	<t>		<t>
	Because of the requirement of precise time synchronization, the		Because of the requirement of precise time synchronization, the
	skipping to change at line 1069 ¶		skipping to change at line 882 ¶
	<title>IEEE Standard for Low-Rate Wireless Networks</title>		<title>IEEE Standard for Low-Rate Wireless Networks</title>
	<author>		<author>
	<organization>IEEE</organization>		<organization>IEEE</organization>
	</author>		</author>
	<date month="April" year="2016"/>		<date month="April" year="2016"/>
	</front>		</front>
	<seriesInfo name="IEEE Standard" value="802.15.4-2015"/>		<seriesInfo name="IEEE Standard" value="802.15.4-2015"/>
	<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>		<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>
	</reference>		</reference>
	<!-- [auth]
	@INPROCEEDINGS{Lee02ieee-1588standard,
	author = {Kang Lee and John Eidson},
	title = {IEEE-1588 Standard for a Precision Clock Synchronization Protocol f
	or Networked Measurement and Control Systems},
	booktitle = {In 34 th Annual Precise Time and Time Interval (PTTI) Meeting},
	year = {2002},
	pages = {98 thru 105}
	}
	-->
	<reference anchor="IEEE.1588.2008">		<reference anchor="IEEE.1588.2008">
	<front>		<front>
	<title>IEEE Standard for a Precision Clock		<title>IEEE Standard for a Precision Clock
	Synchronization		Synchronization
	Protocol for Networked Measurement and Control Systems</title>		Protocol for Networked Measurement and Control Systems</title>
	<author>		<author>
	<organization>IEEE</organization>		<organization>IEEE</organization>
	</author>		</author>
	<date month="July" year="2008"/>		<date month="July" year="2008"/>
	</front>		</front>
	skipping to change at line 1131 ¶		skipping to change at line 934 ¶
	</title>		</title>
	<author surname="IEEE 802.1AS Working Group">		<author surname="IEEE 802.1AS Working Group">
	<organization>IEEE</organization>		<organization>IEEE</organization>
	</author>		</author>
	<date month="March" year="2011"/>		<date month="March" year="2011"/>
	</front>		</front>
	<refcontent>IEEE Std 802.1AS-2011</refcontent>		<refcontent>IEEE Std 802.1AS-2011</refcontent>
	<seriesInfo name="DOI" value="10.1109/IEEESTD.2011.5741898"/>		<seriesInfo name="DOI" value="10.1109/IEEESTD.2011.5741898"/>
	</reference>		</reference>
	<!-- [rfced] For [PHY-SPEC], is this specification available from
	wi-sun.org? If so, please provide the URL for this reference.
	Current:
	[PHY-SPEC] Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March
	2016.
	<!-- [Author Resp] NEW TEXT
	[PHY-SPEC] Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March
	2016. <http://wi-sun.org>
	<reference anchor="PHY-SPEC" target="http://wi-sun.org">		<reference anchor="PHY-SPEC" target="http://wi-sun.org">
	<front>		<front>
	<title>Wi-SUN PHY Specification V1.0</title>		<title>Wi-SUN PHY Specification V1.0</title>
	<author>		<author>
	<organization>Wi-SUN Alliance</organization>		<organization>Wi-SUN Alliance</organization>
	</author>		</author>
	<date month="March" year="2016"/>		<date month="March" year="2016"/>
	</front>		</front>
	</reference>		</reference>
	<!-- [auth]
	<title> Wi-SUN is a wireless communication technology designed for Uti
	lities, Smart Cities and IoT. Wi-SUN is based on various IEEE, IETF, and NSI/TI
	A standards supporting low power and lossy networks.</title>
	-->
	<!-- [auth]
	Hiroshi Harada et al,
	"IEEE 802.15.4g Based Wi-SUN Communication Systems",
	IEICE Transactions on Communications.
	@article{article,
	author = {Harada, Hiroshi and Mizutani, Keiichi and FUJIWARA, Jun and MOCHIZUKI,
	Kentaro and OBATA, Kentaro and Okumura, Ryota},
	year = {2017},
	month = {01},
	pages = {},
	title = {IEEE 802.15.4g based Wi-SUN communication systems},
	volume = {E100.B},
	booktitle = {IEICE Transactions on Communications}
	}
	<author fullname="Luca Leonardi" initials="L." surname="Leonardi">
	-->
	<!-- [Wi-SUN]		<!-- [Wi-SUN]
	URL https://search.ieice.org/bin/summary.php?id=e100-b_7_1032		URL https://search.ieice.org/bin/summary.php?id=e100-b_7_1032
	DOI http://dx.doi.org/10.1587/transcom.2016SCI0002 -->		DOI http://dx.doi.org/10.1587/transcom.2016SCI0002 -->
	<reference anchor="Wi-SUN">		<reference anchor="Wi-SUN">
	<front>		<front>
	<title>IEEE 802.15.4g Based Wi-SUN Communication Systems</title>		<title>IEEE 802.15.4g Based Wi-SUN Communication Systems</title>
	<author fullname="Hiroshi Harada" initials="H." surname="Harada">		<author fullname="Hiroshi Harada" initials="H." surname="Harada">
	<organization> </organization>		<organization> </organization>
	</author>		</author>
End of changes. 20 change blocks.
	207 lines changed or deleted		1 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/