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

[Gorry Fairhurst <[e-mail]>]

On 11/07/2023 16:16, Martin Duke 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)"
>
> (S5.4)
> OLD: Metro Ethernet Forum (MEF)
> NEW: MEF Forum (MEF)
> ????!!!????
>
I agree to the above, please add this to the requested changes.

Gorry

>
>
>
> 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>
>>>     <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>
>>>     <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
>>>
>>>     ===
>>
>