Skip to main content

Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item
draft-ietf-manet-dlep-traffic-classification-13

Revision differences

Document history

Date Rev. By Action
2025-02-13
13 (System) Changed action holders to Lou Berger, Bow-Nan Cheng, Don Fedyk, David Wiggins (IESG state changed)
2025-02-13
13 Jim Guichard IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2025-02-07
13 Carlos Pignataro Closed request for Telechat review by OPSDIR with state 'Team Will not Review Version'
2025-02-07
13 Carlos Pignataro Assignment of request for Telechat review by OPSDIR to Tina Tsou was marked no-response
2025-02-06
13 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2025-02-05
13 Murray Kucherawy
[Ballot discuss]
Section 5.2 declares a new registry, a range of which is controlled by "Specification Required" rules.  RFC 8126, Section 4.6, says:

  …
[Ballot discuss]
Section 5.2 declares a new registry, a range of which is controlled by "Specification Required" rules.  RFC 8126, Section 4.6, says:

  As with Expert Review (Section 4.5), clear guidance to the designated
  expert should be provided when defining the registry, and thorough
  understanding of Section 5 is important.

Is no such advice in order here?

Also, as Roman observed: Should there be a "Reference" column added to this registry?
2025-02-05
13 Murray Kucherawy Ballot discuss text updated for Murray Kucherawy
2025-02-05
13 Murray Kucherawy
[Ballot discuss]
Section 5.2 declares a new registry, a range of which is controlled by "Specification Required" rules.  RFC 8126, Section 4.6, says:

  …
[Ballot discuss]
Section 5.2 declares a new registry, a range of which is controlled by "Specification Required" rules.  RFC 8126, Section 4.6, says:

  As with Expert Review (Section 4.5), clear guidance to the designated
  expert should be provided when defining the registry, and thorough
  understanding of Section 5 is important.

Is no such advice in order here?
2025-02-05
13 Murray Kucherawy
[Ballot comment]
Section 5 says:

  This document requests the assignment of several values by IANA. All assignments are to registries defined by [RFC8175 …
[Ballot comment]
Section 5 says:

  This document requests the assignment of several values by IANA. All assignments are to registries defined by [RFC8175].

But it only creates one registration to an extant registry, right?  I would just delete this text.

Also about Section 5.2: The presentation here is a little confusing.  One of these rows defines a range available for reservation and the rules for such registrations, while all other rows are actual registrations.  It might be helpful to take the "Specification Required" row out and turn it into prose.

A nit about Section 4:

* "... introduces finer grain flow ..." -- s/grain/grained/

...and one in Appendix A:

* "... We morn his passing ..." -- s/morn/mourn/
2025-02-05
13 Murray Kucherawy [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy
2025-02-05
13 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2025-02-05
13 Orie Steele [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele
2025-02-05
13 Zaheduzzaman Sarker
[Ballot comment]
Thanks to David Black for really good review of the document that has lead to more clarity on the classification.

I am supporting …
[Ballot comment]
Thanks to David Black for really good review of the document that has lead to more clarity on the classification.

I am supporting Romans's discuss. This specification refers to RFC8126 but does not follows it.
2025-02-05
13 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2025-02-04
13 Gunter Van de Velde
[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-manet-dlep-traffic-classification-13

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-manet-dlep-traffic-classification-13.txt

# …
[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-manet-dlep-traffic-classification-13

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-manet-dlep-traffic-classification-13.txt

# Many thanks to Darren Dukes for the RTGDIR review follow up.

# Detailed Review
# ===============

315                   0  1  2  3  4  5  6  7
316                 +---+---+---+---+---+---+---+---+
317                 |        DSCP          |  MBZ  |
318                 +---+---+---+---+---+---+---+---+
319
320                   DSCP: Differentiated Services Codepoint
321                   MBZ:  MUST be zero

GV> This reads odd. Why the uppercase "MUST" and then all lower case "be zero" instead of "Be Zero". What most the device do when MBZ happens to be not zero? Same MBZ observation applies to line402 of the document. What about the following:

"
DSCP: Differentiated Services Codepoint (RFC 2474).
MBZ: Must Be Zero MUST be set to zero when transmitted. Receivers MUST ignore this field upon reception.
"
2025-02-04
13 Gunter Van de Velde [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde
2025-02-03
13 Mahesh Jethanandani
[Ballot discuss]
"Abstract", paragraph 0
>    This document defines a new Data Item for the Dynamic Link Exchange
>    Protocol (DLEP) to support …
[Ballot discuss]
"Abstract", paragraph 0
>    This document defines a new Data Item for the Dynamic Link Exchange
>    Protocol (DLEP) to support traffic classification.  Traffic
>    classification information identifies traffic flows based on frame/
>    packet content such as destination address.  The Data Item is defined
>    in an extensible and reusable fashion.  Its use will be mandated in
>    other documents defining specific DLEP extensions.  This document
>    also introduces DLEP Sub-Data Items, and Sub-Data Items are defined
>    to support DiffServ and Ethernet traffic classification.

I would note that both RTGDIR and TSVART's early review of the document had issues with the document. However, I did not see a Last Call or Telechat review of the same. But this could easily have been missed because there are four documents, and some of these issues could have been debated as part of the other documents. Even otherwise, there is no e-mail thread that I could find that discusses how the issues were resolved. In either case, it would be nice to know from the Shepherd that the issues raised by David Black were addressed, and more specifically how they were addressed.
2025-02-03
13 Mahesh Jethanandani
[Ballot comment]
-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or …
[Ballot comment]
-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.


Section 2, paragraph 2
> fic Classification Data Item This sections defines the Traffic Classification
>                                  ^^^^^^^^
Consider using the singular form after the singular determiner "This".

Section 6.2, paragraph 1
> ritical to the acceptance of DLEP. We morn his passing on November 23, 2023.
>                                    ^^^^^^^
s/morn/mourn/
2025-02-03
13 Mahesh Jethanandani [Ballot Position Update] New position, Discuss, has been recorded for Mahesh Jethanandani
2025-02-03
13 Roman Danyliw
[Ballot discuss]
** Section 5.2 defines a registry which includes code points with an allocation policy of Specification Required.  Implicit in policy is the review …
[Ballot discuss]
** Section 5.2 defines a registry which includes code points with an allocation policy of Specification Required.  Implicit in policy is the review of a designated expert (DE).  However, this document does not provide guidance to the DE on what to approve.  See Sections 4.5 and 4.6 of RFC8126.
2025-02-03
13 Roman Danyliw
[Ballot comment]
** Section 2.  Editorial.
  The Traffic Classification Data Item represents a list of flows that
  may be used at the same …
[Ballot comment]
** Section 2.  Editorial.
  The Traffic Classification Data Item represents a list of flows that
  may be used at the same time for traffic sent from a router to a
  modem.

"Used at the same time" to do what?

** Section 2.1
  When an extension requires use of this
  Data Item the Traffic Classification Data Item SHOULD be included by
  a modem in any Session Initialization Response Message

-- Are “Data Item” and “Traffic Classification Data Item” the same data item?

-- What is the alternative to using his Data Item in a Session Initialization Response Message?

** Section 5.2.  Should the new registry defined in this section have an additional column which is a reference to a document which provides further details?
2025-02-03
13 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2025-02-03
13 Paul Wouters
[Ballot discuss]
I support Deb's DISCUSS


Section 2.3.1

It states "After successful validation, the receiver MUST ...", but it does not state what the receiver …
[Ballot discuss]
I support Deb's DISCUSS


Section 2.3.1

It states "After successful validation, the receiver MUST ...", but it does not state what the receiver should do when it fails validation. As the protocol seems to have a window size of 1, my guess is that it MUST sent an error message of some kind so that the other peer can send another/new/different DLEP messages again?
2025-02-03
13 Paul Wouters
[Ballot comment]
The figure in Section 2.1 makes it appear that a Traffic Classification Sub-Data Item is 32 bits in size, but Section 2.1.1 shows …
[Ballot comment]
The figure in Section 2.1 makes it appear that a Traffic Classification Sub-Data Item is 32 bits in size, but Section 2.1.1 shows it is variable length of at least 64 bits (again using to to me unknown convention of ":" instead of "~"

A field name of "Must be two" is confusing. Normally we write the real name with the value,eg  foo (2)
2025-02-03
13 Paul Wouters [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters
2025-02-02
13 Deb Cooley
[Ballot discuss]
Section 4:  The transport layer security recommendations in RFC8175 are largely outdated (it predates TLS1.3, RFC8446).  It references RFC 7525 (which has …
[Ballot discuss]
Section 4:  The transport layer security recommendations in RFC8175 are largely outdated (it predates TLS1.3, RFC8446).  It references RFC 7525 (which has been obsoleted by RFC 9325) and RFC 5487 which may/may not be relevant today (i.e. it is very old - predating both TLS 1.2, RFC 5746, and TLS1.3).  In addition, the link layer security recommendations are similarily outdated.  Please address this issue in this draft's Security Considerations. 

Section 4:  I would also like to see documentation of the risk of 'leaking data' into unused (and unvalidated by the receiver) protocol fields.
2025-02-02
13 Deb Cooley
[Ballot comment]
Section 2.1:  Data item type field is 16 bits? Please clarify.

Section 2.1:  Is there an upper limit to the length of the …
[Ballot comment]
Section 2.1:  Data item type field is 16 bits? Please clarify.

Section 2.1:  Is there an upper limit to the length of the length field (in Section 2.1.1 the length field for the sub data item is a 16 bit unsigned integer)?  If not, why not? 

Section 2.1:  Reserved field, why doesn't the router have to validate this (it allows a covert channel if not validated)? 

Section 2.2:  NumDSCPs:  How does it work to have a wildcard in this field?  Does the entity creating the item not know how many DSCPs there are?  Seems odd.  Also seems like a way for a third party to add/remove DSCPs.

Section 2.3:  Length:  Same comment as Section 2.1.  Is there a total bit length for the field?  If not, why not?

Section 2.3:  NumPCPs:  Same comment as Section 2.2 (NumDSCPs).

Section 2.3:  Pad:  Same comment as Section 2.1 (reserved field).

Section 3:  What is the expected behaviour when either the router or modem don't understand the extensions?  Is it treated like a failure?  Or are they ignored?  Is there a transition strategy where some parts of the system have been updated but others have not?
2025-02-02
13 Deb Cooley [Ballot Position Update] New position, Discuss, has been recorded for Deb Cooley
2025-01-31
13 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2025-01-31
13 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2025-01-19
13 Carlos Pignataro Request for Telechat review by OPSDIR is assigned to Tina Tsou
2025-01-17
13 Shawn Emery Request for Telechat review by SECDIR Completed: Ready. Reviewer: Shawn Emery. Sent review to list. Submission of review completed at an earlier date.
2025-01-17
13 Shawn Emery Request for Telechat review by SECDIR Completed: Ready. Reviewer: Shawn Emery.
2025-01-16
13 Tero Kivinen Request for Telechat review by SECDIR is assigned to Shawn Emery
2025-01-08
13 Jenny Bui Placed on agenda for telechat - 2025-02-06
2025-01-08
13 Jim Guichard Ballot has been issued
2025-01-08
13 Jim Guichard [Ballot Position Update] New position, Yes, has been recorded for Jim Guichard
2025-01-08
13 Jim Guichard Created "Approve" ballot
2025-01-08
13 Jim Guichard IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2025-01-08
13 Jim Guichard Ballot writeup was changed
2024-11-19
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-11-19
13 Don Fedyk New version available: draft-ietf-manet-dlep-traffic-classification-13.txt
2024-11-19
13 (System) New version approved
2024-11-19
13 (System) Request for posting confirmation emailed to previous authors: Bow-Nan Cheng , David Wiggins , Lou Berger , manet-chairs@ietf.org
2024-11-19
13 Don Fedyk Uploaded new revision
2024-08-12
12 Stewart Bryant Request for Last Call review by GENART Completed: Ready. Reviewer: Stewart Bryant. Sent review to list.
2024-08-10
12 Shawn Emery Request for Early review by SECDIR Completed: Has Nits. Reviewer: Shawn Emery. Sent review to list. Submission of review completed at an earlier date.
2024-08-10
12 Shawn Emery Request for Early review by SECDIR Completed: Has Nits. Reviewer: Shawn Emery.
2024-08-08
12 David Dong IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2024-08-08
12 David Dong IANA Experts State changed to Expert Reviews OK from Reviews assigned
2024-08-06
12 Darren Dukes Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Darren Dukes. Sent review to list.
2024-08-06
12 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-08-05
12 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2024-08-05
12 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-manet-dlep-traffic-classification-12. If any part of this review is inaccurate, please let us know.

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

IANA has completed its review of draft-ietf-manet-dlep-traffic-classification-12. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the Data Item Type Values registry on the Dynamic Link Exchange Protocol (DLEP) Parameters registry page located at:

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

a single new data item type value will be registered from the Specification Required range as follows:

Type Code: [ TBD-at-Registration ]
Description: Traffic Classification
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, a new registry will be created called the Traffic Classification Sub-Data Item Type Values registry. The new registry will be located in the Dynamic Link Exchange Protocol (DLEP) Parameters registry group located at:

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

The registration policy for the new registry, as defined by RFC 8126 is:

0 - Reserved
1 - 65407 - Specification Required
65408 - 65534 - Private Use
65535 - Reserved

There are initial registrations in the new registry as follows:

Type Code Description Reference
0 Reserved [ RFC-to-be ]
1 DiffServ Traffic Classification [ RFC-to-be ]
2 Ethernet Traffic Classification [ RFC-to-be ]
3-65534 Unassigned
65535 Reserved [ RFC-to-be ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2024-07-30
12 Carlos Pignataro Request for Early review by OPSDIR Completed: Has Issues. Reviewer: Tina Tsou. Sent review to list.
2024-07-26
12 Tero Kivinen Request for Early review by SECDIR is assigned to Shawn Emery
2024-07-25
12 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2024-07-23
12 David Dong IANA Experts State changed to Reviews assigned
2024-07-23
12 Cindy Morgan IANA Review state changed to IANA - Review Needed
2024-07-23
12 Cindy Morgan
The following Last Call announcement was sent out (ends 2024-08-06):

From: The IESG
To: IETF-Announce
CC: draft-ietf-manet-dlep-traffic-classification@ietf.org, james.n.guichard@futurewei.com, manet-chairs@ietf.org, manet@ietf.org, ronald.intvelt@tno.nl …
The following Last Call announcement was sent out (ends 2024-08-06):

From: The IESG
To: IETF-Announce
CC: draft-ietf-manet-dlep-traffic-classification@ietf.org, james.n.guichard@futurewei.com, manet-chairs@ietf.org, manet@ietf.org, ronald.intvelt@tno.nl
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DLEP Traffic Classification Data Item) to Proposed Standard


The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to
consider the following document: - 'DLEP Traffic Classification Data Item'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-08-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a new Dynamic Link Exchange Protocol (DLEP)
  Data Item that is used to support traffic classification.  Traffic
  classification information is used to identify traffic flows based on
  frame/packet content such as destination address.  The Data Item is
  defined in an extensible and reusable fashion.  Its use will be
  mandated in other documents defining specific DLEP extensions.  This
  document also introduces DLEP Sub-Data Items, and Sub-Data Items are
  defined to support DiffServ and Ethernet traffic classification.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-traffic-classification/



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




2024-07-23
12 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2024-07-23
12 Daniam Henriques Request for Early review by RTGDIR is assigned to Darren Dukes
2024-07-23
12 Carlos Pignataro Request for Early review by OPSDIR is assigned to Tina Tsou
2024-07-23
12 Jim Guichard Requested Early review by RTGDIR
2024-07-23
12 Jim Guichard Requested Early review by OPSDIR
2024-07-23
12 Jim Guichard Requested Early review by SECDIR
2024-07-23
12 Jim Guichard Last call was requested
2024-07-23
12 Jim Guichard Last call announcement was generated
2024-07-23
12 Jim Guichard Ballot approval text was generated
2024-07-23
12 Jim Guichard Ballot writeup was generated
2024-07-23
12 Jim Guichard IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2024-07-23
12 Jim Guichard Changed action holders to Jim Guichard
2024-07-23
12 (System) Changed action holders to Stan Ratliff, Jim Guichard (IESG state changed)
2024-07-23
12 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-07-23
12 Lou Berger New version available: draft-ietf-manet-dlep-traffic-classification-12.txt
2024-07-23
12 Lou Berger New version accepted (logged-in submitter: Lou Berger)
2024-07-23
12 Lou Berger Uploaded new revision
2024-07-11
11 (System) Changed action holders to Lou Berger, Stan Ratliff, Bow-Nan Cheng (IESG state changed)
2024-07-11
11 Jim Guichard IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2024-07-11
11 Jim Guichard AD review posted === https://mailarchive.ietf.org/arch/msg/manet/qTn9JAeIcWtuPeWsJ5Pv_pv1QJw/ ===
2024-07-10
11 (System) Changed action holders to Jim Guichard (IESG state changed)
2024-07-10
11 Jim Guichard IESG state changed to AD Evaluation from AD Evaluation::Revised I-D Needed
2024-06-19
11 (System) Changed action holders to Jim Guichard, Bow-Nan Cheng, Stan Ratliff, Lou Berger (IESG state changed)
2024-06-19
11 Jim Guichard IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2024-05-10
11 Ronald in 't Velt
 
Shepherd writeup on draft-ietf-manet-dlep-traffic-classification

Document History

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being …
 
Shepherd writeup on draft-ietf-manet-dlep-traffic-classification

Document History

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being silent, or did it reach broad
agreement?

  This document is part of a cluster of four which together specify a
  credit-base flow control extension to the Dynamic Link Exchange Protocol
  (DLEP, RFC8175). The companion documents are:
  - draft-ietf-manet-dlep-credit-flow-control,
  - draft-ietf-manet-dlep-da-credit-extension,
  - draft-ietf-manet-dlep-ether-credit-extension.
  There was strong consensus early on in the WG that it would be beneficial
  to have a Flow Control extension to DLEP that is more sophisticated than
  the Control-Plane-based Pause approach specified in RFC 8651. Most of the
  remaining discussion revolved around how to best structure and modularize
  the specification. (See answer to question 2).

2. Was there controversy about particular points, or were there decisions
where the consensus was particularly rough?

  There was discussion (rather than controversy) on how the functional
  elements of credit-based flow control should be distributed over separate
  documents. Between IETF 100 and IETF 103, the specification went from
  being contained in a single document to being broken down into four
  separate ones. Traffic Classification was split off, because it is
  considered a generic mechanism that can be useful for other purposes
  than flow control alone. draft-ietf-manet-dlep-da-credit-extension
  was the original monolithic specification, that was reduced to merely
  defining the Extension Type value after Message and Data Item definitions
  were moved to draft-ietf-manet-dlep-credit-flow-control and
  draft-ietf-manet-dlep-traffic-classification. Using IEEE 802.1Q fields of
  Ethernet frames instead of DS fields in IP packets as an alternative way
  of distinguishing flows made it necessary to define an additional
  Extension Type value in draft-ietf-manet-dlep-ether-credit-extension. The
  motivation for having both Extension Type values in different documents is
  to allow implementers of DLEP to specify exactly which extensions they
  support by means of RFC numbers. The TSV ART reviewer commented that
  draft-ietf-manet-dlep-da-credit-extension was very light on content and
  strongly suggested to merge this document into
  draft-ietf-manet-dlep-traffic-classification. (At the time,
  draft-ietf-manet-dlep-ether-credit-extension had not yet been subjected to
  TSV ART early review). The WG considered this suggestion around IETF 113
  and again at IETF 115, but decided that reasons for the four-way split
  were still valid and to therefore stick to that structure.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

4. For protocol documents, are there existing implementations of the
contents of the document? Have a significant number of potential
implementers indicated plans to implement? Are any existing
implementations reported somewhere, either in the document itself (as
RFC 7942 recommends) or elsewhere (where)?

  This document's shepherd has no knowledge of existing implementations. Since
  this document (and its companions) describes an extension to DLEP (RFC 8175),
  a starting point for an implementation could be the open source DLEP
  library, to which David Wiggins (one of the authors of this
  document) is the main contributor: https://github.com/mit-ll/LL-DLEP .
  There has been some discussion on the mailing list on how to implement the
  router side of credit-based flow control (in Linux, specifically):
  https://mailarchive.ietf.org/arch/msg/manet/MPTLhKgaljq1BRdjE_dEk9x1YhI/

Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

  A TSV ART Early Review took place. Main concern was the split in three
  different documents. (See answer to question 2). Some lesser issue have
  been resolved.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  A RtgDir review still needs to take place. None of the other expert
  reviews mentioned (MIB Doctor, etc.) apply to this document.

7. If the document contains a YANG module, has the final version of
the module been checked with any of the recommended validation tools
for syntax and formatting validation? If there are any resulting
errors or warnings, what is the justification for not fixing them at
this time? Does the YANG module comply with the Network Management
Datastore Architecture (NMDA) as specified in RFC 8342?

  This document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate
sections of the final version of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL,
etc.

  This document contains no formal language. The shepherd has
  carefully reviewed this draft, as documented at
https://mailarchive.ietf.org/arch/msg/manet/OmQhM-zMGU2PEJNgTtGLNcsBnQM/
  These comments have been resolved.

Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion
that this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled lists of common issues that
their reviewers encounter. Do any such issues remain that would merit
specific attention from subsequent reviews?

  Shepherd has not identified any such issues.

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this
intent?

  Standards Track as indicated on the title page. This document and its
  companion documents specify a more sophisticated and fine-grained flow
  control mechanism than the one defined in RFC 8651 (which is a Proposed
  Standard). Moreover, credit-based flow control is an explicit work item
  on the WG's charter, whereas Control-Plane-Based Pause (RFC 8651) was
  not (and was criticized for that reason during IESG review).

12. Has the interested community confirmed that any and all
appropriate IPR disclosures required by BCP 78 and BCP 79 have been
filed? If not, explain why. If yes, summarize any discussion and
conclusion regarding the intellectual property rights (IPR)
disclosures, including links to relevant emails.

  See IPR statements at
https://mailarchive.ietf.org/arch/msg/manet/9NNWOL7odZofBoZ4q9Uwya1B6oI/
https://mailarchive.ietf.org/arch/msg/manet/itiAXwQ7dQaerG43rTH6SXNiDdY/
https://mailarchive.ietf.org/arch/msg/manet/J9EUsx1QPPUz6CwnRu4uEAwa634/

  It appears that no IPR is being claimed.

13. Has each Author or Contributor confirmed their willingness to be
listed as such? If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  Implicitly as per question 12 above. Sadly, David Wiggins passed away
  in 2023.

14. Identify any remaining I-D nits in this document. (See the idnits
tool and the checkbox items found in Guidelines to Authors of
Internet-Drafts). Simply running the idnits tool is not enough; please
review the entire guidelines document.

  The document adheres to the naming convention for Internet-Drafts.
  The document contains all the required sections. 

15. Should any informative references be normative or vice-versa?

  The shepherd believes the references to be categorized correctly.

16. List any normative references that are not freely available to
anyone. Did the community have sufficient access to review any such
normative references?

  All normative references are to RFCs.

17. Are there any normative downward references (see RFC 3967, BCP
97
)? If so, list them.

  There are no downward normative references.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If they exist, what
is the plan for their completion?

  There are no such normative references.

19. Will publication of this document change the status of any
existing RFCs? If so, does the Datatracker metadata correctly reflect
this and are those RFCs listed on the title page, in the abstract, and
discussed in the introduction? If not, explain why and point to the
part of the document where the relationship of this document to these
other RFCs is discussed.

  This document (together with its companion documents, see answer to
  question 1) defines an extension to RFC 8175, in the same way as
  RFC 8629, RFC 8651, RFC 8703 and RFC 8757 do, but it does not change the
  status of RFC 8175 or any other RFC.

20. Describe the document shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document. Confirm that all aspects of the document requiring IANA
assignments are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that each newly created IANA registry
specifies its initial contents, allocations procedures, and a
reasonable name (see RFC 8126).

  This document adds one entry to the existing DLEP Data Item
  Registry named "Data Item Type Values". This addition is in the range
  with a "Specification Required" policy. This document requests the
  creation of a new DLEP IANA registry, named "Traffic Classification
  Sub-Data Item Type Values" and provides three initial registry values.
  The requested actions in the IANA Considerations Section (section 5)
  have been found to be consistent with the body of the document.

21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear? Please include suggestions of designated experts, if
appropriate.

  The new IANA registry that this document creates (see answer to question
  20) does not contain value ranges for future allocation to which the
  Designated Expert Review policy applies.

2024-05-10
11 Ronald in 't Velt IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2024-05-10
11 Ronald in 't Velt IESG state changed to Publication Requested from I-D Exists
2024-05-10
11 (System) Changed action holders to Jim Guichard (IESG state changed)
2024-05-10
11 Ronald in 't Velt Responsible AD changed to Jim Guichard
2024-05-10
11 Ronald in 't Velt Document is now in IESG state Publication Requested
2024-05-10
11 Ronald in 't Velt Tag Awaiting Expert Review/Resolution of Issues Raised cleared.
2024-05-10
11 Ronald in 't Velt
 
Shepherd writeup on draft-ietf-manet-dlep-traffic-classification

Document History

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being …
 
Shepherd writeup on draft-ietf-manet-dlep-traffic-classification

Document History

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being silent, or did it reach broad
agreement?

  This document is part of a cluster of four which together specify a
  credit-base flow control extension to the Dynamic Link Exchange Protocol
  (DLEP, RFC8175). The companion documents are:
  - draft-ietf-manet-dlep-credit-flow-control,
  - draft-ietf-manet-dlep-da-credit-extension,
  - draft-ietf-manet-dlep-ether-credit-extension.
  There was strong consensus early on in the WG that it would be beneficial
  to have a Flow Control extension to DLEP that is more sophisticated than
  the Control-Plane-based Pause approach specified in RFC 8651. Most of the
  remaining discussion revolved around how to best structure and modularize
  the specification. (See answer to question 2).

2. Was there controversy about particular points, or were there decisions
where the consensus was particularly rough?

  There was discussion (rather than controversy) on how the functional
  elements of credit-based flow control should be distributed over separate
  documents. Between IETF 100 and IETF 103, the specification went from
  being contained in a single document to being broken down into four
  separate ones. Traffic Classification was split off, because it is
  considered a generic mechanism that can be useful for other purposes
  than flow control alone. draft-ietf-manet-dlep-da-credit-extension
  was the original monolithic specification, that was reduced to merely
  defining the Extension Type value after Message and Data Item definitions
  were moved to draft-ietf-manet-dlep-credit-flow-control and
  draft-ietf-manet-dlep-traffic-classification. Using IEEE 802.1Q fields of
  Ethernet frames instead of DS fields in IP packets as an alternative way
  of distinguishing flows made it necessary to define an additional
  Extension Type value in draft-ietf-manet-dlep-ether-credit-extension. The
  motivation for having both Extension Type values in different documents is
  to allow implementers of DLEP to specify exactly which extensions they
  support by means of RFC numbers. The TSV ART reviewer commented that
  draft-ietf-manet-dlep-da-credit-extension was very light on content and
  strongly suggested to merge this document into
  draft-ietf-manet-dlep-traffic-classification. (At the time,
  draft-ietf-manet-dlep-ether-credit-extension had not yet been subjected to
  TSV ART early review). The WG considered this suggestion around IETF 113
  and again at IETF 115, but decided that reasons for the four-way split
  were still valid and to therefore stick to that structure.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

4. For protocol documents, are there existing implementations of the
contents of the document? Have a significant number of potential
implementers indicated plans to implement? Are any existing
implementations reported somewhere, either in the document itself (as
RFC 7942 recommends) or elsewhere (where)?

  This document's shepherd has no knowledge of existing implementations. Since
  this document (and its companions) describes an extension to DLEP (RFC 8175),
  a starting point for an implementation could be the open source DLEP
  library, to which David Wiggins (one of the authors of this
  document) is the main contributor: https://github.com/mit-ll/LL-DLEP .
  There has been some discussion on the mailing list on how to implement the
  router side of credit-based flow control (in Linux, specifically):
  https://mailarchive.ietf.org/arch/msg/manet/MPTLhKgaljq1BRdjE_dEk9x1YhI/

Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

  A TSV ART Early Review took place. Main concern was the split in three
  different documents. (See answer to question 2). Some lesser issue have
  been resolved.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  A RtgDir review still needs to take place. None of the other expert
  reviews mentioned (MIB Doctor, etc.) apply to this document.

7. If the document contains a YANG module, has the final version of
the module been checked with any of the recommended validation tools
for syntax and formatting validation? If there are any resulting
errors or warnings, what is the justification for not fixing them at
this time? Does the YANG module comply with the Network Management
Datastore Architecture (NMDA) as specified in RFC 8342?

  This document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate
sections of the final version of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL,
etc.

  This document contains no formal language. The shepherd has
  carefully reviewed this draft, as documented at
https://mailarchive.ietf.org/arch/msg/manet/OmQhM-zMGU2PEJNgTtGLNcsBnQM/
  These comments have been resolved.

Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion
that this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled lists of common issues that
their reviewers encounter. Do any such issues remain that would merit
specific attention from subsequent reviews?

  Shepherd has not identified any such issues.

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this
intent?

  Standards Track as indicated on the title page. This document and its
  companion documents specify a more sophisticated and fine-grained flow
  control mechanism than the one defined in RFC 8651 (which is a Proposed
  Standard). Moreover, credit-based flow control is an explicit work item
  on the WG's charter, whereas Control-Plane-Based Pause (RFC 8651) was
  not (and was criticized for that reason during IESG review).

12. Has the interested community confirmed that any and all
appropriate IPR disclosures required by BCP 78 and BCP 79 have been
filed? If not, explain why. If yes, summarize any discussion and
conclusion regarding the intellectual property rights (IPR)
disclosures, including links to relevant emails.

  See IPR statements at
https://mailarchive.ietf.org/arch/msg/manet/9NNWOL7odZofBoZ4q9Uwya1B6oI/
https://mailarchive.ietf.org/arch/msg/manet/itiAXwQ7dQaerG43rTH6SXNiDdY/
https://mailarchive.ietf.org/arch/msg/manet/J9EUsx1QPPUz6CwnRu4uEAwa634/

  It appears that no IPR is being claimed.

13. Has each Author or Contributor confirmed their willingness to be
listed as such? If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  Implicitly as per question 12 above. Sadly, David Wiggins passed away
  in 2023.

14. Identify any remaining I-D nits in this document. (See the idnits
tool and the checkbox items found in Guidelines to Authors of
Internet-Drafts). Simply running the idnits tool is not enough; please
review the entire guidelines document.

  The document adheres to the naming convention for Internet-Drafts.
  The document contains all the required sections. 

15. Should any informative references be normative or vice-versa?

  The shepherd believes the references to be categorized correctly.

16. List any normative references that are not freely available to
anyone. Did the community have sufficient access to review any such
normative references?

  All normative references are to RFCs.

17. Are there any normative downward references (see RFC 3967, BCP
97
)? If so, list them.

  There are no downward normative references.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If they exist, what
is the plan for their completion?

  There are no such normative references.

19. Will publication of this document change the status of any
existing RFCs? If so, does the Datatracker metadata correctly reflect
this and are those RFCs listed on the title page, in the abstract, and
discussed in the introduction? If not, explain why and point to the
part of the document where the relationship of this document to these
other RFCs is discussed.

  This document (together with its companion documents, see answer to
  question 1) defines an extension to RFC 8175, in the same way as
  RFC 8629, RFC 8651, RFC 8703 and RFC 8757 do, but it does not change the
  status of RFC 8175 or any other RFC.

20. Describe the document shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document. Confirm that all aspects of the document requiring IANA
assignments are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that each newly created IANA registry
specifies its initial contents, allocations procedures, and a
reasonable name (see RFC 8126).

  This document adds one entry to the existing DLEP Data Item
  Registry named "Data Item Type Values". This addition is in the range
  with a "Specification Required" policy. This document requests the
  creation of a new DLEP IANA registry, named "Traffic Classification
  Sub-Data Item Type Values" and provides three initial registry values.
  The requested actions in the IANA Considerations Section (section 5)
  have been found to be consistent with the body of the document.

21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear? Please include suggestions of designated experts, if
appropriate.

  The new IANA registry that this document creates (see answer to question
  20) does not contain value ranges for future allocation to which the
  Designated Expert Review policy applies.

2024-05-10
11 Ronald in 't Velt
 
Shepherd writeup on draft-ietf-manet-dlep-traffic-classification

Document History

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being …
 
Shepherd writeup on draft-ietf-manet-dlep-traffic-classification

Document History

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being silent, or did it reach broad
agreement?

  This document is part of a cluster of four which together specify a
  credit-base flow control extension to the Dynamic Link Exchange Protocol
  (DLEP, RFC8175). The companion documents are:
  - draft-ietf-manet-dlep-credit-flow-control,
  - draft-ietf-manet-dlep-da-credit-extension,
  - draft-ietf-manet-dlep-ether-credit-extension.
  There was strong consensus early on in the WG that it would be beneficial
  to have a Flow Control extension to DLEP that is more sophisticated than
  the Control-Plane-based Pause approach specified in RFC 8651. Most of the
  remaining discussion revolved around how to best structure and modularize
  the specification. (See answer to question 2).

2. Was there controversy about particular points, or were there decisions
where the consensus was particularly rough?

  There was discussion (rather than controversy) on how the functional
  elements of credit-based flow control should be distributed over separate
  documents. Between IETF 100 and IETF 103, the specification went from
  being contained in a single document to being broken down into four
  separate ones. Traffic Classification was split off, because it is
  considered a generic mechanism that can be useful for other purposes
  than flow control alone. draft-ietf-manet-dlep-da-credit-extension
  was the original monolithic specification, that was reduced to merely
  defining the Extension Type value after Message and Data Item definitions
  were moved to draft-ietf-manet-dlep-credit-flow-control and
  draft-ietf-manet-dlep-traffic-classification. Using IEEE 802.1Q fields of
  Ethernet frames instead of DS fields in IP packets as an alternative way
  of distinguishing flows made it necessary to define an additional
  Extension Type value in draft-ietf-manet-dlep-ether-credit-extension. The
  motivation for having both Extension Type values in different documents is
  to allow implementers of DLEP to specify exactly which extensions they
  support by means of RFC numbers. The TSV ART reviewer commented that
  draft-ietf-manet-dlep-da-credit-extension was very light on content and
  strongly suggested to merge this document into
  draft-ietf-manet-dlep-traffic-classification. (At the time,
  draft-ietf-manet-dlep-ether-credit-extension had not yet been subjected to
  TSV ART early review). The WG considered this suggestion around IETF 113
  and again at IETF 115, but decided that reasons for the four-way split
  were still valid and to therefore stick to that structure.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

4. For protocol documents, are there existing implementations of the
contents of the document? Have a significant number of potential
implementers indicated plans to implement? Are any existing
implementations reported somewhere, either in the document itself (as
RFC 7942 recommends) or elsewhere (where)?

  This document's shepherd has no knowledge of existing implementations. Since
  this document (and its companions) describes an extension to DLEP (RFC 8175),
  a starting point for an implementation could be the open source DLEP
  library, to which David Wiggins (one of the authors of this
  document) is the main contributor: https://github.com/mit-ll/LL-DLEP .
  There has been some discussion on the mailing list on how to implement the
  router side of credit-based flow control (in Linux, specifically):
  https://mailarchive.ietf.org/arch/msg/manet/MPTLhKgaljq1BRdjE_dEk9x1YhI/

Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

  A TSV ART Early Review took place. Main concern was the split in three
  different documents. (See answer to question 2). Some lesser issue have
  been resolved.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  A RtgDir review still needs to take place. None of the other expert
  reviews mentioned (MIB Doctor, etc.) apply to this document.

7. If the document contains a YANG module, has the final version of
the module been checked with any of the recommended validation tools
for syntax and formatting validation? If there are any resulting
errors or warnings, what is the justification for not fixing them at
this time? Does the YANG module comply with the Network Management
Datastore Architecture (NMDA) as specified in RFC 8342?

  This document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate
sections of the final version of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL,
etc.

  This document contains no formal language. The shepherd has
  carefully reviewed this draft, as documented at
https://mailarchive.ietf.org/arch/msg/manet/Knm_a-HXt_5i9xlRAnfp7jhLkds/
  These comments have been resolved.

Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion
that this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled lists of common issues that
their reviewers encounter. Do any such issues remain that would merit
specific attention from subsequent reviews?

  Shepherd has not identified any such issues.

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this
intent?

  Standards Track as indicated on the title page. This document and its
  companion documents specify a more sophisticated and fine-grained flow
  control mechanism than the one defined in RFC 8651 (which is a Proposed
  Standard). Moreover, credit-based flow control is an explicit work item
  on the WG's charter, whereas Control-Plane-Based Pause (RFC 8651) was
  not (and was criticized for that reason during IESG review).

12. Has the interested community confirmed that any and all
appropriate IPR disclosures required by BCP 78 and BCP 79 have been
filed? If not, explain why. If yes, summarize any discussion and
conclusion regarding the intellectual property rights (IPR)
disclosures, including links to relevant emails.

  See IPR statements at
https://mailarchive.ietf.org/arch/msg/manet/9NNWOL7odZofBoZ4q9Uwya1B6oI/
https://mailarchive.ietf.org/arch/msg/manet/itiAXwQ7dQaerG43rTH6SXNiDdY/
https://mailarchive.ietf.org/arch/msg/manet/J9EUsx1QPPUz6CwnRu4uEAwa634/

  It appears that no IPR is being claimed.

13. Has each Author or Contributor confirmed their willingness to be
listed as such? If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  Implicitly as per question 12 above. Sadly, David Wiggins passed away
  in 2023.

14. Identify any remaining I-D nits in this document. (See the idnits
tool and the checkbox items found in Guidelines to Authors of
Internet-Drafts). Simply running the idnits tool is not enough; please
review the entire guidelines document.

  The document adheres to the naming convention for Internet-Drafts.
  The document contains all the required sections. 

15. Should any informative references be normative or vice-versa?

  The shepherd believes the references to be categorized correctly.

16. List any normative references that are not freely available to
anyone. Did the community have sufficient access to review any such
normative references?

  All normative references are to RFCs.

17. Are there any normative downward references (see RFC 3967, BCP
97
)? If so, list them.

  There are no downward normative references.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If they exist, what
is the plan for their completion?

  There are no such normative references.

19. Will publication of this document change the status of any
existing RFCs? If so, does the Datatracker metadata correctly reflect
this and are those RFCs listed on the title page, in the abstract, and
discussed in the introduction? If not, explain why and point to the
part of the document where the relationship of this document to these
other RFCs is discussed.

  This document (together with its companion documents, see answer to
  question 1) defines an extension to RFC 8175, in the same way as
  RFC 8629, RFC 8651, RFC 8703 and RFC 8757 do, but it does not change the
  status of RFC 8175 or any other RFC.

20. Describe the document shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document. Confirm that all aspects of the document requiring IANA
assignments are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that each newly created IANA registry
specifies its initial contents, allocations procedures, and a
reasonable name (see RFC 8126).

  This document adds one entry to the existing DLEP Data Item
  Registry named "Data Item Type Values". This addition is in the range
  with a "Specification Required" policy. This document requests the
  creation of a new DLEP IANA registry, named "Traffic Classification
  Sub-Data Item Type Values" and provides three initial registry values.
  The requested actions in the IANA Considerations Section (section 5)
  have been found to be consistent with the body of the document.

21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear? Please include suggestions of designated experts, if
appropriate.

  The new IANA registry that this document creates (see answer to question
  20) does not contain value ranges for future allocation to which the
  Designated Expert Review policy applies.

2024-03-18
11 Lou Berger New version available: draft-ietf-manet-dlep-traffic-classification-11.txt
2024-03-18
11 Tess Chapeta Posted submission manually
2024-03-16
10 Ronald in 't Velt
 
WORK IN PROGRESS

Shepherd writeup on draft-ietf-manet-dlep-traffic-classification

Document History

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, …
 
WORK IN PROGRESS

Shepherd writeup on draft-ietf-manet-dlep-traffic-classification

Document History

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being silent, or did it reach broad
agreement?

  This document is part of a cluster of four which together specify a
  credit-base flow control extension to the Dynamic Link Exchange Protocol
  (DLEP, RFC8175). The companion documents are:
  - draft-ietf-manet-dlep-credit-flow-control,
  - draft-ietf-manet-dlep-da-credit-extension,
  - draft-ietf-manet-dlep-ether-credit-extension.
  There was strong consensus early on in the WG that it would be beneficial
  to have a Flow Control extension to DLEP that is more sophisticated than
  the Control-Plane-based Pause approach specified in RFC 8651. Most of the
  remaining discussion revolved around how to best structure and modularize
  the specification. (See answer to question 2).

2. Was there controversy about particular points, or were there decisions
where the consensus was particularly rough?

  There was discussion (rather than controversy) on how the functional
  elements of credit-based flow control should be distributed over separate
  documents. Between IETF 100 and IETF 103, the specification went from
  being contained in a single document to being broken down into four
  separate ones. Traffic Classification was split off, because it is
  considered a generic mechanism that can be useful for other purposes
  than flow control alone. draft-ietf-manet-dlep-da-credit-extension
  was the original monolithic specification, that was reduced to merely
  defining the Extension Type value after Message and Data Item definitions
  were moved to draft-ietf-manet-dlep-credit-flow-control and
  draft-ietf-manet-dlep-traffic-classification. Using IEEE 802.1Q fields of
  Ethernet frames instead of DS fields in IP packets as an alternative way
  of distinguishing flows made it necessary to define an additional
  Extension Type value in draft-ietf-manet-dlep-ether-credit-extension. The
  motivation for having both Extension Type values in different documents is
  to allow implementers of DLEP to specify exactly which extensions they
  support by means of RFC numbers. The TSV ART reviewer commented that
  draft-ietf-manet-dlep-da-credit-extension was very light on content and
  strongly suggested to merge this document into
  draft-ietf-manet-dlep-traffic-classification. (At the time,
  draft-ietf-manet-dlep-ether-credit-extension had not yet been subjected to
  TSV ART early review). The WG considered this suggestion around IETF 113
  and again at IETF 115, but decided that reasons for the four-way split
  were still valid and to therefore stick to that structure.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

4. For protocol documents, are there existing implementations of the
contents of the document? Have a significant number of potential
implementers indicated plans to implement? Are any existing
implementations reported somewhere, either in the document itself (as
RFC 7942 recommends) or elsewhere (where)?

  This document's shepherd has no knowledge of existing implementations. Since
  this document (and its companions) describes an extension to DLEP (RFC 8175),
  a starting point for an implementation could be the open source DLEP
  library, to which David Wiggins (one of the authors of this
  document) is the main contributor: https://github.com/mit-ll/LL-DLEP .
  There has been some discussion on the mailing list on how to implement the
  router side of credit-based flow control (in Linux, specifically):
  https://mailarchive.ietf.org/arch/msg/manet/MPTLhKgaljq1BRdjE_dEk9x1YhI/

Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

  A TSV ART Early Review took place. Main concern was the split in three
  different documents. (See answer to question 2). Some lesser issue are
  being resolved.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  A RtgDir review still needs to take place. None of the other expert
  reviews mentioned (MIB Doctor, etc.) apply to this document.

7. If the document contains a YANG module, has the final version of
the module been checked with any of the recommended validation tools
for syntax and formatting validation? If there are any resulting
errors or warnings, what is the justification for not fixing them at
this time? Does the YANG module comply with the Network Management
Datastore Architecture (NMDA) as specified in RFC 8342?

  This document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate
sections of the final version of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL,
etc.

  This document contains no formal language. The shepherd has
  carefully reviewed this draft, as documented at
https://mailarchive.ietf.org/arch/msg/manet/Knm_a-HXt_5i9xlRAnfp7jhLkds/
  (**as WG participant**)
  These comments have been resolved.

Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion
that this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled lists of common issues that
their reviewers encounter. Do any such issues remain that would merit
specific attention from subsequent reviews?

  Shepherd has not identified any such issues.

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this
intent?

  Standards Track as indicated on the title page. This document and its
  companion documents specify a more sophisticated and fine-grained flow
  control mechanism than the one defined in RFC 8651 (which is a Proposed
  Standard). Moreover, credit-based flow control is an explicit work item
  on the WG's charter, whereas Control-Plane-Based Pause (RFC 8651) was
  not (and was criticized for that reason during IESG review).

12. Has the interested community confirmed that any and all
appropriate IPR disclosures required by BCP 78 and BCP 79 have been
filed? If not, explain why. If yes, summarize any discussion and
conclusion regarding the intellectual property rights (IPR)
disclosures, including links to relevant emails.

  See IPR statements at
https://mailarchive.ietf.org/arch/msg/manet/GZPzumdxzHMIGY_zcnT1milVz0w/
https://mailarchive.ietf.org/arch/msg/manet/itiAXwQ7dQaerG43rTH6SXNiDdY/
https://mailarchive.ietf.org/arch/msg/manet/J9EUsx1QPPUz6CwnRu4uEAwa634/

  It appears that no IPR is being claimed.

13. Has each Author or Contributor confirmed their willingness to be
listed as such? If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  Implicitly as per question 12 above. Sadly, David Wiggins passed away
  in 2023.

14. Identify any remaining I-D nits in this document. (See the idnits
tool and the checkbox items found in Guidelines to Authors of
Internet-Drafts). Simply running the idnits tool is not enough; please
review the entire guidelines document.

  The document adheres to the naming convention for Internet-Drafts.
  The document contains all the required sections. 

15. Should any informative references be normative or vice-versa?

  The shepherd believes the references to be categorized correctly.

16. List any normative references that are not freely available to
anyone. Did the community have sufficient access to review any such
normative references?

  All normative references are to RFCs.

17. Are there any normative downward references (see RFC 3967, BCP
97
)? If so, list them.

  There are no downward normative references.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If they exist, what
is the plan for their completion?

  There are no such normative references.

19. Will publication of this document change the status of any
existing RFCs? If so, does the Datatracker metadata correctly reflect
this and are those RFCs listed on the title page, in the abstract, and
discussed in the introduction? If not, explain why and point to the
part of the document where the relationship of this document to these
other RFCs is discussed.

  This document (together with its companion documents, see answer to
  question 1) defines an extension to RFC 8175, in the same way as
  RFC 8629, RFC 8651, RFC 8703 and RFC 8757 do, but it does not change the
  status of RFC 8175 or any other RFC.

20. Describe the document shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document. Confirm that all aspects of the document requiring IANA
assignments are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that each newly created IANA registry
specifies its initial contents, allocations procedures, and a
reasonable name (see RFC 8126).

  This document adds one entry to the existing DLEP Data Item
  Registry named "Data Item Type Values". This addition is in the range
  with a "Specification Required" policy. This document requests the
  creation of a new DLEP IANA registry, named "Traffic Classification
  Sub-Data Item Type Values" and provides three initial registry values.
  The requested actions in the IANA Considerations Section (section 5)
  have been found to be consistent with the body of the document.

21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear? Please include suggestions of designated experts, if
appropriate.

  The new IANA registry that this document creates (see answer to question
  20) does not contain value ranges for future allocation to which the
  Designated Expert Review policy applies.

WORK IN PROGRESS
2024-03-04
10 Lou Berger New version available: draft-ietf-manet-dlep-traffic-classification-10.txt
2024-03-04
10 Tess Chapeta Posted submission manually
2024-01-11
09 (System) Document has expired
2023-12-20
09 Ronald in 't Velt
 
WORK IN PROGRESS

Shepherd writeup on draft-ietf-manet-dlep-traffic-classification

Document History

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, …
 
WORK IN PROGRESS

Shepherd writeup on draft-ietf-manet-dlep-traffic-classification

Document History

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being silent, or did it reach broad
agreement?

  This document is part of a cluster of four which together specify a
  credit-base flow control extension to the Dynamic Link Exchange Protocol
  (DLEP, RFC8175). The companion documents are:
  - draft-ietf-manet-dlep-credit-flow-control,
  - draft-ietf-manet-dlep-da-credit-extension,
  - draft-ietf-manet-dlep-ether-credit-extension.
  There was strong consensus early on in the WG that it would be beneficial
  to have a Flow Control extension to DLEP that is more sophisticated than
  the Control-Plane-based Pause approach specified in RFC 8651. Most of the
  remaining discussion revolved around how to best structure and modularize
  the specification. (See answer to question 2).

2. Was there controversy about particular points, or were there decisions
where the consensus was particularly rough?

  There was discussion (rather than controversy) on how the functional
  elements of credit-based flow control should be distributed over separate
  documents. Between IETF 100 and IETF 103, the specification went from
  being contained in a single document to being broken down into four
  separate ones. Traffic Classification was split off, because it is
  considered a generic mechanism that can be useful for other purposes
  than flow control alone. draft-ietf-manet-dlep-da-credit-extension
  was the original monolithic specification, that was reduced to merely
  defining the Extension Type value after Message and Data Item definitions
  were moved to draft-ietf-manet-dlep-credit-flow-control and
  draft-ietf-manet-dlep-traffic-classification. Using IEEE 802.1Q fields of
  Ethernet frames instead of DS fields in IP packets as an alternative way
  of distinguishing flows made it necessary to define an additional
  Extension Type value in draft-ietf-manet-dlep-ether-credit-extension. The
  motivation for having both Extension Type values in different documents is
  to allow implementers of DLEP to specify exactly which extensions they
  support by means of RFC numbers. The TSV ART reviewer commented that
  draft-ietf-manet-dlep-da-credit-extension was very light on content and
  strongly suggested to merge this document into
  draft-ietf-manet-dlep-traffic-classification. (At the time,
  draft-ietf-manet-dlep-ether-credit-extension had not yet been subjected to
  TSV ART early review). The WG considered this suggestion around IETF 113
  and again at IETF 115, but decided that reasons for the four-way split
  were still valid and to therefore stick to that structure.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

4. For protocol documents, are there existing implementations of the
contents of the document? Have a significant number of potential
implementers indicated plans to implement? Are any existing
implementations reported somewhere, either in the document itself (as
RFC 7942 recommends) or elsewhere (where)?

  This document's shepherd has no knowledge of existing implementations. Since
  this document (and its companions) describes an extension to DLEP (RFC 8175),
  a starting point for an implementation could be the open source DLEP
  library, to which David Wiggins (one of the authors of this
  document) is the main contributor: https://github.com/mit-ll/LL-DLEP .
  There has been some discussion on the mailing list on how to implement the
  router side of credit-based flow control (in Linux, specifically):
  https://mailarchive.ietf.org/arch/msg/manet/MPTLhKgaljq1BRdjE_dEk9x1YhI/

Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

  A TSV ART Early Review took place. Main concern was the split in three
  different documents. (See answer to question 2). Some lesser issue are
  being resolved.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  A RtgDir review still needs to take place. None of the other expert
  reviews mentioned (MIB Doctor, etc.) apply to this document.

7. If the document contains a YANG module, has the final version of
the module been checked with any of the recommended validation tools
for syntax and formatting validation? If there are any resulting
errors or warnings, what is the justification for not fixing them at
this time? Does the YANG module comply with the Network Management
Datastore Architecture (NMDA) as specified in RFC 8342?

  This document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate
sections of the final version of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL,
etc.

  This document contains no formal language. The shepherd has
  carefully reviewed this draft, as documented at
https://mailarchive.ietf.org/arch/msg/manet/Knm_a-HXt_5i9xlRAnfp7jhLkds/
  (**as WG participant**)
  These comments have been resolved.

Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion
that this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled lists of common issues that
their reviewers encounter. Do any such issues remain that would merit
specific attention from subsequent reviews?

  Shepherd has not identified any such issues.

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this
intent?

  Standards Track as indicated on the title page. This document and its
  companion documents specify a more sophisticated and fine-grained flow
  control mechanism than the one defined in RFC 8651 (which is a Proposed
  Standard). Moreover, credit-based flow control is an explicit work item
  on the WG's charter, whereas Control-Plane-Based Pause (RFC 8651) was
  not (and was criticized for that reason during IESG review).

12. Has the interested community confirmed that any and all
appropriate IPR disclosures required by BCP 78 and BCP 79 have been
filed? If not, explain why. If yes, summarize any discussion and
conclusion regarding the intellectual property rights (IPR)
disclosures, including links to relevant emails.

  See IPR statments at
https://mailarchive.ietf.org/arch/msg/manet/GZPzumdxzHMIGY_zcnT1milVz0w/
https://mailarchive.ietf.org/arch/msg/manet/itiAXwQ7dQaerG43rTH6SXNiDdY/
  (IPR statement by Bow-Nan Cheng is still pending, but his affiliation is
  the same as that of David Wiggins; it therefore seems unlikely that the
  former is aware of IPR of which the latter is not aware).

  It appears that no IPR is being claimed.

13. Has each Author or Contributor confirmed their willingness to be
listed as such? If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  Implicitly as per question 12 above.

14. Identify any remaining I-D nits in this document. (See the idnits
tool and the checkbox items found in Guidelines to Authors of
Internet-Drafts). Simply running the idnits tool is not enough; please
review the entire guidelines document.

  The document adheres to the naming convention for Internet-Drafts.
  The document contains all the required sections. 

15. Should any informative references be normative or vice-versa?

  The shepherd believes the references to be categorized correctly.

16. List any normative references that are not freely available to
anyone. Did the community have sufficient access to review any such
normative references?

  All normative references are to RFCs.

17. Are there any normative downward references (see RFC 3967, BCP
97
)? If so, list them.

  There are no downward normative references.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If they exist, what
is the plan for their completion?

  There are no such normative references.

19. Will publication of this document change the status of any
existing RFCs? If so, does the Datatracker metadata correctly reflect
this and are those RFCs listed on the title page, in the abstract, and
discussed in the introduction? If not, explain why and point to the
part of the document where the relationship of this document to these
other RFCs is discussed.

  This document (together with its companion documents, see answer to
  question 1) defines an extension to RFC 8175, in the same way as
  RFC 8629, RFC 8651, RFC 8703 and RFC 8757 do, but it does not change the
  status of RFC 8175 or any other RFC.

20. Describe the document shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document. Confirm that all aspects of the document requiring IANA
assignments are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that each newly created IANA registry
specifies its initial contents, allocations procedures, and a
reasonable name (see RFC 8126).

  This document adds one entry to the existing DLEP Data Item
  Registry named "Data Item Type Values". This addition is in the range
  with a "Specification Required" policy. This document requests the
  creation of a new DLEP IANA registry, named "Traffic Classification
  Sub-Data Item Type Values" and provides three initial registry values.
  The requested actions in the IANA Considerations Section (section 5)
  have been found to be consistent with the body of the document.

21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear? Please include suggestions of designated experts, if
appropriate.

  The new IANA registry that this document creates (see answer to question
  20) does not contain value ranges for future allocation to which the
  Designated Expert Review policy applies.

WORK IN PROGRESS
2023-11-05
09 Ronald in 't Velt
 
WORK IN PROGRESS

Shepherd writeup on draft-ietf-manet-dlep-traffic-classification

Document History

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, …
 
WORK IN PROGRESS

Shepherd writeup on draft-ietf-manet-dlep-traffic-classification

Document History

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being silent, or did it reach broad
agreement?

  This document is part of a cluster of four which together specify a
  credit-base flow control extension to the Dynamic Link Exchange Protocol
  (DLEP, RFC8175). The companion documents are:
  - draft-ietf-manet-dlep-credit-flow-control,
  - draft-ietf-manet-dlep-da-credit-extension,
  - draft-ietf-manet-dlep-ether-credit-extension.
  There was strong consensus early on in the WG that it would be beneficial
  to have a Flow Control extension to DLEP that is more sophisticated than
  the Control-Plane-based Pause approach specified in RFC 8651. Most of the
  remaining discussion revolved around how to best structure and modularize
  the specification. (See answer to question 2).

2. Was there controversy about particular points, or were there decisions
where the consensus was particularly rough?

  There was discussion (rather than controversy) on how the functional
  elements of credit-based flow control should be distributed over separate
  documents. Between IETF 100 and IETF 103, the specification went from
  being contained in a single document to being broken down into four
  separate ones. Traffic Classification was split off, because it is
  considered a generic mechanism that can be useful for other purposes
  than flow control alone. draft-ietf-manet-dlep-da-credit-extension
  was the original monolithic specification, that was reduced to merely
  defining the Extension Type value after Message and Data Item definitions
  were moved to draft-ietf-manet-dlep-credit-flow-control and
  draft-ietf-manet-dlep-traffic-classification. Using IEEE 802.1Q fields of
  Ethernet frames instead of DS fields in IP packets as an alternative way
  of distinguishing flows made it necessary to define an additional
  Extension Type value in draft-ietf-manet-dlep-ether-credit-extension. The
  motivation for having both Extension Type values in different documents is
  to allow implementers of DLEP to specify exactly which extensions they
  support by means of RFC numbers. The TSV ART reviewer commented that
  draft-ietf-manet-dlep-da-credit-extension was very light on content and
  strongly suggested to merge this document into
  draft-ietf-manet-dlep-da-credit-extension. (At the time,
  draft-ietf-manet-dlep-ether-credit-extension had not yet been subjected to
  TSV ART early review). The WG considered this suggestion around IETF 113
  and again at IETF 115, but decided that reasons for the four-way split
  were still valid and to therefore stick to that structure.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

4. For protocol documents, are there existing implementations of the
contents of the document? Have a significant number of potential
implementers indicated plans to implement? Are any existing
implementations reported somewhere, either in the document itself (as
RFC 7942 recommends) or elsewhere (where)?

  This document's shepherd has no knowledge of existing implementations. Since
  this document (and its companions) describes an extension to DLEP (RFC 8175),
  a starting point for an implementation could be the open source DLEP
  library, to which David Wiggins (one of the authors of this
  document) is the main contributor: https://github.com/mit-ll/LL-DLEP .
  There has been some discussion on the mailing list on how to implement the
  router side of credit-based flow control (in Linux, specifically):
  https://mailarchive.ietf.org/arch/msg/manet/MPTLhKgaljq1BRdjE_dEk9x1YhI/

Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

  A TSV ART Early Review took place. Main concern was the split in three
  different documents. (See answer to question 2). Some lesser issue are
  being resolved.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  A RtgDir review still needs to take place. None of the other expert
  reviews mentioned (MIB Doctor, etc.) apply to this document.

7. If the document contains a YANG module, has the final version of
the module been checked with any of the recommended validation tools
for syntax and formatting validation? If there are any resulting
errors or warnings, what is the justification for not fixing them at
this time? Does the YANG module comply with the Network Management
Datastore Architecture (NMDA) as specified in RFC 8342?

  This document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate
sections of the final version of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL,
etc.

  This document contains no formal language. The shepherd has
  carefully reviewed this draft, as documented at
https://mailarchive.ietf.org/arch/msg/manet/Knm_a-HXt_5i9xlRAnfp7jhLkds/
  (**as WG participant**)
  These comments have been resolved.

Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion
that this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled lists of common issues that
their reviewers encounter. Do any such issues remain that would merit
specific attention from subsequent reviews?

  Shepherd has not identified any such issues.

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this
intent?

  Standards Track as indicated on the title page. This document and its
  companion documents specify a more sophisticated and fine-grained flow
  control mechanism than the one defined in RFC 8651 (which is a Proposed
  Standard). Moreover, credit-based flow control is an explicit work item
  on the WG's charter, whereas Control-Plane-Based Pause (RFC 8651) was
  not (and was criticized for that reason during IESG review).

12. Has the interested community confirmed that any and all
appropriate IPR disclosures required by BCP 78 and BCP 79 have been
filed? If not, explain why. If yes, summarize any discussion and
conclusion regarding the intellectual property rights (IPR)
disclosures, including links to relevant emails.

  See IPR statments at
https://mailarchive.ietf.org/arch/msg/manet/GZPzumdxzHMIGY_zcnT1milVz0w/
https://mailarchive.ietf.org/arch/msg/manet/itiAXwQ7dQaerG43rTH6SXNiDdY/
  (IPR statement by Bow-Nan Cheng is still pending, but his affiliation is
  the same as that of David Wiggins; it therefore seems unlikely that the
  former is aware of IPR of which the latter is not aware).

  It appears that no IPR is being claimed.

13. Has each Author or Contributor confirmed their willingness to be
listed as such? If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  Implicitly as per question 12 above.

14. Identify any remaining I-D nits in this document. (See the idnits
tool and the checkbox items found in Guidelines to Authors of
Internet-Drafts). Simply running the idnits tool is not enough; please
review the entire guidelines document.

  The document adheres to the naming convention for Internet-Drafts.
  The document contains all the required sections. 

15. Should any informative references be normative or vice-versa?

  The shepherd believes the references to be categorized correctly.

16. List any normative references that are not freely available to
anyone. Did the community have sufficient access to review any such
normative references?

  All normative references are to RFCs.

17. Are there any normative downward references (see RFC 3967, BCP
97
)? If so, list them.

  There are no downward normative references.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If they exist, what
is the plan for their completion?

  There are no such normative references.

19. Will publication of this document change the status of any
existing RFCs? If so, does the Datatracker metadata correctly reflect
this and are those RFCs listed on the title page, in the abstract, and
discussed in the introduction? If not, explain why and point to the
part of the document where the relationship of this document to these
other RFCs is discussed.

  This document (together with its companion documents, see answer to
  question 1) defines an extension to RFC 8175, in the same way as
  RFC 8629, RFC 8651, RFC 8703 and RFC 8757 do, but it does not change the
  status of RFC 8175 or any other RFC.

20. Describe the document shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document. Confirm that all aspects of the document requiring IANA
assignments are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that each newly created IANA registry
specifies its initial contents, allocations procedures, and a
reasonable name (see RFC 8126).

  This document adds one entry to the existing DLEP Data Item
  Registry named "Data Item Type Values". This addition is in the range
  with a "Specification Required" policy. This document requests the
  creation of a new DLEP IANA registry, named "Traffic Classification
  Sub-Data Item Type Values" and provides three initial registry values.
  The requested actions in the IANA Considerations Section (section 5)
  have been found to be consistent with the body of the document.

21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear? Please include suggestions of designated experts, if
appropriate.

  The new IANA registry that this document creates (see answer to question
  20) does not contain value ranges for future allocation to which the
  Designated Expert Review policy applies.

WORK IN PROGRESS
2023-11-05
09 Ronald in 't Velt Notification list changed to ronald.intvelt@tno.nl because the document shepherd was set
2023-11-05
09 Ronald in 't Velt Document shepherd changed to Ronald in 't Velt
2023-07-10
09 Lou Berger New version available: draft-ietf-manet-dlep-traffic-classification-09.txt
2023-07-10
09 Lou Berger New version accepted (logged-in submitter: Lou Berger)
2023-07-10
09 Lou Berger Uploaded new revision
2023-01-30
08 (System) Document has expired
2022-07-29
08 Lou Berger New version available: draft-ietf-manet-dlep-traffic-classification-08.txt
2022-07-29
08 Ronald in 't Velt New version approved
2022-07-29
08 (System) Request for posting confirmation emailed to previous authors: Bow-Nan Cheng , David Wiggins , Lou Berger , manet-chairs@ietf.org
2022-07-29
08 Lou Berger Uploaded new revision
2022-02-24
07 Lou Berger New version available: draft-ietf-manet-dlep-traffic-classification-07.txt
2022-02-24
07 (System) New version accepted (logged-in submitter: Lou Berger)
2022-02-24
07 Lou Berger Uploaded new revision
2022-01-30
06 (System) Document has expired
2021-11-19
06 David Black Request for Early review by TSVART Completed: On the Right Track. Reviewer: David Black.
2021-10-30
06 Ronald in 't Velt Under TSV-ART review
2021-10-30
06 Ronald in 't Velt Tag Awaiting Expert Review/Resolution of Issues Raised set.
2021-10-30
06 Ronald in 't Velt IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-10-30
06 Ronald in 't Velt Changed consensus to Yes from Unknown
2021-10-30
06 Ronald in 't Velt Intended Status changed to Proposed Standard from None
2021-10-27
06 Magnus Westerlund Request for Early review by TSVART is assigned to David Black
2021-10-27
06 Magnus Westerlund Request for Early review by TSVART is assigned to David Black
2021-10-26
06 Ronald in 't Velt Requested Early review by TSVART
2021-07-29
06 Lou Berger New version available: draft-ietf-manet-dlep-traffic-classification-06.txt
2021-07-29
06 (System) New version accepted (logged-in submitter: Lou Berger)
2021-07-29
06 Lou Berger Uploaded new revision
2021-06-21
05 Lou Berger New version available: draft-ietf-manet-dlep-traffic-classification-05.txt
2021-06-21
05 (System) New version approved
2021-06-21
05 (System) Request for posting confirmation emailed to previous authors: Bow-Nan Cheng , David Wiggins , Lou Berger , manet-chairs@ietf.org
2021-06-21
05 Lou Berger Uploaded new revision
2021-06-07
04 (System) Document has expired
2020-12-04
04 Lou Berger New version available: draft-ietf-manet-dlep-traffic-classification-04.txt
2020-12-04
04 (System) New version accepted (logged-in submitter: Lou Berger)
2020-12-04
04 Lou Berger Uploaded new revision
2020-06-03
03 Lou Berger New version available: draft-ietf-manet-dlep-traffic-classification-03.txt
2020-06-03
03 (System) New version accepted (logged-in submitter: Lou Berger)
2020-06-03
03 Lou Berger Uploaded new revision
2020-05-22
02 (System) Document has expired
2019-11-19
02 Lou Berger New version available: draft-ietf-manet-dlep-traffic-classification-02.txt
2019-11-19
02 (System) New version accepted (logged-in submitter: Lou Berger)
2019-11-19
02 Lou Berger Uploaded new revision
2019-09-07
01 (System) Document has expired
2019-03-11
01 Justin Dean IETF WG state changed to In WG Last Call from WG Document
2019-03-06
01 Lou Berger New version available: draft-ietf-manet-dlep-traffic-classification-01.txt
2019-03-06
01 (System) New version approved
2019-03-06
01 (System) Request for posting confirmation emailed to previous authors: manet-chairs@ietf.org, Lou Berger , David Wiggins , Bow-Nan Cheng
2019-03-06
01 Lou Berger Uploaded new revision
2019-02-11
00 (System) Document has expired
2018-08-10
00 Lou Berger New version available: draft-ietf-manet-dlep-traffic-classification-00.txt
2018-08-10
00 (System) WG -00 approved
2018-08-02
00 Lou Berger Set submitter to "Lou Berger ", replaces to (none) and sent approval email to group chairs: manet-chairs@ietf.org
2018-08-02
00 Lou Berger Uploaded new revision