Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-bier-te-arch-13> for your review

[Gregory CAUCHIE <[e-mail]>]

Hi Lynne,

Accent are sometimes causing problems, so I would say to leave it as is with no accent.

Thanks for the offer though :)

--
Gregory

> On 10 Oct 2022, at 22:34, Michael Menth <[e-mail]> wrote:
> 
> Thanks a lot - that's great.
> 
> Michael
> 
> Am 10.10.2022 um 22:23 schrieb Lynne Bartholomew:
>> Hi, Michael.  We have updated your contact information per your note below.
>> Thank you for pointing out that RFCs to date use "Tuebingen"; updated accordingly.
>> The latest files are posted here (no new iteration; the lastrfcdiff.html file shows "France" plus your updates).  Please refresh your browser:
>>    https://www.rfc-editor.org/authors/rfc9262.txt
>>    https://www.rfc-editor.org/authors/rfc9262.pdf
>>    https://www.rfc-editor.org/authors/rfc9262.html
>>    https://www.rfc-editor.org/authors/rfc9262.xml
>>    https://www.rfc-editor.org/authors/rfc9262-diff.html
>>    https://www.rfc-editor.org/authors/rfc9262-rfcdiff.html
>>    https://www.rfc-editor.org/authors/rfc9262-auth48diff.html
>>    https://www.rfc-editor.org/authors/rfc9262-lastdiff.html
>>    https://www.rfc-editor.org/authors/rfc9262-lastrfcdiff.html
>>    https://www.rfc-editor.org/authors/rfc9262-xmldiff1.html
>>    https://www.rfc-editor.org/authors/rfc9262-xmldiff2.html
>>    https://www.rfc-editor.org/authors/rfc9262-alt-diff.html
>> Thanks again!
>> RFC Editor/lb
>>> On Oct 10, 2022, at 10:03 AM, Michael Menth <[e-mail]> wrote:
>>> 
>>> Hi Lynne,
>>> 
>>> thanks for coming back to me. It may be good adding "Germany" after my affiliation "University of Tübingen" in the address section.
>>> 
>>> I have a bunch of other RFCs: 6627, 6660, 6661, 6662, 6663 and they all use the spelling "University of Tuebingen". So I prefer this spelling for consistency reasons.
>>> 
>>> Kind regards
>>> 
>>> Michael
>>> 
>>> Am 10.10.2022 um 18:41 schrieb Lynne Bartholomew:
>>>> Hi, Grégory and Michael.
>>>> Grégory, we have added "France" to your contact information.  Would you also like us to place the accent over the "e" in your name ("é") in this RFC and any future RFCs that list your full name, or do you prefer it as is (no accent)?
>>>> Michael, please note that <https://datatracker.ietf.org/doc/html/draft-ietf-bier-te-arch-13> is the version that was approved by the IETF for editing and then for publication as an RFC; it is a "snapshot" of that point in time and will not be further updated.  The updated version will be RFC 9262.  Please review the latest files listed below, and you will see that your name is properly displayed.
>>>> The latest files are posted here:
>>>>    https://www.rfc-editor.org/authors/rfc9262.txt
>>>>    https://www.rfc-editor.org/authors/rfc9262.pdf
>>>>    https://www.rfc-editor.org/authors/rfc9262.html
>>>>    https://www.rfc-editor.org/authors/rfc9262.xml
>>>>    https://www.rfc-editor.org/authors/rfc9262-diff.html
>>>>    https://www.rfc-editor.org/authors/rfc9262-rfcdiff.html
>>>>    https://www.rfc-editor.org/authors/rfc9262-auth48diff.html
>>>>    https://www.rfc-editor.org/authors/rfc9262-lastdiff.html
>>>>    https://www.rfc-editor.org/authors/rfc9262-lastrfcdiff.html
>>>>    https://www.rfc-editor.org/authors/rfc9262-xmldiff1.html
>>>>    https://www.rfc-editor.org/authors/rfc9262-xmldiff2.html
>>>>    https://www.rfc-editor.org/authors/rfc9262-alt-diff.html
>>>> We have noted your approvals on the AUTH48 status page:
>>>>    https://www.rfc-editor.org/auth48/rfc9262
>>>> Thank you!
>>>> RFC Editor/lb
>>>>> On Oct 9, 2022, at 11:19 PM, Michael Menth <[e-mail]> wrote:
>>>>> 
>>>>> 
>>>>> Dear Lynne,
>>>>> 
>>>>> I approve the document. However, "M. M. Menth" on the header of the document should be changed to "M. Menth". I think we reflected that before but I still see an old version:
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-bier-te-arch-13
>>>>> 
>>>>> Kind regards
>>>>> 
>>>>> Michael
>>>>> On Oct 9, 2022, at 4:59 PM, Grégory CAUCHIE <[e-mail]> wrote:
>>>>> 
>>>>> Dear Lynne,
>>>>> 
>>>>> I am in-line with the conclusion of the “native” topic, so I therefore agree with the publication of the document.
>>>>> If I may, for stats, I would only invite you to add FRANCE in my contact details.
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> --
>>>>> Grégory CAUCHIE
>>>>> Koevoo
>>>>> [phone]
>>>>> 
>>>>>> Le 7 oct. 2022 à 19:34, Lynne Bartholomew <[e-mail]> a écrit :
>>>>>> 
>>>>>> Dear authors,
>>>>>> 
>>>>>> Checking in with you regarding the status of this document.  Please let us know whether further changes are needed or you approve this document for publication in its current form.
>>>>>> 
>>>>>> Toerless, FYI that this item is still pending on our end:
>>>>>> 
>>>>>>> As for the question of sourcecode type="pseudocode-bier" -- apologies for the delay on this one.  We will address this as soon as we can.
>>>>>> 
>>>>>> 
>>>>>> The AUTH48 status page is here:
>>>>>> 
>>>>>>  https://www.rfc-editor.org/auth48/rfc9262
>>>>>> 
>>>>>> Thank you!
>>>>>> 
>>>>>> RFC Editor/lb
>>>>>> 
>>>>>>> On Sep 15, 2022, at 4:33 PM, Lynne Bartholomew <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Dear Toerless,
>>>>>>> 
>>>>>>> Thank you for the email.
>>>>>>> 
>>>>>>> Regarding this item:
>>>>>>> 
>>>>>>>>> This question needs to be addressed as well; please advise:
>>>>>>>>> 
>>>>>>>>> <!-- [rfced] We note that https://dl.acm.org/doi/10.5555/2692227.2692232 resolves, but
>>>>>>>>> <https://dx.doi.org/> was unable to find 10.5555/2692227.2692232 in the system.  We
>>>>>>>>> found this DOI: 10.3233/JHS-1994-3405, but it's unclear to use if you chose to avoid
>>>>>>>>> <https://content.iospress.com/articles/journal-of-high-speed-networks/jhs3-4-05>
>>>>>>>>> because it requires payment.  Please review and let us know if any updates are needed.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> [RCSD94]   Zhang, H. and D. Domenico, "Rate-Controlled Service
>>>>>>>>>           Disciplines",  Journal of High-Speed Networks, 1994, May
>>>>>>>>>           1994, <https://dl.acm.org/doi/10.5555/2692227.2692232>.
>>>>>>>>> -->
>>>>>>>> 
>>>>>>>> Sorry for overlooking.
>>>>>>>> 
>>>>>>>> Q: what is the relevance of finding or not finding or not finding 10.5555/2692227.2692232
>>>>>>>> on https://dx.doi.org/ ?
>>>>>>>> 
>>>>>>>> I do not mind if the reference goes to the ACM paywall. This reference is only for
>>>>>>>> the term RCSD, which IMHO should be in the list of RFC abbreviations, but because it is
>>>>>>>> not, i was asked for a reference. It is possible to find the private download URL of
>>>>>>>> the author (http://www.cs.cmu.edu/~hzhang/papers/HighSpeedNetworks94.ps.gz), but i
>>>>>>>> don't think such URLs should be used. According to the rules of ACM, those are only allowed
>>>>>>>> for personal use, so we wouldn't do the author a favor, and secondly, i wonder what happens
>>>>>>>> to all those private URLs, when the authors retire or die.
>>>>>>> 
>>>>>>> No worries, and thank you for your notes here.  We generally "test" a DOI via <https://dx.doi.org/>, and the DOIs usually "resolve".  In this case it didn't, so we thought that we should ask you about it.  Given your helpful reply, we have updated this reference entry.
>>>>>>> 
>>>>>>> As for the question of sourcecode type="pseudocode-bier" -- apologies for the delay on this one.  We will address this as soon as we can.
>>>>>>> 
>>>>>>> The latest files are posted here:
>>>>>>> 
>>>>>>> https://www.rfc-editor.org/authors/rfc9262.txt
>>>>>>> https://www.rfc-editor.org/authors/rfc9262.pdf
>>>>>>> https://www.rfc-editor.org/authors/rfc9262.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9262.xml
>>>>>>> https://www.rfc-editor.org/authors/rfc9262-diff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9262-rfcdiff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9262-auth48diff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9262-lastdiff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9262-lastrfcdiff.html
>>>>>>> 
>>>>>>> https://www.rfc-editor.org/authors/rfc9262-xmldiff1.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9262-xmldiff2.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9262-alt-diff.html
>>>>>>> 
>>>>>>> Thanks again for your help and patience!
>>>>>>> 
>>>>>>> RFC Editor/lb
>>>>>>> 
>>>>>>>>> On Sep 13, 2022, at 5:11 PM, Toerless Eckert <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> Dear Lynne, *:
>>>>>>>> 
>>>>>>>> Let me start with replacing "native":
>>>>>>>> 
>>>>>>>> OLD: section 2.3:
>>>>>>>> this may be called a "native" BIER-TE topology.
>>>>>>>> NEW:
>>>>>>>> this may be called an "underlay" BIER-TE topology.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> OLD: section 3.2:
>>>>>>>> the native and/or overlay adjacencies
>>>>>>>> NEW:
>>>>>>>> the adjacencies
>>>>>>>> 
>>>>>>>> Explanation: "native and/or overlay" was confusing here anyhow, so better left out
>>>>>>>> 
>>>>>>>> Rest inline.
>>>>>>>> 
>>>>>>>> On Tue, Aug 30, 2022 at 11:35:49AM -0700, Lynne Bartholomew wrote:
>>>>>>>>> Regarding contact information:  We have updated your email address in this document and in our corresponding database record for it.  Please note that we used "Tübingen" per our ability to do so via xml2rfc v3, but if "Tuebingen" is preferred we will revert the change.
>>>>>>>> 
>>>>>>>> Deleting all replies where i agree and/or would just acknowledge,
>>>>>>>> appreciate your ctions (thanks!).
>>>>>>>> OTHER: For Michael to chime in. If he does not assume Tübingen is what he wants.
>>>>>>>> 
>>>>>>>>>> In the (non-TE) BIER architecture [RFC8279], BIER control plane
>>>>>>>>>> and BIER forwarding plane are not explicitly separated from each other,
>>>>>>>>>> but are summarized together in Section 4.2 of [RFC8279].
>>>>>>>>> 
>>>>>>>>> We have updated per your note.  However, we do not see how Section 4.2 of [RFC8279] is related to this text, except that it does appear to be a summary of some sort.  We do not see "control" or "plane" in that section (although we do see "forwarding").  Is the concept behind the BIER control and forwarding planes summarized in Section 4.2 of [RFC8279], as opposed to their separation?  Apologies for our confusion.  Possibly:
>>>>>>>> 
>>>>>>>> OK: Yes, the terms control and forwarding plane are not used in RFC8279 4.2.
>>>>>>>> 
>>>>>>>>> In the (non-TE) BIER architecture [RFC8279], the BIER control plane
>>>>>>>>> and BIER forwarding plane are not explicitly separated from each
>>>>>>>>> other.  This concept is summarized in Section 4.2 of [RFC8279].
>>>>>>>> 
>>>>>>>> NOK: How about:
>>>>>>>> 
>>>>>>>> In the (non-TE) BIER architecture [RFC8279], the BIER Layer is
>>>>>>>> summarized in Section 4.2. This summary includes both the functions
>>>>>>>> of the BIER Layer control plane and forwarding plane, without using
>>>>>>>> those terms.
>>>>>>>> 
>>>>>>>>> = = = = =
>>>>>>>>> 
>>>>>>>>> Regarding our question 14) and your reply:
>>>>>>>>> 
>>>>>>>>>> (14) [rfced] Section 3.2:  We changed "for a BIER-TE sub-domains" to
>>>>>>>>>> "for BIER-TE subdomains" in this sentence.  Please let us know if it
>>>>>>>>>> should be "for a BIER-TE subdomain" instead.
>>>>>>>>>> 
>>>>>>>>>> Yes
>>>>>>>>> 
>>>>>>>>> Does "Yes" mean that the term should be singular instead of plural (i.e., a BIER-TE subdomain")?
>>>>>>>> 
>>>>>>>> OK: Your change is good (subdomains is correct).
>>>>>>>> 
>>>>>>>>>> (Section 3.2, BIER-TE tree control, point 2.)
>>>>>>>>>> 
>>>>>>>>>> Section 3.2 is very long, so the pointer to the section alone is not very helpful.
>>>>>>>>> 
>>>>>>>>> We updated the text for readers who will only look at the .txt output file, while preserving the "BIER-TE topology control" and "BIER-TE tree control" hyperlinks in the .html and .pdf output files, because the hyperlinks easily direct the reader to the text in question.  Please review the .txt, .html, and .pdf outputs, and let us know any objections.  Also, please note that if you do not want the "(Section 3.2)" entries (i.e., if you want to add text within the parentheses), we will lose the helpful hyperlink functionality.
>>>>>>>> 
>>>>>>>> OK: Checked.  I guess this is as good as it can get with todays XMLv3, thanks.
>>>>>>>> 
>>>>>>>> Btw: Its still not ideal, some XMLv3 element that would allow to point directly
>>>>>>>> to that indented bullet point consistently in all rendering (not only html) would
>>>>>>>> be lovely. Now i forgot where i would have to raise an RFE with the XMLv3 gods... ;-)
>>>>>>>> 
>>>>>>>>> = = = = =
>>>>>>>>> 
>>>>>>>>> Regarding this note:
>>>>>>>>> 
>>>>>>>>>> (35b) When reviewing (36) below, i noted that the following
>>>>>>>>>> descriptoin is not good:
>>>>>>>>>> 
>>>>>>>>>> Replace:
>>>>>>>>>> that will cause a packet to be forwarded by the routing underlay towards
>>>>>>>>>> the adjacent BFR
>>>>>>>>>> 
>>>>>>>>>> With
>>>>>>>>>> 
>>>>>>>>>> that will cause a packet to be forwarded by the routing underlay towards
>>>>>>>>>> the BFR indicates via the l3-neighbor parameter of the forward_route() adjacency.
>>>>>>>>> 
>>>>>>>>> "indicates" would result in a lengthy fragment.  We changed it to "indicated".  If this is not correct, please provide updated text (e.g., possibly "towards the adjacent BFR and indicates"?).  Please note that per the rest of the document we also changed "forward_route()" to "forward_routed()"; please let us know if this sentence lists a distinct parameter.
>>>>>>>> 
>>>>>>>> OK: perfect.
>>>>>>>> 
>>>>>>>>> = = = = =
>>>>>>>>> 
>>>>>>>>> Regarding our question 39) and this part of your reply:
>>>>>>>>> 
>>>>>>>>>> I would suggest though to use a tag "pseudocode-bier", because i think
>>>>>>>>>> in general, no two pseudocodes across different RFCs will use the same
>>>>>>>>>> syntax (this is an issue we need to work on some time), except for
>>>>>>>>>> example here, where i reuse exactly the rfc8279 pseudocode (but i have
>>>>>>>>>> other drafts not related to bier that have other pseudocodes in it).
>>>>>>>>>> That way, your rfc-editor.org URL would start listing multiple different
>>>>>>>>>> pseudocodes and it would be easier to to see who is all using pseudocodes.
>>>>>>>>> 
>>>>>>>>> We will ask the "tools team" if this new type would be acceptable addition to <https://www.rfc-editor.org/materials/sourcecode-types.txt>.  If you'd like, you can also send a comment to this mailing list:  <[e-mail]>.
>>>>>>>> 
>>>>>>>> OK: thanks. I did send: https://mailarchive.ietf.org/arch/msg/xml2rfc/dBRYofuVGo-dVPOnQbqd9Po8DkQ
>>>>>>>> 
>>>>>>>> If tools team ok. before we finish AUTH48, we can do the fix, else lets just
>>>>>>>> keep it as "pseudocode" (aka: non-blocking comment).
>>>>>>>> 
>>>>>>>>> = = = = =
>>>>>>>>> 
>>>>>>>>> Regarding this item:
>>>>>>>>> 
>>>>>>>>>> (43) [rfced] Section 4.5:  We changed "forwarded_routed" to
>>>>>>>>>> "forward_routed()", as this was the only instance of "forwarded"
>>>>>>>>>> in this document that was followed by an underscore.  Please let us
>>>>>>>>>> know if this is incorrect (i.e., should all instances of "forward_"
>>>>>>>>>> be "forwarded_"?).
>>>>>>>>>> 
>>>>>>>>>> All uses of forwarded_* are typos and should be forward_*()
>>>>>>>>>> routed or connected. Sorry. I missed adding the () to them because
>>>>>>>>>> i wasn't looking for forwarded_* either.
>>>>>>>>> 
>>>>>>>>> We believe that all previous instances of "forwarded_*" are now "forward_*().  Please let us know if we missed anything.
>>>>>>>> 
>>>>>>>> OK: perfect.
>>>>>>>> 
>>>>>>>>> = = = = =
>>>>>>>>> 
>>>>>>>>> Our question 47)b) still needs to be addressed.  Please advise; perhaps change "to BFR1:" to "to BFR1 as follows." per your reply to a subsequent (similar) question?
>>>>>>>>> 
>>>>>>>>> <!-- [rfced] Section 5.1.6:  To what text does the colon after "to
>>>>>>>>> BFR1" refer - the next paragraph or the next two paragraphs (in which
>>>>>>>>> case we should indent the text in question)?  If neither, may we
>>>>>>>>> change the colon to a period?
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> For the rings shown in Figure 9, a single bit position will suffice
>>>>>>>>> to forward traffic entering the ring at BFRa or BFRb all the way up
>>>>>>>>> to BFR1:
>>>>>>>>> 
>>>>>>>>> Currently:
>>>>>>>>> For the ring shown in Figure 9, a single bit position will suffice to
>>>>>>>>> forward traffic entering the ring at BFRa or BFRb all the way up to
>>>>>>>>> BFR1: -->
>>>>>>>> 
>>>>>>>> Please change ":" to "as follows." as you suggested.
>>>>>>>> 
>>>>>>>>> = = = = =
>>>>>>>>> 
>>>>>>>>> This question needs to be addressed as well; please advise:
>>>>>>>>> 
>>>>>>>>> <!-- [rfced] We note that https://dl.acm.org/doi/10.5555/2692227.2692232 resolves, but
>>>>>>>>> <https://dx.doi.org/> was unable to find 10.5555/2692227.2692232 in the system.  We
>>>>>>>>> found this DOI: 10.3233/JHS-1994-3405, but it's unclear to use if you chose to avoid
>>>>>>>>> <https://content.iospress.com/articles/journal-of-high-speed-networks/jhs3-4-05>
>>>>>>>>> because it requires payment.  Please review and let us know if any updates are needed.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> [RCSD94]   Zhang, H. and D. Domenico, "Rate-Controlled Service
>>>>>>>>>           Disciplines",  Journal of High-Speed Networks, 1994, May
>>>>>>>>>           1994, <https://dl.acm.org/doi/10.5555/2692227.2692232>.
>>>>>>>>> -->
>>>>>>>> 
>>>>>>>> Sorry for overlooking.
>>>>>>>> 
>>>>>>>> Q: what is the relevance of finding or not finding or not finding 10.5555/2692227.2692232
>>>>>>>> on https://dx.doi.org/ ?
>>>>>>>> 
>>>>>>>> I do not mind if the reference goes to the ACM paywall. This reference is only for
>>>>>>>> the term RCSD, which IMHO should be in the list of RFC abbreviations, but because it is
>>>>>>>> not, i was asked for a reference. It is possible to find the private download URL of
>>>>>>>> the author (http://www.cs.cmu.edu/~hzhang/papers/HighSpeedNetworks94.ps.gz), but i
>>>>>>>> don't think such URLs should be used. According to the rules of ACM, those are only allowed
>>>>>>>> for personal use, so we wouldn't do the author a favor, and secondly, i wonder what happens
>>>>>>>> to all those private URLs, when the authors retire or die.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks again
>>>>>>>> Toerless
>>>>>>>> 
>>>>>>>>> = = = = =
>>>>>>>>> 
>>>>>>>>> The latest files are posted here.  Please review our updates carefully, and let us know if anything is incorrect or missing:
>>>>>>>>> 
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262.txt
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262.pdf
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262.xml
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262-diff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262-rfcdiff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262-auth48diff.html
>>>>>>>>> 
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262-alt-diff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262-xmldiff1.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262-xmldiff2.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262-alt-diff.html
>>>>>>>>> 
>>>>>>>>> Thanks again for your help and time!
>>>>>>>>> 
>>>>>>>>> RFC Editor/lb
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Aug 26, 2022, at 11:23 AM, Toerless Eckert <[e-mail]> wrote:
>>>>>>>>>> 
>>>>>>>>>> Dear RFC Editor
>>>>>>>>>> 
>>>>>>>>>> I have attempted to answer all rfced questions in this email and numbered them,
>>>>>>>>>> includeed also a few other points to fix - all listed as (n).
>>>>>>>>>> 
>>>>>>>>>> If this is ok. pls fixup the text according to the answers (hopefully i did not
>>>>>>>>>> overlook any), and i will do another full read on the then final text.
>>>>>>>>>> 
>>>>>>>>>> Cheers
>>>>>>>>>> toerless
>>>>>>>>>> 
>>>>>>>>>> (1) <!-- [rfced] First-page header:  We do not see multiple initials used
>>>>>>>>>> for the authors of this document in any published RFC or in the draft
>>>>>>>>>> references where the same authors are listed (e.g.,
>>>>>>>>>> draft-eckert-bier-te-frr).  Are the multiple initials intended as a
>>>>>>>>>> precedent for future RFCs?  If not, we suggest using single initials.
>>>>>>>>>> 
>>>>>>>>>> Original:
>>>>>>>>>> T.T.E. Eckert, Ed.
>>>>>>>>>> M.M. Menth
>>>>>>>>>> G.C. Cauchie
>>>>>>>>>> 
>>>>>>>>>> Suggested (per published RFCs and current documents):
>>>>>>>>>> T. Eckert, Ed.
>>>>>>>>>> M. Menth
>>>>>>>>>> G. Cauchie -->
>>>>>>>>>> 
>>>>>>>>>> Toerless: Agreed. Please change accordingly.
>>>>>>>>>> 
>>>>>>>>>> (2) Toerless: Please change the email address [e-mail] to [e-mail]
>>>>>>>>>> (i am trying to give up on that +ietf thingy, not working too well).
>>>>>>>>>> 
>>>>>>>>>> (3) Toerless: I am observing that Michael Menths University was in prior
>>>>>>>>>> RFC written as "University of Tuebingen", whereas you choose to
>>>>>>>>>> use the German Umlaut "University of Tübingen". Maybe Michael has
>>>>>>>>>> an opinion which one to prefer. (i am fine with eithre).
>>>>>>>>>> 
>>>>>>>>>> (4) <!-- [rfced] Please insert any keywords (beyond those that appear in the
>>>>>>>>>> title) for use on <https://www.rfc-editor.org/search>. -->
>>>>>>>>>> <keyword>example</keyword>
>>>>>>>>>> 
>>>>>>>>>> Toerless:
>>>>>>>>>> 
>>>>>>>>>> BIER
>>>>>>>>>> BIER-TE
>>>>>>>>>> controller
>>>>>>>>>> ECMP
>>>>>>>>>> forwarding
>>>>>>>>>> traffic-engineering
>>>>>>>>>> multicast
>>>>>>>>>> pseudocode
>>>>>>>>>> routing
>>>>>>>>>> traffic-steering
>>>>>>>>>> tree-steering
>>>>>>>>>> 
>>>>>>>>>> (5) <!-- [rfced] We found a comment called "Removed for now by review
>>>>>>>>>> with Lou Berger" in the original XML file with the section title "BIER-TE and Traffic Engineering (BIER-TE)."  Please confirm that the removal of this section is correct.  (If you need to restore the
>>>>>>>>>> section, we will do so via the pre-edited draft version.) -->
>>>>>>>>>> 
>>>>>>>>>> Toerless: Yes, that comended out section should please also be removed from the XML of the RFC.
>>>>>>>>>> 
>>>>>>>>>> (6) <!-- [rfced] Abstract and Section 1:  Because per other RFCs and
>>>>>>>>>> Internet searches "Interior Gateway Routing protocol" usually refers
>>>>>>>>>> to Cisco's IGRP, we looked up definitions of "IGP" and updated these
>>>>>>>>>> sentences accordingly, in an effort to avoid possible confusion for
>>>>>>>>>> some readers.  If these updates do not convey your intended meaning,
>>>>>>>>>> please provide clarifying text.
>>>>>>>>>> 
>>>>>>>>>> Toerless: The changes are fine, but
>>>>>>>>>> 
>>>>>>>>>> a) According to https://www.rfc-editor.org/materials/abbrev.expansion.txt,
>>>>>>>>>> IGP has a (*), so you may also choose to remove the expansion and just keep
>>>>>>>>>> the TLA (your choice).
>>>>>>>>>> 
>>>>>>>>>> b) if you think IGRP usually refers to
>>>>>>>>>> Cisco IGRP, can you please have accordingly the following line be aded to
>>>>>>>>>> 
>>>>>>>>>> https://www.rfc-editor.org/materials/abbrev.expansion.txt
>>>>>>>>>> 
>>>>>>>>>> IGRP     - Interior Gateway Routing Protocol (precursor of EIGRP/RFC7868)
>>>>>>>>>> 
>>>>>>>>>> Unless you officially nail this down in your list of abbreviation, authors
>>>>>>>>>> may continue to use this original definition of IGRP meaning all interior
>>>>>>>>>> gateway protocols. E.g:
>>>>>>>>>> 
>>>>>>>>>> rfc7576: interior gateway routing protocols such as OSPF and IS-IS
>>>>>>>>>> 
>>>>>>>>>> (7) <!-- [rfced] Section 2.1:  We defined "BFIR" as "Bit-Forwarding
>>>>>>>>>> Ingress Router" per RFC 8556 and per the definition of "BFER(s)".
>>>>>>>>>> Please let us know any objections.
>>>>>>>>>> 
>>>>>>>>>> Toerless: Ok.
>>>>>>>>>> 
>>>>>>>>>> (8) <!-- [rfced] Section 2.1:  We found "This is showing the ability of
>>>>>>>>>> the shown BIER-TE Topology" difficult to follow.  We updated this
>>>>>>>>>> sentence as noted below.  Please let us know if this is incorrect.
>>>>>>>>>> 
>>>>>>>>>> Toerless: Ok.
>>>>>>>>>> 
>>>>>>>>>> (9) <!-- [rfced] Section 2.1:  We had trouble with this sentence.
>>>>>>>>>> If the suggested text is not correct, please clarify "non-L2, but
>>>>>>>>>> routed/tunneled forwarding of BIER-TE packets".
>>>>>>>>>> 
>>>>>>>>>> Toerless: please change to:
>>>>>>>>>> 
>>>>>>>>>> To to explicitly distinguish routed/tunneled forwarding of BIER-TE packets
>>>>>>>>>> from Layer 2 forwarding (forward_connected()), these adjacencies are called
>>>>>>>>>> "forward_routed()" adjacencies.
>>>>>>>>>> 
>>>>>>>>>> (10) <!-- [rfced] Section 2.1:  We had trouble following the "and"
>>>>>>>>>> relationships in these two sentences.  If the suggested text does not
>>>>>>>>>> preserve your intended meaning, please clarify.
>>>>>>>>>> 
>>>>>>>>>> Toerless: great!
>>>>>>>>>> 
>>>>>>>>>> (11) <!-- [rfced] Section 2.3:  We had trouble following this sentence.
>>>>>>>>>> If the suggested text is not correct, please clarify "and therefore
>>>>>>>>>> also no unique BFR-id".
>>>>>>>>>> 
>>>>>>>>>> The goal was more to say "may not have Bfr-ID" (Bfr-ID are calculated
>>>>>>>>>> from BP). And this can actually be an issue, which my sentence didn't
>>>>>>>>>> highlight, and your rewrite makes it sound as if there is no challenge.
>>>>>>>>>> 
>>>>>>>>>> Suggest the following rewrite. The additional reference to 5.3.3 is to the
>>>>>>>>>> place where the challenge is discussed.
>>>>>>>>>> 
>>>>>>>>>> The BIER-TE layer forwarding plane does not require BFRs to have a unique BP, see Section 5.1.3.
>>>>>>>>>> Therefore, BFR may not have unique BFR-id, See Section 5.3.3.
>>>>>>>>>> 
>>>>>>>>>> (12) [rfced] Section 3.1:  We had trouble following the use of "may
>>>>>>>>>> also be preferred to" in this sentence.  If the suggested text is not
>>>>>>>>>> correct, please clarify.
>>>>>>>>>> 
>>>>>>>>>> Yes
>>>>>>>>>> 
>>>>>>>>>> (13) [rfced] Section 3.2:  We could not follow this sentence.  If the
>>>>>>>>>> suggested text is not correct, please clarify "but instead their
>>>>>>>>>> functions are summarized together in Section 4.2" (i.e., what do
>>>>>>>>>> "instead", "their", and "summarized together" refer to?).
>>>>>>>>>> 
>>>>>>>>>> I suggest the following sentence rewrite if that is better readable for you.
>>>>>>>>>> 
>>>>>>>>>> In the (non-TE) BIER architecture [RFC8279], BIER control plane
>>>>>>>>>> and BIER forwarding plane are not explicitly separated from each other,
>>>>>>>>>> but are summarized together in Section 4.2 of [RFC8279].
>>>>>>>>>> 
>>>>>>>>>> (14) [rfced] Section 3.2:  We changed "for a BIER-TE sub-domains" to
>>>>>>>>>> "for BIER-TE subdomains" in this sentence.  Please let us know if it
>>>>>>>>>> should be "for a BIER-TE subdomain" instead.
>>>>>>>>>> 
>>>>>>>>>> Yes
>>>>>>>>>> 
>>>>>>>>>> (15) [rfced] Section 3.2:  We do not see entropy/Entropy mentioned in
>>>>>>>>>> any of the cited sections.  Please confirm that these citations are
>>>>>>>>>> correct and will be clear to readers.
>>>>>>>>>> 
>>>>>>>>>> Good catch. Entropy is discussed in 4.2.3.
>>>>>>>>>> 
>>>>>>>>>> Maybe replace sentence with:
>>>>>>>>>> 
>>>>>>>>>> BitStrings are discussed in Section 3.2.1.2, Section 3.5 and Section 5.3.4, Entropy in Section 4.2.3.
>>>>>>>>>> 
>>>>>>>>>> (16) [rfced] Section 3.2:  To what does "the main responsibility"
>>>>>>>>>> refer?  If the suggested text is not correct, please clarify.
>>>>>>>>>> 
>>>>>>>>>> Suggested text:
>>>>>>>>>> 
>>>>>>>>>> Different aspects
>>>>>>>>>> of this point, as well as the next point, are discussed
>>>>>>>>>> throughout Section 3.2.1 and in Section 4.3. The main component
>>>>>>>>>> responsible for these two points is the Multicast Flow
>>>>>>>>>> Overlay (Section 3.1), which is architecturally inherited from
>>>>>>>>>> BIER.
>>>>>>>>>> 
>>>>>>>>>> (17) [rfced] Regarding this note from you: [RFC-Editor: the following text
>>>>>>>>>> 
>>>>>>>>>> Maybe manually refine current
>>>>>>>>>> 
>>>>>>>>>> (Section 3.2)
>>>>>>>>>> 
>>>>>>>>>> as
>>>>>>>>>> 
>>>>>>>>>> (Section 3.2, BIER-TE tree control, point 2.)
>>>>>>>>>> 
>>>>>>>>>> Section 3.2 is very long, so the pointer to the section alone is not very helpful.
>>>>>>>>>> 
>>>>>>>>>> (18) [rfced] Section 3.2.1.1:  We had trouble determining what is
>>>>>>>>>> listed in this sentence and how they relate to each other.  If the
>>>>>>>>>> suggested text is not correct, please clarify.
>>>>>>>>>> 
>>>>>>>>>> perfect!
>>>>>>>>>> 
>>>>>>>>>> (19) [rfced] Section 3.2.1.1:  Should "BitPositions/adjacencies" be
>>>>>>>>>> "BPs/adjacencies", and should "SI:BitPositions" be "SIs:BPs"?
>>>>>>>>>> The only other instances of the form "BitPosition" that we see are
>>>>>>>>>> "GetFirstBitPosition" and "GetNextBitPosition" in the figures in
>>>>>>>>>> Section 4.4.
>>>>>>>>>> 
>>>>>>>>>> Yes. Please make that change.
>>>>>>>>>> 
>>>>>>>>>> I tend to write abbreviation or expansions of terms often based on how i feel
>>>>>>>>>> it would sound best for one particular sentence (can it afford the
>>>>>>>>>> expansion), but that approach its not very logical and consistent.
>>>>>>>>>> Thanks for insisting consistency.
>>>>>>>>>> 
>>>>>>>>>> (20) [rfced] Section 3.2.1.1:  For ease of the reader, we defined
>>>>>>>>>> "SDN" as "Software-Defined Network" per RFC 8279.  If this is
>>>>>>>>>> incorrect, please provide the correct definition.
>>>>>>>>>> 
>>>>>>>>>> Correct, but both RFC8279 and i hope rfc9262 are introducing new terms
>>>>>>>>>> with parenthesis -> "Software-Defined Network". Please add.
>>>>>>>>>> 
>>>>>>>>>> (21) [rfced] Section 3.2.1.2:  Does "such as shortest path trees, ..."
>>>>>>>>>> refer to the policy reasons or the different overlay flows?  If the
>>>>>>>>>> suggested text is not correct, please clarify.
>>>>>>>>>> 
>>>>>>>>>> Yes, it is for policy reason,b ut i am not sure your sentence is
>>>>>>>>>> easier to read than my original.
>>>>>>>>>> 
>>>>>>>>>> How about:
>>>>>>>>>> 
>>>>>>>>>> Likewise, the BitString from
>>>>>>>>>> the same BFIR to the same set of BFER can be different for different
>>>>>>>>>> overlay flows if different policies should be applied to those overlay
>>>>>>>>>> flows, such as shortest path trees, Steiner
>>>>>>>>>> trees (minimum cost trees), diverse path trees for redundancy and so.
>>>>>>>>>> 
>>>>>>>>>> If you don't like it better than your suggestion, then pls. use
>>>>>>>>>> your suggestion.
>>>>>>>>>> 
>>>>>>>>>> (22) [rfced] Section 3.2.1.2:  We do not see the word "tree" used in
>>>>>>>>>> [I-D.ietf-bier-multicast-http-response].  Please confirm that this
>>>>>>>>>> citation is correct and will be clear to readers
>>>>>>>>>> 
>>>>>>>>>> Yes, the citation is correct, just the terminology has not been
>>>>>>>>>> aligned well.
>>>>>>>>>> 
>>>>>>>>>> (23) [rfced] Section 3.2.1.4:  For ease of the reader, we expanded
>>>>>>>>>> "FRR" as "Fast Reroute".  Please let us know any objections.
>>>>>>>>>> 
>>>>>>>>>> This is fine. But check for consistency for how to write a term
>>>>>>>>>> that's first time mentioned and abbreviation introduced, e.g
>>>>>>>>>> 
>>>>>>>>>> "Fast ReRoute" (FRR)
>>>>>>>>>> 
>>>>>>>>>> (24) [rfced] Section 3.3:  Because the "or" in "and/or" would mean
>>>>>>>>>> that there would not be a combination, we updated this sentence as
>>>>>>>>>> follows.  If this update does not properly convey your intended
>>>>>>>>>> meaning, please provide clarifying text.
>>>>>>>>>> 
>>>>>>>>>> Perfect.
>>>>>>>>>> 
>>>>>>>>>> (25) [rfced] Section 3.3:  For ease of the reader, we defined "DSCP"
>>>>>>>>>> as "Differentiated Services Code Point".  If this is incorrect,
>>>>>>>>>> please provide the correct definition.
>>>>>>>>>> 
>>>>>>>>>> Corect. Pls consider parenthesis for the expanded term.
>>>>>>>>>> 
>>>>>>>>>> (26) [rfced] Section 3.4:  Does "This" mean "This process", "This
>>>>>>>>>> calculation", or something else?  Please clarify.
>>>>>>>>>> 
>>>>>>>>>> How about:
>>>>>>>>>> BIER relies on the routing underlay to calculate paths towards BFERs
>>>>>>>>>> and derive next-hop BFR adjacencies for those paths.  These two steps commonly
>>>>>>>>>> rely on BIER specific extensions to the routing protocols of the
>>>>>>>>>> routing underlay but may also be established by a controller.
>>>>>>>>>> 
>>>>>>>>>> Aka: (a) calculate paths,... and (b) derive next hops => two steps.
>>>>>>>>>> 
>>>>>>>>>> (27) [rfced] Section 3.4:  For ease of the reader, we expanded "BFD"
>>>>>>>>>> as "Bidirectional Forwarding Detection".  If this is incorrect,
>>>>>>>>>> please provide the correct definition.
>>>>>>>>>> 
>>>>>>>>>> Yes correct. Consider quoting.
>>>>>>>>>> 
>>>>>>>>>> (28) [rfced] Section 3.5:  Please confirm that "TE" stands for
>>>>>>>>>> "Traffic Engineering" and not "Tree Engineering" here.  We would
>>>>>>>>>> like to spell it out as appropriate, because the standalone term
>>>>>>>>>> "TE" is not used anywhere else in this document.
>>>>>>>>>> 
>>>>>>>>>> Suggested:
>>>>>>>>>> The key elements needed to effect Traffic Engineering are
>>>>>>>>>> policy, path steering, and resource management. -->
>>>>>>>>>> 
>>>>>>>>>> Correct.
>>>>>>>>>> 
>>>>>>>>>> (29) [rfced] Section 3.5:  Because Section 4.2.1 discusses
>>>>>>>>>> forward_connected() adjacencies and Section 4.2.2 discusses
>>>>>>>>>> forward_routed() adjacencies, we changed "4.2.1" to "4.2.2" here.
>>>>>>>>>> Please let us know any concerns (e.g., should the instances of
>>>>>>>>>> "forward_routed()" be "forward_connected()" here?).
>>>>>>>>>> 
>>>>>>>>>> Correct.
>>>>>>>>>> 
>>>>>>>>>> (30) [rfced] Section 4.1:  This sentence reads oddly, as a BIFT is
>>>>>>>>>> already defined as being a table.  May we update as suggested?
>>>>>>>>>> If not, please clarify "it is a table as shown".
>>>>>>>>>> 
>>>>>>>>>> Suggestion is good, but would "is constructed" not be better than
>>>>>>>>>> "would be constructed" ? Pick your favorite!
>>>>>>>>>> 
>>>>>>>>>> (31) [rfced] Section 4.1:  Does "those adjacencies forwarding
>>>>>>>>>> entries" mean "those adjacencies that forward entries", "those
>>>>>>>>>> adjacencies' forwarding entries", or something else?
>>>>>>>>>> 
>>>>>>>>>> Suggestion:
>>>>>>>>>> In BIER-TE, each BIFT-index and therefore SI:BP indicates one or
>>>>>>>>>> in case of reuse of SI:BP more than one adjacencies between BFRs
>>>>>>>>>> in the topology. The SI:BP is populated with the adjacency on the
>>>>>>>>>> upstream BFR of the adjacency.
>>>>>>>>>> 
>>>>>>>>>> (32) [rfced] We incorporated the "BIER-TE Bit Index Forwarding Table
>>>>>>>>>> (BIFT)" text that appeared at the bottom of Figure 4 into the
>>>>>>>>>> figure's title, as it appears to say the same thing as the original
>>>>>>>>>> figure title (but provides the expansion for "BIFT").  Please let us
>>>>>>>>>> know any objections.
>>>>>>>>>> 
>>>>>>>>>> Correct.
>>>>>>>>>> 
>>>>>>>>>> (33) [rfced] Section 4.1:  Please clarify the meaning of "the BIER-TE
>>>>>>>>>> Forwarding Procedures".  Are they found elsewhere in this document
>>>>>>>>>> or perhaps in another RFC?  Please specify the section number or RFC,
>>>>>>>>>> as applicable.
>>>>>>>>>> 
>>>>>>>>>> Suggested rewrite:
>>>>>>>>>> The BIFT is then used to forward packets, according to the procedures
>>>>>>>>>> of the BIER-TE Forwarding Plane as specified in Section 3.3.
>>>>>>>>>> 
>>>>>>>>>> (34) [rfced] Section 4.1:  We do not see "controller" mentioned in
>>>>>>>>>> Section 5.1.6.  Please confirm that this citation is correct and will
>>>>>>>>>> be clear to readers
>>>>>>>>>> 
>>>>>>>>>> (35) [rfced] Section 4.1:  We do not see "controller" mentioned in
>>>>>>>>>> Section 5.1.6.  Please confirm that this citation is correct and will
>>>>>>>>>> be clear to readers.
>>>>>>>>>> 
>>>>>>>>>> Yes, this is correct. I hope this is clear to readers, because
>>>>>>>>>> section 5. is called "BIER-TE Controller Operational Considerations",
>>>>>>>>>> aka: its all about the controller.
>>>>>>>>>> 
>>>>>>>>>> (35b) When reviewing (36) below, i noted that the following
>>>>>>>>>> descriptoin is not good:
>>>>>>>>>> 
>>>>>>>>>> Replace:
>>>>>>>>>> that will cause a packet to be forwarded by the routing underlay towards
>>>>>>>>>> the adjacent BFR
>>>>>>>>>> 
>>>>>>>>>> With
>>>>>>>>>> 
>>>>>>>>>> that will cause a packet to be forwarded by the routing underlay towards
>>>>>>>>>> the BFR indicates via the l3-neighbor parameter of the forward_route() adjacency.
>>>>>>>>>> 
>>>>>>>>>> (36) [rfced] Section 4.2.2:  We had trouble with the usage of
>>>>>>>>>> "either" and determining what "or by" refers to in this sentence.
>>>>>>>>>> If the suggested text is not correct, please clarify.
>>>>>>>>>> 
>>>>>>>>>> Suggested rewrite is fine.
>>>>>>>>>> 
>>>>>>>>>> (37) [rfced] Section 4.3:  We found the wording of this sentence
>>>>>>>>>> confusing, as it does prompted us to BIER.</t> search RFC 8279 for "maximum" and
>>>>>>>>>> "MTU" (only to find that it doesn't mention either term).  May we
>>>>>>>>>> rephrase as suggested?  If not, please provide clarifying text.
>>>>>>>>>> 
>>>>>>>>>> Nice. Suggested rewrite is fine, maybe add "either" ?
>>>>>>>>>> 
>>>>>>>>>> ... and is not discussed in [RFC8279] either.
>>>>>>>>>> 
>>>>>>>>>> (38) [rfced] Section 4.3:  This paragraph is difficult to follow.
>>>>>>>>>> Does "which" mean that the fixed mapping never explicitly partitions
>>>>>>>>>> the BIFT-id space, or can the fixed mapping sometimes explicitly
>>>>>>>>>> partition the BIFT-id space, in which case "which" should be "that"?
>>>>>>>>>> Does "same or different SD" mean "same SD or a different SD",
>>>>>>>>>> "same SD or different SDs", or something else?
>>>>>>>>>> 
>>>>>>>>>> The rewrite is fine. It is still terrible english german (long context).
>>>>>>>>>> 
>>>>>>>>>> How about beaking the sentence apart as follows:
>>>>>>>>>> 
>>>>>>>>>> Assume that a fixed mapping ... Section 5. (full stop after 5.)
>>>>>>>>>> In this case, it is necessary...
>>>>>>>>>> 
>>>>>>>>>> If you think this makes it better readable, pleasse use, else stick
>>>>>>>>>> to only your suggestion.
>>>>>>>>>> 
>>>>>>>>>> (39) [rfced] Section 4.4:  Because Figures 4 and 5 are referred to as
>>>>>>>>>> "pseudocode", we changed "<artwork>" in the XML file to <sourcecode>
>>>>>>>>>> with type="pseudocode".  Please let us know any concerns.  For
>>>>>>>>>> information regarding <sourcecode> types, please see
>>>>>>>>>> <https://www.rfc-editor.org/materials/sourcecode-types.txt>. -->
>>>>>>>>>> 
>>>>>>>>>> Seems to be fine. I would be mostly worried that the type will at some
>>>>>>>>>> point be used to provide more fancy formatting that might not fit, but
>>>>>>>>>> given how everybody uses pseudocode differently, i think there is a
>>>>>>>>>> slim chance for this to happen for pseudocode.
>>>>>>>>>> 
>>>>>>>>>> I would suggest though to use a tag "pseudocode-bier", because i think
>>>>>>>>>> in general, no two pseudocodes across different RFCs will use the same
>>>>>>>>>> syntax (this is an issue we need to work on some time), except for
>>>>>>>>>> example here, where i reuse exactly the rfc8279 pseudocode (but i have
>>>>>>>>>> other drafts not related to bier that have other pseudocodes in it).
>>>>>>>>>> That way, your rfc-editor.org URL would start listing multiple different
>>>>>>>>>> pseudocodes and it would be easier to to see who is all using pseudocodes.
>>>>>>>>>> 
>>>>>>>>>> (40) [rfced] Section 4.4:  We had trouble following this sentence.
>>>>>>>>>> If the suggested text is not correct, please clarify the meaning of
>>>>>>>>>> "to create duplicates".
>>>>>>>>>> 
>>>>>>>>>> Correct.
>>>>>>>>>> 
>>>>>>>>>> (41) [rfced] Section 4.4:  This sentence does not parse.  If the
>>>>>>>>>> suggested text is not correct, please clarify.
>>>>>>>>>> 
>>>>>>>>>> Correct.
>>>>>>>>>> 
>>>>>>>>>> (42) [rfced] Section 4.4:  xml2rfc v3 now permits subscripting and
>>>>>>>>>> superscripting.  Would you like to use superscripting in "BSL^2*SI"?
>>>>>>>>>> If yes, should "2*SI" be superscripted, or only the "2"?
>>>>>>>>>> 
>>>>>>>>>> Yes, please do so.
>>>>>>>>>> Exponent is just "2", but given how superscription does not show in txt rendering,
>>>>>>>>>> maybe best to write SI*BSL^2 - makes it easier to read IMHO.
>>>>>>>>>> 
>>>>>>>>>> (43) [rfced] Section 4.5:  We changed "forwarded_routed" to
>>>>>>>>>> "forward_routed()", as this was the only instance of "forwarded"
>>>>>>>>>> in this document that was followed by an underscore.  Please let us
>>>>>>>>>> know if this is incorrect (i.e., should all instances of "forward_"
>>>>>>>>>> be "forwarded_"?).
>>>>>>>>>> 
>>>>>>>>>> All uses of forwarded_* are typos and should be forward_*()
>>>>>>>>>> routed or connected. Sorry. I missed adding the () to them because
>>>>>>>>>> i wasn't looking for forwarded_* either.
>>>>>>>>>> 
>>>>>>>>>> (44) [rfced] Section 5.1.1:  Does "P2P" stand for "peer-to-peer" or
>>>>>>>>>> "point-to-point" in this document?  We would like to define it for
>>>>>>>>>> ease of the reader.
>>>>>>>>>> 
>>>>>>>>>> Yes. It stands for point-to-point. Replace the abbreviation pls.
>>>>>>>>>> rfc9262
>>>>>>>>>> 
>>>>>>>>>> (45) [rfced] Section 5.1.4:  Should the vertical line for p3 in
>>>>>>>>>> Figure 8 be aligned under a "+" sign, as are the other vertical
>>>>>>>>>> lines)?
>>>>>>>>>> 
>>>>>>>>>> Yes. As follows:
>>>>>>>>>> 
>>>>>>>>>>        BFR1
>>>>>>>>>>         |p1
>>>>>>>>>> LAN1---+-+---+-----+
>>>>>>>>>>     p3|   p4|   p2|
>>>>>>>>>>     BFR3  BFR4  BFR7
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> (46) [rfced] Section 5.1.4:  Please clarify the meaning of
>>>>>>>>>> "Adjacencies of such BFRs into their LAN".  Does it mean "Adding
>>>>>>>>>> adjacencies of such BFRs to these LANs" or something else?
>>>>>>>>>> 
>>>>>>>>>> Suggested text:
>>>>>>>>>> 
>>>>>>>>>> This optimization does not work in the case of BFRs redundantly
>>>>>>>>>> connected to more than one LAN with this optimization. These
>>>>>>>>>> BFRs would receive duplicates and forward those duplicates into the
>>>>>>>>>> other LANs. Such BFRs require separate bit positions for each LAN they
>>>>>>>>>> connect to.
>>>>>>>>>> 
>>>>>>>>>> (47) [rfced] Section 5.1.6:
>>>>>>>>>> 
>>>>>>>>>> Singular "ring" is correct.
>>>>>>>>>> 
>>>>>>>>>> (48) [rfced] Section 5.1.7:  Regarding this question from you
>>>>>>>>>> 
>>>>>>>>>> Thanks. Looks fine to me now.
>>>>>>>>>> But already looked fine to me before (not going to become a native speaker any time soon ;-)
>>>>>>>>>> 
>>>>>>>>>> (49) [rfced] Section 5.1.9:  To which paragraph or paragraphs does
>>>>>>>>>> the colon in "useful path choices:" refer?  Should the paragraph or
>>>>>>>>>> paragraphs be indented?  If so, which paragraph(s)?  Alternatively,
>>>>>>>>>> may we change the colon to a period?
>>>>>>>>>> 
>>>>>>>>>> Colon refers to the following paragraph, but yes, i think thats not correct english.
>>>>>>>>>> 
>>>>>>>>>> Maybe amend text:
>>>>>>>>>> 
>>>>>>>>>> the set of useful path choices:
>>>>>>>>>> 
>>>>>>>>>> the set of useful path choices, as in the following example.
>>>>>>>>>> 
>>>>>>>>>> I don't think indepntation of that following paraph is necessary with this
>>>>>>>>>> lead-in.
>>>>>>>>>> 
>>>>>>>>>> (50) [rfced] Section 5.1.9:  Does "5 areas" refer to areas 2...6, or
>>>>>>>>>> should it be "six areas"?  Also, please confirm that "through other
>>>>>>>>>> BPs for the Core to" should not be "through other BPs from the core
>>>>>>>>>> to".
>>>>>>>>>> 
>>>>>>>>>> It refers to areas 2...6. Maybe introduce the term earlier:
>>>>>>>>>> 
>>>>>>>>>> Replace:
>>>>>>>>>> and areas 2...6 contain
>>>>>>>>>> With:
>>>>>>>>>> and the five areas 2...6 contain
>>>>>>>>>> 
>>>>>>>>>> But any way you you think reads best is fine with me.
>>>>>>>>>> 
>>>>>>>>>> And yes, "from the core" is correct. Please apply fix.
>>>>>>>>>> 
>>>>>>>>>> (51) [rfced] Section 5.1.10:  We had trouble following this sentence.
>>>>>>>>>> We updated it as follows.  If this is incorrect, please clarify
>>>>>>>>>> "subnet adjacent neighbor".
>>>>>>>>>> 
>>>>>>>>>> This is fine. Thanks.
>>>>>>>>>> 
>>>>>>>>>> (52) [rfced] Section 5.3.1:  We had trouble following "packets that
>>>>>>>>>> need to be sent ... require different BIER packets" in this sentence.
>>>>>>>>>> Is it correct to say that packets require packets?  If not, please
>>>>>>>>>> (1) let us know if the suggested text preserves your intended
>>>>>>>>>> meaning or (2) provide clarifying text.
>>>>>>>>>> 
>>>>>>>>>> Replace:
>>>>>>>>>> the same: Packets that
>>>>>>>>>> 
>>>>>>>>>> With:
>>>>>>>>>> the same: Multicast Flow Overlay packets that
>>>>>>>>>> 
>>>>>>>>>> (aka: the BFIR receives one multicast flow overlay packet and needs
>>>>>>>>>> to generate multiple BIER/BIER-TE packets from it).
>>>>>>>>>> 
>>>>>>>>>> Suggest also to replace:
>>>>>>>>>> in different SIs or sub-domains require different BIER packets
>>>>>>>>>> with:
>>>>>>>>>> in different SIs or sub-domains require multiple BIER packets
>>>>>>>>>> 
>>>>>>>>>> (53) [rfced] Section 5.3.1:  "BIER architecture shared by BIER-TE"
>>>>>>>>>> did not seem to be quite the correct wording here.  We updated this
>>>>>>>>>> sentence as follows.  If this update is incorrect, please provide
>>>>>>>>>> clarifying text.
>>>>>>>>>> 
>>>>>>>>>> That whole first sentence of the paragraph is ugly and i think the
>>>>>>>>>> text will become better by skipping it instead of attempting to explain it.
>>>>>>>>>> 
>>>>>>>>>> Please replace paragraph with:
>>>>>>>>>> 
>>>>>>>>>> SI and sub-domain have different purposes in the BIER architecture
>>>>>>>>>> also also the BIER-TE archtecture.  This impacts how operators are managing them and
>>>>>>>>>> how especially flow overlays will likely use them.
>>>>>>>>>> 
>>>>>>>>>> (54) [rfced] Section 5.3.2:  We found this paragraph difficult to
>>>>>>>>>> follow.  We updated it as noted below.  Please review carefully.  If
>>>>>>>>>> anything is incorrect, please provide clarifying text.
>>>>>>>>>> 
>>>>>>>>>> Looks nice. Thanks.
>>>>>>>>>> 
>>>>>>>>>> (55) [rfced] Section 5.3.4:  It appears to us that "it needs" refers
>>>>>>>>>> to the flow overlay applications, in which case it should be "they
>>>>>>>>>> need".  May we update as suggested?  If not, please clarify what "it"
>>>>>>>>>> refers to.
>>>>>>>>>> 
>>>>>>>>>> Yes, correct. Thanks.
>>>>>>>>>> 
>>>>>>>>>> (56) [rfced] Section 5.3.5:  Does "their" in this sentence refer to
>>>>>>>>>> subdomains, BIER and BIER-TE, or something else?  If the suggested
>>>>>>>>>> text is not correct, please clarify.
>>>>>>>>>> 
>>>>>>>>>> their was meant to refer only to BIER.
>>>>>>>>>> 
>>>>>>>>>> Please replace text with:
>>>>>>>>>> 
>>>>>>>>>> A.  BIER and BIER-TE have different BFR-ids in the same subdomain.
>>>>>>>>>> This allows higher replication efficiency for BIER because the
>>>>>>>>>> BIER BFR-ids can be assigned sequentially, while the
>>>>>>>>>> BitStrings for BIER-TE will also have to assign the additional bits for
>>>>>>>>>> the topology adjacencies. -->
>>>>>>>>>> 
>>>>>>>>>> (57) [rfced] Section 5.3.6.1:  These sentences did not parse well.
>>>>>>>>>> We updated as follows.  If these updates do not convey your intended
>>>>>>>>>> meaning, please provide clarifying text.
>>>>>>>>>> 
>>>>>>>>>> Replacement is fine. Thanks.
>>>>>>>>>> 
>>>>>>>>>> (58) [rfced] Section 5.3.6.1:  We found the two "even"s in this
>>>>>>>>>> sentence confusing.  We updated as follows.  If this is incorrect,
>>>>>>>>>> please provide clarifying text.
>>>>>>>>>> 
>>>>>>>>>> Replacement is fine. Thanks.
>>>>>>>>>> 
>>>>>>>>>> (59) [rfced] Section 5.3.6.2: a) To what does the colon in "area edge BFR:" refer - the next
>>>>>>>>>> paragraph, or the next two paragraphs?  We would like to indent the
>>>>>>>>>> text of the next paragraph or the next two paragraphs, as
>>>>>>>>>> appropriate.  Alternatively, could the colon be changed to a period?
>>>>>>>>>> 
>>>>>>>>>> The ":" refers to the next paragraph. Maybe replace ":" with "as follows." ?
>>>>>>>>>> Don't think indentation would look good here.
>>>>>>>>>> 
>>>>>>>>>> (60) [rfced] Section 5.3.6.2:
>>>>>>>>>> b) We had trouble following the text in the second paragraph.  If the
>>>>>>>>>> suggested text is not correct, please clarify "the bits indicate bits
>>>>>>>>>> for topology and BFER" and "For BFER in the same area as in the BFIR".
>>>>>>>>>> 
>>>>>>>>>> Please modify your replacement as follows:
>>>>>>>>>> 
>>>>>>>>>> Replace:
>>>>>>>>>> In each packet, these bits in turn indicate bits for the topology and
>>>>>>>>>> the BFERs in that topology, plus
>>>>>>>>>> With
>>>>>>>>>> In each packet, the BitString includes bits for one area and
>>>>>>>>>> the BFERs in that area, plus
>>>>>>>>>> 
>>>>>>>>>> (61) [rfced] Section 6:  We had trouble following the meaning of
>>>>>>>>>> "results of the routing protocol".  Is "results of" necessary?
>>>>>>>>>> If the suggested text is not correct, please clarify.
>>>>>>>>>> 
>>>>>>>>>> Suggest to replace:
>>>>>>>>>> the results of the routing protocol
>>>>>>>>>> 
>>>>>>>>>> With:
>>>>>>>>>> the information that BIER-TE learns from the routing protocol (routes, next-hops, BFR-ids, ...)
>>>>>>>>>> 
>>>>>>>>>> (62) [rfced] Section 6:  This sentence did not parse.  We updated it
>>>>>>>>>> as follows.  If this is incorrect, please clarify "same degree of
>>>>>>>>>> looping packets as possible".
>>>>>>>>>> 
>>>>>>>>>> Perfect.
>>>>>>>>>> 
>>>>>>>>>> (63) [rfced] Appendix A:  We made quite a few updates to this section
>>>>>>>>>> in an effort to clarify the text.  Please review all updates
>>>>>>>>>> carefully.  If anything is incorrect, please provide clarifying text.
>>>>>>>>>> 
>>>>>>>>>> Please replace:
>>>>>>>>>> relies on source routing via the definition of a BitString,
>>>>>>>>>> With
>>>>>>>>>> relies on source routing (via a BitString),
>>>>>>>>>> 
>>>>>>>>>> Because: the way you emphasize the comaprison with bullet points would make
>>>>>>>>>> it more worrysome to read that SR also has BitStrings (which it doesnt). Only
>>>>>>>>>> the source-routing is shared.
>>>>>>>>>> 
>>>>>>>>>> rest of changes are fine. Thanks.
>>>>>>>>>> 
>>>>>>>>>> (64) [rfced] Please review the "Inclusive Language" portion of the
>>>>>>>>>> online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
>>>>>>>>>> and let us know if any changes are needed.  Aside from "native", our script did not identify problematic terms.
>>>>>>>>>> 
>>>>>>>>>> I could not find on those URLs a place where "native" was listed as problematic,
>>>>>>>>>> where/what is the script you are using ?
>>>>>>>>>> 
>>>>>>>>>> I had a set of discussions about the use of the word native at IETF114,
>>>>>>>>>> including with Andrew Alston who told me how its use in parts of africa might
>>>>>>>>>> be life threatening, so i am aware of possible concerns. However:
>>>>>>>>>> 
>>>>>>>>>> The term has been widely used in RFCs and especially in multicast contexts,
>>>>>>>>>> and i really would want to have some reference URL from rfc-editor where you track ideally single
>>>>>>>>>> recommended replacement words (like you track abbreviations). It is
>>>>>>>>>> a widely used technical term and i had to search several times through RFCs
>>>>>>>>>> with this term to find stuff. So i want to make sure that when we replace it,
>>>>>>>>>> we do not end up with a hodge-podge of differrent new terms that would
>>>>>>>>>> make searching and recognition of the term more difficult.
>>>>>>>>>> 
>>>>>>>>>> Aka: If this does not exist, and if you permit me to keep the word, i would
>>>>>>>>>> choose that option right now. But i encourage you to work towards a replacement
>>>>>>>>>> tracking service for future RFCs, and i am happy to chime in support of that
>>>>>>>>>> if that would help.
>>>>>>>>>> 
>>>>>>>>>> (65) [rfced] Please let us know if any changes are needed for the
>>>>>>>>>> following:
>>>>>>>>>> 
>>>>>>>>>> a) Very thorough work on consistent terms. All good. Thanks a lot!
>>>>>>>>>> 
>>>>>>>>>> b) The following terms appear to be used inconsistently in this
>>>>>>>>>> document.  Please let us know which form is preferred.
>>>>>>>>>> 
>>>>>>>>>>> accelerated hardware forwarding (text) /
>>>>>>>>>> Accelerated/Hardware forwarding comparison (section title)
>>>>>>>>>> (In other words, does the slash ("/") serve a specific purpose?)
>>>>>>>>>> 
>>>>>>>>>> The / was meant as an abbrebiation of accelerated and/or hardware forwarding.
>>>>>>>>>> The problem is that there is no good solid term to use. I think its
>>>>>>>>>> fine to just use accelerated hardware forwarding (remove /). I am sure that ANY variation
>>>>>>>>>> we pick would have one or the other reader that does not like it ;-(
>>>>>>>>>> 
>>>>>>>>>>> capitalization:
>>>>>>>>>> 
>>>>>>>>>> BIER-TE controller
>>>>>>>>>> BIER-TE topology
>>>>>>>>>> entropy
>>>>>>>>>> flow overlay
>>>>>>>>>> forwarding pseudocode
>>>>>>>>>> multicast flow overlay
>>>>>>>>>> 
>>>>>>>>>> E.g.: i think we do not want to introduce new names (and hence capitalized spelling),
>>>>>>>>>> aka: no capitalization in running text, just keep it, where it exists in titles or pictures.
>>>>>>>>>> 
>>>>>>>>>>> IP/IPv6
>>>>>>>>>> 
>>>>>>>>>> E.g.: do not use IPv4, but use IP instead. Thats correct IETF language. IPv4
>>>>>>>>>> is just waht i like to emphasize its not IPv6.
>>>>>>>>>> 
>>>>>>>>>>> leaf BFER
>>>>>>>>>> 
>>>>>>>>>> agree with your argument to remove hyphen.
>>>>>>>>>> 
>>>>>>>>>>> should "SI:BitStrings" be "SIs:BitStrings"?
>>>>>>>>>> 
>>>>>>>>>> Yes.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Thank you so much again!
>>>>>>>>>> 
>>>>>>>>>> Toerless
>>>>>>>>>> 
>>>>>>>>>> On Mon, Jul 11, 2022 at 06:40:53PM -0700, [e-mail] wrote:
>>>>>>>>>>> *****IMPORTANT*****
>>>>>>>>>>> 
>>>>>>>>>>> Updated 2022/07/11
>>>>>>>>>>> 
>>>>>>>>>>> RFC Author(s):
>>>>>>>>>>> --------------
>>>>>>>>>>> 
>>>>>>>>>>> Instructions for Completing AUTH48
>>>>>>>>>>> 
>>>>>>>>>>> Your document has now entered AUTH48.  Once it has been reviewed and
>>>>>>>>>>> approved by you and all coauthors, it will be published as an RFC.
>>>>>>>>>>> If an author is no longer available, there are several remedies
>>>>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>>>>>>>>>> 
>>>>>>>>>>> You and you coauthors are responsible for engaging other parties
>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing
>>>>>>>>>>> your approval.
>>>>>>>>>>> 
>>>>>>>>>>> Planning your review
>>>>>>>>>>> ---------------------
>>>>>>>>>>> 
>>>>>>>>>>> Please review the following aspects of your document:
>>>>>>>>>>> 
>>>>>>>>>>> *  RFC Editor questions
>>>>>>>>>>> 
>>>>>>>>>>> Please review and resolve any questions raised by the RFC Editor
>>>>>>>>>>> that have been included in the XML file as comments marked as
>>>>>>>>>>> follows:
>>>>>>>>>>> 
>>>>>>>>>>> <!-- [rfced] ... -->
>>>>>>>>>>> 
>>>>>>>>>>> These questions will also be sent in a subsequent email.
>>>>>>>>>>> 
>>>>>>>>>>> *  Changes submitted by coauthors
>>>>>>>>>>> 
>>>>>>>>>>> Please ensure that you review any changes submitted by your
>>>>>>>>>>> coauthors.  We assume that if you do not speak up that you
>>>>>>>>>>> agree to changes submitted by your coauthors.
>>>>>>>>>>> 
>>>>>>>>>>> *  Content
>>>>>>>>>>> 
>>>>>>>>>>> Please review the full content of the document, as this cannot
>>>>>>>>>>> change once the RFC is published.  Please pay particular attention to:
>>>>>>>>>>> - IANA considerations updates (if applicable)
>>>>>>>>>>> - contact information
>>>>>>>>>>> - references
>>>>>>>>>>> 
>>>>>>>>>>> *  Copyright notices and legends
>>>>>>>>>>> 
>>>>>>>>>>> Please review the copyright notice and legends as defined in
>>>>>>>>>>> RFC 5378 and the Trust Legal Provisions
>>>>>>>>>>> (TLP – https://trustee.ietf.org/license-info/).
>>>>>>>>>>> 
>>>>>>>>>>> *  Semantic markup
>>>>>>>>>>> 
>>>>>>>>>>> Please review the markup in the XML file to ensure that elements of
>>>>>>>>>>> content are correctly tagged.  For example, ensure that <sourcecode>
>>>>>>>>>>> and <artwork> are set correctly.  See details at
>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>>>>>>>>>> 
>>>>>>>>>>> *  Formatted output
>>>>>>>>>>> 
>>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the
>>>>>>>>>>> formatted output, as generated from the markup in the XML file, is
>>>>>>>>>>> reasonable.  Please note that the TXT will have formatting
>>>>>>>>>>> limitations compared to the PDF and HTML.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Submitting changes
>>>>>>>>>>> ------------------
>>>>>>>>>>> 
>>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all
>>>>>>>>>>> the parties CCed on this message need to see your changes. The parties
>>>>>>>>>>> include:
>>>>>>>>>>> 
>>>>>>>>>>> *  your coauthors
>>>>>>>>>>> 
>>>>>>>>>>> *  [e-mail] (the RPC team)
>>>>>>>>>>> 
>>>>>>>>>>> *  other document participants, depending on the stream (e.g.,
>>>>>>>>>>>  IETF Stream participants are your working group chairs, the
>>>>>>>>>>>  responsible ADs, and the document shepherd).
>>>>>>>>>>> 
>>>>>>>>>>> *  [e-mail], which is a new archival mailing list
>>>>>>>>>>>  to preserve AUTH48 conversations; it is not an active discussion
>>>>>>>>>>>  list:
>>>>>>>>>>> 
>>>>>>>>>>> *  More info:
>>>>>>>>>>>    https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>>>>>>>>> 
>>>>>>>>>>> *  The archive itself:
>>>>>>>>>>>    https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>>>>>>> 
>>>>>>>>>>> *  Note: If only absolutely necessary, you may temporarily opt out
>>>>>>>>>>>    of the archiving of messages (e.g., to discuss a sensitive matter).
>>>>>>>>>>>    If needed, please add a note at the top of the message that you
>>>>>>>>>>>    have dropped the address. When the discussion is concluded,
>>>>>>>>>>>    [e-mail] will be re-added to the CC list and
>>>>>>>>>>>    its addition will be noted at the top of the message.
>>>>>>>>>>> 
>>>>>>>>>>> You may submit your changes in one of two ways:
>>>>>>>>>>> 
>>>>>>>>>>> An update to the provided XML file
>>>>>>>>>>> — OR —
>>>>>>>>>>> An explicit list of changes in this format
>>>>>>>>>>> 
>>>>>>>>>>> Section # (or indicate Global)
>>>>>>>>>>> 
>>>>>>>>>>> OLD:
>>>>>>>>>>> old text
>>>>>>>>>>> 
>>>>>>>>>>> NEW:
>>>>>>>>>>> new text
>>>>>>>>>>> 
>>>>>>>>>>> You do not need to reply with both an updated XML file and an explicit
>>>>>>>>>>> list of changes, as either form is sufficient.
>>>>>>>>>>> 
>>>>>>>>>>> We will ask a stream manager to review and approve any changes that seem
>>>>>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text,
>>>>>>>>>>> and technical changes.  Information about stream managers can be found in
>>>>>>>>>>> the FAQ.  Editorial changes do not require approval from a stream manager.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Approving for publication
>>>>>>>>>>> --------------------------
>>>>>>>>>>> 
>>>>>>>>>>> To approve your RFC for publication, please reply to this email stating
>>>>>>>>>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>>>>>>>>>>> as all the parties CCed on this message need to see your approval.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Files
>>>>>>>>>>> -----
>>>>>>>>>>> 
>>>>>>>>>>> The files are available here:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262.xml
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262.pdf
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262.txt
>>>>>>>>>>> 
>>>>>>>>>>> Diff file of the text:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262-diff.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262-rfcdiff.html (side by side)
>>>>>>>>>>> 
>>>>>>>>>>> This file will allow you to more easily view changes in any text that was moved (e.g., acknowledgements; some paragraphs were moved before or after the figures):
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262-alt-diff.html
>>>>>>>>>>> 
>>>>>>>>>>> Diff of the XML:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262-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/rfc9262.original.v2v3.xml
>>>>>>>>>>> 
>>>>>>>>>>> XMLv3 file that is a best effort to capture v3-related format updates
>>>>>>>>>>> only:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9262.form.xml
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Tracking progress
>>>>>>>>>>> -----------------
>>>>>>>>>>> 
>>>>>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9262
>>>>>>>>>>> 
>>>>>>>>>>> Please let us know if you have any questions.
>>>>>>>>>>> 
>>>>>>>>>>> Thank you for your cooperation,
>>>>>>>>>>> 
>>>>>>>>>>> RFC Editor
>>>>>>>>>>> 
>>>>>>>>>>> --------------------------------------
>>>>>>>>>>> RFC9262 (draft-ietf-bier-te-arch-13)
>>>>>>>>>>> 
>>>>>>>>>>> Title            : Tree Engineering for Bit Index Explicit Replication (BIER-TE)
>>>>>>>>>>> Author(s)        : T.T.E. Eckert, Ed., M.M. Menth, G.C. Cauchie
>>>>>>>>>>> WG Chair(s)      : Tony Przygienda, Greg Shepherd
>>>>>>>>>>> 
>>>>>>>>>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> -- 
>>>>>>>>>> ---
>>>>>>>>>> [e-mail]
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> ---
>>>>>>>> [e-mail]
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> -- 
>>> Prof. Dr. habil. Michael Menth
>>> University of Tuebingen
>>> Faculty of Science
>>> Department of Computer Science
>>> Chair of Communication Networks
>>> Sand 13, 72076 Tuebingen, Germany
>>> phone: [phone]
>>> fax: [phone]
>>> mailto:[e-mail]
>>> http://kn.inf.uni-tuebingen.de
>>> 
> 
> -- 
> Prof. Dr. habil. Michael Menth
> University of Tuebingen
> Faculty of Science
> Department of Computer Science
> Chair of Communication Networks
> Sand 13, 72076 Tuebingen, Germany
> phone: [phone]
> fax: [phone]
> mailto:[e-mail]
> http://kn.inf.uni-tuebingen.de