Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Control Messages and Data Items
draft-ietf-manet-dlep-credit-flow-control-19

[Ballot comment]
I was unaware of this work in Manet, and thank you for making an interesting and useful specification.

Thank you for addressing these concerns in rev-18:

1. The text says: “In the absence of a wildcard, a packet may not match any of the data items and, in this case, SHOULD be dropped by the router.”.- Why is this not a MUST? (If it needs to be a SHOULD, then please add text to explain what happens whene there is no match and explain whether sending this pacekt also consumens credit.)

2. If a packet is not matched and is dropped, ought it to be logged? (It would be logged if there was no FID). Either way, the specification ought to explain whether an entry in the log is to be expected.

3. I don’t think the security mechanisms are sufficiently defined to be useful. Please can you explain what threats these updates are expected to counter. This currently leads to two very ineffective security considerations.

[Ballot comment]
I was unaware of this work in Manet, and thank you for making an interesting and useful specification.

Thank you for addressing these concerns:

1. The text says: “In the absence of a wildcard, a packet may not match any of the data items and, in this case, SHOULD be dropped by the router.”.- Why is this not a MUST? (If it needs to be a SHOULD, then please add text to explain what happens whene there is no match and explain whether sending this pacekt also consumens credit.)

2. If a packet is not matched and is dropped, ought it to be logged? (It would be logged if there was no FID). Either way, the specification ought to explain whether an entry in the log is to be expected.

3. I don’t think the security mechanisms are sufficiently defined to be useful. Please can you explain what threats these updates are expected to counter. This currently leads to two very ineffective security considerations.

[Ballot comment]
Hi authors,

Special thanks to Eric and the WG Chairs for he effort put in the last mile to finalize the specification (and others in the set).

I only checked diff 18 vs. 17 as I already reviewed for OPSDIR both -15 and -17 (*).

Most of my comments raised in -15 were addressed. I hoped to see more about how to expose
default values/control the configuration parameters out there, but knowing the context of
this spec, I won't insist on this. So, I'm fine with this version to be published.

Cheers,
Med

(*)
  - 15: https://datatracker.ietf.org/doc/review-ietf-manet-dlep-credit-flow-control-15-opsdir-early-boucadair-2024-07-24/
  - 17: https://datatracker.ietf.org/doc/review-ietf-manet-dlep-credit-flow-control-17-opsdir-telechat-boucadair-2025-01-20/

[Ballot discuss]
I was unaware of this work in Manet, and thank you for making an interesting and useful specification. I have two concerns I’d like to discuss:

1. The text says: “In the absence of a wildcard, a packet may not match any of the data items and, in this case, SHOULD be dropped by the router.”.- Why is this not a MUST? (If it needs to be a SHOULD, then please add text to explain what happens whene there is no match and explain whether sending this pacekt also consumens credit.)

2. If a packet is not matched and is dropped, ought it to be logged? (It would be logged if there was no FID). Either way, the specification ought to explain whether an entry in the log is to be expected.

[Ballot comment]
I don’t think the security mechanisms are sufficiently defined to be useful. Please can you explain what threats these updates are expected to counter. This currently leads to two very ineffective security considerations:

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-manet-dlep-credit-flow-control-17

# 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-credit-flow-control-17.txt

# Many thanks to Dhruv Dhody  for the RTGDIR review, and the follow up.


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

400   Length:
401       16
402
403       Per [RFC8175] Length is the number of octets in the Data Item.  It
404       MUST be equal to sixteen (16).

GV> This field seems slightly underspecified. Maybe point out that the Length is set in multiples of bytes, not bits.
GV> What must happen if the length is not set to value '16'? ignore? send a trap? reset the process? Please advice

496   Length:
497       2
498
499       Per [RFC8175] Length is the number of octets in the Data Item.  It
500       MUST be equal to two (2).

GV> similar observation as above.

Kind Regards,
Gunter Van de Velde
Routing Area Director

[Ballot comment]
I suggest reviewing several of the SHOULDs in this document.  For instance, there's a cluster of them in the last paragraph of Section 2.3.4.  Since SHOULD presents a choice to an implementer, I could decide to do none of these and still claim I'm compliant with this specification.  Is that the intent?  You might instead want to add some guidance about when you imagine an implementer might legitimately not do what you're saying here.  Or if you can't come up with such guidance, then consider that this really might be a MUST.

[Ballot comment]
Thanks for carrying this document across the finish line. I have one question:

### Section 2.3.1

"Finally, a queue size (in octets) is provided for informational purposes."

