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

[Lynne Bartholomew <[e-mail]>]

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]
>