## COMMENTS (non-blocking)

### Med's DISCUSS

I support Med's DISCUSS points about the IANA-frozen type in the I-D.

### Abstract

s/This document describes a YANG data model /This document *specifies* a YANG data model / as it is a PS.

### Section 1

s/This document introduces a YANG data model/This document *specifies* a YANG data model/

### Section 3.1

Typo in `Opaque specifc Key` and s/ipv4/IPv4/, please run a spell-checker ;-)

### Section 9.2

s/::0/::/ to be consistent with the canonical way to write IPv6 addresses.

### Section 11

Please add an informational reference to the actual URI of the registries, e.g., https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns

Section 12.1, normative reference to RFC 8407:

2860 >    [RFC8407]  Bierman, A., "Guidelines for Authors and Reviewers of
2861 >               Documents Containing YANG Data Models", BCP 216, RFC 8407,
2862 >               DOI 10.17487/RFC8407, October 2018,
2863 >               <https://www.rfc-editor.org/info/rfc8407>.

RFC 8407 has been obsoleted by RFC 9907. In my view, the normative reference
should be updated to RFC 9907. Several RFC 9907 requirements (noted below in
subsequent comments and in the YANG Doctors review by Joe Clarke, thanks Joe) are not
fully satisfied in the current revision.

---

Section 9.1, module description statement:

1159 >      description
1160 >        "This YANG module defines the essential components for the
1161 >         management of Multiprotocol Label Switching (MPLS) Multipoint
1162 >         LDP (mLDP).
...

Section 9.2, module description statement:

1782 >      description
1783 >        "This YANG module defines the extended components for the
1784 >         management of Multiprotocol Label Switching (MPLS) Multipoint
1785 >         LDP (mLDP).

