Re: [auth48] AD - Re: AUTH48: RFC-to-be 9435 <draft-ietf-tsvwg-dscp-considerations-13> for your review (round 2)

[Martin Duke <[e-mail]>]

I think expanding MEF would make it easier for the reader, but if they're
engaged in some dumb branding exercise where MEF doesn't stand for
anything, I won't die on that hill. Whatever Alice and Gorry are OK with is
fine.

On Tue, Jul 11, 2023 at 9:06 AM Alice Russo <[e-mail]> wrote:

> Martin, Gorry,
>
> inline.
>
> > On Jul 11, 2023, at 10:16 AM, Martin Duke <[e-mail]>
> wrote:
> >
> > (S4.2.1)
> > You changed "greater than 48 decimal (0x30)" to "greater than 48
> decimals (0x30)"
> >
> > This means "48 in decimal notation" so 48 decimals is definitely wrong.
> I understood the original perfectly well, but if there must be a change
> here it would be better to say "48 in decimal notation (0x30)" or simply
> "(0x30)"
> >
>
> This has been corrected. (Refresh files at same locations as below.)
>
>
> > (S5.4)
> > OLD: Metro Ethernet Forum (MEF)
> > NEW: MEF Forum (MEF)
> > ????!!!????
> >
>
> On https://www.mef.net/ at the end of the page:
> "MEF Forum is a California-based, USA registered 501 c (6) industry
> association." and generally their site uses "MEF" without expansion.
>
> > MEF        - MEF Forum (MEF) (no longer "Metro Ethernet Forum (MEF)")
>
>
> is noted on the RPC's abbreviations list
> (https://www.rfc-editor.org/materials/abbrev.expansion.txt).
>
> If you still want an update, please let us know.
>
> RFC Editor/ar
>
> >
> >
> > On Tue, Jul 11, 2023 at 1:54 AM Gorry Fairhurst <[e-mail]>
> wrote:
> > Hello Alice!
> >
> > Please see below:
> >
> > On 07/07/2023 00:35, Alice Russo wrote:
> >> Gorry and Martin (as AD),
> >>
> >> Martin,
> >> Please review and let us know if you approve the changes listed below.
> They are also visible in this diff file:
> https://www.rfc-editor.org/authors/rfc9435-auth48diff.html
> >>
> >> - Section 3.1: text added re: Best Effort and CS0.
> >> - Sections 6.2, 6.2.1, and 6.3: one sentence added at start of each.
> >> - Figures 2, 3, and 5: new titles.
> >>
> >> The last 2 are per "cross-area INT review":
> >> - Section 4: added text defining unknown DSCP and unexpected DSCP.
> >> - Section 5.1.1: sentence deleted. ("This aligned with the now
> deprecated use of CS1 as the codepoint for the Lower Effort service, as
> previously specified in [RFC4594].")
> >> --
> >>
> >> Gorry,
> >> Thank you for your reply. Please see the follow-ups below. The revised
> files are here (please refresh):
> >>   https://www.rfc-editor.org/authors/rfc9435.html
> >>   https://www.rfc-editor.org/authors/rfc9435.txt
> >>   https://www.rfc-editor.org/authors/rfc9435.pdf
> >>   https://www.rfc-editor.org/authors/rfc9435.xml
> >>
> >> This diff file shows all changes from the approved I-D:
> >>   https://www.rfc-editor.org/authors/rfc9435-diff.html
> >>   https://www.rfc-editor.org/authors/rfc9435-rfcdiff.html (side by
> side)
> >>
> >> This diff file shows the changes made during AUTH48 thus far:
> >>   https://www.rfc-editor.org/authors/rfc9435-auth48diff.html
> >>
> >> Re: #6  ("being re-marked to 'x' & 0x07 and then forwarded")
> >>> GF: I'd prefer to NOT change.  The ampersand here represents a
> "bit-wise and". If this does need to be clarified please propose something.
> >>
> >> Thanks for clarifying. In RFCs, we see it written out as "bitwise AND".
> Below are examples of how it has been defined in some recentish RFCs.
> Perhaps add ("&" represents the bitwise AND operator) after the sentence?
> >>
> >> rfc6225.txt:   "&" is a bitwise AND
> >> rfc7188.txt:   where "bitand" denotes a bitwise AND
> >> rfc8439.txt:   Where "&=" is the C language bitwise AND assignment
> operator.
> >> rfc8554.txt:      AND : a AND b denotes the bitwise AND of the two
> nonnegative
> >> rfc8881.txt:   ("&" represents the bitwise AND operator)
> >> rfc9189.txt:   i & j     bitwise AND of unsigned integers i and j.
> >>
> > * Re: #6  ("being re-marked to 'x' & 0x07 and then forwarded")
> >
> > The proposed resolution is to add a definition to the end of section 2
> to define'&':
> > NEW:
> > In this document, the symbol "&" denotes a bitwise AND of two unsigned
> values.
> >
> > ---
> >>
> >> Re: #11, we updated the figure titles as requested, but the question
> was actually about tables.
> > * We suggest the best way to address the question regarding the table
> headings is to add text below the first use of the table, as below:
> > OLD:
> >    The DSCP space is shown in the following table.
> > NEW:
> >    The DSCP space is shown in the following table. Each row corresponds
> to one setting of the the first three bits of the DSCP field and each
> column to one setting of the the last three bits of the DSCP field.
> >
> > ---
> >> Specifically, should there be any column or row labels added to Table 2
> or 3?
> >>
> >> Re:
> >>> We could add a title row above the bit pattern with the bit number
> within the DS field:
> >>>
> >>> ADD NEW:
> >>> +-+-+-+-+-+-+
> >>> |7|6|5|4|3|2|1|0|
> >>> +-+-+-+-+-+-+
> >>> | ...
> >>> +-+-+-+-+-+-+
> >>
> >> We added this bit ruler, but it's longer than the bits provided; please
> tell us how Figures 2, 3, and 5 should be updated.
> >>
> > * Sorry!!! The following were a result of requested changes, but were
> incorrect, can you please update as shown below:
> >
> > Figure 2 (This should be a 6b field):
> >
> > OLD:
> > +-+-+-+-+-+-+
> > |7|6|5|4|3|2|1|0|
> > +-+-+-+-+-+-+
> > |0 0 0|x x x|
> > +-+-+-+-+-+-+
> > NEW:
> > +-+-+-+-+-+-+
> > |5|4|3|2|1|0|
> > +-+-+-+-+-+-+
> > |0 0 0|x x x|
> > +-+-+-+-+-+-+
> >
> >
> > Figure 3 (This should be a 6b field):
> > OLD:
> > +-+-+-+-+-+-+
> > |7|6|5|4|3|2|1|0|
> > +-+-+-+-+-+-+
> > |0 0 1|x x x|
> > +-+-+-+-+-+-+
> >
> > NEW:
> > +-+-+-+-+-+-+
> > |5|4|3|2|1|0|
> > +-+-+-+-+-+-+
> > |0 0 0|x x x|
> > +-+-+-+-+-+-+
> >
> > Figure 4 (This should be consistent with 2,3 as a 6b field):
> >
> > OLD:
> > +-+-+-+-+-+-+
> > |x x x|. . .|
> > +-+-+-+-+-+-+
> > NEW:
> > +-+-+-+-+-+-+
> > |5|4|3|2|1|0|
> > +-+-+-+-+-+-+
> > |x x x|. . .|
> > +-+-+-+-+-+-+
> >
> > Figure 5:
> > OLD:
> > +-+-+-+-+-+-+
> > |7|6|5|4|3|2|1|0|
> > +-+-+-+-+-+-+
> > |x x x|0 0 0|
> > +-+-+-+-+-+-+
> > NEW:
> > +-+-+-+-+-+-+
> > |5|4|3|2|1|0|
> > +-+-+-+-+-+-+
> > |x x x|0 0 0|
> > +-+-+-+-+-+-+
> >>
> >> Re:
> >>> 1. An updated citation for  [IEEE.802.11] is: [...]  802.11-2016
> >>
> >> Updated as requested. FYI, the page says it was superseded by
> 802.11-2020. Please let us know if you want to update the reference to that.
> >>
> > * - Yes please update.
> >> We will wait to hear from you again and from your coauthors
> >> before continuing the publication process. This page shows
> >> the AUTH48 status of your document:
> >>   https://www.rfc-editor.org/auth48/rfc9435
> >>
> >> Thank you.
> >> RFC Editor/ar
> > * After cross-checking your uypdated text with the RFCs and IEE spec, we
> would like to consistently use the IEEE usage of the term AC. We understand
> that the use of "Access Classes" in RFC8325 is less correct, and was
> inconsistent in that RFC, so please update as follows:
> >
> > OLD
> > The IEEE 802.11 standards [IEEE-802.11] provide Media Access Control
> (MAC) functions to support QoS in WLANs using Access Classes (AC).
> > NEW:
> > The IEEE 802.11 standards [IEEE-802.11] provide Media Access Control
> (MAC) functions to support QoS in WLANs using Access Categories (ACs).
> > ---
> > * The following requested change was actually ambiguous  (sorry) as to
> whether all bits were set to 1 or the combined field had a value of 1.
> Please change:
> > OLD:
> > This considers a proposed DSCP where the least significant 3 bits have a
> value of 1.
> >
> > NEW:
> > This considers a proposed DSCP where the least significant 3 bits
> together represent a value of 1 (i.e., 0b001).
> >
> > ---
> > Please could you also correct some typos:
> >
> > * Please insert /the/:
> > OLD:
> >  defined by IETF,
> > NEW:
> >  defined by the IETF,
> > ---
> > * Two use of the word /new/ in the same sentence seems more than needed
> in the abstract, the new part is the DSCP assignment:
> >
> > OLD:
> > This document discusses considerations for assigning a new recommended
> Differentiated Services Code Point (DSCP) for a new standard Per-Hop
> Behavior (PHB).
> > NEW:
> > This document discusses considerations for assigning a new recommended
> Differentiated Services Code Point (DSCP) for a standard Per-Hop Behavior
> (PHB).
> >
> > ---
> >
> > Thanks for preparing this document. All the editors have now read the
> text and we expect to approve the next version after we confirm these
> updates.
> >
> > Best wishes,
> >
> > Gorry
> >
> >>
> >>> On Jul 4, 2023, at 5:31 AM, Gorry Fairhurst <[e-mail]>
> wrote:
> >>>
> >>> Thank you we have now reviewed your changes, we were quite impressed
> at the level of attention to detail.
> >>> Please see our comments and replies marked "GF", and some additional
> requests at the end.
> >>>
> >>> We plan to complete a full review and approve this, once these changes
> have been implemented.
> >>>
> >>> Best wishes,
> >>> Gorry
> >>>
> >>> ====
> >>>
> >>> Authors,
> >>>
> >>> While reviewing this document during AUTH48, please resolve (as
> necessary) the following questions, which are also in the XML file.
> >>>
> >>> 1) <!-- [rfced] FYI, the title of the document has been updated as
> follows.
> >>>
> >>> Original: Considerations for Assigning a new Recommended DiffServ
> Codepoint
> >>> (DSCP)
> >>>
> >>> Current: Considerations for Assigning a New Recommended Differentiated
> >>> Services Code Point (DSCP)
> >>> -->
> >>>
> >>> GF: Works for me.
> >>>
> >>> 2) <!-- [rfced] FYI: Repeated references
> >>>
> >>> a) Since "[RFC2474]" was cited twice in this sentence, and no other
> >>> citation was present, we placed it at the end of the sentence.
> >>>
> >>> Original:
> >>> It provides differentiated traffic forwarding
> >>> based on the DiffServ Code Point (DSCP) [RFC2474] carried in the
> >>> DiffServ field [RFC2474] of the IP packet header.
> >>>
> >>> Current:
> >>> It provides differentiated traffic forwarding
> >>> based on the DSCP carried in the Diffserv field of the IP packet
> header [RFC2474].
> >>>
> >>> GF: Works for me.
> >>>
> >>> b) Similarly, since "[RFC4594]" was cited twice in this sentence, we
> placed this reference at the end of the sentence.
> >>>
> >>> Original:
> >>> DiffServ associates traffic with a service class [RFC4594] and
> >>> categorises it into Behavior Aggregates [RFC4594].
> >>> Suggested:
> >>> Diffserv associates traffic with a service class and
> >>> categorizes it into Behavior Aggregates [RFC4594]. -->
> >>>
> >>> GF: Works for me.
> >>>
> >>> 3) <!-- [rfced] FYI, we have updated this text to:
> >>> - cite RFC 2474 because it's the source of the quote, and
> >>> - change "standards" to "standardized" to match the source, and
> >>> - include the phrase "if Pool 1 is ever exhausted" because it's in the
> source.
> >>> Please let us know if you prefer otherwise.
> >>>
> >>> Original:
> >>> This was initially available for experimental (EXP) or Local Use
> >>> (LU), but was originally specified to be "preferentially utilized
> >>> for standards assignments" if Pool 1 is ever exhausted.
> >>> Current:
> >>> This was initially available for Experimental (EXP) Use or Local Use
> >>> (LU), but was originally specified to be "preferentially utilized
> >>> for standardized assignments if Pool 1 is ever exhausted" [RFC2474].
> -->
> >>>
> >>> GF: Works for me.
> >>>
> >>> 4) <!-- [rfced] Please note that the quoted text does not appear in
> RFC 8436. Please review and let us know how this may be updated.
> >>> Perhaps you intended the "NEW" text in Section 3 of RFC 8436
> >>> (https://www.rfc-editor.org/rfc/rfc8436#section-3)?
> >>>
> >>> Original:
> >>> Pool 3
> >>> codepoints are now "utilized for standards assignments and are no
> >>> longer available for assignment to experimental or local use"
> >>> [RFC8436].
> >>> Perhaps:
> >>> Pool 3
> >>> codepoints are now "utilized for standardized assignments (replacing
> >>> the previous availability for experimental or local use)" [RFC8436].
> -->
> >>>
> >>> GF: Works for me.
> >>>
> >>> 5) <!-- [rfced] Regarding Table 2 references:
> >>>
> >>> a) Neither "Best Effort" nor "CS0" is mentioned in RFC 2474. How
> should the second row be updated?
> >>>
> >>> GF: Correct - but Class Selector mapping is - this is confusing. A
> sentence or two here would be better to explain these rather complicated
> equivalent words.
> >>>
> >>> OLD:
> >>> BE (Best Effort), also known as "CS0", describes the default
> forwarding treatment.
> >>> NEW:
> >>> The Default PHB is defined in section 4.1 of [RFC2474]. This provides
> Best Effort (BE) forwarding, and the recommended DSCP of  '000000' (section
> 4.2.2.1  of [RFC2474]). This
> >>> is the lowest value in the set of Class Selector (CS) DSCPs, and hence
> is also known as "CS0" [
> https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml].
> >>>
> >>> GF: I realise this may also move the definition of CS earlier, please
> check and correct.
> >>>
> >>> b) "Voice Admit" nor "VA" appears in RFC 5865.
> >>> How should it be updated?
> >>>
> >>> GF: RFC 5865 uses "VOICE-ADMIT" as the name
> >>> GF: It seems industry uses VA as an abbreivation, I'd like to propose
> we keep this (see also below on a caption change).
> >>>
> >>> Perhaps it refers to Call Admission Control?
> >>> GF: No: This is not the same thing.
> >>>
> >>> Current:
> >>> + - + - - - - - - - - - - + - - - - - +
> >>> | CS | Class Selector | [RFC2474] |
> >>> + - + - - - - - - - - - - + - - - - - +
> >>> | BE | Best Effort (CS0) | [RFC2474] |
> >>> + - + - - - - - - - - - - + - - - - - +
> >>> | AF | Assured Forwarding | [RFC2597] |
> >>> + - + - - - - - - - - - - + - - - - - +
> >>> | EF | Expedited Forwarding | [RFC3246] |
> >>> + - + - - - - - - - - - - + - - - - - +
> >>> | VA | Voice Admit | [RFC5865] |
> >>> + - + - - - - - - - - - - + - - - - - +
> >>> | LE | Lower Effort | [RFC8622] |
> >>> + - + - - - - - - - - - - + - - - - - + -->
> >>>
> >>> GF: There is no reason to say "Used in Published RFCs", although that
> was the goal, so I suggest:
> >>>
> >>> OLD:
> >>> Table 2: Summary of the DSCP Abbreviations Used in Published RFCs
> >>>
> >>> NEW:
> >>>
> >>> Table 2: Abbreviations for DSCPs and PHB Groups
> >>>
> >>>
> >>>
> >>> 6) <!--[rfced] Regarding use of ampersand in Section 4.2.1, may it be
> replaced with "and" or is the symbol preferred?
> >>>
> >>> Original:
> >>> ... result in the DSCP being re-marked to 'x' & 0x07 and then
> forwarded using the PHB specified...
> >>>
> >>> Perhaps:
> >>> ... result in the DSCP being re-marked to 'x' and 0x07 and then
> forwarded using the PHB specified...
> >>> -->
> >>> GF: I'd prefer to NOT change.  The ampersand here represents a
> "bit-wise and". If this does need to be
> >>> clarified please propose something.
> >>>
> >>> 7) <!-- [rfced] What do "Section 5.1.2" and "Section 4.1" refer to -
> >>> sections within RFC 8325, IEEE 802.11 UP, or this RFC?
> >>> Original:
> >>> RFC8325 [RFC8325] notes inconsistencies that can result from such re-
> >>> marking, and recommends a different mapping to perform this re-
> >>> marking, dependent on the direction in which a packet is forwarded.
> >>> It provides recommendations for mapping a DSCP to an IEEE 802.11 UP
> >>> for interconnection between wired and wireless networks. The
> >>> recommendation in Section 5.1.2 maps network control traffic, CS6 and
> >>> CS7, as well as unassigned DSCPs, to UP 0 when forwarding in the
> >>> upstream direction (wireless-to-wired). It also recommends mapping
> >>> CS6 and CS7 traffic to UP 7, when forwarding in the downstream
> >>> direction (Section 4.1).
> >>>
> >>> Perhaps as follows?
> >>> - Section 5.1.2 of this document ("Mapping Specified for IEEE 802.11")
> >>> - Section 4.1 of RFC 8325 ("Network Control Traffic")
> >>> -->
> >>>
> >>> GF: This works for me.
> >>>
> >>> 8) <!--[rfced] Regarding Table 5, should the header be updated
> >>> as follows or otherwise? The term "Aggregate Class" does not appear in
> RFC 8100. Should it be defined within this document?
> >>>
> >>> Original:
> >>> | RFC8100 | DSCP | | Agg. Class | |
> >>> Perhaps:
> >>> | Treatment Aggregate [RFC8100] | DSCP |
> >>>
> >>> GF: This works for me.
> >>>
> >>> Similarly, regarding Table 6, should the header be updated as follows
> or otherwise? We note that GSMA IR.34 lists the four "UMTS QoS classes" in
> Section 6.2.1. The term "Aggregate Class" does not appear in IR.34.
> >>>
> >>> Original:
> >>> | GSMA IR.34 | PHB | | Agg. Class | |
> >>> Perhaps:
> >>> | QoS Class in [GSMA-IR.34] | PHB |
> >>> -->
> >>>
> >>> GF: This works for me.
> >>>
> >>> 9) <!-- [rfced] To more clearly indicate the forwarding direction, may
> we update
> >>> the hyphens to "to" in the following?
> >>>
> >>> Original:
> >>> A provider service path may consist of sections where multiple and
> >>> changing layers use their own code points to determine differentiated
> >>> forwarding (e.g., IP - MPLS - IP - Ethernet - Wi-Fi).
> >>>
> >>> Suggested:
> >>> A provider service path may consist of sections where multiple and
> >>> changing layers use their own code points to determine differentiated
> >>> forwarding (e.g., IP to MPLS to IP to Ethernet to Wi-Fi).
> >>> -->
> >>>
> >>> GF: This seems good.
> >>>
> >>> 10) <!--[rfced] Will the use of ampersand in the title of Section
> 6.2.1 be clear to readers? Would it be more clear to write the meaning in
> prose?
> >>>
> >>> Original:
> >>> 6.2. Where the proposed DSCP > 0x07 (7)
> >>> 6.2.1. Where the proposed DSCP&0x07=0x01
> >>> 6.3. Where the proposed DSCP <= 0x07 (7)
> >>> -->
> >>>
> >>> GF: I'm unsure I want to changge.
> >>> GF: I do suggest we add one sentence after each subsection heading
> clarify this:
> >>>
> >>> 6.2. Where the proposed DSCP > 0x07 (7)
> >>> ADD NEW:
> >>> This considers a proposed DSCP with a codepoint larger than 7.
> >>>
> >>> 6.2.1. Where the proposed DSCP&0x07=0x01
> >>> ADD NEW:
> >>> This considers a proposed DSCP where the least significant 3 bits have
> a value of 1.
> >>>
> >>> 6.3. Where the proposed DSCP <= 0x07 (7)
> >>> ADD NEW:
> >>> This considers a proposed DSCP where the DSCP is less than or equal to
> 7.
> >>>
> >>>
> >>> 11) <!-- [rfced] Table Headers
> >>>
> >>> a) In Tables 1, 3, and 4, there's an identical line (Tables 1 and 3,
> last
> >>> row; Table 4, top row). Should this row be in a consistent location
> >>> of each table (e.g., the top row)?
> >>>
> >>> Identical row:
> >>> + - - - + - - + - + - + - + - + - + - +
> >>> | 0/CS0 | 1/LE | 2 | 3 | 4 | 5 | 6 | 7 |
> >>> + - - - + - - + - + - + - + - + - + - +
> >>>
> >>> GF: No: This seems a nice idea, but the row ordering is significant,
> and this corresponds
> >>> to the lowest set of numerical values and belongs at the bottom of
> tables 1,3.
> >>>
> >>> b) For Tables 2, 5, and 6, please consider whether any labels should be
> >>> added to the columns or rows so that it's clearer to the reader what
> the table contains.
> >>> -->
> >>> GF: Please include 3 in this list, it's the same format
> >>> For Tables 2,3,5
> >>>
> >>> We could add a title row above the bit pattern with the bit number
> within the DS field:
> >>>
> >>> ADD NEW:
> >>> +-+-+-+-+-+-+
> >>> |7|6|5|4|3|2|1|0|
> >>> +-+-+-+-+-+-+
> >>> | ...
> >>> +-+-+-+-+-+-+
> >>>
> >>> GF: In addition, I think it would be clearer if the legend explained
> in each case that this was the D
> >>>
> >>> OLD:
> >>> Figure 2: Bleaching of the ToS Precedence
> >>> NEW:
> >>> Figure 2: Bits in the Diffserv field modified by bleaching of the ToS
> Precedence
> >>>
> >>> OLD:
> >>> Figure 3: ToS Precedence Re-marking
> >>> NEW:
> >>> Figure 3: Bits in the Diffserv field modified by ToS Precedence
> Re-marking
> >>>
> >>> OLD:
> >>> Figure 5: Observed Re-marking Behavior Resulting from Deriving from
> UP-to-DSCP Mapping in Some 802.11 Networks
> >>> NEW:
> >>> Figure 5: Bits in the Diffserv field modified by Re-marking Observed
> as a Result of UP-to-DSCP Mapping in Some 802.11 Networks
> >>>
> >>> 12) <!-- [rfced] Terminology
> >>>
> >>> a) Throughout the text, the following terminology appears to be used
> inconsistently. May we update to the version on the right?
> >>>
> >>> ToS Precedence bleaching vs. ToS Precedence Bleaching
> >>> ToS precedence field vs. ToS Precedence field
> >>>
> >>> GF: Please do update as you suggest.
> >>>
> >>> b) We see that "Traffic Class" and "traffic class" along with the
> acronym "TC"
> >>> are used throughout the document. Would you like to expand the first
> instance
> >>> of these and then use the acronyms in the remainder of the document?
> Or do
> >>> you prefer the current usage?
> >>>
> >>> GF: Ah, good question. These are various things with the same name,
> and I think these are mostly correct:
> >>>
> >>> GF: No CHANGE: The term "traffic class", in section 5 is ok
> >>> GF: No CHANGE: The term "traffic class", lower case, in section 5.1 is
> not related to MPLS and should remain in lower case.
> >>> GF: No CHANGE: The term "traffic class", lower case, in section 5.2
> does relate to MPLS.
> >>> GF: No CHANGE: The term "traffic class", lower case, in section 5.3 is
> not related to MPLS and should remain in lower case.
> >>>
> >>>
> >>>
> >>> GF: PLEASE DO UPDATE: The term "traffic class", in section 6.2.1 could
> potentially be confused, and would be better as "PHB":
> >>> OLD:
> >>> demoting the traffic to the Lower Effort traffic class.
> >>> NEW:
> >>> demoting the traffic to the Lower Effort PHB.
> >>>
> >>> c) To avoid confusion with "Access Classes (AC)", may we make "Access
> Categories" lowercase?
> >>>
> >>> Original:
> >>> Then, in turn, this is mapped
> >>> to the four Wi-Fi Multimedia (WMM) Access Categories.
> >>> Perhaps:
> >>> Then, in turn, this is mapped
> >>> to the four Wi-Fi Multimedia (WMM) access categories.
> >>>
> >>> GF: Good note, please go ahead and do this.
> >>>
> >>> d) FYI, we have added expansions for abbreviations upon first use.
> Please review each expansion in the document carefully to ensure
> correctness.
> >>>
> >>> DSCP - Differentiated Services Code Point
> >>> EF - Expedited Forwarding
> >>> EXP - updated "experimental" to "Experimental" per RFC 8126
> >>> IPX - IP Packet eXchange
> >>> LSR - updated "Label-Switched Router" to "Label Switching Router" per
> published RFCs
> >>> LU - updated "local use" to "Local Use" per RFC 8126
> >>> MAC - Media Access Control
> >>> MEF - updated "Metro Ethernet Forum" to "MEF Forum"
> >>> PDB - updated "Per Domain Behavior" to "Per-Domain Behavior" like
> "Per-Hop" in PHB
> >>> P-GW - updated "Packet Gateway" to "Packet Data Network Gateway"
> >>> UMTS - Universal Mobile Telecommunications System
> >>> -->
> >>>
> >>> GF: These changes are all good.
> >>>
> >>> 13) <!-- [rfced] Please review whether any of the notes in this
> document
> >>> should be in the <aside> element. It is defined as "a container for
> content that is semantically less important or tangential to the content
> that surrounds it" (https://authors.ietf.org/rfcxml-vocabulary#aside).
> >>> -->
> >>>
> >>> GF: I am not aware of any content of this type.
> >>>
> >>> 14) <!-- [rfced] Please review the "Inclusive Language" portion of the
> online Style Guide <
> https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> >>> and let us know if any changes are needed.
> >>>
> >>> Note that our script did not flag any words in particular, but this
> should still be reviewed as a best practice.
> >>> -->
> >>>
> >>> GF: We plan to review the entire text bvefore we approve and we will
> review this at this next stage
> >>>
> >>> Thank you.
> >>>
> >>> RFC Editor/st/ar
> >>>
> >>> GF: We have some very late cross-area INT review comments that it was
> suggested we incorporate at this stage:
> >>>
> >>> 1. An updated citation for  [IEEE.802.11] is:
> >>>
> >>> IEEE, "IEEE Standard for Information technology -
> >>> Telecommunications and information exchange between
> >>> systems - Local and metropolitan area networks - Specific
> >>> requirements - Part 11: Wireless LAN Medium Access Control
> >>> (MAC) and Physical Layer (PHY) Specifications",
> >>> IEEE 802.11, DOI 10.1109/IEEESTD.2016.7786995, December
> >>> 2016, https://standards.ieee.org/ieee/8802-11/10034/802.11/5536/.
> >>>
> >>> 2. s/exchange point/diffserv domain boundary/ in Section 4
> >>> OLD:
> >>> and agreements between providers at an exchange point
> >>> NEW:
> >>> and agreements between providers at a diffserv domain boundary
> >>>
> >>>  3. Please remove the following sentence: This aligned with the now
> deprecated use of
> >>> CS1 as the codepoint for the lower effort service, as previously
> specified in [RFC4594].
> >>> DELETE:
> >>> This aligned with the now deprecated use of CS1 as the codepoint for
> the Lower Effort service, as previously specified in [RFC4594].
> >>>
> >>> 4. Explain "unknown" using our agreed text:
> >>> OLD:
> >>> The treatment of packets that are marked with an unknown or an
> unexpected DSCP at Diffserv domain boundaries is determined by the policy
> for a Diffserv domain
> >>> NEW:
> >>> A packet that arrives with a DSCP that is not associated with a PHB,
> results in an “unknown DSCP”. A node could receive a packet with an
> "Unexpected DSCP" due to misconfiguration, or because there is no
> consistent policy in place. The treatment of packets that are marked with
> an unknown or an unexpected DSCP at Diffserv domain boundaries is
> determined by the policy for a Diffserv domain.
> >>>
> >>> ===
> >>>
> >>> Thanks!
> >>>
> >>> On Jul 3, 2023, [e-mail] wrote:
> >>>
> >>> *****IMPORTANT*****
> >>>
> >>> Updated 2023/07/03
> >>>
> >>> RFC Author(s):
> >>> --------------
> >>>
> >>> Instructions for Completing AUTH48
> >>>
> >>> Your document has now entered AUTH48. Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC. If an
> author is no longer available, there are several remedies available as
> listed in the FAQ (https://www.rfc-editor.org/faq/).
> >>>
> >>> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing your
> approval.
> >>>
> >>> Planning your review ---------------------
> >>>
> >>> Please review the following aspects of your document:
> >>>
> >>> * RFC Editor questions
> >>>
> >>> Please review and resolve any questions raised by the RFC Editor that
> have been included in the XML file as comments marked as follows:
> >>>
> >>> <!-- [rfced] ... -->
> >>>
> >>> These questions will also be sent in a subsequent email.
> >>>
> >>> * Changes submitted by coauthors
> >>> Please ensure that you review any changes submitted by your coauthors.
> We assume that if you do not speak up that you agree to changes submitted
> by your coauthors.
> >>>
> >>> * Content
> >>> Please review the full content of the document, as this cannot change
> once the RFC is published. Please pay particular attention to:
> >>> - IANA considerations updates (if applicable)
> >>> - contact information
> >>> - references
> >>>
> >>> * Copyright notices and legends
> >>>
> >>> Please review the copyright notice and legends as defined in
> >>> RFC 5378 and the Trust Legal Provisions (TLP –
> https://trustee.ietf.org/license-info/).
> >>>
> >>> * Semantic markup
> >>>
> >>> Please review the markup in the XML file to ensure that elements of
> content are correctly tagged. For example, ensure that <sourcecode> and
> <artwork> are set correctly. See details at <
> https://authors.ietf.org/rfcxml-vocabulary>.
> >>>
> >>> * Formatted output
> >>>
> >>> Please review the PDF, HTML, and TXT files to ensure that the
> formatted output, as generated from the markup in the XML file, is
> reasonable. Please note that the TXT will have formatting limitations
> compared to the PDF and HTML.
> >>>
> >>>
> >>> Submitting changes
> >>> ------------------
> >>>
> >>> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
> >>>
> >>> * your coauthors
> >>>
> >>> * [e-mail] (the RPC team)
> >>>
> >>> * other document participants, depending on the stream (e.g., IETF
> Stream participants are your working group chairs, the responsible ADs, and
> the document shepherd).
> >>>
> >>> * [e-mail], which is a new archival mailing list
> to preserve AUTH48 conversations; it is not an active discussion list:
> >>>
> >>> * More info:
> >>>
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> >>>
> >>> * The archive itself:
> >>> https://mailarchive.ietf.org/arch/browse/auth48archive/
> >>>
> >>> * Note: If only absolutely necessary, you may temporarily opt out of
> the archiving of messages (e.g., to discuss a sensitive matter).
> >>> If needed, please add a note at the top of the message that you have
> dropped the address. When the discussion is concluded,
> [e-mail] will be re-added to the CC list and its
> addition will be noted at the top of the message.
> >>> You may submit your changes in one of two ways:
> >>>
> >>> An update to the provided XML file
> >>> — OR —
> >>> An explicit list of changes in this format
> >>>
> >>> Section # (or indicate Global)
> >>>
> >>> OLD:
> >>> old text
> >>>
> >>> NEW:
> >>> new text
> >>>
> >>> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
> >>>
> >>> We will ask a stream manager to review and approve any changes that
> seem
> >>> beyond editorial in nature, e.g., addition of new text, deletion of
> text, and technical changes. Information about stream managers can be found
> in the FAQ. Editorial changes do not require approval from a stream manager.
> >>>
> >>>
> >>> Approving for publication
> >>> --------------------------
> >>>
> >>> To approve your RFC for publication, please reply to this email stating
> >>> that you approve this RFC for publication. Please use ‘REPLY ALL’,
> >>> as all the parties CCed on this message need to see your approval.
> >>>
> >>>
> >>> Files -----
> >>>
> >>> The files are available here:
> >>> https://www.rfc-editor.org/authors/rfc9435.xml
> >>> https://www.rfc-editor.org/authors/rfc9435.html
> >>> https://www.rfc-editor.org/authors/rfc9435.pdf
> >>> https://www.rfc-editor.org/authors/rfc9435.txt
> >>>
> >>> Diff file of the text:
> >>> https://www.rfc-editor.org/authors/rfc9435-diff.html
> >>> https://www.rfc-editor.org/authors/rfc9435-rfcdiff.html (side by side)
> >>>
> >>> Diff of the XML:
> https://www.rfc-editor.org/authors/rfc9435-xmldiff1.html
> >>>
> >>> The following files are provided to facilitate creation of your own
> diff files of the XML.
> >>> Initial XMLv3 created using XMLv2 as input:
> >>> https://www.rfc-editor.org/authors/rfc9435.original.v2v3.xml
> >>> XMLv3 file that is a best effort to capture v3-related format updates
> only: https://www.rfc-editor.org/authors/rfc9435.form.xml
> >>>
> >>>
> >>> Tracking progress
> >>> -----------------
> >>>
> >>> The details of the AUTH48 status of your document are here:
> >>> https://www.rfc-editor.org/auth48/rfc9435
> >>>
> >>> Please let us know if you have any questions.
> >>> Thank you for your cooperation,
> >>>
> >>> RFC Editor
> >>>
> >>> --------------------------------------
> >>> RFC9435 (draft-ietf-tsvwg-dscp-considerations-13)
> >>>
> >>> Title : Considerations for Assigning a New Recommended Differentiated
> Services Codepoint                       (DSCP)
> >>> Author(s) : A. Custura, G. Fairhurst, R. Secchi
> >>> WG Chair(s) : Gorry Fairhurst, Marten Seemann
> >>> Area Director(s) : Martin Duke, Zaheduzzaman Sarker
> >>>
> >>> ===
> >>
> >
> >
>
>