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

[Lynne Bartholomew <[e-mail]>]

Dear authors,

Checking in with you regarding the status of this document.  Please review our questions below in this email thread, and let us know how this document should be updated.

The files are posted here:

   https://www.rfc-editor.org/authors/rfc9262.txt
   https://www.rfc-editor.org/authors/rfc9262.html
   https://www.rfc-editor.org/authors/rfc9262.pdf
   https://www.rfc-editor.org/authors/rfc9262.xml
   https://www.rfc-editor.org/authors/rfc9262-diff.html
   https://www.rfc-editor.org/authors/rfc9262-alt-diff.html
   https://www.rfc-editor.org/authors/rfc9262-rfcdiff.html

   https://www.rfc-editor.org/authors/rfc9262-xmldiff1.html
   https://www.rfc-editor.org/authors/rfc9262-xmldiff2.html

Thank you!

RFC Editor/lb

> On Jul 22, 2022, at 3:13 PM, Lynne Bartholomew <[e-mail]> wrote:
> 
> Hi, Toerless.  Thank you for letting us know, and no worries.  Good point about IETF 114; we will hold off on the reminders until August 5 or so.
> 
> Thanks again for checking in, and we hope that IETF 114 goes well!
> 
> RFC Editor/lb
> 
>> On Jul 22, 2022, at 2:52 PM, Toerless Eckert <[e-mail]> wrote:
>> 
>> 
>> No, sorry for the delay. Unfortunately, there is a lot of stuff
>> to prepare for IETF114, so i will only get to this shortly after
>> IETF114 ;-(
>> 
>> But thank you so much for your work.
>> 
>> Cheers
>>  Toerless
>> 
>> On Fri, Jul 22, 2022 at 02:09:10PM -0700, Lynne Bartholomew wrote:
>>> Dear authors,
>>> 
>>> We do not believe that we have heard from you regarding this document's readiness for publication.  Please see the questions below.
>>> 
>>> The latest files are posted 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
>>> https://www.rfc-editor.org/authors/rfc9262-diff.html
>>> https://www.rfc-editor.org/authors/rfc9262-alt-diff.html
>>> https://www.rfc-editor.org/authors/rfc9262-rfcdiff.html
>>> 
>>> https://www.rfc-editor.org/authors/rfc9262-xmldiff1.html
>>> https://www.rfc-editor.org/authors/rfc9262-xmldiff2.html
>>> 
>>> Thank you!
>>> 
>>> RFC Editor/lb
>>> 
>>>> On Jul 11, 2022, at 6:47 PM, [e-mail] wrote:
>>>> 
>>>> Authors,
>>>> 
>>>> While reviewing this document during AUTH48, please resolve (as necessary) 
>>>> the following questions, which are also in the XML file.
>>>> 
>>>> 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 -->
>>>> 
>>>> 
>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
>>>> title) for use on <https://www.rfc-editor.org/search>. -->
>>>> 
>>>> 
>>>> 3) <!-- [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.) -->
>>>> 
>>>> 
>>>> 4) <!-- [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.
>>>> 
>>>> Original:
>>>> Except for the optional routed adjacencies, BIER-TE does not require
>>>> a BIER routing underlay, and can therefore operate without depending
>>>> on an "Interior Gateway Routing protocol" (IGP).
>>>> ...
>>>> Except for
>>>> the optional routed adjacencies, BIER-TE does not require a BIER
>>>> routing underlay, and can therefore operate without depending on an
>>>> "Interior Gateway Routing protocol" (IGP).
>>>> 
>>>> Currently:
>>>> Except for the optional routed adjacencies,
>>>> BIER-TE does not require a BIER routing underlay and can therefore
>>>> operate without depending on a routing protocol such as the Interior
>>>> Gateway Protocol (IGP).
>>>> ...
>>>> Except for
>>>> the optional routed adjacencies, BIER-TE does not require a BIER
>>>> routing underlay and can therefore operate without depending on a
>>>> routing protocol such as the Interior Gateway Protocol (IGP). -->
>>>> 
>>>> 
>>>> 5) <!-- [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.
>>>> 
>>>> Original:
>>>> All BFRs
>>>> can act as an ingress BFR (BFIR), BFR1, BFR3, BFR4 and BFR6 can also
>>>> be BFERs.
>>>> 
>>>> Currently:
>>>> All
>>>> BFRs can act as a Bit-Forwarding Ingress Router (BFIR); BFR1, BFR3,
>>>> BFR4, and BFR6 can also be BFERs. -->
>>>> 
>>>> 
>>>> 6) <!-- [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.
>>>> 
>>>> Original:
>>>> This is
>>>> showing the ability of the shown BIER-TE Topology to make the traffic
>>>> pass across any possible path and be replicated where desired.
>>>> 
>>>> Currently:
>>>> This
>>>> demonstrates the ability of the BIER-TE Topology, as shown in
>>>> Figure 1, to make the traffic pass across any possible path and be
>>>> replicated where desired. -->
>>>> 
>>>> 
>>>> 7) <!-- [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".
>>>> 
>>>> Original:
>>>> To emphasize non-L2, but routed/tunneled forwarding of
>>>> BIER-TE packets, these adjacencies are called "forward_routed".
>>>> 
>>>> Suggested:
>>>> To specify routed/tunneled forwarding of BIER-TE packets
>>>> (i.e., not Layer 2), these adjacencies are called "forward_routed()"
>>>> adjacencies. -->
>>>> 
>>>> 
>>>> 8) <!-- [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.
>>>> 
>>>> Original:
>>>> A
>>>> packet from BFR1 to be received by BFR4, and from BFR4 to be received
>>>> by BFR6 and from there to be received by BFR3 uses
>>>> (p2,p3,p4,p6,p7,p9).  A packet from BFR1 to be received by BFR3, and
>>>> from BFR3 to be received by BFR6 there to be received by BFR4 uses
>>>> (p1,p3,p4,p5,p8,p9).
>>>> 
>>>> Suggested:
>>>> A
>>>> packet from BFR1 to be received by BFR4, then from BFR4 to be
>>>> received by BFR6, and finally from BFR6 to be received by BFR3, uses
>>>> (p2,p3,p4,p6,p7,p9).  A packet from BFR1 to be received by BFR3,
>>>> then from BFR3 to be received by BFR6, and finally from BFR6 to be
>>>> received by BFR4, uses (p1,p3,p4,p5,p8,p9). -->
>>>> 
>>>> 
>>>> 9) <!-- [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".
>>>> 
>>>> Original:
>>>> 2.  The BIER-TE layer forwarding plane does not require BFRs to
>>>>   have a unique BP and therefore also no unique BFR-id.
>>>> 
>>>> Suggested:
>>>> 2.  The BIER-TE layer forwarding plane does not require BFRs to
>>>>   have a unique BP; therefore, a unique BFR-id is not needed
>>>>   either. -->
>>>> 
>>>> 
>>>> 10) <!-- [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.
>>>> 
>>>> Original:
>>>> When a BIER-TE controller is used, then the signaling for the
>>>> Multicast Flow Overlay may also be preferred to operate through a
>>>> central point of control.
>>>> 
>>>> Suggested:
>>>> When a BIER-TE controller is used, it might also be preferable that
>>>> Multicast Flow Overlay signaling be performed through a central
>>>> point of control. -->
>>>> 
>>>> 
>>>> 11) <!-- [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?).
>>>> 
>>>> Original:
>>>> In the (non-TE) BIER architecture [RFC8279], the BIER control plane
>>>> is not explicitly separated from the BIER forwarding plane, but
>>>> instead their functions are summarized together in Section 4.2.
>>>> 
>>>> Suggested:
>>>> In the (non-TE) BIER architecture [RFC8279], the BIER control plane
>>>> is not explicitly separated from the BIER forwarding plane.  See
>>>> Section 4.2 for a description of relevant functions. -->
>>>> 
>>>> 
>>>> 12) <!-- [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.
>>>> 
>>>> Original:
>>>> 1.  Determine the desired BIER-TE topology for a BIER-TE sub-
>>>>   domains: the native and/or overlay adjacencies that are
>>>>   assigned to BPs.
>>>> 
>>>> Currently:
>>>> 1.  Determine the desired BIER-TE topology for BIER-TE subdomains:
>>>>   the native and/or overlay adjacencies that are assigned to
>>>>   BPs. -->
>>>> 
>>>> 
>>>> 13) <!-- [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.
>>>> 
>>>> Original:
>>>> 2.  Determine the BitStrings and optionally Entropy.  This is
>>>>   discussed in Section 3.2.1.2, Section 3.5 and Section 5.3.4. -->
>>>> 
>>>> 
>>>> 14) <!-- [rfced] Section 3.2:  To what does "the main responsibility"
>>>> refer?  If the suggested text is not correct, please clarify.
>>>> 
>>>> Original:
>>>> Different aspects
>>>> of this and the next point are discussed throughout
>>>> Section 3.2.1 and in Section 4.3, but the main responsibility
>>>> of these two points is with the Multicast Flow Overlay
>>>> (Section 3.1), which is architecturally inherited from BIER.
>>>> 
>>>> Suggested:
>>>> Different aspects
>>>> of this point, as well as the next point, are discussed
>>>> throughout Section 3.2.1 and in Section 4.3, but the main
>>>> purpose of these two points relates to the Multicast Flow
>>>> Overlay (Section 3.1), which is architecturally inherited from
>>>> BIER. -->
>>>> 
>>>> 
>>>> 15) <!-- [rfced] Regarding this note from you:
>>>> 
>>>> [RFC-Editor: the following text has three references to anchors 
>>>> topology-control, topology-control-1 and tree-control. Unfortunately, 
>>>> XMLv2 does not offer any tagging that reasonable references are generated
>>>> (i had this problem already in RFCs last year. Please make sure there 
>>>> are useful-to-read cross-references in the RFC in these three places 
>>>> after you convert to XMLv3.]
>>>> 
>>>> With v3, it appears to us that the "topology-control" and
>>>> "tree-control" tags, whose anchors are embedded in "top-level"
>>>> "<dd>" elements, are working properly in the .html and .pdf
>>>> outputs.  However, the "topology-control-1" link, whose anchor was
>>>> embedded in a nested "<li>" element, was translated in the text of
>>>> Section 3.2.1.1 by v3 (as it was in the submitted v2 copy) as
>>>> "(Section 3.2, Paragraph 3, Item 2.2.1)", which was inaccurate given
>>>> that the list is only two levels deep.
>>>> 
>>>> We applied 'format="none"' to the "topology-control-1" xref as
>>>> follows:  <xref target="topology-control-1" format="none">.  We also
>>>> included a pointer to Section 3.2, as noted below.  Please check the
>>>> updated links in the .html and .pdf outputs, and let us know any
>>>> concerns.
>>>> 
>>>> Original:
>>>> The first item of BIER-TE topology control (Section 3.2, Paragraph 3,
>>>> Item 2.2.1) includes network topology discovery and BIER-TE topology
>>>> creation.
>>>> 
>>>> Currently (two links, the first more specific than the second):
>>>> The first item listed for BIER-TE topology control (Section 3.2)
>>>> includes network topology discovery and BIER-TE topology creation. -->
>>>> 
>>>> 
>>>> 16) <!-- [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.
>>>> 
>>>> Original:
>>>> In other networks, topology discovery may rely on protocols including
>>>> extending a "Link-State-Protocol" based IGP into the BIER-TE
>>>> controller itself, [RFC7752] (BGP-LS) or [RFC8345] (YANG topology) as
>>>> well as BIER-TE specific methods, for example via
>>>> [I-D.ietf-bier-te-yang].
>>>> 
>>>> Suggested:
>>>> In other networks, topology discovery may rely on such protocols as
>>>> those that include extending an IGP based on a link-state protocol
>>>> into the BIER-TE controller itself, e.g., BGP-LS [RFC7752] or YANG
>>>> topology [RFC8345], as well as methods specific to BIER-TE - for
>>>> example, via [BIER-TE-YANG]. -->
>>>> 
>>>> 
>>>> 17) <!-- [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.
>>>> 
>>>> Original:
>>>> When the BIER-TE topology is determined, the BIER-TE Controller then
>>>> pushes the BitPositions/adjacencies to the BIFT of the BFRs.  On each
>>>> BFR only those SI:BitPositions are populated that are adjacencies to
>>>> other BFRs in the BIER-TE topology. -->
>>>> 
>>>> 
>>>> 18) <!-- [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.
>>>> 
>>>> Original:
>>>> Vendor-specific CLI on the BFRs is also an option (as in many
>>>> other SDN solutions lacking definition of standardized data models).
>>>> 
>>>> Currently:
>>>> A vendor-specific CLI on the BFRs is also an option (as in
>>>> many other Software-Defined Network (SDN) solutions lacking
>>>> definitions of standardized data models). -->
>>>> 
>>>> 
>>>> 19) <!-- [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.
>>>> 
>>>> Original:
>>>> Likewise, the BitString from
>>>> the same BFIR to the same set of BFER can be different for different
>>>> overlay flows for policy reasons such as shortest path trees, Steiner
>>>> trees (minimum cost trees), diverse path trees for redundancy and so
>>>> on.
>>>> 
>>>> Suggested (assuming that the different overlay flows apply here):
>>>> Likewise, for policy reasons, the BitString from
>>>> the same BFIR to the same set of BFERs can be different for such
>>>> different overlay flows as shortest path trees, Steiner trees
>>>> (minimum-cost trees), diverse path trees for redundancy, and so on. -->
>>>> 
>>>> 
>>>> 20) <!-- [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.
>>>> 
>>>> Original:
>>>> See also [I-D.ietf-bier-multicast-http-response] for an application
>>>> leveraging BIER-TE engineered trees. -->
>>>> 
>>>> 
>>>> 21) <!-- [rfced] Section 3.2.1.4:  For ease of the reader, we expanded
>>>> "FRR" as "Fast Reroute".  Please let us know any objections.
>>>> 
>>>> Original:
>>>> When link or nodes fail or recover in the topology, BIER-TE could
>>>> quickly respond with FRR procedures such as [I-D.eckert-bier-te-frr],
>>>> the details of which are out of scope for this document.
>>>> 
>>>> Currently:
>>>> When links or nodes fail or recover in the topology, BIER-TE could
>>>> quickly respond with Fast Reroute (FRR) procedures such as those
>>>> described in [BIER-TE-PROTECTION], the details of which are out of
>>>> scope for this document. -->
>>>> 
>>>> 
>>>> 22) <!-- [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.
>>>> 
>>>> Original:
>>>> This is driven by a combination of state established by
>>>> the BIER-TE control plane and/or the multicast flow overlay as
>>>> explained in Section 3.1.
>>>> 
>>>> Currently:
>>>> This is driven by state established by the BIER-TE
>>>> control plane, the multicast flow overlay as explained in
>>>> Section 3.1, or a combination of both. -->
>>>> 
>>>> 
>>>> 23) <!-- [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.
>>>> 
>>>> Original:
>>>> Processing of other BIER header fields such as DSCP
>>>> is outside the scope of this document.
>>>> 
>>>> Currently:
>>>> Processing of other BIER header fields, such as the
>>>> Differentiated Services Code Point (DSCP) field, is outside the
>>>> scope of this document. -->
>>>> 
>>>> 
>>>> 24) <!-- [rfced] Section 3.4:  Does "This" mean "This process", "This
>>>> calculation", or something else?  Please clarify.
>>>> 
>>>> Original (the previous sentence is included for context):
>>>> BIER relies on the routing underlay to calculate paths towards BFERs
>>>> and derive next-hop BFR adjacencies for those paths.  This commonly
>>>> relies on BIER specific extensions to the routing protocols of the
>>>> routing underlay but may also be established by a controller. -->
>>>> 
>>>> 
>>>> 25) <!-- [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.
>>>> 
>>>> Original:
>>>> If the BFR intends to support FRR for BIER-TE, then the BIER-TE
>>>> forwarding plane needs to receive fast adjacency up/down
>>>> notifications: Link up/down or neighbor up/down, e.g. from BFD.
>>>> 
>>>> Currently:
>>>> If the BFR intends to support FRR for BIER-TE, then the BIER-TE
>>>> forwarding plane needs to receive fast adjacency up/down
>>>> notifications: link up/down or neighbor up/down, e.g., from
>>>> Bidirectional Forwarding Detection (BFD). -->
>>>> 
>>>> 
>>>> 26) <!-- [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.
>>>> 
>>>> Original (the previous sentence is included for context):
>>>> Traffic Engineering ([I-D.ietf-teas-rfc3272bis]) provides performance
>>>> optimization of operational IP networks while utilizing network
>>>> resources economically and reliably.  The key elements needed to
>>>> effect TE are policy, path steering and resource management.
>>>> 
>>>> Suggested:
>>>> The key elements needed to effect Traffic Engineering are
>>>> policy, path steering, and resource management. -->
>>>> 
>>>> 
>>>> 27) <!-- [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?).
>>>> 
>>>> Original:
>>>> The resource usage of the BIER-TE traffic
>>>> admitted by the BIER-TE controller can be solely tracked on the BIER-
>>>> TE Controller based on local accounting as long as no
>>>> forward_routed() adjacencies are used (see Section 4.2.1 for the
>>>> definition of forward_routed() adjacencies).
>>>> 
>>>> Currently:
>>>> The resource usage of the BIER-TE traffic
>>>> admitted by the BIER-TE controller can be solely tracked on the BIER-
>>>> TE Controller based on local accounting as long as no
>>>> forward_routed() adjacencies are used (see Section 4.2.2 for the
>>>> definition of forward_routed() adjacencies). -->
>>>> 
>>>> 
>>>> 28) <!-- [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".
>>>> 
>>>> Original (the previous two sentences are included for context;
>>>> "shown shown" has been corrected):
>>>> The BIER-TE BIFT is the equivalent to the BIER BIFT for (non-TE)
>>>> BIER.  It exists on every BFR running BIER-TE.  For every BIER sub-
>>>> domain (SD) in use for BIER-TE, it is a table as shown shown in
>>>> Figure 4.
>>>> 
>>>> Suggested:
>>>> For every BIER subdomain (SD) in use
>>>> for BIER-TE, the BIFT would be constructed per the example shown in
>>>> Figure 4. -->
>>>> 
>>>> 
>>>> 29) <!-- [rfced] Section 4.1:  Does "those adjacencies forwarding
>>>> entries" mean "those adjacencies that forward entries", "those
>>>> adjacencies' forwarding entries", or something else?
>>>> 
>>>> Original:
>>>> In BIER-TE, each BIFT-index and therefore SI:BP indicates one or more
>>>> adjacencies between BFRs in the topology and is only populated with
>>>> those adjacencies forwarding entries on the BFR that is the upstream
>>>> for these adjacencies. -->
>>>> 
>>>> 
>>>> 30) <!-- [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.
>>>> 
>>>> Original:
>>>> ...
>>>>    BIER-TE Bit Index Forwarding Table (BIFT)
>>>> 
>>>> Figure 4: BIER-TE BIFT with different adjacencies
>>>> 
>>>> Currently:
>>>> ...
>>>> Figure 4: BIER-TE Bit Index Forwarding Table (BIFT) with
>>>>                Different Adjacencies -->
>>>> 
>>>> 
>>>> 31) <!-- [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.
>>>> 
>>>> Original:
>>>> The BIFT is then used to forward packets, according to the rules
>>>> specified in the BIER-TE Forwarding Procedures. -->
>>>> 
>>>> 
>>>> 32) <!-- [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.
>>>> 
>>>> Original:
>>>> See Section 5.1.6 for an example of how a
>>>> BIER-TE controller could assign BPs to (logical) adjacencies shared
>>>> across multiple BFRs, Section 5.1.3 for an example of assigning the
>>>> same BP to different adjacencies, and Section 5.1.9 for general
>>>> guidelines regarding re-use of BPs across different adjacencies. -->
>>>> 
>>>> 
>>>> 33) <!-- [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.
>>>> 
>>>> Original:
>>>> This identification can either rely on the BIER/BIER-TE co-
>>>> existence mechanisms described in Section 4.3, or by explicit support
>>>> for a BIER-TE payload type in the tunneling encapsulation.
>>>> 
>>>> Suggested (assuming that this identification relies on either
>>>> the mechanisms or explicit support):
>>>> This identification can rely on either the BIER/BIER-TE co-
>>>> existence mechanisms described in Section 4.3 or explicit support
>>>> for a BIER-TE payload type in the tunneling encapsulation. -->
>>>> 
>>>> 
>>>> 34) <!-- [rfced] Section 4.3:  We found the wording of this sentence
>>>> confusing, as it prompted us to 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.
>>>> 
>>>> Original:
>>>> Like [RFC8279], handling of "Maximum Transmission Unit" (MTU)
>>>> limitations is outside the scope of this document and instead part of
>>>> the BIER-TE packet encapsulation and/or flow overlay.  See for
>>>> example [RFC8296], Section 3.
>>>> 
>>>> Suggested:
>>>> The handling of Maximum Transmission Unit (MTU) limitations is
>>>> outside the scope of this document and is not discussed in
>>>> [RFC8279].  Instead, this process is part of the BIER-TE packet
>>>> encapsulation and/or flow overlay; for example, see [RFC8296],
>>>> Section 3. -->
>>>> 
>>>> 
>>>> 35) <!-- [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?
>>>> 
>>>> If the suggested text is not correct, please clarify.
>>>> 
>>>> Original:
>>>> When a fixed mapping from BSL, SD and SI to BIFT-id is used which
>>>> does not explicitly partition the BIFT-id space between BIER and
>>>> BIER-TE, such as proposed for non-MPLS forwarding with [RFC8296]
>>>> encapsulation in [I-D.ietf-bier-non-mpls-bift-encoding] revision 04,
>>>> section 5, then it is necessary to allocate disjoint SDs to BIER and
>>>> BIER-TE BIFTs so that both can be addressed by the BIFT-ids.  The
>>>> encoding proposed in section 6. of the same document does not
>>>> statically encode BSL or SD into the BIFT-id, but allows for a
>>>> mapping, and hence could provide for the same freedom as when MPLS is
>>>> being used (same or different SD for BIER/BIER-TE).
>>>> 
>>>> Suggested (assuming that the fixed mapping never explicitly
>>>> partitions the BIFT-id space; also assuming "different SDs"):
>>>> When a fixed mapping from BSL, SD, and SI to a BIFT-id is used,
>>>> which does not explicitly partition the BIFT-id space between BIER
>>>> and BIER-TE - for example, as proposed for non-MPLS forwarding with
>>>> BIER encapsulation [RFC8296] in [NON-MPLS-BIER-ENCODING], Section 5
>>>> - it is necessary to allocate disjoint SDs to BIER and BIER-TE BIFTs
>>>> so that both can be addressed by the BIFT-ids.  The encoding
>>>> proposed in Section 6 of [NON-MPLS-BIER-ENCODING] does not
>>>> statically encode the BSL or SD into the BIFT-id, but the encoding
>>>> permits a mapping and hence could provide the same freedom as when
>>>> MPLS is being used (the same SD, or different SDs for BIER/BIER-TE). -->
>>>> 
>>>> 
>>>> 36) <!-- [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>. -->
>>>> 
>>>> 
>>>> 37) <!-- [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".
>>>> 
>>>> Original:
>>>> This protects against BIER replication on any
>>>> possible further BFR to create duplicates ([2]).
>>>> 
>>>> Suggested:
>>>> This prevents BIER's replication logic from creating duplicates on
>>>> any possible further BFRs ([2]). -->
>>>> 
>>>> 
>>>> 38) <!-- [rfced] Section 4.4:  This sentence does not parse.  If the
>>>> suggested text is not correct, please clarify.
>>>> 
>>>> Original:
>>>> This Forwarding Pseudocode can support the required BIER-TE
>>>> forwarding functions (see Section 4.5), forward_connected(),
>>>> forward_routed() and local_decap(), but not the recommended functions
>>>> DNC flag and multiple adjacencies per bit nor the optional function,
>>>> ECMP() adjacencies.
>>>> 
>>>> Suggested:
>>>> This Forwarding Pseudocode can support the required BIER-TE
>>>> forwarding functions (see Section 4.5) - forward_connected(),
>>>> forward_routed(), and local_decap() - but cannot support the
>>>> recommended functions (DNC flag and multiple adjacencies per bit)
>>>> or the optional function (i.e., ECMP() adjacencies). -->
>>>> 
>>>> 
>>>> 39) <!-- [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"?
>>>> 
>>>> (For an example of superscripting in a recent RFC, see the
>>>> "Implementation Note" paragraph in Appendix A of RFC 9260
>>>> (https://www.rfc-editor.org/rfc/rfc9260.html).
>>>> 
>>>> Original:
>>>> *  This pseudocode eliminates per-bit F-BM, therefore reducing the
>>>>  size of BIFT state by BSL^2*SI and eliminating the need for per-
>>>>  packet-copy BitString masking operations except for adjacencies
>>>>  with the DNC flag set: -->
>>>> 
>>>> 
>>>> 40) <!-- [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_"?).
>>>> 
>>>> Original:
>>>> This is an
>>>> optional requirement, because for ECMP deployments using BIER-TE one
>>>> can also leverage ECMP of the routing underlay via forwarded_routed
>>>> adjacencies and/or might prefer to have more explicit control of the
>>>> path chosen via explicit BP/adjacencies for each ECMP path
>>>> alternative.
>>>> 
>>>> Currently:
>>>> This is an
>>>> optional requirement, because for ECMP deployments using BIER-TE one
>>>> can also leverage the routing underlay ECMP via forward_routed()
>>>> adjacencies and/or might prefer to have more explicit control of the
>>>> path chosen via explicit BPs/adjacencies for each ECMP path
>>>> alternative. -->
>>>> 
>>>> 
>>>> 41) <!-- [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.
>>>> 
>>>> Original:
>>>> On a P2P link that connects two BFRs, the same bit position can be
>>>> used on both BFRs for the adjacency to the neighboring BFR. -->
>>>> 
>>>> 
>>>> 42) <!-- [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)?
>>>> 
>>>> Original (best viewed with a fixed-point font such as Courier;
>>>> dashed lines are broken so that they will not be confused with a
>>>> comment):
>>>>        BFR1
>>>>         |p1
>>>>  LAN1-+-+- -+- - -+
>>>>      p3|  p4|   p2|
>>>>      BFR3 BFR4  BFR7
>>>> 
>>>> Figure 8: LAN Example
>>>> 
>>>> Perhaps:
>>>>        BFR1
>>>>         |p1
>>>>  LAN1-+-+- -+- - -+
>>>>     p3|   p4|   p2|
>>>>     BFR3  BFR4  BFR7
>>>> 
>>>> Figure 8: LAN Example
>>>> 
>>>> Or possibly:
>>>>        BFR1
>>>>         |p1
>>>>  LAN1-+-+- - -+- - -+
>>>>       p3|   p4|   p2|
>>>>       BFR3  BFR4  BFR7
>>>> 
>>>> Figure 8: LAN Example -->
>>>> 
>>>> 
>>>> 43) <!-- [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?
>>>> 
>>>> Original:
>>>> Adjacencies of such BFRs into their LAN still need a
>>>> separate bit position. -->
>>>> 
>>>> 
>>>> 44) <!-- [rfced] We have removed "(SA)" as SA is not used elsewhere in the 
>>>> text.  Please let us know any objections. 
>>>> 
>>>> Original:
>>>> This type of optimized BP could be used for example when all traffic
>>>> is "broadcast" traffic (very dense receiver set) such as live-TV or
>>>> many-to-many telemetry including situation-awareness (SA).
>>>> -->
>>>> 
>>>> 
>>>> 45) <!-- [rfced] Section 5.1.6:
>>>> 
>>>> a) As all other mentions of "ring" related to Figure 9 are singular,
>>>> we changed "the rings shown in Figure 9" to "the ring shown in
>>>> Figure 9".  Note:  If this update is incorrect, please review all
>>>> instances of the singular "ring" in this section, and let us know if
>>>> they should be changed to "rings" (e.g., "entering the ring", "any
>>>> BFR in the ring").
>>>> 
>>>> b) 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: -->
>>>> 
>>>> 
>>>> 46) <!-- [rfced] Section 5.1.7:  Regarding this question from you:
>>>> [RFC-Editor: A reviewer (Lars Eggert) noted that the infinite "to use" 
>>>> in the following sentence is not correct. The same was also noted for 
>>>> several other similar instances. The following URL seems to indicate 
>>>> though that this is a per-case decision, which seems undefined: https://writingcenter.gmu.edu/guides/choosing-between-infinitive-and-gerund-to-do-or-doing. What exactly should be done about this ?].
>>>> 
>>>> Thank you for asking this question.  We reviewed all such instances
>>>> in this document and updated the text where needed.  Please review,
>>>> and let us know any concerns regarding our updates. -->
>>>> 
>>>> 
>>>> 47) <!-- [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?
>>>> 
>>>> Original:
>>>> Packets with both BP 0:5 and BP
>>>> 0:6 would now be able to reach both BFR2 and BFR3 and the still
>>>> existing re-use of BP 0:7 between BFR2 and BFR3 is a case of (B)
>>>> where reuse of BP is perfect because it does not limit the set of
>>>> useful path choices: -->
>>>> 
>>>> 
>>>> 48) <!-- [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".
>>>> 
>>>> Original:
>>>> These two BPs could be reused across the 5
>>>> areas.  Packets would be replicated through other BPs for the Core to
>>>> the desired subset of areas, and once a packet copy reaches the ring
>>>> of the area, the two ring BPs come into play. -->
>>>> 
>>>> 
>>>> 49) <!-- [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".
>>>> 
>>>> Original:
>>>> Without any optimization, a BIER-TE Controller would attempt to map
>>>> the network subnet topology 1:1 into the BIER-TE topology and every
>>>> subnet adjacent neighbor requires a forward_connected() BP and every
>>>> BFER requires a local_decap() BP.
>>>> 
>>>> Currently:
>>>> Without any optimization, a BIER-TE Controller would attempt to map
>>>> the network subnet topology 1:1 into the BIER-TE topology, every
>>>> adjacent neighbor in the subnet would require a forward_connected()
>>>> BP, and every BFER would require a local_decap() BP. -->
>>>> 
>>>> 
>>>> 50) <!-- [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.
>>>> 
>>>> Original:
>>>> For (non-TE) BIER and BIER-TE forwarding, the most important result
>>>> of using multiple SI and/or sub-domains is the same: Packets that
>>>> need to be sent to BFERs in different SIs or sub-domains require
>>>> different BIER packets: each one with a BitString for a different
>>>> (SI,sub-domain) combination.
>>>> 
>>>> Suggested (guessing that the packets must be sent as distinct BIER
>>>> packets):
>>>> For (non-TE) BIER and BIER-TE forwarding, the most important result
>>>> of using multiple SIs and/or subdomains is the same: packets that
>>>> need to be sent to BFERs in different SIs or subdomains must be sent
>>>> as distinct BIER packets, each one with a BitString for a different
>>>> (SI,subdomain) combination. -->
>>>> 
>>>> 
>>>> 51) <!-- [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.
>>>> 
>>>> Original:
>>>> For BIER and BIER-TE forwarding themselves there is also no
>>>> difference whether different SIs and/or sub-domains are chosen, but
>>>> SI and sub-domain have different purposes in the BIER architecture
>>>> shared by BIER-TE.
>>>> 
>>>> Currently:
>>>> For BIER and BIER-TE forwarding, it doesn't matter whether or not
>>>> different SIs and/or subdomains are chosen, but SIs and subdomains
>>>> have different purposes in the BIER architecture in cases where it
>>>> also applies to BIER-TE. -->
>>>> 
>>>> 
>>>> 52) <!-- [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.
>>>> 
>>>> Original:
>>>> "Desired" topology because it depends on the physical topology, and
>>>> on the desire of the operator to allow for explicit path steering
>>>> across every single hop (which requires more bits), or reducing the
>>>> number of required bits by exploiting optimizations such as unicast
>>>> (forward_routed()), ECMP() or flood (DNC) over "uninteresting" sub-
>>>> parts of the topology - e.g. parts where different trees do not need
>>>> to take different paths due to path steering reasons.
>>>> 
>>>> Currently:
>>>> "Desired" topology means that it depends on the physical topology and
>>>> the operator's desire to
>>>> 
>>>> *  permit explicit path steering across every single hop (which
>>>>  requires more bits), or
>>>> 
>>>> *  reduce the number of required bits by exploiting optimizations
>>>>  such as unicast (forward_routed()), ECMP(), or flood (DNC) over
>>>>  "uninteresting" sub-parts of the topology, e.g., parts where, for
>>>>  path steering reasons, different trees do not need to take
>>>>  different paths. -->
>>>> 
>>>> 
>>>> 53) <!-- [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.
>>>> 
>>>> Original (the previous sentence is included for context.  "BIFR"
>>>> has been corrected):
>>>> The flow overlay on the BIFR can
>>>> then independently of the controller calculate the SI:BitString for
>>>> all desired BFERs by OR'ing their BitStrings.  This allows for flow
>>>> overlay applications to operate independently of the controller
>>>> whenever it needs to determine which subset of BFERs need to receive
>>>> a particular packet.
>>>> 
>>>> Suggested:
>>>> This allows flow
>>>> overlay applications to operate independently of the controller
>>>> whenever they need to determine which subset of BFERs needs to receive
>>>> a particular packet. -->
>>>> 
>>>> 
>>>> 54) <!-- [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.
>>>> 
>>>> Original (the previous sentence is included for context):
>>>> A.  BIER and BIER-TE have different BFR-id in the same sub-domain.
>>>> This allows higher replication efficiency for BIER because their BFR-
>>>> id can be assigned sequentially, while the BitStrings for BIER-TE
>>>> will have also the additional bits for the topology.
>>>> 
>>>> Suggested (assuming that "their" means "BIER and BIER-TE BFR-ids"):
>>>> A.  BIER and BIER-TE have different BFR-ids in the same subdomain.
>>>>   This allows higher replication efficiency for BIER because the
>>>>   BIER and BIER-TE BFR-ids can be assigned sequentially, while the
>>>>   BitStrings for BIER-TE will also have the additional bits for
>>>>   the topology. -->
>>>> 
>>>> 
>>>> 55) <!-- [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.
>>>> 
>>>> Original:
>>>> Allocating SIs to areas with initially sufficiently many spare bits
>>>> for growths can help to alleviate this issue.  Or renumber BFERs
>>>> after network expansion.
>>>> 
>>>> Currently:
>>>> Allocating SIs to areas that initially have sufficiently many spare
>>>> bits for growth can help alleviate this issue.  Alternatively, BFERs
>>>> can be renumbered after network expansion. -->
>>>> 
>>>> 
>>>> 56) <!-- [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.
>>>> 
>>>> Original:
>>>> This example shows that intelligent BFR-id allocation within at least
>>>> sub-domain 0 can even be helpful or even necessary in BIER.
>>>> 
>>>> Currently:
>>>> This example shows that intelligent BFR-id allocation within at least
>>>> subdomain 0 can be helpful or even necessary in BIER. -->
>>>> 
>>>> 
>>>> 57) <!-- [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?
>>>> 
>>>> 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".
>>>> 
>>>> Original:
>>>> These bits are then set up with the
>>>> right forward_routed() adjacencies on the BFIR and area edge BFR:
>>>> 
>>>> On all BFIRs in an area j|j=1...6, bia in each BIFT:SI is populated
>>>> with the same forward_routed(BFRja), and bib with
>>>> forward_routed(BFRjb).  On all area edge BFR, bea in
>>>> BIFT:SI=k|k=1...6 is populated with forward_routed(BFRka) and beb in
>>>> BIFT:SI=k with forward_routed(BFRkb).
>>>> 
>>>> For BIER-TE forwarding of a packet to a subset of BFERs across all
>>>> areas, a BFIR would create at most 6 copies, with SI=1...SI=6, In
>>>> each packet, the bits indicate bits for topology and BFER in that
>>>> topology plus the four bits to indicate whether to pass this packet
>>>> via the ingress area a or b border BFR and the egress area a or b
>>>> border BFR, therefore allowing path steering for those two "unicast"
>>>> legs: 1) BFIR to ingress area edge and 2) core to egress area edge.
>>>> Replication only happens inside the egress areas.  For BFER in the
>>>> same area as in the BFIR, these four bits are not used.
>>>> 
>>>> Suggested (second paragraph):
>>>> For BIER-TE forwarding of a packet to a subset of BFERs across all
>>>> areas, a BFIR would create at most six copies, with SI=1...SI=6.  In
>>>> each packet, these bits in turn indicate bits for the topology and
>>>> the BFERs in that topology, plus the four bits to indicate whether
>>>> to pass this packet via the ingress area a or b border BFR and the
>>>> egress area a or b border BFR, therefore allowing path steering for
>>>> those two "unicast" legs: 1) BFIR to ingress area edge and 2) core
>>>> to egress area edge.  Replication only happens inside the egress
>>>> areas.  For BFERs that are in the same area as the BFIR, these four
>>>> bits are not used. -->
>>>> 
>>>> 
>>>> 58) <!-- [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.
>>>> 
>>>> Original:
>>>> Attacking the protocols for the BIER routing
>>>> underlay or (non-TE) BIER layer control plane, or impairment of any
>>>> BFR in a domain may lead to successful attacks against the results of
>>>> the routing protocol, enabling DoS attacks against paths or the
>>>> addressing (BFR-id, BFR-prefixes) used by BIER.
>>>> 
>>>> Suggested:
>>>> Attacking the protocols for the BIER routing
>>>> underlay or (non-TE) BIER layer control plane, or the impairment of
>>>> any BFRs in a domain, may lead to successful attacks that target the
>>>> routing protocol, enabling DoS attacks against paths or the
>>>> addressing (BFR-ids, BFR-prefixes) used by BIER. -->
>>>> 
>>>> 
>>>> 59) <!-- [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".
>>>> 
>>>> Original:
>>>> In
>>>> result, BIER-TE has the same degree of looping packets as possible
>>>> with unintentional or malicious loops in the routing underlay with
>>>> BIER or even with unicast traffic.
>>>> 
>>>> Currently:
>>>> As a result, looping packets can occur in BIER-TE to the same degree
>>>> as is possible with unintentional or malicious loops in the routing
>>>> underlay with BIER, or even with unicast traffic. -->
>>>> 
>>>> 
>>>> 60) <!-- [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>.
>>>> -->
>>>> 
>>>> 
>>>> 61) <!-- [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.
>>>> 
>>>> For example, please clarify the following if our updates to the text
>>>> in question are incorrect:
>>>> 
>>>> * what "either" refers to in the second paragraph
>>>> * what "This can be called" refers to; we changed "This" to "These
>>>> segments"
>>>> * what "SID" stands for; we defined it as "Segment Identifier" per
>>>> RFC 8402
>>>> * what "would directly replicate to it" means; we changed it to "would
>>>> directly replicate traffic on it" -->
>>>> 
>>>> 
>>>> 62) <!-- [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. 
>>>> -->
>>>> 
>>>> 
>>>> 63) <!-- [rfced] Please let us know if any changes are needed for the
>>>> following:
>>>> 
>>>> a) The following terms were used inconsistently in this document.
>>>> We chose to use the latter forms.  Please let us know any objections.
>>>> 
>>>> BIFT index (1 instance) / BIFT-index (7 instances)
>>>> 
>>>> ECMP adjacencies (2 instances) / ECMP() adjacencies (10 instances)
>>>> 
>>>> FBM (1 instance) / F-BM
>>>> 
>>>> forward_routed adjacency (or adjacencies) (3 instances) /
>>>> forward_routed() adjacency (or adjacencies) (19 instances)
>>>> 
>>>> Leaf BFER (1 instance in text) / leaf BFER (2 instances in text)
>>>> 
>>>> Non-Leaf BFER (1 instance in text) /
>>>> non-Leaf BFER (3 instances in text) /
>>>> non-leaf BFER (5 instances in text)
>>>> 
>>>> p2p / P2P (in running text)
>>>> 
>>>> traffic engineering / Traffic Engineering (in running text)
>>>> (We see that "Tree Engineering" is consistently
>>>>  initial-capitalized in this document, so we went with the
>>>>  initial-capitalized form for "Traffic Engineering" as well.)
>>>> 
>>>> 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?)
>>>> 
>>>> BIER-TE controller / BIER-TE Controller
>>>> (For example, we see "... by the BIER-TE controller can be solely
>>>>  tracked on the BIER-TE Controller" in Section 3.5.)
>>>> 
>>>> (We also see both "controller" and "Controller" where used more
>>>>  generally, e.g., "a controller", "a Controller".  For
>>>>  consistency, please advise regarding which form should be used.)
>>>> 
>>>> BIER-TE Topology / BIER-TE topology (in running text)
>>>> 
>>>> entropy / Entropy (for example, "entropy field", "Entropy fields",
>>>> "and optionally Entropy", "the packet entropy")
>>>> 
>>>> Flow overlay / flow overlay (in running text)
>>>> (We see the lowercase form "routing underlay" used consistently
>>>>  in running text.)
>>>> 
>>>> Forwarding Pseudocode / forwarding pseudocode (in running text)
>>>> 
>>>> IP/IPv6 / IPv4/IPv6
>>>> 
>>>> leaf-BFER (noun) / leaf BFER (noun)
>>>> (We do not see any instances of  "non-leaf-BFER" where used as
>>>> a noun.  We suggest removing the hyphen after "leaf", as it
>>>> appears that the term appears to indicate whether or not a
>>>> BFER is a "leaf".)
>>>> 
>>>> Multicast Flow Overlay (3 instances in running text) /
>>>> multicast flow overlay (6 instances in running text)
>>>> 
>>>> SIs/BitStrings / SI:BitString / SI:BitStrings
>>>> Should the slash ("/") be a colon (":"), and should
>>>>   "SI:BitStrings" be "SIs:BitStrings"?
>>>> 
>>>> (We also see one instance of "SI:BitPositions".) -->
>>>> 
>>>> 
>>>> Thank you.
>>>> 
>>>> RFC Editor
>>>> 
>>>> 
>>>> 
>>>> On Jul 11, 2022, at 6:40 PM, [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)
>>>> 
>>>> 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]
>> 
>