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

[Martin Duke via Datatracker <[e-mail]>]

Martin Duke 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:
----------------------------------------------------------------------

Thanks to Tommy Pauly for the TSVART review.

(2.1) s/p1...p14/p1...p15

(4.4) I had to read this section several times to understand the F-BM logic.
Here are some suggestions to clarify it:

s/F-BM is handled as follows/F-BM is generated as follows: "handled" is similar
"processed", which is not what I think you mean.

"All bits with an adjacency.. has only those bits set for which this BFR does
not have an adjacency." This sentence was very confusing for me until I grasped
that there were two different bitmaps here: the first reference to 'bits' is
the BitString, the second reference is the F-BM, which has no direct relation
to the BitString. More introductory text to specify the two bitmaps, and be
clear about which bitmap each reference to 'bit' refers to, would be helpful.

(5.1) What does "(4.1, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8)" mean?

(5.1.3) Another situation where Leaf BFER's can't fully collapse into one
codepoint is if there are two local_decap() interfaces. Or does this concept
not logically exist?