[Bier] Lars Eggert's No Objection on draft-ietf-bier-te-arch-10: (with COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-bier-te-arch-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Robert Spark's GenART review on Aug 8 flagged a long list of issues and
nits that I haven't seen a response to yet. Please respond to Robert.

Section 1. , paragraph 12, comment:
>    Bloom filters in general can support larger trees/topologies with
>    fewer addressing bits than explicit BitStrings, but they introduce
>    the heuristic risk of false positives and cannot clear bits in the
>    BitString during forwarding to avoid loops.  For these reasons, BIER-
>    TE uses explicit BitStrings like BIER.  The explicit BitStrings of
>    BIER-TE can also be seen as a special type of Bloom filter, and this
>    is how related work [ICC] describes it.

There is research work on Bloom filters without false positives, e.g.,
https://ieeexplore.ieee.org/document/8486415. Don't want to start a long
debate, but was just wondering if these newer approaches wouldn't be suitable?

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "native"; alternatives might be "built-in", "fundamental",
   "ingrained", "intrinsic", "original".

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.3. , paragraph 2, nit:
-    BIER-TE is designed so that is forwarding plane is a simple extension
+    BIER-TE is designed so that its forwarding plane is a simple extension
+                                 +

Section 5.3.3. , paragraph 7, nit:
-    that is unique to the BFR in question.  For a BFIR this can be he
+    that is unique to the BFR in question.  For a BFIR this can be the
+                                                                   +

Section 2.1. , paragraph 15, nit:
> ies are called "forward_routed". Otherwise there is no difference in their p
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Otherwise".

Section 2.2. , paragraph 3, nit:
> The BIER forwarding plane, with the exception of how bits have to be cleared
>                            ^^^^^^^^^^^^^^^^^^^^^
Consider using "except" or "except for".

Section 3.2.1.1. , paragraph 4, nit:
> ne The BIER-TE Forwarding Plane constitutes of the following components: 1. O
>                                 ^^^^^^^^^^^^^^
Did you mean "consists of"?

Section 4.1. , paragraph 5, nit:
> meter. The seed parameter allows to design hash functions that are easy to i
>                                  ^^^^^^^^^
Did you mean "designing"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 4.4. , paragraph 6, nit:
> A DID NOT MIND ANOTHER EXAMPLE. Step by step example of basic BIER-TE forwar
>                                 ^^^^^^^^^^^^
Did you mean the adjective or adverb "Step-by-step" (spelled with hyphens)?

Section 4.4. , paragraph 23, nit:
> ER-TE forwarding functions can be implement via the same Forwarding Pseudocod
>                                   ^^^^^^^^^
The past participle is required after "can be".

Section 4.5. , paragraph 5, nit:
> re Non-Leaf BFER as shown on the right hand side, one traffic copy would be
>                                  ^^^^^^^^^^
Did you mean the adjective "right-hand"?

Section 4.5. , paragraph 5, nit:
> hich makes BFER2 a non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forw
>                                   ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Likewise".

Section 4.5. , paragraph 5, nit:
> FER2. Note that the BFERs in the left hand picture are only guaranteed to be
>                                  ^^^^^^^^^
Did you mean the adjective "left-hand"?

Section 4.5. , paragraph 9, nit:
> BFER can be used to distinguish whether or not packets should reach the BFER.
>                                 ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

Section 5.1.2. , paragraph 1, nit:
> h (ECMP) The ECMP adjacency allows to use just one BP per link bundle between
>                                    ^^^^^^
Did you mean "using"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 5.1.6. , paragraph 9, nit:
> ted() adjacencies can also allow to operate BIER-TE across intermediate hop
>                                  ^^^^^^^^^^
Did you mean "operating"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 5.1.7. , paragraph 1, nit:
> that have arrived at BFR1 or BFR4 via a shortest path in the routing underlay
>                                       ^
Use "the" before the superlative.

Section 5.1.10. , paragraph 9, nit:
>  but instead that they will allow to express desirable path steering alternat
>                                   ^^^^^^^^^^
Did you mean "expressing"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 5.2.1. , paragraph 10, nit:
> rlay applications to operate independently from the controller whenever it n
>                              ^^^^^^^^^^^^^^^^^^
The usual collocation for "independently" is "of", not "from". Did you mean
"independently of"?

Document references draft-ietf-bier-multicast-http-response-05, but -06 is the
latest available revision.

Document references draft-ietf-bier-non-mpls-bift-encoding-03, but -04 is the
latest available revision.

Document references draft-ietf-bier-te-yang-02, but -03 is the latest available
revision.

Document references draft-ietf-teas-rfc3272bis-11, but -12 is the latest
available revision.

These URLs in the document can probably be converted to HTTPS:
 * http://www.github.com/toerless/bier-te-arch