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

[Jen Linkova <[e-mail]>]

On Fri, Jun 12, 2026 at 5:46 AM Tony Li <[e-mail]> wrote:
> 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

;)
Thank you Tony for letting me know and for addressing my suggestions/comments.

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


-- 
Cheers, Jen Linkova