Where?

[Ballot comment]
I support Deb Cooley's DISCUSS position.

Thank you to Sue Hares for the GENART review.  From her review, please consider:

** Section 2.4, Management Considerations, would benefit discuss of the "potential challenges and downsides of the flow control scheme. For instance, if the RF link capacity rapidly changes, what is the benefit of this flow control?"

** Additional operational considerations: "knowledge about credits may get inconsistent. Mismatches may also include situations where packets are lost or dropped (e.g. checksum failures)"

[Ballot comment]
First of all, special thanks to David Black for his (as usual) excellent TSVART review and  to the authors for resolving those.

Nit: s/"Message Values" /" Message Type Values" in section 5.1. There is no "message values" registry defined by RFC8175

[Ballot comment]
I suspect Deb's DISCUSS.

Note the figure in Section 2.3.1 shows 2 32 bit credit fields but the text describes it as one 64 bit credit field. Please fix the figure.
Looking again, I see a ":" notation that I've never seen used before. I think the following is far cleaner:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Credit Value                          |
    |                                                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This is also done in other sections, eg 2.3.3, 2.3.4, etc


In 2.3.2 the description of field "Data Item Type" should be "Data Item Type (TBA5)".

Flow Identifier (FID): should probably say it is a two octet value ?
I would also use the more common ~ instead of : syntax in the diagrams
to indicate variable length.

Section 4

Since this protocol has a window size of one (only one outstanding msg allowed),
couldn't an enduser/malicious code somehow block this traffic flow from happening
by sending bogus msgs that fill up the queue of size 1? How can an implementation
protect itself against this?

[Ballot discuss]
Please note that this discuss applies to the traffic classification draft, and perhaps to the other two DLEP drafts on the telechat.  I would be happy to have them all addressed together, at the authors discretion.

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.

[Ballot comment]
Section 2, paragraph 6:  Wildcards are mentioned here, but no where else in the draft.  Specifically, which packet types listed in this draft can have wildcards specified?

Sections 2.3.1, 2.3.3, 2.3.4:  Reserved field, why doesn't the router/modem have to validate this (it allows a covert channel if not validated)?

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

IANA has completed its review of draft-ietf-manet-dlep-credit-flow-control-15. 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 Message Type Values registry in the Dynamic Link Exchange Protocol (DLEP) Parameters registry group located at:

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

two new message types are to be registered from the Specification Required range as follows:

Type Code: [ TBD-at-Registration ]
Description: Credit Control
Reference: [ RFC-to-be ]

Type Code: [ TBD-at-Registration ]
Description: Credit Control Response
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated 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, in the DLEP Data Item Registry also in the Dynamic Link Exchange Protocol (DLEP) Parameters registry group located at:

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

five new data item values are to be registered from the Specification Required range as follows:

Type Code: [ TBD-at-Registration ]
Description: Credit Window Initialization
Reference: [ RFC-to-be ]

Type Code: [ TBD-at-Registration ]
Description: Credit Window Association
Reference: [ RFC-to-be ]

Type Code: [ TBD-at-Registration ]
Description: Credit Window Grant
Reference: [ RFC-to-be ]

Type Code: [ TBD-at-Registration ]
Description: Credit Window Status
Reference: [ RFC-to-be ]

Type Code: [ TBD-at-Registration ]
Description: Credit Window Request
Reference: [ RFC-to-be ]

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated 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."

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

The following Last Call announcement was sent out (ends 2024-08-06):

From: The IESG
To: IETF-Announce
CC: draft-ietf-manet-dlep-credit-flow-control@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 Credit-Based Flow Control Messages and Data Items) to Proposed Standard


The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to
consider the following document: - 'DLEP Credit-Based Flow Control Messages
and Data Items'
  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 new Dynamic Link Exchange Protocol (DLEP) Data
  Items that are used to support credit-based flow control.  Credit
  window control is used to regulate when data may be sent to an
  associated virtual or physical queue.  The Data Items are defined in
  an extensible and reusable fashion.  Their use will be mandated in
  other documents defining specific DLEP extensions.




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



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

Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control

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-traffic-classification,
  - 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) was 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 additional issues 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/GZPzumdxzHMIGY_zcnT1milVz0w/
