IETF Last Call Review of draft-ietf-bier-oam-requirements-18
review-ietf-bier-oam-requirements-18-tsvart-lc-eddy-2025-10-06-00

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

This is a very short and simple document, simply listing requirements.

This may be "too late" in the process to mention as an issue, but these
requirements are missing any context as to "why" they are required.  Maybe
these motivations are obvious to the WG participants, but it's not clear in
reading the draft by itself whether there are specific operator needs, use
cases, or other concerns that are driving these requirements.  If the authors
have bandwidth, I would encourage them to provide a bit more context about how
these requirements were determined.  Or maybe there are other documents for
context that it would be useful to cite as references?

As an example, requirement 3 reads:
   3.   It SHOULD be possible to initialize a BIER OAM session from a
        centralized controller.
But there is no discussion about why this is a SHOULD rather than a MUST (e.g.
why is this important?  under what conditions would it be acceptable to not
support initializing BIER OAM from centralized controllers?).

A question: requirement 9 reads:
   9.   BIER OAM MUST support Path Maximum Transmission Unit discovery
        [RFC1191].
Is there any case of BIER transport where PLPMTUD (RFC 8899) would be relevant,
and more desirable as an option?