I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bess-mvpn-evpn-sr-p2mp-12
Reviewer: Paul Kyzivat
Review Date: 2025-06-01
IETF LC End Date: TBD
IESG Telechat date: TBD

Summary:

This draft is on the right track but has open issues, described in the 
review.

ISSUES: 1
NITS: 3

This document is very dense in terminology from its subject domain.
This reviewer is not at all familiar with the domain, so this review 
does not attempt to discuss the technical content of the document. 
Instead it focuses on form and language use. As a result, it is 
difficult to assign a summary statement. You should not take it to be of 
much significance.

I'll also observe that much of the text seems to be repeated instances 
of a common pattern: rules for originating and terminating different 
kinds of routes. While I don't understand any of the details, I have the 
sense that perhaps much of this could be specified in a table, with a 
row for each kind of route. If that were possible it could potentially 
simplify the document considerably.

1) ISSUE: Use of unqualified SHOULD

I counted six uses of SHOULD. All but one of these lack any discussion 
of the situations in which it is appropriate to disregard the SHOULD, 
and the implications of doing so. Failure to specify what happens in 
these cases can lead to problems with interoperation between 
implementations.

I suggest you either change these to MUST, or else give guidance on when 
it is appropriate to disregard the SHOULD.

2) NIT: Language Usage

Much of the text seems to have been written by a non-native English 
speaker. Of particular note, articles are missing in many/most places 
where they would typically expected. I also noticed some errors of 
pluralization. I will not attempt to enumerate them, because the list 
would be very long and error prone. I suggest you have a native-English 
subject expert do an edit focused on language usage.

3) NIT: IANA Considerations:

I checked the current state of the IANA registries that are mentioned in 
Section 8. Of the five items mentioned in Section 8, four have already 
been temporarily added to their specified table.

Section 8 requests that IANA add five of them. But for "SR-MPLS P2MP 
Tree" it instead states that the value has already been assigned, and 
doesn't ask for any further action by IANA.

In reality, IANA will need to add the one ("SRv6 P2MP Tree") that isn't 
already in the table, and update all of the entries to reference the new 
RFC number, and to specify the IETF as the change agent.

While IANA will probably do the right thing, I suggest that you be 
consistent, by also asking assignment of a code point for "SR-MPLS P2MP 
Tree"'.

4) NIT: Typo

I didn't actively search for typos, but I did notice one in section 
3.1.2:  s/MAY user/MAY use/