We received an error on our end when trying to send this the first time; resending. Apologies if you receive this email twice.
> On Nov 19, 2025, at 10:25 AM, Lynne Bartholomew > <[email protected]> wrote: > > Hi, Donald, Ronald, Lou, and Don. > > Thank you for your replies. Lou, we did not receive your first response, so > thank you for sending another. > > Don, adding you to the "To:" list, because Lou suggests three updates to > RFC-to-be 9892; please see his response below regarding our question 4). > > Donald, Ronald, and Lou, we have updated RFCs-to-be 9893, 9894, and 9895 to > use "credit window scheme" (no hyphen) per your (Donald's and Lou's) notes > below. > > = = = = = > > Please note that we will need the authors to reach agreement regarding our > questions 4), 5), and 6) before we make further updates. Please advise: > > 4): "credit window control" (approx. 24 instances in cluster) vs. "credit > window flow control" > (3 instances in cluster): Authors need to reach agreement on this. > > Donald's reply: > Yes, I would say they mean the same thing in these documents. "credit > window flow control" is just a more complete term and if there are > seveal uses in the same paragraph or the like, it is reasonable to use > the more complete term initially and the shortened term subsequently. > > Lou's reply: > So the, albeit subtle, distinction between the terms is that "credit window > flow control" is the overall preprocess of using credit-based flow control, > while "credit window control" relates to the mechanisms/procedures defined to > grant and maintain credits. I think the alternatives are to leave as is or to > clarify the distinction. > for the latter, my suggestions are: > OLD > credit/draft-ietf-manet-dlep-da-credit-extension.xml: credit window control > mechanisms defined in <xref > credit/draft-ietf-manet-dlep-da-credit-extension.xml: the credit window > control and flow mechanisms defined in <xref > ether-credit/draft-ietf-manet-dlep-ether-credit-extension.xml: traffic > classification and credit window control mechanisms > ether-credit/draft-ietf-manet-dlep-ether-credit-extension.xml: and the > credit window control and flow mechanisms defined in > tc/draft-ietf-manet-dlep-traffic-classification.xml: with applications > such as credit window control as specified in > tc/draft-ietf-manet-dlep-traffic-classification.xml: The credit window > control document provides an > tc/draft-ietf-manet-dlep-traffic-classification.xml: credit window > control, allows credit windows to be shared > fc/draft-ietf-manet-dlep-credit-flow-control.xml: Credit window control > is used to regulate when data may be sent to > fc/draft-ietf-manet-dlep-credit-flow-control.xml: introduces support for > credit window control by defining two new DLEP > fc/draft-ietf-manet-dlep-credit-flow-control.xml: The use of credit window > control impacts the data plane. > fc/draft-ietf-manet-dlep-credit-flow-control.xml: The credit window > control mechanisms defined in this document > fc/draft-ietf-manet-dlep-credit-flow-control.xml: requiring the use of > credit window control is used. > fc/draft-ietf-manet-dlep-credit-flow-control.xml: The defined credit > window control has similar objectives as the > fc/draft-ietf-manet-dlep-credit-flow-control.xml: Two new messages are > defined in support for credit window control: > fc/draft-ietf-manet-dlep-credit-flow-control.xml: <name>Credit Window > Control Data Items</name> > fc/draft-ietf-manet-dlep-credit-flow-control.xml: Five new Data Items > are defined to support credit window control. > fc/draft-ietf-manet-dlep-credit-flow-control.xml: the credit window > control defined in this document is used. Note > fc/draft-ietf-manet-dlep-credit-flow-control.xml: This document introduces > credit window control and flow mechanisms > NEW > credit/draft-ietf-manet-dlep-da-credit-extension.xml: credit window flow > control mechanisms defined in <xref > credit/draft-ietf-manet-dlep-da-credit-extension.xml: the credit window > flow control mechanisms defined in <xref > ether-credit/draft-ietf-manet-dlep-ether-credit-extension.xml: traffic > classification and credit window flow control mechanisms > ether-credit/draft-ietf-manet-dlep-ether-credit-extension.xml: and the > credit window flow control mechanisms defined in > tc/draft-ietf-manet-dlep-traffic-classification.xml: with applications > such as credit window flow control as specified in > tc/draft-ietf-manet-dlep-traffic-classification.xml: The credit window > flow control document provides an > fc/draft-ietf-manet-dlep-credit-flow-control.xml: introduces support for > credit window flow control by defining two new DLEP > tc/draft-ietf-manet-dlep-traffic-classification.xml: credit window flow > control, allows credit windows to be shared > fc/draft-ietf-manet-dlep-credit-flow-control.xml: Credit window flow > control is used to regulate when data may be sent to > fc/draft-ietf-manet-dlep-credit-flow-control.xml: <name>Credit Window > Flow Control</name> > fc/draft-ietf-manet-dlep-credit-flow-control.xml: REPLACE: The use of > credit window control impacts the data plane. > > WITH: The additions provide the DLEP mechanisms to control > credits. Routers then use this > > information to regulate when data is sent to a modem. > fc/draft-ietf-manet-dlep-credit-flow-control.xml: The credit window flow > control mechanisms defined in this document > fc/draft-ietf-manet-dlep-credit-flow-control.xml: requiring the use of > credit window flow control is used. > fc/draft-ietf-manet-dlep-credit-flow-control.xml: The defined credit > window flow control has similar objectives as the > fc/draft-ietf-manet-dlep-credit-flow-control.xml: Two new messages are > defined in support for control of credit windows: > fc/draft-ietf-manet-dlep-credit-flow-control.xml: Five new Data Items > are defined to support the control of credit windows. > fc/draft-ietf-manet-dlep-credit-flow-control.xml: the credit window > flow control defined in this document is used. Note > fc/draft-ietf-manet-dlep-credit-flow-control.xml: This document introduces > credit window flow control mechanisms > some of the above could refer to ether the process or the mechanisms , in > which case I chose process. I think this leaves one instance: > fc/draft-ietf-manet-dlep-credit-flow-control.xml: <name>Credit Window > Control Data Items</name> > I think this is better then "Data Items for the Control of Credit Windows" -- > but this too is acceptable. > > > 5): "Type Value" vs: "Type value": Authors need to reach agreement on this. > > Donald's reply: > I am inclined to capitalize Value. > > Lou's reply: > lower case. to be consistent with rfc8175. > > > 6): 'Rick Taylor's "Data Item Containers"' only mentioned in two of the four > documents: Authors need to reach agreement on the following: > > Donald's reply: > Yes, I think it would be reasonable and consistant to add that > sentence to the Acknowledgements sections of the other two > drafts. They all mention Data Items. > > Ronald's reply: > Here I have to disagree with my esteemed co-chair. Note that I am not an > author on any of these documents, so consider the following as no more than an > opinion. > > I would move in the opposite direction and keep the acknowledgment of Rick > Taylor as "the father of Sub-Data Items" *only* in > draft-ietf-manet-traffic-classification. It is not my intention to diminish in > any way the numerous and important contributions of Rick Taylor to the cluster > of credit-based flow control I-Ds, DLEP as a whole or the MANET WG in general, > but the mention of "Data Item Containers" as a predecessor of "Sub-Data Items" > only makes sense in draft-ietf-manet-dlep-traffic-classification as this is > the only document in the cluster to actually specify Sub-Data Items. I believe > the acknowledgment of Rick Taylor in draft-ietf-manet-dlep-da-credit-extension > is there for "hysterical raisins", i.e., as a left-over from the earliest > versions of this draft which included the Traffic Classification Data Item and > its Sub-Data Items before these were moved elsewhere in version -05. See also > the Acknowledgment section of RFC 8651. (As an aside: I don't like "Sub-Data > Item" as a term. I would have preferred "Data Item Sub-item" or perhaps "Data > Sub-item" or "Data Item Sub-TLV". It is way too late to make any such change, > however, because RFC 8651 has set a precedent). > > Lou's reply: > I'd leave as is or go with Ronald's proposal. > > = = = = = > > In the meantime, the latest copies of RFCs-to-be 9893, 9894, and 9895 are > posted here. Please refresh your browser: > > https://www.rfc-editor.org/authors/rfc9893.txt > https://www.rfc-editor.org/authors/rfc9893.pdf > https://www.rfc-editor.org/authors/rfc9893.html > https://www.rfc-editor.org/authors/rfc9893.xml > https://www.rfc-editor.org/authors/rfc9893-diff.html > https://www.rfc-editor.org/authors/rfc9893-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9893-auth48diff.html > https://www.rfc-editor.org/authors/rfc9893-auth48rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9893-alt-diff.html > https://www.rfc-editor.org/authors/rfc9893-xmldiff1.html > https://www.rfc-editor.org/authors/rfc9893-xmldiff2.html > https://www.rfc-editor.org/authors/rfc9893-alt-diff.html > ------------------------------------------------------------------------------- > https://www.rfc-editor.org/authors/rfc9894.txt > https://www.rfc-editor.org/authors/rfc9894.pdf > https://www.rfc-editor.org/authors/rfc9894.html > https://www.rfc-editor.org/authors/rfc9894.xml > https://www.rfc-editor.org/authors/rfc9894-diff.html > https://www.rfc-editor.org/authors/rfc9894-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9894-auth48diff.html > https://www.rfc-editor.org/authors/rfc9894-auth48rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9894-lastdiff.html > https://www.rfc-editor.org/authors/rfc9894-lastrfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9894-xmldiff1.html > https://www.rfc-editor.org/authors/rfc9894-xmldiff2.html > ------------------------------------------------------------------------------- > https://www.rfc-editor.org/authors/rfc9895.txt > https://www.rfc-editor.org/authors/rfc9895.pdf > https://www.rfc-editor.org/authors/rfc9895.html > https://www.rfc-editor.org/authors/rfc9895.xml > https://www.rfc-editor.org/authors/rfc9895-diff.html > https://www.rfc-editor.org/authors/rfc9895-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9895-auth48diff.html > https://www.rfc-editor.org/authors/rfc9895-auth48rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9895-lastdiff.html > https://www.rfc-editor.org/authors/rfc9895-lastrfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9895-xmldiff1.html > https://www.rfc-editor.org/authors/rfc9895-xmldiff2.html > > Thanks again! > > Lynne Bartholomew > RFC Production Center > > >> On Nov 19, 2025, at 5:14 AM, Lou Berger <[email protected]> wrote: >> >> Donald, >> >> Thank you for the response! please see my email (which got delayed due to >> mailer issues) and let me/us know if you are okay with my responses. >> >> Lou >> >> On 11/17/2025 5:50 PM, Donald Eastlake wrote: >>> Hi, >>> >>> On Fri, Nov 14, 2025 at 5:16 PM <[email protected]> wrote: >>>> Authors and AD*, >>>> >>>> *AD, please see #1 below. >>>> >>>> Authors, while reviewing this cluster of documents*, please reply to >>>> the questions below regarding consistency across the cluster. These >>>> questions are in addition to the document-specific questions sent >>>> for each RFC-to-be. Your reply will likely impact two or more of the >>>> documents in the cluster, so please discuss off-list as necessary, >>>> and then let us know how to proceed. Note - You have the option of >>>> updating the edited XML files yourself, if you prefer. We will wait >>>> to hear from you before continuing with the publication process. >>>> >>>> * Cluster 541 (C541) currently in AUTH48 state: >>>> https://www.rfc-editor.org/authors/rfc9892.html >>>> https://www.rfc-editor.org/authors/rfc9893.html >>>> https://www.rfc-editor.org/authors/rfc9894.html >>>> https://www.rfc-editor.org/authors/rfc9895.html >>>> (In addition, the .pdf, .txt, .xml, and diff files are available.) >>>> >>>> You may track the progress of all documents in this cluster through >>>> AUTH48 at: https://www.rfc-editor.org/auth48/C541 >>>> >>>> 1) *AD - We are sorry to hear of the passing of David Wiggins and >>>> Stan Ratliff. David is listed as an author for RFCs-to-be 9892, >>>> 9893, 9894, and 9895 (all documents in the cluster). Stan is listed >>>> as an author for RFC-to-be 9893. >>>> >>>> As AD, please confirm that you will approve the documents on behalf >>>> of David and Stan. (Note: Any of the three options at >>>> https://www.rfc-editor.org/faq/#missingauthor are acceptable.) >>>> >>>> 2) FYI - We updated "DiffServ" to "Diffserv" throughout the cluster >>>> per https://www.rfc-editor.org/rpc/wiki/doku.php?id=terms. If no >>>> objections, we will ask IANA to update the following descriptions >>>> prior to publication. >>>> Link to registry group: https://www.iana.org/assignments/dlep-parameters >>>> >>>> "Traffic Classification Sub-Data Item Type Values" registry >>>> (draft-ietf-manet-dlep-traffic-classification): >>>> >>>> OLD: >>>> DiffServ Traffic Classification >>>> >>>> NEW: >>>> Diffserv Traffic Classification >>>> >>>> "Extension Type Values" registry >>>> (draft-ietf-manet-dlep-da-credit-extension): >>>> >>>> OLD: >>>> DiffServ Aware Credit Window >>>> >>>> NEW: >>>> Diffserv Aware Credit Window >>> I think these updates to only an initial captial letter are fine and >>> result in conformance to RFC Editor defaults. >>> >>>> 3) We see "Credit window control" (beginning of sentence, so the "C" is >>>> capitalized) but "credit-window scheme". We suggest updating to "credit >>>> window >>>> scheme" (no hyphen). >>> OK with me. >>> >>>> 4) Do "credit window control" (approx. 24 instances in cluster) and "credit >>>> window flow control" (3 instances in cluster) mean the same thing? Will >>>> the >>>> interchangeable usage of these terms - or the distinction between the two - >>>> be clear to readers? >>> Yes, I would say they mean the same thing in these documents. "credit >>> window flow control" is just a more complete term and if there are >>> seveal uses in the same paragraph or the like, it is reasonable to use >>> the more complete term initially and the shortened term subsequently. >>> >>>> 5) We see both "Type Value" and "Type value" in running text. Which >>>> form is preferred? >>>> >>>> Some examples: >>>> "Message Type value" in draft-ietf-manet-dlep-credit-flow-control >>>> >>>> "DLEP Extension Type Value" in >>>> draft-ietf-manet-dlep-da-credit-extension and >>>> draft-ietf-manet-dlep-ether-credit-extension >>>> >>>> "DiffServ Aware Credit Window Type Value" in >>>> draft-ietf-manet-dlep-da-credit-extension >>>> >>>> "IEEE 802.1Q Aware Credit Window Type Value" in >>>> draft-ietf-manet-dlep-ether-credit-extension >>> I am inclined to capitalize Value. >>> >>>> 6) 'Rick Taylor's "Data Item Containers"' is only mentioned in the >>>> Acknowledgments sections of two of the four documents in this group >>>> (draft-ietf-manet-dlep-traffic-classification and >>>> draft-ietf-manet-dlep-da-credit-extension). Would you like to add the >>>> applicable sentence to the Acknowledgments sections of >>>> draft-ietf-manet-dlep-credit-flow-control and >>>> draft-ietf-manet-dlep-ether-credit-extension as well? >>> Yes, I think it would be reasonable and consistant to add that >>> sentence to the Acknowledgements sections of the other two >>> drafts. They all mention Data Items. >>> >>> Thanks, >>> Donald >>> =============================== >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 2386 Panoramic Circle, Apopka, FL 32703 USA >>> [email protected] > > >> On Nov 19, 2025, at 5:11 AM, Lou Berger <[email protected]> wrote: >> >> sigh - my mailer (on my phone) seems to have eaten my first response. [If >> you have a copy, please send it back to me ;-)] >> This response has additional response - so if you did receive the first >> message, please use this message in its place. >> Thank you, >> Lou >> PS I see there are other responses (Thank you!) and I'll respond to those if >> I have anything to add. >> On 11/14/2025 5:16 PM, [email protected] wrote: >>> Authors and AD*, >>> >>> *AD, please see #1 below. >>> >>> Authors, while reviewing this cluster of documents*, please reply to the >>> questions below regarding consistency across the cluster. These questions >>> are >>> in addition to the document-specific questions sent for each RFC-to-be. Your >>> reply will likely impact two or more of the documents in the cluster, so >>> please discuss off-list as necessary, and then let us know how to >>> proceed. Note - You have the option of updating the edited XML files >>> yourself, >>> if you prefer. We will wait to hear from you before continuing with the >>> publication process. >>> >>> * Cluster 541 (C541) currently in AUTH48 state: >>> https://www.rfc-editor.org/authors/rfc9892.html >>> https://www.rfc-editor.org/authors/rfc9893.html >>> https://www.rfc-editor.org/authors/rfc9894.html >>> https://www.rfc-editor.org/authors/rfc9895.html >>> (In addition, the .pdf, .txt, .xml, and diff files are available.) >>> >>> You may track the progress of all documents in this cluster through AUTH48 >>> at: >>> https://www.rfc-editor.org/auth48/C541 >>> >>> >>> 1) *AD - We are sorry to hear of the passing of David Wiggins and Stan >>> Ratliff. David is listed as an author for RFCs-to-be 9892, 9893, 9894, and >>> 9895 (all documents in the cluster). Stan is listed as an author for >>> RFC-to-be >>> 9893. >>> >>> As AD, please confirm that you will approve the documents on behalf of David >>> and Stan. (Note: Any of the three options at >>> https://www.rfc-editor.org/faq/#missingauthor are acceptable.) >>> >>> >>> 2) FYI - We updated "DiffServ" to "Diffserv" throughout the cluster per >>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=terms. If no objections, we >>> will ask IANA to update the following descriptions prior to publication. >>> >>> Link to registry group: https://www.iana.org/assignments/dlep-parameters >>> >>> "Traffic Classification Sub-Data Item Type Values" registry >>> (draft-ietf-manet-dlep-traffic-classification): >>> >>> OLD: >>> DiffServ Traffic Classification >>> >>> NEW: >>> Diffserv Traffic Classification >>> >>> "Extension Type Values" registry >>> (draft-ietf-manet-dlep-da-credit-extension): >>> >>> OLD: >>> DiffServ Aware Credit Window >>> >>> NEW: >>> Diffserv Aware Credit Window >>> >> looks, right. Thank you. >> >>> >>> 3) We see "Credit window control" (beginning of sentence, so the "C" is >>> capitalized) but "credit-window scheme". We suggest updating to "credit >>> window >>> scheme" (no hyphen). >>> >> Sure. >>> >>> >>> 4) Do "credit window control" (approx. 24 instances in cluster) and "credit >>> window flow control" (3 instances in cluster) mean the same thing? Will the >>> interchangeable usage of these terms - or the distinction between the two - >>> be clear to readers? >>> >> So the, albeit subtle, distinction between the terms is that "credit window >> flow control" is the overall preprocess of using credit-based flow control, >> while "credit window control" relates to the mechanisms/procedures defined >> to grant and maintain credits. I think the alternatives are to leave as is >> or to clarify the distinction. >> for the latter, my suggestions are: >> OLD >> credit/draft-ietf-manet-dlep-da-credit-extension.xml: credit window control >> mechanisms defined in <xref >> credit/draft-ietf-manet-dlep-da-credit-extension.xml: the credit window >> control and flow mechanisms defined in <xref >> ether-credit/draft-ietf-manet-dlep-ether-credit-extension.xml: >> traffic classification and credit window control mechanisms >> ether-credit/draft-ietf-manet-dlep-ether-credit-extension.xml: and >> the credit window control and flow mechanisms defined in >> tc/draft-ietf-manet-dlep-traffic-classification.xml: with applications >> such as credit window control as specified in >> tc/draft-ietf-manet-dlep-traffic-classification.xml: The credit window >> control document provides an >> tc/draft-ietf-manet-dlep-traffic-classification.xml: credit window >> control, allows credit windows to be shared >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: Credit window control >> is used to regulate when data may be sent to >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: introduces support >> for credit window control by defining two new DLEP >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: The use of credit >> window control impacts the data plane. >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: The credit window >> control mechanisms defined in this document >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: requiring the use of >> credit window control is used. >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: The defined credit >> window control has similar objectives as the >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: Two new messages are >> defined in support for credit window control: >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: <name>Credit Window >> Control Data Items</name> >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: Five new Data Items >> are defined to support credit window control. >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: the credit window >> control defined in this document is used. Note >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: This document >> introduces credit window control and flow mechanisms >> NEW >> credit/draft-ietf-manet-dlep-da-credit-extension.xml: credit window flow >> control mechanisms defined in <xref >> credit/draft-ietf-manet-dlep-da-credit-extension.xml: the credit window >> flow control mechanisms defined in <xref >> ether-credit/draft-ietf-manet-dlep-ether-credit-extension.xml: >> traffic classification and credit window flow control mechanisms >> ether-credit/draft-ietf-manet-dlep-ether-credit-extension.xml: and >> the credit window flow control mechanisms defined in >> tc/draft-ietf-manet-dlep-traffic-classification.xml: with applications >> such as credit window flow control as specified in >> tc/draft-ietf-manet-dlep-traffic-classification.xml: The credit window >> flow control document provides an >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: introduces support >> for credit window flow control by defining two new DLEP >> tc/draft-ietf-manet-dlep-traffic-classification.xml: credit window flow >> control, allows credit windows to be shared >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: Credit window flow >> control is used to regulate when data may be sent to >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: <name>Credit Window >> Flow Control</name> >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: REPLACE: The use of >> credit window control impacts the data plane. >> >> WITH: The additions provide the DLEP mechanisms to control >> credits. Routers then use this >> >> information to regulate when data is sent to a >> modem. >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: The credit window flow >> control mechanisms defined in this document >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: requiring the use of >> credit window flow control is used. >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: The defined credit >> window flow control has similar objectives as the >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: Two new messages are >> defined in support for control of credit windows: >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: Five new Data Items >> are defined to support the control of credit windows. >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: the credit window >> flow control defined in this document is used. Note >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: This document >> introduces credit window flow control mechanisms >> some of the above could refer to ether the process or the mechanisms , in >> which case I chose process. I think this leaves one instance: >> fc/draft-ietf-manet-dlep-credit-flow-control.xml: <name>Credit Window >> Control Data Items</name> >> I think this is better then "Data Items for the Control of Credit Windows" >> -- but this too is acceptable. >>> >>> 5) We see both "Type Value" and "Type value" in running text. Which form is >>> preferred? >>> >>> Some examples: >>> "Message Type value" in draft-ietf-manet-dlep-credit-flow-control >>> >>> "DLEP Extension Type Value" in draft-ietf-manet-dlep-da-credit-extension and >>> draft-ietf-manet-dlep-ether-credit-extension >>> >>> "DiffServ Aware Credit Window Type Value" in >>> draft-ietf-manet-dlep-da-credit-extension >>> >>> "IEEE 802.1Q Aware Credit Window Type Value" in >>> draft-ietf-manet-dlep-ether-credit-extension >>> >>> >> lower case. to be consistent with rfc8175. >>> 6) 'Rick Taylor's "Data Item Containers"' is only mentioned in the >>> Acknowledgments sections of two of the four documents in this group >>> (draft-ietf-manet-dlep-traffic-classification and >>> draft-ietf-manet-dlep-da-credit-extension). Would you like to add the >>> applicable sentence to the Acknowledgments sections of >>> draft-ietf-manet-dlep-credit-flow-control and >>> draft-ietf-manet-dlep-ether-credit-extension as well? >>> >> I'd leave as is or go with Ronald's proposal. >> Thank you! >> Lou > > >> On Nov 18, 2025, at 3:42 PM, Lou Berger <[email protected]> wrote: >> >> WFM - thanks! >> >> Lou >> >> On 11/18/2025 6:37 PM, Velt, R. (Ronald) in 't wrote: >>> Hi, >>> >>>>> 6) 'Rick Taylor's "Data Item Containers"' is only mentioned in the >>>>> Acknowledgments sections of two of the four documents in this group >>>>> (draft-ietf-manet-dlep-traffic-classification and >>>>> draft-ietf-manet-dlep-da-credit-extension). Would you like to add the >>>>> applicable sentence to the Acknowledgments sections of >>>>> draft-ietf-manet-dlep-credit-flow-control and >>>>> draft-ietf-manet-dlep-ether-credit-extension as well? >>>> Yes, I think it would be reasonable and consistant to add that sentence to >>>> the Acknowledgements sections of the other two drafts. They all mention >>>> Data Items. >>> Here I have to disagree with my esteemed co-chair. Note that I am not an >>> author on any of these documents, so consider the following as no more than >>> an >>> opinion. >>> >>> I would move in the opposite direction and keep the acknowledgment of Rick >>> Taylor as "the father of Sub-Data Items" *only* in >>> draft-ietf-manet-traffic-classification. It is not my intention to diminish >>> in >>> any way the numerous and important contributions of Rick Taylor to the >>> cluster >>> of credit-based flow control I-Ds, DLEP as a whole or the MANET WG in >>> general, >>> but the mention of "Data Item Containers" as a predecessor of "Sub-Data >>> Items" >>> only makes sense in draft-ietf-manet-dlep-traffic-classification as this is >>> the only document in the cluster to actually specify Sub-Data Items. I >>> believe >>> the acknowledgment of Rick Taylor in >>> draft-ietf-manet-dlep-da-credit-extension >>> is there for "hysterical raisins", i.e., as a left-over from the earliest >>> versions of this draft which included the Traffic Classification Data Item >>> and >>> its Sub-Data Items before these were moved elsewhere in version -05. See >>> also >>> the Acknowledgment section of RFC 8651. (As an aside: I don't like "Sub-Data >>> Item" as a term. I would have preferred "Data Item Sub-item" or perhaps >>> "Data >>> Sub-item" or "Data Item Sub-TLV". It is way too late to make any such >>> change, >>> however, because RFC 8651 has set a precedent). >>> >>> Thanks, >>> Ronald >> > > >> On Nov 18, 2025, at 3:37 PM, Velt, R. (Ronald) in 't >> <[email protected]> wrote: >> >> Hi, >> >>>> 6) 'Rick Taylor's "Data Item Containers"' is only mentioned in the >>>> Acknowledgments sections of two of the four documents in this group >>>> (draft-ietf-manet-dlep-traffic-classification and >>>> draft-ietf-manet-dlep-da-credit-extension). Would you like to add the >>>> applicable sentence to the Acknowledgments sections of >>>> draft-ietf-manet-dlep-credit-flow-control and >>>> draft-ietf-manet-dlep-ether-credit-extension as well? >>> >>> Yes, I think it would be reasonable and consistant to add that sentence to >>> the Acknowledgements sections of the other two drafts. They all mention >>> Data Items. >> >> Here I have to disagree with my esteemed co-chair. Note that I am not an >> author on any of these documents, so consider the following as no more than >> an >> opinion. >> >> I would move in the opposite direction and keep the acknowledgment of Rick >> Taylor as "the father of Sub-Data Items" *only* in >> draft-ietf-manet-traffic-classification. It is not my intention to diminish >> in >> any way the numerous and important contributions of Rick Taylor to the >> cluster >> of credit-based flow control I-Ds, DLEP as a whole or the MANET WG in >> general, >> but the mention of "Data Item Containers" as a predecessor of "Sub-Data >> Items" >> only makes sense in draft-ietf-manet-dlep-traffic-classification as this is >> the only document in the cluster to actually specify Sub-Data Items. I >> believe >> the acknowledgment of Rick Taylor in >> draft-ietf-manet-dlep-da-credit-extension >> is there for "hysterical raisins", i.e., as a left-over from the earliest >> versions of this draft which included the Traffic Classification Data Item >> and >> its Sub-Data Items before these were moved elsewhere in version -05. See >> also >> the Acknowledgment section of RFC 8651. (As an aside: I don't like "Sub-Data >> Item" as a term. I would have preferred "Data Item Sub-item" or perhaps >> "Data >> Sub-item" or "Data Item Sub-TLV". It is way too late to make any such >> change, >> however, because RFC 8651 has set a precedent). >> >> Thanks, >> Ronald > > >> On Nov 17, 2025, at 2:50 PM, Donald Eastlake <[email protected]> wrote: >> >> Hi, >> >> On Fri, Nov 14, 2025 at 5:16 PM <[email protected]> wrote: >>> >>> Authors and AD*, >>> >>> *AD, please see #1 below. >>> >>> Authors, while reviewing this cluster of documents*, please reply to >>> the questions below regarding consistency across the cluster. These >>> questions are in addition to the document-specific questions sent >>> for each RFC-to-be. Your reply will likely impact two or more of the >>> documents in the cluster, so please discuss off-list as necessary, >>> and then let us know how to proceed. Note - You have the option of >>> updating the edited XML files yourself, if you prefer. We will wait >>> to hear from you before continuing with the publication process. >>> >>> * Cluster 541 (C541) currently in AUTH48 state: >>> https://www.rfc-editor.org/authors/rfc9892.html >>> https://www.rfc-editor.org/authors/rfc9893.html >>> https://www.rfc-editor.org/authors/rfc9894.html >>> https://www.rfc-editor.org/authors/rfc9895.html >>> (In addition, the .pdf, .txt, .xml, and diff files are available.) >>> >>> You may track the progress of all documents in this cluster through >>> AUTH48 at: https://www.rfc-editor.org/auth48/C541 >>> >>> 1) *AD - We are sorry to hear of the passing of David Wiggins and >>> Stan Ratliff. David is listed as an author for RFCs-to-be 9892, >>> 9893, 9894, and 9895 (all documents in the cluster). Stan is listed >>> as an author for RFC-to-be 9893. >>> >>> As AD, please confirm that you will approve the documents on behalf >>> of David and Stan. (Note: Any of the three options at >>> https://www.rfc-editor.org/faq/#missingauthor are acceptable.) >>> >>> 2) FYI - We updated "DiffServ" to "Diffserv" throughout the cluster >>> per https://www.rfc-editor.org/rpc/wiki/doku.php?id=terms. If no >>> objections, we will ask IANA to update the following descriptions >>> prior to publication. >> >>> Link to registry group: https://www.iana.org/assignments/dlep-parameters >>> >>> "Traffic Classification Sub-Data Item Type Values" registry >>> (draft-ietf-manet-dlep-traffic-classification): >>> >>> OLD: >>> DiffServ Traffic Classification >>> >>> NEW: >>> Diffserv Traffic Classification >>> >>> "Extension Type Values" registry >>> (draft-ietf-manet-dlep-da-credit-extension): >>> >>> OLD: >>> DiffServ Aware Credit Window >>> >>> NEW: >>> Diffserv Aware Credit Window >> >> I think these updates to only an initial captial letter are fine and >> result in conformance to RFC Editor defaults. >> >>> 3) We see "Credit window control" (beginning of sentence, so the "C" is >>> capitalized) but "credit-window scheme". We suggest updating to "credit >>> window >>> scheme" (no hyphen). >> >> OK with me. >> >>> 4) Do "credit window control" (approx. 24 instances in cluster) and "credit >>> window flow control" (3 instances in cluster) mean the same thing? Will the >>> interchangeable usage of these terms - or the distinction between the two - >>> be clear to readers? >> >> Yes, I would say they mean the same thing in these documents. "credit >> window flow control" is just a more complete term and if there are >> seveal uses in the same paragraph or the like, it is reasonable to use >> the more complete term initially and the shortened term subsequently. >> >>> 5) We see both "Type Value" and "Type value" in running text. Which >>> form is preferred? >>> >>> Some examples: >>> "Message Type value" in draft-ietf-manet-dlep-credit-flow-control >>> >>> "DLEP Extension Type Value" in >>> draft-ietf-manet-dlep-da-credit-extension and >>> draft-ietf-manet-dlep-ether-credit-extension >>> >>> "DiffServ Aware Credit Window Type Value" in >>> draft-ietf-manet-dlep-da-credit-extension >>> >>> "IEEE 802.1Q Aware Credit Window Type Value" in >>> draft-ietf-manet-dlep-ether-credit-extension >> >> I am inclined to capitalize Value. >> >>> 6) 'Rick Taylor's "Data Item Containers"' is only mentioned in the >>> Acknowledgments sections of two of the four documents in this group >>> (draft-ietf-manet-dlep-traffic-classification and >>> draft-ietf-manet-dlep-da-credit-extension). Would you like to add the >>> applicable sentence to the Acknowledgments sections of >>> draft-ietf-manet-dlep-credit-flow-control and >>> draft-ietf-manet-dlep-ether-credit-extension as well? >> >> Yes, I think it would be reasonable and consistant to add that >> sentence to the Acknowledgements sections of the other two >> drafts. They all mention Data Items. >> >> Thanks, >> Donald >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 2386 Panoramic Circle, Apopka, FL 32703 USA >> [email protected] >> >>> Thank you, >>> >>> Lynne Bartholomew and Rebecca VanRheenen >>> RFC Production Center >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
