[manet] Re: Murray Kucherawy's Discuss on draft-ietf-manet -dlep-traffic-classification-13: (with DISCUSS and COMMENT)
Don Fedyk <[email protected]>
| Newsgroups | gmane.ietf.manet |
|---|---|
| Message-ID | <PH7PR14MB53686D309EC943044B01B4B2BBD82@PH7PR14MB5368.namprd14.prod.outlook.com> |
Thanks John
I didn't see your note until after I sent my last message. I reformatted my proposed text, updated the references.
Trying to incorporate your points into the text I have this as a proposal:
55.2. DLEP Traffic Classification Sub-Data Item Registry
Upon approval of this document, IANA is requested to create a new
DLEP registry, named "Traffic Classification Sub-Data Item Type
Values".
The following table provides initial registry values and the
[RFC8126] defined policies that should apply to the registry:
+=============+=================================+=============+
| Type Code | Description | Reference |
+=============+=================================+=============+
| 0 | Reserved | |
+-------------+---------------------------------+-------------+
| 1 | DiffServ Traffic Classification | [RFC2474] |
+-------------+---------------------------------+-------------+
| 2 | Ethernet Traffic Classification | [IEEE8021Q] |
+-------------+---------------------------------+-------------+
| 3-65407 | Specification Required | |
+-------------+---------------------------------+-------------+
| 65408-65534 | Private Use | |
+-------------+---------------------------------+-------------+
| 65535 | Reserved | |
+-------------+---------------------------------+-------------+
Table 2: Initial Registry Values
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the
Traffic Classification Sub-Data Item Type Values registry for the
DLEP protocol, in accordance with BCP 26 and [RFC8126].
Cheng, et al. Expires 21 September 2025 [Page 12]
Internet-Draft DLEP Traffic Classification March 2025
This registry encompasses packet traffic classification, where
standard packet header identifiers in packets or data frames indicate
Quality of Service (QoS) treatment. It includes two specific
registries for widely recognized identifiers used in QoS management
for IP and Ethernet networks. Reserved values are set aside for
similar future identifiers that may emerge to denote QoS treatment.
However, requests for new entries are not expected to be frequent.
Allocations within the registry are subject to the following
requirements:
1. Documentation of the intended use of the requested value, in
compliance with the "Specification Required" policy defined in
[RFC8126].
2. Approval by the Designated Expert (DE) appointed by the IESG.
The DE must:
* Verify that the requested value is clearly documented and its
purpose and usage are unambiguous.
* Ensure the proposed value does not conflict with existing work
or ongoing efforts within the IETF.
* Confirm that any specification requesting a code point has
undergone review by the MANET working group (or a successor
mailing list designated by the IESG).
* Validate that external specifications requesting code points
are publicly available, permanently archived, and do not
conflict with active or published IETF work.
* Ensure the review process is conducted in a timely manner,
with any disputes resolved through consultation with the
appropriate working groups.
To simplify future registrations, it is recommended that this
guidance serves as a standard reference for all DLEP-related
registries. Future specifications may include a header note pointing
to this guidance document.
Don
________________________________
From: John Scudder
Sent: Wednesday, March 19, 2025 11:43 PM
To: Don Fedyk
Cc: Murray S. Kucherawy; The IESG; [email protected]; [email protected]; [email protected]; [email protected]; Rick Taylor
Subject: Re: Murray Kucherawy's Discuss on draft-ietf-manet-dlep-traffic-classification-13: (with DISCUSS and COMMENT)
Hi Don,
Speaking only as a well-meaning bystander here.
RFC 8126 has a handy checklist that will lead you in the right direction: https://www.rfc-editor.org/rfc/rfc8126.html#section-1.3. Notably,
7. If you're using a policy that requires a designated expert
(Expert Review or Specification Required), understand Section 5
and provide review guidance to the designated expert (see
Section 5.3).
I see there are already a bunch of Specification Required registries for DLEP, so I figured I’d look to see what review guidance was provided to the Designated Expert. I don’t see any, though, either in the registries or in RFC 8175. Maybe I missed it. I’ve added Rick Taylor (the Designated Expert for those registries) to the cc; maybe Rick can enlighten us as to whether there is some written guidance I’ve missed.
That means we can’t avail ourselves of the shortcut of saying, “use the same guidance to designated expert as all the other DLEP registries”. But that’s OK; it’s not that hard to write guidance. Here’s an example of a “guidance for designated experts” section that was recently approved by the IESG: https://www.ietf.org/archive/id/draft-ietf-idr-bgp-car-16.html#name-guidance-for-designated-exp. I’m not saying you should dive right in and use that as a template, though; you’re probably best off starting by reading https://www.rfc-editor.org/rfc/rfc8126.html#section-5.3 (it’s not long).
One more comment: if indeed all the DLEP registries are missing the guidance they’re supposed have, I suppose it might be desirable to write your guidance broadly enough that the WG can point all the DLEP registries to that guidance. An example of a registry group that uses this kind of approach is https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml which has a header note that says
For IS-IS registries and value ranges maintained via the "Expert
Review" [RFC8126] registration procedure, guidance for IESG-designated
experts can be found in [RFC7370].
Maybe DLEP should do similarly?
HTH,
—John
On Mar 20, 2025, at 9:45 AM, Don Fedyk <[email protected]> wrote:
Thanks for the fast response perhaps we can resolve this.
We asked for a Traffic Classification code entry out of an existing block
This has its own registry that has two entries based on the traffic marking for QoS either Diff Serv Code Points or Ethernet DSCPs. If any other entries desired in they future , they would have to be some identifier in a packet or a frame that could be used to indicate a separate queue/QoS treatment. We left that for future.
We expect a new draft will have to be written that justifies the entry.
So how do we make that more clear?
Thanks
Don
________________________________
From: Murray S. Kucherawy
Sent: Wednesday, March 19, 2025 7:30 PM
To: Don Fedyk
Cc: The IESG; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: Re: Murray Kucherawy's Discuss on draft-ietf-manet-dlep-traffic-classification-13: (with DISCUSS and COMMENT)
On Thu, Mar 20, 2025 at 2:23 AM Don Fedyk <[email protected]<mailto:[email protected]>> wrote:
Thanks for you comments we have posted a version that tries to address all the points,
https://www.ietf.org/archive/id/draft-ietf-manet-dlep-traffic-classification-14.txt<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-manet-dlep-traffic-classification-14.txt__;!!NEt6yMaO-gk!BO-LlykzCPh53bkYlKK2fib4y3uhDL-5a3pF3xwAkPcY0ozXvwuODsJ5oqEb24lmCO2rEOy087A$>
Please check the current IANA request. I cleaned up the text. We are asking for a range that is Specification Required not expert review.
Hi Don,
I'm looking at a diff between -13 and -14, and it doesn't look like anything changed that addresses the concern with Section 5.2. You're still asking for a "Specification Required" chunk of the registry, but providing no advice to the designated experts for the registry regarding how they should resolve requests for that block.
Also note that my DISCUSS has no power anymore as my term has ended. I'm happy to continue the conversation though, plus I think my replacement is likely to take ownership of it at some point soon.
-MSK
_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]