Per RFC 9907 Section 4.8, each module description must include text directing
readers to the IANA YANG Parameters registry (i.e., a statement along the
lines of "The YANG module in this document conforms to the NMDA as described
in RFC 8342. This module is available from the IANA YANG Parameters registry").
Neither module description includes this required registry pointer. I would
suggest adding the standard registry reference text to the description
statement of both modules.

---

Section 9.1, grouping mldp-binding-label-state-attributes (and the equivalent
grouping mldp-ext-binding-label-peer-state in Section 9.2):

1457 >          leaf peer {
1458 >            type leafref {
1459 >              path
1460 >                "../../../../../../../../../../../ldp:peers/ldp:peer/"
1461 >              + "ldp:lsr-id";

Both groupings use deeply nested relative XPath expressions. Per RFC 9907
Section 4.1, a grouping that uses relative XPath paths must document in its
description the precise schema tree context in which it is intended to be
instantiated, so that the XPath evaluation is unambiguous. Neither grouping
currently includes that context description. I would suggest adding a brief
statement to each grouping description specifying its intended instantiation
point.

---

Section 11, IANA Considerations — YANG module registration:

2737 >    +============+===================================+======+===========+
2738 >    | Name       | Namespace                         |Prefix| Reference |
...

Per RFC 9907 Section 3.8.3.1, the YANG Module Names registration template must
include a "Maintained by IANA?" field (value "N" for modules that are not
IANA-maintained). Neither registration entry in Table 3 includes this field.
I would suggest adding the missing field to both entries.

---

Section 3 and the narrative text throughout: I agree with the OPSDIR reviewer
(Ran Chen, 2026-05-06) that the document would benefit from an Operational
Considerations section. draft-ietf-opsawg-rfc5706bis recommends including
such a section before Security Considerations for documents introducing new
protocol state. mLDP introduces observable protocol state (roots, bindings,
capabilities) and new configuration knobs (MBB timers, address-family enables,
prefix-list policies) that are clearly manageable. While rfc5706bis is not yet
enforceable, I would suggest the authors consider adding at least a brief
Operational Considerations section addressing deployment, fault visibility, and
key configuration considerations.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit. Some were
flagged by automated tools (via
https://github.com/larseggert/ietf-reviewtool), so there will likely
be some false positives. There is no need to let me know what you did
with these suggestions.

Section 9.1, revision 2026-02-03, description:

1188 >          description
1189 >            "Fixing copytight and authors before publication";

s/copytight/copyright/

The same typo appears at the corresponding revision in Section 9.2:

1812 >          description
1813 >            "Fixing copytight and authors before publication";

s/copytight/copyright/

---

Section 9.1, operational state augmentation, container p2mp description:

1499 >          container p2mp {
1500 >            description
1501 >              "Operatiobal state information for the point-to-multipoint
1502 >               capability of a peer";

s/Operatiobal/Operational/

The same misspelling appears in Section 9.2:

2184 >          container hub-and-spoke {
2185 >            description
2186 >              "Operatiobal state information for the peer's
2187 >               hub-and-spoke-multipoint capability.";

2198 >          container node-protection {
2199 >            description
2200 >              "Operatiobal state information for the peer's node-protection
2201 >              capability";

s/Operatiobal/Operational/ (both instances)

---

Section 9.1, grouping mldp-binding-label-state-attributes, list peer description:

1453 >            description
1454 >              "List of peers with bindings exchnaged (sent and/or
1455 >               received)";

s/exchnaged/exchanged/

The same typo appears in Section 9.2:

1933 >          description
1934 >            "List of peers with bindings exchnaged (sent and/or
1935 >             received)";

s/exchnaged/exchanged/

---

Section 3.1, Table 1 header:

306 >       | Opaque Type | Variant     | Opaque specifc Key | RFCs      |

s/specifc/specific/

---

Section 3.1, Table 1:

296 >       *  Transit Birdir

s/Birdir/Bidir/

---

Section 6.2.1:

1017 >    instead, the node treats it as a opaque binary stream

s/a opaque/an opaque/

# Title

OLD: YANG Data Model for MPLS mLDP

NEW: A YANG Data Model for MPLS mLDP

# Reverted NMDA Guidance in RCC9907

CURRENT:
 Abstract 
  …
   The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA).

  …

   The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA) defined in [RFC8342].

RFC9907 does require a mention/justification only when there are NMDA deviations. Please delete that sentence (and other similar text in the draft).

# Maybe add an pointer to where these are provided

CURRENT:
   Moreover, it is important to note here that any assumptions made in
   the LDP YANG data model also hold true in this document, unless
   otherwise explicitly stated.

# Confusing Features

CURRENT:
   The examples of base mLDP features include the enablement of mLDP and
   its capabilities, and static configuration of leaf IPv4 LSPs with
   generic LSP Id, whereas the examples of extended mLDP feature include
   enhanced mLDP capabilities, Recursive FEC [RFC6512], 

I would avoid «features» as this may be confused with YANG «feature» statement. 

This comment applies here and other places in the document.

# Simple not Small?

CURRENT:
   While "base" model support will suffice for small deployments, it is
   expected that large deployments will require both the "base" and
   "extended" model support from the vendors.

I don’t think this is about the size of a deployment but the richness of enabled functions. 

# I would delete as this does not add much

CURRENT:
   There are four types of containers in the module(s):

   *  Read-write parameters for configuration (Section 5)

   *  Read-only parameters for operational state (Section 6)

   *  Notifications for events (Section 7)

# NMDA

CURRENT:
   In mLDP YANG modules, the operational state data is combined with the
   associated configuration data in the same hierarchy [RFC8407].  When
   protocol states are retrieved from the NMDA operational state
   datastore, the returned states cover all "config true" (rw) and
   "config false" (ro) nodes defined in the schema.

## I don’t think we need tp repat what NMDA is

## 8407 was obsoleted by 9907

## The same comment applies for the following

   The mLDP modules conform to the NMDA where the operational state data
   is combined with the associated configuration data in the same
   hierarchy.  This means that When protocol states are retrieved from
   the NMDA operational state datastore, the returned states cover all
   "config true" (rw) and "config false" (ro) nodes defined in the
   schema.

I suggest to delete.

# Tree Diagrams

CURRENT:
   The following diagram depicts high-level mLDP YANG tree organization
   and hierarchy with respect to LDP:

Please add

NEW: The meaning of the symbols in these tree diagrams are defined in [RFC8340].

#  Abstract Tree Structure

CURRENT:
            +-- rw routing
              +-- rw control-plane-protocols
               +-- rw control-plane-protocol
                 +-- rw mpls-ldp
                     +-- rw some_ldp_container
                     |   +-- rw mldp
                     |       +-- rw ...                 // mldp base
                     |       |   +-- rw ...
                     |       |   +-- ro ...
                     |       |   +--
                     |       +-- rw mldp-ext:...        // mldp extended
                     |       |   +-- rw ...
                     |       |   +-- ro ...
                     |       |   +--
                     +-- ro someother_ldp_container
                         +-- ro mldp
                             +-- ro ...                 // mldp base
                             |   +-- ro ...
                             |   +--
                             +-- ro mldp-ext:...        // mldp extended
                                 +-- ro ...
                                 +--

## This is confusing as it some data nodes can be misinterpreted as they are part of the structure. I would use an abstract tree that reflect the modules.

# Which RFC specification?

CURRENT/
   *  This model aims to address the core mLDP constructs, parameters,
      and features as per RFC specification, 

# Vendor

CURRENT:
      Any vendor-specific feature should be defined in a vendor-
      specific augmentation of this model.

I don’t think we need to have this in a PS doc

# On Model/Module/Etc. 

CURRENT:
   *  This mLDP model builds on top of LDP YANG model [RFC9070] which is

## YANG model is to be avoided. 

## Please follow the guidance in Section 2.5 of RFC 9907

# Full tree

Please move to an appendix per the following guidance in RFC9907:

“Tree diagrams longer than one page SHOULD be included in an appendix, i.e., not in the main body of the document.”

# I would delete the following

CURRENT:
8.  Actions

   This document does not define any RPCs/actions for mLDP.

# Please update your modules to follow the template at: https://www.rfc-editor.org/rfc/rfc9907.html#name-template-for-ietf-modules 

# Revisions (for both modules)

CURRENT:
     revision 2026-02-03 {
       // RFC Editor: replace the above date with the date of
       // publication and remove this note.
       description
         "Fixing copytight and authors before publication";
       reference
         "RFC XXXX: YANG Data Model for MPLS mLDP";
        // RFC Editor: replace XXXX with actual RFC number and remove
        // this note
     }

     revision 2025-12-15 {
       // RFC Editor: replace the above date with the date of
       // publication and remove this note.
       description
         "Removed static-lsps-leaf from the model";
       reference
         "RFC XXXX: YANG Data Model for MPLS mLDP";
        // RFC Editor: replace XXXX with actual RFC number and remove
        // this note
     }

     revision 2025-10-20 {
       // RFC Editor: replace the above date with the date of
       // publication and remove this note.
       description
         "Addressing RtgDir review comments related to recursive FEC";
       reference
         "RFC XXXX: YANG Data Model for MPLS mLDP";
        // RFC Editor: replace XXXX with actual RFC number and remove
        // this note
     }
…

Please delete all these except the latest one. We don’t use this as change log. Please refer to RFC9907

# Avoid embedding references in a description

CURRENT:
         "A grouping describing the protocol capabilities of mLDP as
          specified in RFC6388";

Please use a reference statement.

# Boolean (several occurrences)

OLD:
  "'true' to enable the point-to-multipoint capability";

NEW:
  "Enables the point-to-multipoint capability when set to 'true'.";

# root-address

CURRENT:
             leaf root-address {
               type inet:ip-address;
               description
                 "Root address.";
             }

You may explain why the type is not IPv4 as that is what you have in the base.

# Section 10.1

Please update to follow the template at https://www.rfc-editor.org/rfc/rfc9907.html#name-security-considerations-sect 

# These are not normative

Please move these to RFC6241, RFC6242, RFC8040, RFC8340, RFC8446.

Cheers,
Med