[manet] Re: Murray Kucherawy's Discuss on draft-ietf-manet -dlep-traffic-classification-13: (with DISCUSS and COMMENT)
"Andrew Newton (andy)" <[email protected]>
| Newsgroups | gmane.ietf.manet |
|---|---|
| Message-ID | <[email protected]> |
Ok by me. -andy On 3/23/25 21:10, Don Fedyk wrote: > Hi All > > I had an updated version after John Scudder's comment. It makes the same technical points, but it gives more guidance since John had noted previous DLEP drafts were light on DE guidance. > > Please confirm this is still OK > > Thanks > Don > > 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:* Andrew Newton (andy) <[email protected]> > *Sent:* Sunday, March 23, 2025 9:50 AM > *To:* James Guichard <[email protected]> > *Cc:* Don Fedyk <[email protected]>; Murray S. Kucherawy <[email protected]>; The IESG <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> > *Subject:* Re: Murray Kucherawy's Discuss on draft-ietf-manet-dlep-traffic-classification-13: (with DISCUSS and COMMENT) > (this time responding to everybody)... > > Yes, this is good. > > -andy > > On Sun, Mar 23, 2025 at 9:02 AM James Guichard > <[email protected]> wrote: > > > > Adding Andy Newton who now holds the discuss. Andy, please confirm that this new text addresses your discuss. > > > > > > > > Thanks! > > > > > > > > Jim > > > > > > > > From: Don Fedyk <[email protected]> > > Date: Thursday, March 20, 2025 at 1:10 AM > > To: Murray S. Kucherawy <[email protected]> > > Cc: The IESG <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> > > Subject: Re: Murray Kucherawy's Discuss on draft-ietf-manet-dlep-traffic-classification-13: (with DISCUSS and COMMENT) > > > > Thank you I'd propose we add this text below the table: > > > > > > > > 5.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, [RFC2434]. > > > > > > > > This single registry covers packet traffic classification, where > > > > standard packet header identifiers in packets or data frames can be > > > > used to indicate QoS treatment. The two registries requested are > > > > well known identifiers used for QoS in IP networks and Ethernet > > > > networks. > > > > > > > > This registry has reserved values for similar type identifiers that > > > > MAY BE introduced in the future which could indicate QoS treatment. > > > > It is not expected that other entries will be frequently requested. > > > > > > > > Allocations within the registry require documentation of the proposed > > > > use of the allocated value (Specification Required) and approval by > > > > the Designated Expert (DE) assigned by the IESG (see [RFC5226]) and > > > > to verify that the document is permanently and publicly available. > > > > The DE is also expected to check the clarity of purpose and use of > > > > the requested code points. Last, the DE must verify that any > > > > specification produced in the IETF that requests one of these code > > > > points has been made available for review by the MANET or other > > > > appropriate working group and that any specification produced outside > > > > the IETF does not conflict with work that is active or already > > > > published within the IETF. > > > > > > > > Do you think that would satisfy the requirement? > > > > > > > > Thanks again - new registries are new to me > > > > > > > > Don > > > > ________________________________ > > > > From: Murray S. Kucherawy <[email protected]> > > Sent: Wednesday, March 19, 2025 11:32 PM > > To: Don Fedyk <[email protected]> > > Cc: The IESG <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[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 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? > > > > > > > > If someone asks for a code point in your Specification Required range, IANA will forward that request to whoever you offer to appoint as the Designated Expert. That person has to either approve the request, or reply explaining why that request needs correction or should be rejected. How would you like that person to go about making that decision? What criteria do you want them to apply? > > > > > > > > That's what needs to go in Section 5.2. > > > > > > > > -MSK _______________________________________________ manet mailing list -- [email protected] To unsubscribe send an email to [email protected]