Eliot, Authors, Thank you for raising these points. We will plan to remove Section 1.3 as you suggested.
Authors - please let us know if you’d like to add some sort of acknowledgment as Eliot described. We’d also like to add a query to our previous list. 12) The following URLs for DOCSIS Version 3.1 specifications are resulting in a 403 error: URL for [DOCSIS]: <https://www.cablelabs.com/specifications/CM-SP-MULPIv3.1> URL for [DOCSIS-CCAP-OSS]: <https://www.cablelabs.com/specifications/CM-SP-CCAP-OSSIv3.1> [DOCSIS-CM-OSS] <https://www.cablelabs.com/specifications/CM-SP-CM-OSSIv3.1> URL in Table 1: <https://www.cablelabs.com/specifications/CM-SP-MULPIv3.1?v=I21> Can you please provide replacements for these URLs? Note: The DOCSIS Version 4.0 specifications URLs appear to be functioning. Would it be acceptable to update these references to point to DOCSIS 4.0? <https://www.cablelabs.com/specifications/CM-SP-MULPIv4.0> <https://www.cablelabs.com/specifications/CM-SP-CCAP-OSSIv4.0> <https://www.cablelabs.com/specifications/CM-SP-CM-OSSIv4.0> Thank you. Megan Ferguson RFC Production Center > On Apr 7, 2026, at 11:30 AM, Independent Submissions Editor (Eliot Lear) > <[email protected]> wrote: > > In addition, I have the following request: > I'd like this section removed: > 1.3. Copyright Material Parts of this document are reproduced from [DOCSIS] > with kind permission of the copyright holder, Cable Television Laboratories, > Inc. ("CableLabs"). > The issue here is that (a) you are not identifying what is copyrighted, (b) > it conflicts with the IETF copyright, and (c) it will therefore delay > publication. Beyond that, you may leave an acknowledgment to CableLabs for > their contribution to the text. > Eliot > > On 07.04.2026 07:46, [email protected] wrote: >> Authors, >> >> While reviewing this document during AUTH48, please resolve (as necessary) >> the following questions, which are also in the source file. >> >> 1) <!--[rfced] May the "®" be removed from the title? >> We note that previous RFCs with DOCSIS in the title do not use this. >> Also, on this topic, the Chicago Manual of Style says that it is >> not necessary in "publications that are not advertising or sales materials". >> >> Original: The DOCSIS® Queue Protection Algorithm to Preserve Low Latency >> >> Suggested: The DOCSIS Queue Protection Algorithm to Preserve Low Latency >> --> >> >> >> 2) <!--[rfced] We note that the companion document RFC-to-be 9956 >> (draft-ietf-tsvwg-nab-33) cites more information for Reno >> and Cubic. Should citations be added here as well for >> the ease of the reader? >> >> Original: >> The Classic queue is only necessary for traffic such as traditional >> (Reno/Cubic) TCP that needs about a round trip of buffering to fully >> utilize the link, and therefore has no incentive to mismark itself as >> low latency. >> >> Perhaps: >> The Classic queue is only necessary for traffic such as traditional >> (Reno [RFC5681] / Cubic [RFC9438) TCP that needs about a round trip of >> buffering to fully utilize the link; therefore, this traffic has no >> incentive to mismark itself as low latency. >> --> >> >> >> 3) <!--[rfced] FYI, "us" has been updated to "µs" in three instances >> where it follows numerals in comments in the pseudocode. This is >> in keeping with using µs for microseconds in RFC-to-be 9956. >> >> Original: >> 4000us >> 1000us >> 525 us >> >> Current: >> 4000 µs >> 1000 µs >> 525 µs >> --> >> >> >> 4) <!--[rfced] Please review and rephrase the following sentence with >> regard to the clause that begins "but in the floating..." as the >> sentence does not seem to parse as is. >> >> Original: >> The actual DOCSIS >> QProt algorithm is defined using integer arithmetic, but in the >> floating point arithmetic used in this document, (0 <= probNative <= 1). >> >> Perhaps: >> The actual DOCSIS >> QProt algorithm is defined using integer arithmetic, but in the >> floating-point arithmetic used in this document, >> the native marking probability is between 0 and 1 (inclusive), >> i.e., 0 <= probNative <= 1. >> --> >> >> >> 5) <!--[rfced] Section 5 is titled "Rationale". Then there is a >> difference between the formatting of the title of Section 5.1 >> (Rationale:) and the other titles. Might we update as follows? >> >> Original: >> 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 18 >> 5.1. Rationale: Blame for Queuing, not for Rate in Itself . . 18 >> 5.2. Rationale for Constant Aging of the Queuing Score . . . . 20 >> 5.3. Rationale for Transformed Queuing Score . . . . . . . . . 21 >> 5.4. Rationale for Policy Conditions . . . . . . . . . . . . . 22 >> 5.5. Rationale for Reclassification as the Policy Action . . . 25 >> >> Perhaps A (all colons): >> 5. Rationale >> 5.1. Rationale: Blame for Queuing, Not for Rate in Itself >> 5.2. Rationale: Constant Aging of the Queuing Score >> 5.3. Rationale: Transformed Queuing Score >> 5.4. Rationale: Policy Conditions >> 5.5. Rationale: Reclassification as the Policy Action >> >> Perhaps B (all "for"): >> 5. Rationale >> 5.1. Rationale for Blame for Queuing, Not for Rate in Itself >> 5.2. Rationale for Constant Aging of the Queuing Score >> 5.3. Rationale for Transformed Queuing Score >> 5.4. Rationale for Policy Conditions >> 5.5. Rationale for Reclassification as the Policy Action >> >> Perhaps C (just removing as they are all subsections of "Rationale"): >> 5. Rationale >> 5.1. Blame for Queuing, Not for Rate in Itself >> 5.2. Constant Aging of the Queuing Score >> 5.3. Transformed Queuing Score >> 5.4. Policy Conditions >> 5.5. Reclassification as the Policy Action >> --> >> >> >> 6) <!-- [rfced] We had the following questions related to the >> Implementation Status section: >> >> a) Should this section be removed per the guidance in RFC 7942 >> (relevant parts copied below for your convenience)? >> >> We recommend that the Implementation Status section should be removed >> from Internet-Drafts before they are published as RFCs. As a result, >> we do not envisage changes to this section after approval of the >> document for publication, while the document sits in the RFC Editor >> queue, e.g., the RFC errata process does not apply. >> >> This process is not mandatory. Authors of Internet-Drafts are >> encouraged to consider using the process for their documents, and >> working groups are invited to think about applying the process to all >> of their protocol specifications. >> >> ... >> >> This process was initially proposed as an experiment in [RFC6982]. >> That document is now obsoleted, and the process advanced to Best >> Current Practice. >> >> ... >> >> Each Internet-Draft may contain a section entitled "Implementation >> Status". This section, if it appears, should be located just before >> the "Security Considerations" section ... >> >> ... >> >> Since this information is necessarily time dependent, it is >> inappropriate for inclusion in a published RFC. The authors should >> include a note to the RFC Editor requesting that the section be >> removed before publication. >> >> ... >> >> Authors are requested to add a note to the RFC Editor at the top of >> this section, advising the Editor to remove the entire section before >> publication, as well as the reference to RFC 7942. >> >> b) If not, should Table 1 have some sort of title? >> >> c) FYI - In the meantime, we have updated per your guidance on the >> document intake form as follows: >> >> Old:" and one CMTS implementation by a third manufacturer." >> >> Current: " and several CMTS implementations by other manufacturers.” >> --> >> >> >> 7) <!-- [rfced] Please review the following and let us know if any >> further updates are necessary: >> >> The original URLs for [DOCSIS], [DOCSIS-CCAP-OSS], and [DOCSIS-CM-OSS] >> resolved to a blank search results page. We found more-direct URLs for >> these CableLabs specifications and updated the references accordingly. >> >> Note that we also updated the date for [DOCSIS-CCAP-OSS] from "21 >> January 2019" to "7 February 2019" to match the information provided >> at that URL. >> --> >> >> >> 8) <!-- [rfced] FYI: We updated the [BBRv3] and [SCReAM] references to >> match current style guidance for references to web-based public >> code repositories: >> https://www.rfc-editor.org/styleguide/part2/#ref_repo --> >> >> >> 9) <!--[rfced] We had the following questions related to terminology used >> throughout the document: >> >> a) Several sections use "the algorithm" in an opening statement while >> other sections say "The QProt algorithm". Would it be easier for the >> reader to call it "The QProt algorithm" in first mentions in a section >> (and use "the algorithm" thereafter in the section)? Thinking of >> readers that may not read the entire RFC, but instead jump to a >> section from a reference link. >> >> b) We have updated to use the form on the right throughout. Please >> let us know any objections. >> >> IPSec / IPsec (to match RFC 4303) >> flow-ID / flow ID >> >> c) How may we make the following terms consistent throughout? >> >> Congestion-rate vs. congestion-rate >> >> Coupled DualQ AQM vs. Dual Queue Coupled AQM (companion uses "IETF's >> Coupled DualQ AQM") >> >> Diffserv Codepoint vs. Diffserv codepoint (companion uses Diffserv >> Code Point and Differentiated Services Code Point) >> >> flow state vs. flow-state >> >> Native vs. native vs. "Native" >> >> per-flow-state vs. per-flow state >> >> queue protection vs. Queue Protection >> >> >> >> --> >> >> >> 10) <!--[rfced] We had the following questions related to abbreviations >> used throughout the document: >> >> a) FYI - We have added expansions for abbreviations upon first use per >> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >> expansion in the document carefully to ensure correctness. >> >> b) We see that the companion document (draft-ietf-tsvwg-nqb-33) uses >> the following abbreviations: >> >> NQB - Non-Queue-Building >> QB - Queue-Building >> >> We see that this document only uses NQB when mentioning the Diffserv >> codepoint. Can NQB be introduced earlier in the document and be used >> to refer to the general concept? >> >> >> c) We see that [DOCSIS] uses "Queue Protection" rather than "queue >> protection". We see both the capped and lowercase versions used in >> this document. May we update to simply QProt (after first expansion) >> when referring to the algorithm? And/Or are there places where >> capping or lowercasing this term is necessary? If not, please let us >> know how we may make this consistent. >> >> Further, is it QProt algorithm or DOCSIS QProt algorithm? >> >> d) FYI - We have updated the expansion of DOCSIS to use hyphenation >> (i.e., Data-Over-Cable) to match the use in [DOCSIS] and the companion >> document. Please let us know any objections. >> >> e) How may we expand the following abbreviations? >> >> CE >> MAC >> >> f) We will update to use the abbreviated forms of the following after >> expansion on first use (per the guidance at >> https://www.rfc-editor.org/styleguide/part2/#exp_abbrev): >> >> LL >> CM >> >> g) We note that this document uses LL queue as an abbreviation for >> low-latency queue. However, we see RFC 9332 uses "low-latency (L) >> queue". Please review this discrepancy and let us know if any further >> updates are necessary. >> >> Further, please note that we have hyphenated low latency when it appears in >> attributive position to match its use in RFC 9330-9332. >> --> >> >> >> 11) <!-- [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. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> For example, please consider whether the following should be updated: >> >> native >> >> In addition, please consider whether uses of "tradition" should be updated >> for >> clarity. While the NIST website >> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> >> indicates that this term is potentially biased, it is also ambiguous. >> "Tradition" is a subjective term, as it is not the same for everyone. >> --> >> >> >> Thank you. >> >> Megan Ferguson and Alice Russo >> RFC Production Center >> >> On Apr 6, 2026, [email protected] wrote: >> >> *****IMPORTANT***** >> >> Updated 2026/04/06 >> >> 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 >> >> * [email protected] (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). >> >> * [email protected], 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, >> [email protected] 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/rfc9957.xml >> https://www.rfc-editor.org/authors/rfc9957.html >> https://www.rfc-editor.org/authors/rfc9957.pdf >> https://www.rfc-editor.org/authors/rfc9957.txt >> >> Diff file of the text: >> https://www.rfc-editor.org/authors/rfc9957-diff.html >> https://www.rfc-editor.org/authors/rfc9957-rfcdiff.html (side by side) >> >> Diff of the XML: >> https://www.rfc-editor.org/authors/rfc9957-xmldiff1.html >> >> >> Tracking progress >> ----------------- >> >> The details of the AUTH48 status of your document are here: >> https://www.rfc-editor.org/auth48/rfc9957 >> >> Please let us know if you have any questions. >> >> Thank you for your cooperation, >> >> RFC Editor >> >> -------------------------------------- >> RFC9957 (draft-briscoe-docsis-q-protection-07) >> >> Title : The DOCSIS® Queue Protection Algorithm to Preserve Low Latency >> Author(s) : B. Briscoe, Ed., G. White >> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
