Shepherd writeup on draft-ietf-manet-dlep-traffic-classification
Document History
1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being silent, or did it reach broad
agreement?
This document is part of a cluster of four which together specify a
credit-base flow control extension to the Dynamic Link Exchange Protocol
(DLEP, RFC8175). The companion documents are:
- draft-ietf-manet-dlep-credit-flow-control,
- draft-ietf-manet-dlep-da-credit-extension,
- draft-ietf-manet-dlep-ether-credit-extension.
There was strong consensus early on in the WG that it would be beneficial
to have a Flow Control extension to DLEP that is more sophisticated than
the Control-Plane-based Pause approach specified in RFC 8651. Most of the
remaining discussion revolved around how to best structure and modularize
the specification. (See answer to question 2).
2. Was there controversy about particular points, or were there decisions
where the consensus was particularly rough?
There was discussion (rather than controversy) on how the functional
elements of credit-based flow control should be distributed over separate
documents. Between IETF 100 and IETF 103, the specification went from
being contained in a single document to being broken down into four
separate ones. Traffic Classification was split off, because it is
considered a generic mechanism that can be useful for other purposes
than flow control alone. draft-ietf-manet-dlep-da-credit-extension
was the original monolithic specification, that was reduced to merely
defining the Extension Type value after Message and Data Item definitions
were moved to draft-ietf-manet-dlep-credit-flow-control and
draft-ietf-manet-dlep-traffic-classification. Using IEEE 802.1Q fields of
Ethernet frames instead of DS fields in IP packets as an alternative way
of distinguishing flows made it necessary to define an additional
Extension Type value in draft-ietf-manet-dlep-ether-credit-extension. The
motivation for having both Extension Type values in different documents is
to allow implementers of DLEP to specify exactly which extensions they
support by means of RFC numbers. The TSV ART reviewer commented that
draft-ietf-manet-dlep-da-credit-extension was very light on content and
strongly suggested to merge this document into
draft-ietf-manet-dlep-traffic-classification. (At the time,
draft-ietf-manet-dlep-ether-credit-extension had not yet been subjected to
TSV ART early review). The WG considered this suggestion around IETF 113
and again at IETF 115, but decided that reasons for the four-way split
were still valid and to therefore stick to that structure.
3. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
No.
4. For protocol documents, are there existing implementations of the
contents of the document? Have a significant number of potential
implementers indicated plans to implement? Are any existing
implementations reported somewhere, either in the document itself (as
RFC 7942 recommends) or elsewhere (where)?
This document's shepherd has no knowledge of existing implementations. Since
this document (and its companions) describes an extension to DLEP (RFC 8175),
a starting point for an implementation could be the open source DLEP
library, to which David Wiggins (one of the authors of this
document) is the main contributor: https://github.com/mit-ll/LL-DLEP .
There has been some discussion on the mailing list on how to implement the
router side of credit-based flow control (in Linux, specifically):
https://mailarchive.ietf.org/arch/msg/manet/MPTLhKgaljq1BRdjE_dEk9x1YhI/
Additional Reviews
5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.
A TSV ART Early Review took place. Main concern was the split in three
different documents. (See answer to question 2). Some lesser issue have
been resolved.
6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.
A RtgDir review still needs to take place. None of the other expert
reviews mentioned (MIB Doctor, etc.) apply to this document.
7. If the document contains a YANG module, has the final version of
the module been checked with any of the recommended validation tools
for syntax and formatting validation? If there are any resulting
errors or warnings, what is the justification for not fixing them at
this time? Does the YANG module comply with the Network Management
Datastore Architecture (NMDA) as specified in RFC 8342?
This document does not contain a YANG module.
8. Describe reviews and automated checks performed to validate
sections of the final version of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL,
etc.
This document contains no formal language. The shepherd has
carefully reviewed this draft, as documented at
https://mailarchive.ietf.org/arch/msg/manet/OmQhM-zMGU2PEJNgTtGLNcsBnQM/
These comments have been resolved.
Document Shepherd Checks
9. Based on the shepherd's review of the document, is it their opinion
that this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director?
Yes.
10. Several IETF Areas have assembled lists of common issues that
their reviewers encounter. Do any such issues remain that would merit
specific attention from subsequent reviews?
Shepherd has not identified any such issues.
11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this
intent?
Standards Track as indicated on the title page. This document and its
companion documents specify a more sophisticated and fine-grained flow
control mechanism than the one defined in RFC 8651 (which is a Proposed
Standard). Moreover, credit-based flow control is an explicit work item
on the WG's charter, whereas Control-Plane-Based Pause (RFC 8651) was
not (and was criticized for that reason during IESG review).
12. Has the interested community confirmed that any and all
appropriate IPR disclosures required by BCP 78 and BCP 79 have been
filed? If not, explain why. If yes, summarize any discussion and
conclusion regarding the intellectual property rights (IPR)
disclosures, including links to relevant emails.
See IPR statements at
https://mailarchive.ietf.org/arch/msg/manet/9NNWOL7odZofBoZ4q9Uwya1B6oI/https://mailarchive.ietf.org/arch/msg/manet/itiAXwQ7dQaerG43rTH6SXNiDdY/https://mailarchive.ietf.org/arch/msg/manet/J9EUsx1QPPUz6CwnRu4uEAwa634/
It appears that no IPR is being claimed.
13. Has each Author or Contributor confirmed their willingness to be
listed as such? If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.
Implicitly as per question 12 above. Sadly, David Wiggins passed away
in 2023.
14. Identify any remaining I-D nits in this document. (See the idnits
tool and the checkbox items found in Guidelines to Authors of
Internet-Drafts). Simply running the idnits tool is not enough; please
review the entire guidelines document.
The document adheres to the naming convention for Internet-Drafts.
The document contains all the required sections.
15. Should any informative references be normative or vice-versa?
The shepherd believes the references to be categorized correctly.
16. List any normative references that are not freely available to
anyone. Did the community have sufficient access to review any such
normative references?
All normative references are to RFCs.
17. Are there any normative downward references (see RFC 3967, BCP
97)? If so, list them.
There are no downward normative references.
18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If they exist, what
is the plan for their completion?
There are no such normative references.
19. Will publication of this document change the status of any
existing RFCs? If so, does the Datatracker metadata correctly reflect
this and are those RFCs listed on the title page, in the abstract, and
discussed in the introduction? If not, explain why and point to the
part of the document where the relationship of this document to these
other RFCs is discussed.
This document (together with its companion documents, see answer to
question 1) defines an extension to RFC 8175, in the same way as
RFC 8629, RFC 8651, RFC 8703 and RFC 8757 do, but it does not change the
status of RFC 8175 or any other RFC.
20. Describe the document shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document. Confirm that all aspects of the document requiring IANA
assignments are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that each newly created IANA registry
specifies its initial contents, allocations procedures, and a
reasonable name (see RFC 8126).
This document adds one entry to the existing DLEP Data Item
Registry named "Data Item Type Values". This addition is in the range
with a "Specification Required" policy. This document requests the
creation of a new DLEP IANA registry, named "Traffic Classification
Sub-Data Item Type Values" and provides three initial registry values.
The requested actions in the IANA Considerations Section (section 5)
have been found to be consistent with the body of the document.
21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear? Please include suggestions of designated experts, if
appropriate.
The new IANA registry that this document creates (see answer to question
20) does not contain value ranges for future allocation to which the
Designated Expert Review policy applies.