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

[Lynne Bartholomew <[e-mail]>]

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