https://mailarchive.ietf.org/arch/msg/manet/itiAXwQ7dQaerG43rTH6SXNiDdY/
https://mailarchive.ietf.org/arch/msg/manet/RCZuga54SM4-lDkXJ5ETM-qUQP0/

  A similar statement from Stan Ratliff is not available, because he
  passed away in October 2019, before the request for IPR statements
  was posted to the MANET WG mailing list.

  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, two of the authors, Stan
  Ratliff and David Wiggins, are no longer with us.

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 (or RFC-to-be, in one case).

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 a normative reference to one of its companion
  documents (see answer to question 1),
  draft-ietf-manet-dlep-traffic-classification, which is 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 two entries to the existing DLEP Message Registry
  named "Message Values" and five entries to the existing DLEP Data Item
  Registry named "Data Item Type Values". Additions to both existing
  registries are in ranges with a "Specification Required" policy. This
  document does not create new IANA registries. 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.

  This document does not create new IANA registries.

Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control

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-traffic-classification,
  - 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) was 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 additional issues 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/GZPzumdxzHMIGY_zcnT1milVz0w/
https://mailarchive.ietf.org/arch/msg/manet/itiAXwQ7dQaerG43rTH6SXNiDdY/
https://mailarchive.ietf.org/arch/msg/manet/RCZuga54SM4-lDkXJ5ETM-qUQP0/

  A similar statement from Stan Ratliff is not available, because he
  passed away in October 2019, before the request for IPR statements
  was posted to the MANET WG mailing list.

  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, two of the authors, Stan
  Ratliff and David Wiggins, are no longer with us.

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 (or RFC-to-be, in one case).

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 a normative reference to one of its companion
  documents (see answer to question 1),
  draft-ietf-manet-dlep-traffic-classification, which is 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 two entries to the existing DLEP Message Registry
  named "Message Values" and five entries to the existing DLEP Data Item
  Registry named "Data Item Type Values". Additions to both existing
  registries are in ranges with a "Specification Required" policy. This
  document does not create new IANA registries. 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.

  This document does not create new IANA registries.

 
WORK IN PROGRESS

Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control

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-traffic-classification,
  - 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) was 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/RCZuga54SM4-lDkXJ5ETM-qUQP0/

  A similar statement from Stan Ratliff is not available, because he
  passed away in October 2019, before the request for IPR statements
  was posted to the MANET WG mailing list.

  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, two of the authors, Stan
  Ratliff and David Wiggins, are no longer with us.

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 (or RFC-to-be, in one case).

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 a normative reference to one of its companion
  documents (see answer to question 1),
  draft-ietf-manet-dlep-traffic-classification, which is 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 two entries to the existing DLEP Message Registry
  named "Message Values" and five entries to the existing DLEP Data Item
  Registry named "Data Item Type Values". Additions to both existing
  registries are in ranges with a "Specification Required" policy. This
  document does not create new IANA registries. 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.

  This document does not create new IANA registries.

WORK IN PROGRESS

 
WORK IN PROGRESS

Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control

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-traffic-classification,
  - 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. Sadly, Stan Ratliff is no longer
  with us.

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 (or RFC-to-be, in one case).

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 a normative reference to one of its companion
  documents (see answer to question 1),
  draft-ietf-manet-dlep-traffic-classification, which is 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 two entries to the existing DLEP Message Registry
  named "Message Values" and five entries to the existing DLEP Data Item
  Registry named "Data Item Type Values". Additions to both existing
  registries are in ranges with a "Specification Required" policy. This
  document does not create new IANA registries. 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.

  This document does not create new IANA registries.

WORK IN PROGRESS

 
WORK IN PROGRESS

Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control

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-traffic-classification,
  - 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. Sadly, Stan Ratliff is no longer
  with us.

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 (or RFC-to-be, in one case).

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 a normative reference to one of its companion
  documents (see answer to question 1),
  draft-ietf-manet-dlep-traffic-classification, which is 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 two entries to the existing DLEP Message Registry
  named "Message Values" and five entries to the existing DLEP Data Item
  Registry named "Data Item Type Values". Additions to both existing
  registries are in ranges with a "Specification Required" policy. This
  document does not create new IANA registries. 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.

  This document does not create new IANA registries.

WORK IN PROGRESS

 
WORK IN PROGRESS

Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control

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-traffic-classification,
  - 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). 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 (or RFC-to-be, in one case).

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 a normative reference to one of its companion
  documents (see answer to question 1),
  draft-ietf-manet-dlep-traffic-classification, which is 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 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 two entries to the existing DLEP Message Registry
  named "Message Values" and five entries to the existing DLEP Data Item
  Registry named "Data Item Type Values". Additions to both existing
  registries are in ranges with a "Specification Required" policy. This
  document does not create new IANA registries. 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.

  This document does not create new IANA registries.

WORK IN PROGRESS