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

[Toerless Eckert <[e-mail]>]

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]