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]

Reply via email to