[mpls] Re: draft-ietf-mpls-mna-nrp-selector-04 telechat Intdir review

[Tony Li <[e-mail]>]

Hi,

An area director has requested that I reply to your email.

All issues have been addressed.

This message intentionally contains zero bits of new information.

Blindly following orders,
Tony


> On Apr 24, 2026, at 5:17 AM, Jen Linkova via Datatracker <[e-mail]> wrote:
> 
> Document: draft-ietf-mpls-mna-nrp-selector
> Title: MPLS Network Actions for Network Resource Partition Selector
> Reviewer: Jen Linkova
> Review result: Ready with Nits
> 
> Hello,
> 
> I have reviewed this document on behalf of the Internet Area Directorate.
> 
> While I have no major technical concerns, I have several editorial comments
> that I believe would improve the document's readability and help prevent
> potential misunderstandings during implementation. These comments specifically
> pertain to Sections 2.1 through 2.3.
> 
> As a reader approaching this for the first time, I found these sections
> somewhat difficult to process. The primary source of confusion is the
> structure: typically, when an ASCII diagram shows an option format, the list
> immediately following it describes the individual fields. Currently, the text
> in these sections mixes field-specific descriptions with more general
> architectural information.
> 
> I suggest separating these elements for clarity. For example, Section 2.1 could
> be restructured as follows:
> 
> The 13-bit NRP Selector (NRPS13) Action uses LSE format B and is encoded in the
> second label stack entry in the Network Action Sub-Stack. The format of the
> NRPS13 Action is shown below:
> 
> [ASCII diagram]
> 
> * Opcode: The Network Action Indicator (TBA).
> * NRPS: The NRP Selector; 13 bits of in-stack ancillary data. The packet
> carrying the NRPS13 action should be given the forwarding treatment specified
> by the associated NRP policy. * S (Scope): The NRPS20 Action is valid in all
> scopes. * NAL (Network Action Length): This field MUST be transmitted as zero.
> (Perhaps it should be made explicit what the receiver should do if a non-zero
> value is received?)
> 
> Also, I have a question about the ASCII diagram in Section 2.1:
> it shows NRPS twice: after the Optcode (13 bits) and after the S bit, where
> draft-ietf-mpls-mna-nrp-selector-04 shows NASL. Maybe it's worth explaining?
> 
> Additionally, I have a few other minor points:
> 
> * Post-Stack Data: Since these actions are not intended to have post-stack
> data, it might be helpful to include a dedicated section (similar to Section
> 2.4) explicitly stating that no post-stack data is associated with these
> formats.
> 
> * Normative Language: In Sections 2.1–2.3, the phrase "the packet... should be
> given" uses lowercase. Is this intentional, or should it use RFC 2119/8174
> normative language (e.g., SHOULD)?
> 
> Cross-references: It may be useful to include a reference to Section 2.4 when
> saying that "The packet carrying the ENRPS13/20 action should be given the
> forwarding treatment specified by the associated NRP policy" as, if I
> understand it correctly, the action still can be ignored if it's not the
> top-most?
> 
> Cheers, Jen Linkova
> 
>