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

[Toerless Eckert <[e-mail]>]

Thanks, Lars Vyncke

Detailed replies for your comments below inline.
It should resolve all your concerns.
These have been integrated into draft rev -12
which the authors feel is ready for RFC editor.

Full diff from -11 to -12:

http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-11.txt&url2=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-12.txt

Diff with just the deltas for comments by Eric Vyncke, Eric Kline, Martin Vigoroux and Lars Eggert

http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/toerless/bier-te-arch/c88c22d82f8e17e66929e2f0d82ca02680b8fe0e/draft-ietf-bier-te-arch.txt&url2=https://raw.githubusercontent.com/toerless/bier-te-arch/ca1c4ec15302e5287c0bd60b9f14d2c58428e50f/draft-ietf-bier-te-arch.txt

Thanks again for your review.

Toerless


On Tue, Aug 24, 2021 at 02:12:48AM -0700, Lars Eggert via Datatracker wrote:
> 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.

Of course. I only sent out replies now after having gone through
all comments as i think it creates a better reply from me.

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

Thanks for the URL. Interesting read. I wish i could add a reference
to it, but i think it would not fit:

The paragrah summarizes the discussion and conclusions we had in the
IETF (BIER and also ROLL) wrt. to bloom filters and related prior work
on the use with bloom filters in BIER-TE type of solutions. The work
you refer to was i think not known/mentioned by contributors to the discussion.

But added URL to changelog so i will find it again ;-)

(reading through it, it also looks as if the compression efficiency suffer quite a bit).

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

I don't think it is useful for authors to randomnly pick one out of multiple
words, none of which seems (right now) to be very logical in replacing
"native" in the context in which i use it ("native" vs "overlay"). We
(multicast technologists) have been using the word in that context for 30+ years
now, and the consistent use is quite important in searching for literature
etc. (searching for "native/overlay foobar"). So do seem to do various other
technologies described in RFCs (native IPv6, native applications etc. pp.):

I can see 3400 uses of "native" in RFCs including in the newest (9xxx)
RFCs, so it does not seem as if we have started a consistent approach to
replace it. If we do want to replace it, then there should be an IETF (or maybe
RFC-editor) decision to replace it with ideally just one word for this one common
use, so that in the future searching won't get too arbitrary.

Given the pain that IMHO changes here would IMHO cause for easily
understood technology classification, and no good clear agreed upon replacement word,
i would like to wait on this one, until native english speaker agree on a solution.

Also noted in changelog.

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

Fixed through other review already.

> 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

Fixed.

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

Fixed.

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

Done.

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

I thought consitutes of is a better form for enumerated building blocks. Added for now:
<t>[RFC-editor Q: "constitutes of" / "consists of" / "composed from..." ???]</t>

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

118 uses of "allows to" in RFC, last rfc9086. I'll keep it for now.

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

Changed. But i am primarily still looking for opinions in favor of keeping
this (second) example section in the text, or else it wil still go in RFC
(marked for deletion).

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

Fixed.

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

Fixed.

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

Fixed. Also found second location with same bug.

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

Fixed.

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

Interesting (did not know). Fixed.

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

You took the effort to find several of these instanes, and i appreciate that very much!

However, i will happily admit that i don't know english grammar by its rules,
but only through learning by doing (reading). And i thought to remember that i
had read all those form that i wrote. So i tried to google:

https://writingcenter.gmu.edu/guides/choosing-between-infinitive-and-gerund-to-do-or-doing

The cases of interest seem to be the ones for footnote 1:

| Infinitives and gerunds follow certain verbs and phrases, and there is no
| rule or reason why, for example, a verb attempt is followed by an infinitive
| (The paper attempts to address), but not a gerund (*The paper attempts
| addressing). This is simply a matter of memorization.
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I could not find a list of verbs and what form (infinite/gerund) is the right one for them though.

I added a note for RFC editor:
<t>[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. What exactly should be done about this ?].</t>

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

see above.

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

Actually, i removed "shortest". That was too much assumption. For example,
the underlay network could use SR or other forms of steering and that would
be fine too.

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

see above.

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

Fixed.

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

No worry. The document is written in RFC XML, so thos references will be
updated automatically with the next ref. Only when any of the draft turns
into an RFC does that need to be done manually.
> 
> These URLs in the document can probably be converted to HTTPS:
>  * http://www.github.com/toerless/bier-te-arch

Done. But github only has a redirector on port 80 anyhow.
>