On Nov 18, 2025, at 6:24 AM, Don Fedyk <[email protected]> wrote:
Hi
Thanks My comments inline [Don]. Please let me know if anything is not clear.
Thank you
Don
From: [email protected] <[email protected]>
Sent: Friday, November 14, 2025 4:57 PM
To: [email protected] <[email protected]>; Lou Berger <[email protected]>; Don Fedyk
<[email protected]>
Cc: [email protected] <[email protected]>; [email protected] <[email protected]>;
[email protected] <[email protected]>; [email protected] <[email protected]>;
[email protected]<[email protected]>;[email protected]
<[email protected]>
Subject: Re: AUTH48: RFC-to-be 9892
<draft-ietf-manet-dlep-traffic-classification-17> for your review
Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the source file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on <https://www.rfc-editor.org/search>. -->
Diffserv Code Points
Ethernet Priority Code Points.
2) <!-- [rfced] Section 1: We had trouble following the "and", "or", and
"and/or" relationships in this sentence. If the suggested text is not
correct, please clarify.
Original:
The defined mechanism allows
for flows to be described in a flexible fashion and when combined
with applications such as credit window control, allows credit
windows to be shared across traffic sent to multiple DLEP
destinations and as part of multiple flows, or used exclusively for
traffic sent to a particular destination and/or belonging to a
particular flow.
Suggested:
The defined mechanism allows
for flows to be described in a flexible fashion and, when combined
with applications such as credit window control, allows credit
windows to be (1) shared across traffic sent to multiple DLEP
destinations and as part of multiple flows or (2) used exclusively
for traffic sent to a particular destination and/or belonging to a
particular flow. -->
[Don] Ok.
3) <!-- [rfced] Section 2: Does "based on IP protocol and" (which looks
like "based on Internet Protocol protocol and") mean "based on IP
protocol type and" or something else?
[Don]The IP transport layer protocol. (Examples: TCP, UDP etc.)
Original:
Other types of flow identification, e.g., based on
IP protocol and ports, may be defined in the future via new Sub-Data
Items. -->
[Don] Suggested: NEW
Other types of flow identification, e.g., based on
IP transport layer protocol and ports, may be defined in the future via new
Sub-Data
4) <!-- [rfced] Sections 2.1 and 2.1.1: We do not see a Type field in
RFC 8175, but we see a "Data Item Type" field. May we update as
suggested (per Section 11.3 ("DLEP Generic Data Item") of RFC 8175),
to distinguish this definition from the definitions of Length in
Sections 11.1 ("DLEP Signal Header") and 11.2 ("DLEP Message Header")
of RFC 8175, which do not mention excluding a "Type" field?
Original:
Per [RFC8175] Length is the number of octets in the Data Item,
excluding the Type and Length fields.
...
Copying [RFC8175], Length is a 16-bit unsigned integer that is the
number of octets in the Sub-Data Item, excluding the Type and
Length fields.
Suggested:
Per Section 11.3 of [RFC8175], Length is the number of octets in the
Data Item, excluding the Data Item Type and Length fields.
...
Per Section 11.3 of [RFC8175], Length is a 16-bit unsigned integer
that is the number of octets in the Sub-Data Item, excluding the
Data Item Type and Length fields. -->
[Don]
Yes Data Item Type vs Type.
5) <!-- [rfced] Section 2.1: For ease of the reader, we changed "below"
to "in Section 2.1.1". If this is incorrect, please clarify what
"below" refers to.
Original:
Traffic Classification Sub-Data Item:
Zero or more Traffic Classification Sub-Data Items of the format
defined below MAY be included.
Currently:
Traffic Classification Sub-Data Item:
Zero or more Traffic Classification Sub-Data Items of the format
defined in Section 2.1.1 MAY be included. -->
[Don] Yes
6) <!-- [rfced] Section 2.1.1: We had trouble following the meaning of
"on a per Sub-Data Item Type". Are some words missing?
Original:
The maximum length is limited on a per Sub-Data
Item Type. -->
[Don] NEW
Each Sub-Data Item has its own length field.
This is all that is needed. Each Sub-Data Item is subject
to the maximum length of encompassing the Data Item.
7) <!-- [rfced] Section 2.1.1: We see that the Value field is mentioned
under "Sub-Data Item Type:" but is not otherwise defined. Would you
like to add a list item and explanation of the Value field?
For example, Section 11.3 of RFC 8175 provides this definition of the
Value field:
Value: A field of <Length> octets that contains data specific to a
particular Data Item.
[Don] Value is the same as defined in RFC 8175.
Repeating this definition is fine. Value is only used for the general format.
Original:
~ Value... ~
...
Sub-Data Item Type:
A 16-bit unsigned integer that indicates the type and
corresponding format of the Sub-Data Item's Value field. ... -->
8) <!-- [rfced] Section 2.2: Please clarify "one DSCPs". There appears
to be a singular-versus-plural issue (i.e., perhaps either "one DSCP"
or "one or more DSCPs" would be correct here).
Original:
This
means that the maximum Length base on a FID per DSCP for this TLV
could be 64 times 3 plus one for Num DSCPs plus one DSCPs or 320
octets. -->
[Don] Should be "one DSCP".
9) <!-- [rfced] Section 2.2: Please confirm that there is no IANA registration
associated with the value "0xFFFF" in this sentence.
Original:
The value of 0xFFFF is reserved and MUST NOT be used in
this field.
-->
[Don] Correct this is just a reserved Flow Identifier. No IANA registration.
10) <!-- [rfced] Section 2.2: We changed "is an 8-bit that carries" to
"is 8 bits long and carries". If this update is incorrect, please
clarify the meaning of "an 8-bit that carries".
Original:
DS Field:
Each DS Field is an 8-bit that carries the DSCP field defined in
[RFC2474].
Currently:
DS Field:
Each DS Field is 8 bits long and carries the DSCP field as
defined in [RFC2474]. -->
[Don] Good "8 bits long" is better
r
11) <!-- [rfced] Section 2.3: We had trouble following these sentences.
Does "the next higher integer quantity" refer to a higher integer
quantity that comes next, or does it mean "the next-higher integer
quantity" or "the next-highest integer quantity"? In the equation,
does "divided by 2 or 16 octets" mean "divided by either 2 octets or
16 octets", or something else?
Original:
Note
that as length is in octets and each Priority field is 4 bits, the
additional length is the value carried in the NumPCPs field
divided by two and rounded up to the next higher integer quantity.
This TLV has maximum length of 4 plus 8 divided by 2 or 16 octets. -->
[Don] I think that is bad math. Sorry.
NEW
that as length is in octets and each Priority field is 4 bits, the
total length of this Sub-Data Item is the 2 octets
of Flow Identifer, plus the 2 octets for NumPCPs and VLAN Identifier
plus the number octets for Priority Code Points. The number of
octets for the PCPs is computed by rounding up the NumPCPs
to the nearest even value and dividing by 2.
This TLV has maximum length of 4 plus 8 divided by 2 or 8 octets.
12) <!-- [rfced] Section 2.3: We changed "The maximum number of PCPs 8"
to "The maximum number of PCPs is 8". If this is incorrect, please
clarify the text.
Original:
The maximum number of PCPs 8.
Currently:
The maximum number of PCPs is 8. -->
[Don] This is correct.
13) <!-- [rfced] Section 2.3: Is "either PCP" correct here? Earlier text
indicates
that there can be up to 8 PCPs.
Original:
Note that zero (0) is a valid value for either PCP.
Perhaps:
Note that zero (0) is a valid value for PCP.
[Don] This is correct removing either.
14) <!-- [rfced] We found the following two comments in the XML file.
May we remove them?
First comment:
Both the router and the modem need to support this document,
DLEP Traffic Classification, and DLEP Credit Flow Control,
<xref target="I-D.ietf-manet-dlep-credit-flow-control" format="default"/>.
Second comment:
This document requests the assignment of several values by IANA. All
assignments are to registries defined by <xref target="RFC8175"
format="default"/>. -->
[Don] Yes please remove.
15) <!-- [rfced] Section 4: We had trouble following "some updated
references to external documents listed below" in this paragraph.
It appears that "external documents" is intended to refer to
[BCP195], [IEEE-802.1AE], and [IEEE-8802-1X].
However, we see that [RFC8175] cites [IEEE-802.1X] ("IEEE Standards
for Local and metropolitan area networks-Port-Based Network Access
Control"), but this document cites [IEEE-8802-1X] ("IEEE/ISO/IEC
International Standard-Telecommunications and exchange between
information technology systems-Requirements for local and
metropolitan area networks-Part 1X:Port-based network access
control").
May we update as suggested? If not, please clarify the text.
Original:
The transport layer security mechanisms documented in [RFC8175], with
some updated references to external documents listed below, can be
applied to this document.
Suggested:
The transport layer security mechanisms documented in [RFC8175],
along with the latest versions of [BCP195], [IEEE-802.1AE], and
[IEEE-8802-1X] at the time of this writing, can be applied to this
document. -->
[Don] Yes accepted Suggested but the IEEE-8802-1X is the ISO version of
IEEE-802.1X
https://ieeexplore.ieee.org/document/9650828
I think we should use the IEEE version change IEEE-8802-1X to IEEE-802.1X.
16) <!-- [rfced] Below are some specific questions relating to IANA text in
Section 5.2 of the document.
a) FYI - To improve clarity, we added a new table (current Table 2) to show
the registration policies and adjusted the original table (current Table 3) to
show only the initial contents of the registry.
[Don] Good.
b) In the current Table 3, which shows the initial values of the new registry,
[RFC2474] and [IEEE8021Q] are listed as references. Should this document be
listed as a reference instead of or in addition to [RFC2474] and [IEEE8021Q]?
It seems that this document defines the Diffserv Traffic Classification in
Section 2.2 and the Ethernet Traffic Classification in Section 2.3. Please
review and let us know if any updates are needed. If needed, we will ask IANA
to update the "Traffic Classification Sub-Data Item Type Values" registry
prior to publication.
[Don] The table referencing [RFC2474] and [IEEE8021Q] is correct for Type code
1 and Type code 2 respectively.
No need to add this document as reference - it is there for the whole table.
Link to registry:
https://www.iana.org/assignments/dlep-parameters/dlep-parameters.xhtml#traffic-classification-sub-data-item-type-values>
c) Related to the question above, the first two sentences below do not
directly indicate that this document defines the two new Sub-Data Items in
Sections 2.2 and 2.3, but the third sentence does. Should any of these
sentences be updated?
Original:
This document also introduces DLEP Sub-Data Items, and Sub-Data Items are
defined to support DiffServ and Ethernet traffic classification.
...
This document defines support for traffic classification using a
single new Data Item in Section 2.1 for general support and two new
Sub-Data Items are defined to support identification of flows based
on DSCPs and PCPs.
[Don] This is good.
...
This document defines traffic classification based on a DLEP
destination and flows identified by either DiffServ [RFC2475]
Differentiated Services Codepoints (DSCPs) or IEEE 802.1Q [IEEE8021Q]
Ethernet Priority Code Points (PCPs).
Perhaps (updates to first two sentences to indicate that this document defines
the two Sub-Data Items; not changes to third sentence):
This document also introduces DLEP Sub-Data Items and defines two new
Sub-Data Items to support Diffserv and Ethernet traffic classification.
...
This document defines support for traffic classification using a
single new Data Item (see Section 2.1) for general support and defines two new
Sub-Data Items to support identification of flows based
on DSCPs and PCPs (see Sections 2.2 and 2.3).
[Don] This is good.
...
This document defines traffic classification based on a DLEP
destination and flows identified by either Diffserv [RFC2475]
Differentiated Services Codepoints (DSCPs) or IEEE 802.1Q [IEEE8021Q]
Ethernet Priority Code Points (PCPs).
d) May we combine the first paragraph after the current Table 3 and the last
paragraph of Section 5.2 as follows? Also, would it be helpful to separate the
text after the current Table 3 into a new section so future documents can
easily refer to the guidance? Last, we suggest including "Specification
Required"
in this text as the guidance only applies to registrations with that policy.
Original:
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the
Traffic Classification Sub-Data Item Type Values registry for the
DLEP protocol, in accordance with BCP 26 and [RFC8126].
...
To simplify future registrations, it is recommended that this
guidance serves as a standard reference for all DLEP-related
registries. Future specifications may include a header note pointing
to this guidance document.
Perhaps:
5.3. Registration Guidance
This section provides guidance for registrations in the "Traffic
Classification Sub-Data Item Type Values" registry. To simplify future
registrations in DLEP-related registries, it is recommended that the
guidance in this section apply to all registries within the "Dynamic Link
Exchange Protocol (DLEP) Parameters" registry group that use the
"Specification Required" policy [RFC8126]. Future specifications
may point to the guidance in this document.
[Don] This update is good.
e) Please clarify "two specific registries" here. Is the intent "two specific
entries" (i.e., 1 for Diffserv Traffic Classification and 2 for Ethernet
Traffic Classification)?
Original (the previous sentence included for context):
This registry encompasses packet traffic classification, where
standard packet header identifiers in packets or data frames indicate
Quality of Service (QoS) treatment. It includes two specific
registries for widely recognized identifiers used in QoS management
for IP and Ethernet networks.
Perhaps:
This registry encompasses packet traffic classification, where
standard packet header identifiers in packets or data frames indicate
Quality of Service (QoS) treatment. It includes two specific
entries for widely recognized identifiers used in QoS management
for IP and Ethernet networks.
[Don] This is good.
-->
17) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed. Updates of this nature
typically result in more precise language, which is helpful for
readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->
18) <!-- [rfced] Please let us know if any changes are needed for the
following:
a) The following term was used inconsistently in this document.
We chose to use the latter form. Please let us know any objections.
data item (1 instance) / Data Item (e.g., "the data item",
"the Data Item") (per the rest of this document and per this
group (cluster) of documents)
[Don] Good thanks.
b) The following terms appear to be used inconsistently in this
document. Please let us know which form is preferred.
priority field / Priority field / Priority Field
(e.g., "priority fields", "Priority fields",
"Each Priority Field is", "each Priority field is")
Item Types / Item types (e.g., "Traffic Classification Sub-Data Item
Types", "Traffic Classification Sub-Data Item types")
Num PCPs (1 instance) / NumPCPs (4 instances)
(We also see "Num DSCPs" and "Num SDIs".)
the individual Sub-Data Item / the individual Sub-Data Items -->
[Don] Good Thanks.
Thank you.
Lynne Bartholomew and Rebecca VanRheenen
RFC Production Center
On Nov 14, 2025, at 1:54 PM, [email protected] wrote:
*****IMPORTANT*****
Updated 2025/11/14
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9892.xml
https://www.rfc-editor.org/authors/rfc9892.html
https://www.rfc-editor.org/authors/rfc9892.pdf
https://www.rfc-editor.org/authors/rfc9892.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9892-diff.html
https://www.rfc-editor.org/authors/rfc9892-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9892-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9892
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9892 (draft-ietf-manet-dlep-traffic-classification-17)
Title : Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item
Author(s) : B. Cheng, D. Wiggins, L. Berger, D. Fedyk, Ed.
WG Chair(s) : Don Fedyk, Ronald in 't Velt, Donald E. Eastlake 3rd
Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde
