Skip to main content

DLEP IEEE 802.1Q Aware Credit Window Extension
draft-ietf-manet-dlep-ether-credit-extension-08

Revision differences

Document history

Date Rev. By Action
2025-02-07
08 Carlos Pignataro Closed request for Telechat review by OPSDIR with state 'Overtaken by Events'
2025-02-06
08 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2025-02-06
08 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2025-02-06
08 Éric Vyncke
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-manet-dlep-ether-credit-extension-08
CC @evyncke

Thank you for the work put into this document.

Please find below some …
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-manet-dlep-ether-credit-extension-08
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Ronald in 't Velt for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

Other thanks to Carlos Bernardos, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-manet-dlep-ether-credit-extension-08-intdir-telechat-bernardos-2025-02-04/ (and I have read Donald's reply)

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Section 1

Should the 'unidirectional' nature of this I-D be reflected in the title ? Based on `This document defines a DLEP extension which provides an Ethernet-based flow control mechanism for traffic sent from a router to a modem`

Suggest introducing "PCP" acronym when "Priority Code Points" first appears.
2025-02-06
08 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2025-02-05
08 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2025-02-05
08 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2025-02-05
08 Orie Steele [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele
2025-02-04
08 Roman Danyliw [Ballot comment]
Thank you to Behcet Sarikaya for the GENART review.
2025-02-04
08 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2025-02-04
08 Carlos Jesús Bernardos Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Carlos Jesús Bernardos. Sent review to list.
2025-02-03
08 Gunter Van de Velde
[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-manet-dlep-ether-credit-extension-08

# 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-ether-credit-extension-08.txt

# …
[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-manet-dlep-ether-credit-extension-08

# 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-ether-credit-extension-08.txt

# Many thanks for to He Jia for the RTGDIR reviews

# Most of the non-blocking observations are clarifications and readability suggestions

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

72   The DLEP specification does not include any flow control capability.
73   There are various flow control techniques theoretically possible with
74   DLEP.  This document defines a DLEP extension which provides an
75   Ethernet-based flow control mechanism for traffic sent from a router
76   to a modem.  Flow control is provided using one or more logical
77   "Credit Windows", each of which will typically be supported by an
78   associated virtual or physical queue.  A router will use traffic flow
79   classification information provided by the modem to identify which
80   traffic is associated with each credit window.  Credit windows may be
81   shared or dedicated on a per flow basis.  See
82   [I-D.ietf-manet-dlep-da-credit-extension] for a DiffServ-based
83   version of credit window flow control.  As specified in Section 2.3.1
84   of [I-D.ietf-manet-dlep-traffic-classification], when both DiffServ
85   and Ethernet traffic classification are specified for a flow, the
86   Ethertype information takes precedence.

GV> When the word "capability" is used, then my routing brain gets triggered by IGP TLVs and BGP capability negotiation principles. I suspect that what the authors are trying to say is that DLEP does not specify any flow control procedures.
GV> In addition I tried streamline the remaining part of the text also.

What do you think of following rewrite:

"
The DLEP specification does not define any flow control mechanisms. While various flow control techniques could be theoretically implemented with DLEP, this document specifies a DLEP extension that introduces an Ethernet-based flow control mechanism for traffic transmitted from a router to a modem. This mechanism utilizes one or more logical "Credit Windows", each of which is typically associated with a virtual or physical queue. The router leverages traffic flow classification information provided by the modem to determine the appropriate credit window for a given traffic flow. Credit windows may be allocated on either a shared or a per-flow basis. For a DiffServ-based approach to credit window flow control, refer to [I-D.ietf-manet-dlep-da-credit-extension]. As specified in Section 2.3.1 of [I-D.ietf-manet-dlep-traffic-classification], when both DiffServ and Ethernet traffic classification are applied to a flow, Ethertype-based classification takes precedence.
"

88   This document uses the traffic classification and credit window
89   control mechanisms defined in
90   [I-D.ietf-manet-dlep-traffic-classification] and
91   [I-D.ietf-manet-dlep-credit-flow-control] to provide credit window
92   based flow control based on DLEP destinations and Ethernet VLANs and
93   Priority Code Points.  Ethernet Priority Code Point support is
94   defined as part of the IEEE 802.1Q [IEEE8021Q] tag format and
95   includes a 3-bit "PCP" field.  The tag format also includes a 12-bit
96   VLAN identifier (VID) field.  The defined mechanism allows for credit
97   windows to be shared across traffic sent to multiple DLEP
98   destinations, Virtual Area Netwokrs (VLANs), and Priority Code Points
99   (PCPs), or used exclusively for traffic sent to a particular
100   destination and/or VLAN and/or PCP.  The extension also supports the
101   "wildcard" matching of any PCP or VID.

GV> What about:

"
This document leverages the traffic classification and credit window control mechanisms defined in [I-D.ietf-manet-dlep-traffic-classification] and [I-D.ietf-manet-dlep-credit-flow-control] to enable credit window-based flow control based on DLEP destinations, Ethernet VLANs, and Priority Code Points (PCPs). Ethernet PCP support is specified as part of the IEEE 802.1Q [IEEE8021Q] tag format, which includes a 3-bit "PCP" field. The tag format also incorporates a 12-bit "VLAN Identifier (VID)" field.

The defined mechanism allows credit windows to be shared across traffic destined for multiple DLEP destinations, Virtual Local Area Networks (VLANs), and PCPs, or to be dedicated exclusively to traffic associated with a specific destination, VLAN, and/or PCP. Additionally, this extension supports "wildcard" matching for any PCP or VID.
"

166   Modems MAY support the configuration of the number of credit windows
167   (queues) to advertise to a router.
168
169   Routers may have limits on the number of queues that they can support
170   and limits on supported credit window combinations.  Per destination
171   queues might not be supported at all.  When modem-provided credit
172   window information exceeds the capabilities of a router, the router
173   SHOULD use a subset of the provided credit windows.  Alternatively, a
174   router MAY reset the session and indicate that the extension is not
175   supported.  In either case, the mismatch of capabilities SHOULD be
176   reported to the user via normal network management mechanisms such as
177   user interface messages or error logging.
178
179   In all cases, if credit windows are in use, traffic for which credits
180   are not available MUST NOT be sent to the modem by the router.

GV> I find this not so easy to parse. What about the following textblob instead:

"
Modems MAY support configuration of the number of credit windows (queues) that they advertise to a router. 

Routers may impose limitations on the number of queues they can support and on the allowable credit window configurations. In some cases, per-destination queues may not be supported. If the credit window information provided by the modem exceeds the router’s capabilities, the router SHOULD utilize a subset of the advertised credit windows. Alternatively, the router MAY reset the session and indicate that the extension is not supported. In either case, any mismatch in capabilities SHOULD be reported to the user through standard network management mechanisms, such as user interface notifications or error logging. 

Regardless of implementation, if credit windows are in use, the router MUST NOT send traffic to the modem unless sufficient credits are available.
"

Kind Regards,
Gunter Van de Velde
Routing Area Director
2025-02-03
08 Gunter Van de Velde [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde
2025-02-03
08 Paul Wouters [Ballot comment]
I support Deb's DISCUSS/Comments on security
2025-02-03
08 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2025-02-03
08 Susan Hares Assignment of request for Telechat review by OPSDIR to Susan Hares was rejected
2025-02-02
08 Deb Cooley
[Ballot comment]
Section 4:  If changes are made to update the Security Consideration sections of draft-ietf-manet-dlep-traffic-classification and draft-ietf-manet-dlep-credit-flow-control, I recommend this draft reference one …
[Ballot comment]
Section 4:  If changes are made to update the Security Consideration sections of draft-ietf-manet-dlep-traffic-classification and draft-ietf-manet-dlep-credit-flow-control, I recommend this draft reference one or both of those drafts.

Section 4:  Wildcards are literally mentioned only in the Introduction and here. I certainly don't mind the recommendation in this section, but should this be a standalone paragraph?  And should it appear in some/all of the other drafts in the group?

Section 4, last sentence:  Does this apply to the wildcard topic?  Or something else, maybe the second sentence?  I think this section could use some restructuring.
2025-02-02
08 Deb Cooley [Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley
2025-02-01
08 Mahesh Jethanandani
[Ballot comment]
-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

Some of the text in this cluster of documents is repeated across the documents.
The nits therefore follow some of …
[Ballot comment]
-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

Some of the text in this cluster of documents is repeated across the documents.
The nits therefore follow some of that duplicated text.

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 1, paragraph 1
>    The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175].
>    This protocol provides the exchange of link related control
>    information between DLEP peers.  DLEP peers consist of a modem and a
>    router.  DLEP defines a base set of mechanisms as well as support for
>    possible extensions.  This document defines one such extension.

s/This protocol/The protocol/

Document references draft-ietf-manet-dlep-credit-flow-control-16, but -17 is
the latest available revision.

Section 1, paragraph 2
> ws may be shared or dedicated on a per flow basis. See [I-D.ietf-manet-dlep-d
>                                    ^^^^^^^^
In this context, "per-flow" forms an adjective and is spelled with a hyphen.
2025-02-01
08 Mahesh Jethanandani Ballot comment text updated for Mahesh Jethanandani
2025-02-01
08 Mahesh Jethanandani
[Ballot comment]

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

Some of the text in this cluster of documents is repeated across the documents.
The nits therefore follow some of …
[Ballot comment]

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

Some of the text in this cluster of documents is repeated across the documents.
The nits therefore follow some of that duplicated text.

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 1, paragraph 1
>    The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175].
>    This protocol provides the exchange of link related control
>    information between DLEP peers.  DLEP peers consist of a modem and a
>    router.  DLEP defines a base set of mechanisms as well as support for
>    possible extensions.  This document defines one such extension.

s/This protocol/The protocol/

Document references draft-ietf-manet-dlep-credit-flow-control-16, but -17 is
the latest available revision.

Section 1, paragraph 2
> ws may be shared or dedicated on a per flow basis. See [I-D.ietf-manet-dlep-d
>                                    ^^^^^^^^
In this context, "per-flow" forms an adjective and is spelled with a hyphen.
2025-02-01
08 Mahesh Jethanandani Ballot comment text updated for Mahesh Jethanandani
2025-02-01
08 Mahesh Jethanandani
[Ballot comment]
Some of the text in this cluster of documents is repeated across the documents.
The nits therefore follow some of that duplicated text. …
[Ballot comment]
Some of the text in this cluster of documents is repeated across the documents.
The nits therefore follow some of that duplicated text.

-------------------------------------------------------------------------------
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 1, paragraph 1
>    The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175].
>    This protocol provides the exchange of link related control
>    information between DLEP peers.  DLEP peers consist of a modem and a
>    router.  DLEP defines a base set of mechanisms as well as support for
>    possible extensions.  This document defines one such extension.

s/This protocol/The protocol/

Document references draft-ietf-manet-dlep-credit-flow-control-16, but -17 is
the latest available revision.

Section 1, paragraph 2
> ws may be shared or dedicated on a per flow basis. See [I-D.ietf-manet-dlep-d
>                                    ^^^^^^^^
In this context, "per-flow" forms an adjective and is spelled with a hyphen.
2025-02-01
08 Mahesh Jethanandani [Ballot Position Update] New position, No Objection, has been recorded for Mahesh Jethanandani
2025-01-31
08 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2025-01-31
08 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2025-01-30
08 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Carlos Jesús Bernardos
2025-01-30
08 Éric Vyncke Requested Telechat review by INTDIR
2025-01-19
08 Carlos Pignataro Request for Telechat review by OPSDIR is assigned to Susan Hares
2025-01-08
08 Jenny Bui Placed on agenda for telechat - 2025-02-06
2025-01-08
08 Jim Guichard Ballot has been issued
2025-01-08
08 Jim Guichard [Ballot Position Update] New position, Yes, has been recorded for Jim Guichard
2025-01-08
08 Jim Guichard Created "Approve" ballot
2025-01-08
08 Jim Guichard IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2025-01-08
08 Jim Guichard Ballot writeup was changed
2024-12-15
08 Donald Eastlake New version available: draft-ietf-manet-dlep-ether-credit-extension-08.txt
2024-12-15
08 Donald Eastlake New version accepted (logged-in submitter: Donald Eastlake)
2024-12-15
08 Donald Eastlake Uploaded new revision
2024-11-22
07 Don Fedyk New version available: draft-ietf-manet-dlep-ether-credit-extension-07.txt
2024-11-22
07 Don Fedyk New version approved
2024-11-22
07 (System) Request for posting confirmation emailed to previous authors: David Wiggins , Lou Berger , manet-chairs@ietf.org
2024-11-22
07 Don Fedyk Uploaded new revision
2024-08-29
06 Daniam Henriques Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: He Jia. Submission of review completed at an earlier date.
2024-08-12
06 Susan Hares Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Susan Hares. Sent review to list.
2024-08-08
06 Daniam Henriques Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: He Jia.
2024-07-22
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-07-22
06 Lou Berger New version available: draft-ietf-manet-dlep-ether-credit-extension-06.txt
2024-07-22
06 Lou Berger New version accepted (logged-in submitter: Lou Berger)
2024-07-22
06 Lou Berger Uploaded new revision
2024-07-13
05 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Susan Hares
2024-07-10
05 Valery Smyslov Request for Last Call review by SECDIR Completed: Ready. Reviewer: Valery Smyslov. Sent review to list.
2024-07-09
05 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2024-07-09
05 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-manet-dlep-ether-credit-extension-05. 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-ether-credit-extension-05. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the Extension Type Value Registry in the Dynamic Link Exchange Protocol (DLEP) Parameters registry group located at:

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

a single new extension type will be registered from the Specification Required range as follows:

Code: [ TBD-at-Registration ]
Description: IEEE 802.1Q Aware Credit Window
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action 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 action 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-09
05 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-07-04
05 Behcet Sarikaya Request for Last Call review by GENART Completed: Ready. Reviewer: Behcet Sarikaya. Sent review to list.
2024-07-04
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Valery Smyslov
2024-07-03
05 Shivan Sahib Assignment of request for Last Call review by SECDIR to Shivan Sahib was rejected
2024-07-02
05 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2024-06-29
05 Daniam Henriques Request for Last Call review by RTGDIR is assigned to He Jia
2024-06-28
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shivan Sahib
2024-06-27
05 David Dong IANA Experts State changed to Expert Reviews OK from Reviews assigned
2024-06-26
05 David Dong IANA Experts State changed to Reviews assigned
2024-06-26
05 Jean Mahoney Request for Last Call review by GENART is assigned to Behcet Sarikaya
2024-06-25
05 Jenny Bui IANA Review state changed to IANA - Review Needed
2024-06-25
05 Jenny Bui
The following Last Call announcement was sent out (ends 2024-07-09):

From: The IESG
To: IETF-Announce
CC: draft-ietf-manet-dlep-ether-credit-extension@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-07-09):

From: The IESG
To: IETF-Announce
CC: draft-ietf-manet-dlep-ether-credit-extension@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 IEEE 802.1Q Aware Credit Window Extension) to Proposed Standard


The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to
consider the following document: - 'DLEP IEEE 802.1Q Aware Credit Window
Extension'
  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-07-09. 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 an extension to the Dynamic Link Exchange
  Protocol (DLEP) that enables a Ethernet IEEE 802.1Q aware credit-
  window scheme for destination-specific and shared flow control.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-ether-credit-extension/



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




2024-06-25
05 Jenny Bui IESG state changed to In Last Call from Last Call Requested
2024-06-25
05 Jim Guichard Last call was requested
2024-06-25
05 Jim Guichard Last call announcement was generated
2024-06-25
05 Jim Guichard Ballot approval text was generated
2024-06-25
05 Jim Guichard Ballot writeup was generated
2024-06-25
05 Jim Guichard IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2024-06-25
05 Jim Guichard Requested Last Call review by RTGDIR
2024-06-25
05 Jim Guichard Requested Last Call review by OPSDIR
2024-06-25
05 Jim Guichard Requested Last Call review by SECDIR
2024-06-25
05 Jim Guichard Changed action holders to Jim Guichard
2024-06-24
05 (System) Changed action holders to Stan Ratliff, Jim Guichard (IESG state changed)
2024-06-24
05 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-06-24
05 Lou Berger New version available: draft-ietf-manet-dlep-ether-credit-extension-05.txt
2024-06-24
05 Lou Berger New version accepted (logged-in submitter: Lou Berger)
2024-06-24
05 Lou Berger Uploaded new revision
2024-05-22
04 (System) Changed action holders to Jim Guichard, Stan Ratliff, Lou Berger (IESG state changed)
2024-05-22
04 Jim Guichard IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2024-05-22
04 Jim Guichard AD review completed === https://mailarchive.ietf.org/arch/msg/manet/WdMvg80Q6Q2yj_Etoix3kTF8cS8/ ===
2024-05-10
04 Ronald in 't Velt
Shepherd writeup on draft-ietf-manet-dlep-ether-credit-extension.

Document History

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

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-traffic-classification,
  - draft-ietf-manet-dlep-da-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 separate 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, separate from the combined review for the
  three companion documents (see answer to question 1), because of later
  availability of this document. However, the reviewer refereed to his earlier
  review and the concerns from that review remaining to be addressed. To a large
  extent, these applied to this document as well. These have now 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/XPxug7QCNXWjyY4Jg4wPddoOWcM/
  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 finer-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 statement at
https://mailarchive.ietf.org/arch/msg/manet/ibXDUDE-MQWHCKkhhmYthz_EnZI/

  A similar statement from the other author, David Wiggins, is not available,
  as, sadly, he passed away in 2023.

  It appears that no IPR is being claimed. (David Wiggins is a co-author of
  all three companion documents of this I-D (as enumerated in the answer to
  question 1) and did state that he was unaware of IPR on any of these).

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?

  The document normatively references IEEE 802.1Q-2014 (** which may
  need to be updated to IEEE 802.1Q-2022 ? **). However, only the
  format of the 802.1Q tag, which is well-known, is of relevance here. 
  All other normative references are to RFCs (or RFCs-to-be, in two cases).

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?

  This document has normative references to two of its companion
  documents (see answer to question 1),
  draft-ietf-manet-dlep-credit-flow-control and
  draft-ietf-manet-dlep-traffic-classification, which are assumed to
  go through post-WG review and processing steps alongside it.

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 Extensions Registry
  named "Extension Type Values". This addition is in the range with a
  "Specification Required" policy. This document does not create new
  IANA registries. The requested action in the IANA Considerations
  Section (section 5) has 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.

  This document does not create new IANA registries.
2024-05-10
04 Ronald in 't Velt IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2024-05-10
04 Ronald in 't Velt IESG state changed to Publication Requested from I-D Exists
2024-05-10
04 (System) Changed action holders to Jim Guichard (IESG state changed)
2024-05-10
04 Ronald in 't Velt Responsible AD changed to Jim Guichard
2024-05-10
04 Ronald in 't Velt Document is now in IESG state Publication Requested
2024-05-10
04 Ronald in 't Velt
Shepherd writeup on draft-ietf-manet-dlep-ether-credit-extension.

Document History

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

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-traffic-classification,
  - draft-ietf-manet-dlep-da-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 separate 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, separate from the combined review for the
  three companion documents (see answer to question 1), because of later
  availability of this document. However, the reviewer refereed to his earlier
  review and the concerns from that review remaining to be addressed. To a large
  extent, these applied to this document as well. These have now 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/XPxug7QCNXWjyY4Jg4wPddoOWcM/
  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 finer-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 statement at
https://mailarchive.ietf.org/arch/msg/manet/ibXDUDE-MQWHCKkhhmYthz_EnZI/

  A similar statement from the other author, David Wiggins, is not available,
  as, sadly, he passed away in 2023.

  It appears that no IPR is being claimed. (David Wiggins is a co-author of
  all three companion documents of this I-D (as enumerated in the answer to
  question 1) and did state that he was unaware of IPR on any of these).

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?

  The document normatively references IEEE 802.1Q-2014 (** which may
  need to be updated to IEEE 802.1Q-2022 ? **). However, only the
  format of the 802.1Q tag, which is well-known, is of relevance here. 
  All other normative references are to RFCs (or RFCs-to-be, in two cases).

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?

  This document has normative references to two of its companion
  documents (see answer to question 1),
  draft-ietf-manet-dlep-credit-flow-control and
  draft-ietf-manet-dlep-traffic-classification, which are assumed to
  go through post-WG review and processing steps alongside it.

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 Extensions Registry
  named "Extension Type Values". This addition is in the range with a
  "Specification Required" policy. This document does not create new
  IANA registries. The requested action in the IANA Considerations
  Section (section 5) has 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.

  This document does not create new IANA registries.
2024-03-18
04 Lou Berger New version available: draft-ietf-manet-dlep-ether-credit-extension-04.txt
2024-03-18
04 Tess Chapeta Posted submission manually
2024-03-16
03 Ronald in 't Velt
 
WORK IN PROGRESS

Shepherd writeup on draft-ietf-manet-dlep-ether-credit-extension.

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-ether-credit-extension.

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-traffic-classification,
  - draft-ietf-manet-dlep-da-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 separate 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, separate from the combined review for the
  three companion documents (see answer to question 1), because of later
  availability of this document. However, the reviewer refereed to his earlier
  review and the concerns from that review remaining to be addressed. To a large
  extent, these apply to this document as well.

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 finer-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 statement at
https://mailarchive.ietf.org/arch/msg/manet/ibXDUDE-MQWHCKkhhmYthz_EnZI/

  A similar statement from the other author, David Wiggins, is not available,
  as, sadly, he passed away in 2023.

  It appears that no IPR is being claimed. (David Wiggins is a co-author of
  all three companion documents of this I-D (as enumerated in the answer to
  question 1) and did state that he was unaware of IPR on any of these).

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?

  The document normatively references IEEE 802.1Q-2014 (** needs to be
  updated to IEEE 802.1Q-2022 ? **). However, only the format of the
  802.1Q tag, which is well-known, is of relevance here. 
  All other normative references are to RFCs (or RFCs-to-be, in two cases).

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?

  This document has normative references to two of its companion
  documents (see answer to question 1),
  draft-ietf-manet-dlep-credit-flow-control and
  draft-ietf-manet-dlep-traffic-classification, which are assumed to
  go through post-WG review and processing steps alongside it.

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 Extensions Registry
  named "Extension Type Values". This addition is in the range with a
  "Specification Required" policy. This document does not create new
  IANA registries. The requested action in the IANA Considerations
  Section (section 5) has 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.

  This document does not create new IANA registries.

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

Shepherd writeup on draft-ietf-manet-dlep-ether-credit-extension.

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-ether-credit-extension.

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-traffic-classification,
  - draft-ietf-manet-dlep-da-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 separate 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, separate from the combined review for the
  three companion documents (see answer to question 1), because of later
  availability of this document. However, the reviewer refereed to his earlier
  review and the concerns from that review remaining to be addressed. To a large
  extent, these apply to this document as well.

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 finer-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/ibXDUDE-MQWHCKkhhmYthz_EnZI/
  (IPR statement by David Wiggins is still pending).

  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?

  The document normatively references IEEE 802.1Q-2014 (** needs to be
  updated to IEEE 802.1Q-2022 ? **). However, only the format of the
  802.1Q tag, which is well-known, is of relevance here. 
  All other normative references are to RFCs (or RFCs-to-be, in two cases).

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?

  This document has normative references to two of its companion
  documents (see answer to question 1),
  draft-ietf-manet-dlep-credit-flow-control and
  draft-ietf-manet-dlep-traffic-classification, which are assumed to
  go through post-WG review and processing steps alongside it.

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 Extensions Registry
  named "Extension Type Values". This addition is in the range with a
  "Specification Required" policy. This document does not create new
  IANA registries. The requested action in the IANA Considerations
  Section (section 5) has 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.

  This document does not create new IANA registries.

WORK IN PROGRESS
2023-12-20
02 Ronald in 't Velt
 
WORK IN PROGRESS

Shepherd writeup on draft-ietf-manet-dlep-ether-credit-extension.

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-ether-credit-extension.

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-traffic-classification,
  - draft-ietf-manet-dlep-da-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 separate 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 finer-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/ibXDUDE-MQWHCKkhhmYthz_EnZI/
  (IPR statement by David Wiggins is still pending).

  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?

  The document normatively references IEEE 802.1Q-2014 (** needs to be
  updated to IEEE 802.1Q-2022 ? **). However, only the format of the
  802.1Q tag, which is well-known, is of relevance here. 
  All other normative references are to RFCs (or RFCs-to-be, in two cases).

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?

  This document has normative references to two of its companion
  documents (see answer to question 1),
  draft-ietf-manet-dlep-credit-flow-control and
  draft-ietf-manet-dlep-traffic-classification, which are assumed to
  go through post-WG review and processing steps alongside it.

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 Extensions Registry
  named "Extension Type Values". This addition is in the range with a
  "Specification Required" policy. This document does not create new
  IANA registries. The requested action in the IANA Considerations
  Section (section 5) has 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.

  This document does not create new IANA registries.

WORK IN PROGRESS
2023-12-20
02 Ronald in 't Velt Notification list changed to ronald.intvelt@tno.nl because the document shepherd was set
2023-12-20
02 Ronald in 't Velt Document shepherd changed to Ronald in 't Velt
2023-12-19
02 David Black Request for Early review by TSVART Completed: On the Right Track. Reviewer: David Black. Sent review to list.
2023-12-18
02 Magnus Westerlund Request for Early review by TSVART is assigned to David Black
2023-12-18
02 Ronald in 't Velt Requested Early review by TSVART
2023-11-05
02 Ronald in 't Velt Changed consensus to Yes from Unknown
2023-11-05
02 Ronald in 't Velt Intended Status changed to Proposed Standard from None
2023-07-10
02 Lou Berger New version available: draft-ietf-manet-dlep-ether-credit-extension-02.txt
2023-07-10
02 Lou Berger New version accepted (logged-in submitter: Lou Berger)
2023-07-10
02 Lou Berger Uploaded new revision
2023-07-10
01 Ronald in 't Velt IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2022-08-28
01 (System) Document has expired
2022-02-24
01 Lou Berger New version available: draft-ietf-manet-dlep-ether-credit-extension-01.txt
2022-02-24
01 (System) New version accepted (logged-in submitter: Lou Berger)
2022-02-24
01 Lou Berger Uploaded new revision
2022-01-30
00 (System) Document has expired
2021-11-15
00 Don Fedyk IETF WG state changed to In WG Last Call from WG Document
2021-07-29
00 Lou Berger New version available: draft-ietf-manet-dlep-ether-credit-extension-00.txt
2021-07-29
00 (System) WG -00 approved
2021-07-29
00 Lou Berger Set submitter to "Lou Berger ", replaces to (none) and sent approval email to group chairs: manet-chairs@ietf.org
2021-07-29
00 Lou Berger Uploaded new revision