A YANG Data Model for OSPF Segment Routing over the MPLS Data Plane
draft-ietf-ospf-sr-yang-50

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-ospf-sr-yang and RFC 9903, changed IESG state to RFC Published)

[Ballot comment]
Hi Acee, all,

Thank you for the discussion and for addressing my comments [1].

I trust that the few pending comments [2] will be addressed in a revised version.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/lsr/hxpYinFTcGMHnGeISMXrwwiXXvQ/

[2] https://mailarchive.ietf.org/arch/msg/lsr/xdPhI2dcMIHvWQbIo-7fgdtyJkg/

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-ospf-sr-yang-37
CC @evyncke

Thank you for the work put into this document as it represents nearly 10 years of effort :-O

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Christian Hopps for the shepherd's concise write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### SR over/for MPLS ?

I think that the right term is "segment routing *over* the MPLS data plane".

### Title

s/A YANG Data Model for OSPF Segment Routing for the MPLS Data Plane/A YANG Data Model for OSPF *Extensions for* Segment Routing *over* the MPLS Data Plane/

### Abstract

Suggest to be consistent with the title, i.e., s/YANG data module/YANG data model/

### Section 2

I do not understand the acronym in `Segment Routing (SRGB)` why not "SR" only ?

s/The ietf-ospf-sr-mpls *data* module/The ietf-ospf-sr-mpls *YANG* module *defined in this document*/ There is no such thing as a "data module" IMHO.

### Section 3

Please add "MPLS" in the section title.

[Ballot comment]
Section 1, paragraph 0
>    This document defines a YANG data model [RFC7950] that can be used to
>    manage OSPFv2 extensions for Segment Routing [RFC8665] and OSPFv3
>    extensions for Segment Routing [RFC8666] for the MPLS data plane.  It
>    is an augmentation to the OSPF YANG data model [RFC9129].

This is a similar comment to the YANG module for SR on ISIS. There seems to be some confusion on the use of the terms "YANG module" and "YANG data model" in this document. A "YANG data model" refers to a collection of YANG modules and submodules that together define a structured representation configuration, operational data, notifications, and RPCs for a given system or protocol, while a "YANG module" refers to a specific YANG file (.yang) defining a set of nodes (container, list, leaf, etc.) that represent configuration or state data. Moreover, a YANG module can be independent and augment other modules.

Based on that definition, what you seem to be defining is a YANG module more than a YANG data model. Can that be reflected consistently in this document?

Section 3, paragraph 9
>        This version of this YANG module is part of RFC XXXX; see
>        the RFC itself for full legal notices.

BTW, is there an instruction for the RFC Editor on what to do with RFC XXXX?

Section 3, paragraph 28
>      grouping sid-tlv-encoding {
>        description
>          "SID TLV Encoding -  20-bit label or 32-bit SID whose
>          interpretation is dependent on the TLV length (3 for an
>          MPLS label or 4 for a 32-bit value)  or the TLV V-Flag and
>          L-Flag settings:
>
>            If the  V-Flag is set to 0 and L-Flag is set to 0:
>            The SID/Index/Label field is a 4-octet index defining
>            the offset in the SID/Label space advertised by this
>            router.
>
>            If V-Flag is set to 1 and L-Flag is set to 1: The
>            ID/Index/Label field is a 3-octet local label where the
>            20 rightmost bits are used for encoding the label value.";
>        reference
>          "RFC 8665: OSPF Extensions for Segment Routing, Section 5
>          RFC 8666: OSPFv3 Extensions for Segment Routing, Section 3";
>        leaf sid-raw {
>          type uint32;
>          description
>            "Raw SID value - labels are in the rightmost 20 bits of
>            the value";
>        }
>        choice sid-value {
>          case label-sid {
>            leaf label-value {
>              type uint32 {
>                  range "0 .. 1048575";
>              }
>              description
>                "A 20-bit MPLS Label";
>            }
>          }
>          case offset-sid {
>            leaf offset-value {
>              type uint32;
>              description
>                "Offset into a label space advertised by this router.";
>            }
>          }
>          description
>            "Choice of either a 20-bit MPLS lable or 32-bit offset into
>            an advertised label space.";
>        }
>      }


I might be completely off, but what is the relationship between 'sid-raw' and the choice statement of 'sid-value'? Is the choice statement being used to determine what value 'sid-raw' will carry? If that is the case, YANG is being used to model a particular wire format. Tell me that is not what is happening here.
I will note that Med has pointed out something similar as part of his DISCUSS in other parts of the model.

Section 4, paragraph 9
>    Some of the readable data nodes in this YANG module may be considered
>    sensitive or vulnerable in some network environments.  It is thus
>    important to control read access (e.g., via get, get-config, or
>    notification) to these data nodes.  Specifically, the following
>    subtrees and data nodes have particular sensitivities/
>    vulnerabilities:

The paragraph seems to imply that specific subtrees and data nodes will be identified for vulnerability. Instead, what I see is a paragraph with some generic description. Did the authors forget to identify particular nodes or subtrees?

No reference entries found for these items, which were mentioned in the text:
[draft-ietf-rtgwg-segment-routing-ti-lfa].

-------------------------------------------------------------------------------
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 3, paragraph 10
>      reference
>        "RFC XXXX";

s/RFC XXXX/RFC XXXX: A YANG Data Model for OSPF Segment Routing for the MPLS Data Plane/

[Ballot discuss]
A couple of points for discussion:

I see the following in the Appendix B:

1833     augment /rt:routing/rt:control-plane-protocols
1834             /rt:control-plane-protocol/ospf:ospf:
1835     +--rw segment-routing
1836     |  +--rw enabled?    boolean
1837     |  +--rw bindings {mapping-server}?
1838     |    +--rw advertise
1839     |    |  +--rw policies*  leafref
1840     |    +--rw receive?    boolean
1841     +--rw protocol-srgb {sr-mpls:protocol-srgb}?
1842         +--rw srgb* [lower-bound upper-bound]
1843           +--rw lower-bound    uint32
1844           +--rw upper-bound    uint32

But I am not able to find these augmentations in the model itself. Am I
missing something? YANG is not my forte. I am unable to find this across
modules and wanted to cross-check.

Also, I am not able to find the RW (config) options for enabling (with a bool)
SR-MPLS for a specific OSPF area, or interface in the model. Have I missed
this as well? If it is not covered, was this discussed during the development
of this model in the WG?

I see that the model defines grouping for ospfv3-adj-sid-sub-tlvs
but not for OSPFv2 for the same thing (it is modeled directly as a container).
I would like to understand why so?

[Ballot comment]
Please find below some comments that are in the idnits output of v37:


91 2.  OSPF Segment Routing YANG Data Module Scope

93   This document defines a model for OSPF Segment Routing Extensions for
94   both OSPFv2 [RFC8665] and OSPFv3 [RFC8666].

... for the MPLS data plane.

96   The OSPF SR YANG module requires support for the base segment routing
97   module [RFC9020], which defines the global segment routing
98   configuration independent of any specific routing protocol
99   configuration, and support of OSPF base model [RFC9129] which defines
100   basic OSPF configuration and state.

102   The ietf-ospf-sr-mpls data module defines both the data nodes to
103   configure OSPF segment routing MPLS extensions and the additions to
104   the OSPF Link State Advertisements (LSAs) necessary to support MPLS
105   segment routing.  The OSPF configuration includes:

s/MPLS segment routing/SR-MPLS


156   *  OSPFv3 Adj-SID Sub-TLV in the OSPFv3 Router-Link TLV [RFC8362].

158   *  OSPFv3 Adj-SID Sub-TLV in the OSPFv3 Router-Link TLV [RFC8362].

160   *  OSPFv3 Lan Adj-SID Sub-TLV in the OSPFv3 Router-Link TLV
161       [RFC8362].

s/Lan/LAN

Please add [RFC8666] reference as well above for (LAN) Adj-SID
encodings


418     /* Groupings */
419     grouping sid-tlv-encoding {
420       description
421         "SID TLV Encoding -  20-bit label or 32-bit SID whose

s/SID/SID index

422         interpretation is dependent on the TLV length (3 for an
423         MPLS label or 4 for a 32-bit value)  or the TLV V-Flag and
424         L-Flag settings:

426           If the  V-Flag is set to 0 and L-Flag is set to 0:
427           The SID/Index/Label field is a 4-octet index defining
428           the offset in the SID/Label space advertised by this
429           router.

431           If V-Flag is set to 1 and L-Flag is set to 1: The
432           ID/Index/Label field is a 3-octet local label where the
433           20 rightmost bits are used for encoding the label value.";
434       reference
435         "RFC 8665: OSPF Extensions for Segment Routing, Section 5
436           RFC 8666: OSPFv3 Extensions for Segment Routing, Section 3";
437       leaf sid-raw {
438         type uint32;
439         description
440           "Raw SID value - labels are in the rightmost 20 bits of
441           the value";
442       }
443       choice sid-value {
444         case label-sid {
445           leaf label-value {
446             type uint32 {
447                 range "0 .. 1048575";
448             }
449             description
450               "A 20-bit MPLS Label";
451           }
452         }
453         case offset-sid {
454           leaf offset-value {

I am not familiar of this "offset" term. What is used more often is
"index" since the value is an index into the (SRGB) label space advertised.
It is not an "offset" since SRGB may comprise of multiple non-contiguous
blocks - they need to be arrange in the order of advertisement to form a
single block and then this index is used to pick the label value. To me,
offset sounds more like something done in memory location that assume it to be
contiguous.
Suggest ...
s/label-sid/sid-label
s/offset-sid/sid-index ... s/offset-value/index-value

455             type uint32;
456             description
457               "Offset into a label space advertised by this router.";
458           }
459         }
460         description
461           "Choice of either a 20-bit MPLS lable or 32-bit offset into
462             an advertised label space.";
463       }
464     }


466     grouping sid-sub-tlv {
467       description
468         "SID/Label sub-TLV grouping.";
469       reference
470         "RFC 8665: OSPF Extensions for Segment Routing
471           (Section 6)";

KT> Reference should be section 2.1 of RFC8665?

472       container sid-sub-tlv {
473         description
474           "Used to advertise the SID/Label associated with a
475             prefix or adjacency.";
476         leaf length {
477           type uint16;
478           description
479             "Length of the SID value. YANG model specification
480               is necessary since it dictates the semantics of the
481               SID.";
482         }
483         uses sid-tlv-encoding;
484       }
485     }


602     grouping sid-range-tlvs {
603       description
604         "SID Range TLV grouping.";
605       reference
606         "RFC 8665: OSPF Extensions for Segment Routing
607           (Section 3.2)";
608       container sid-range-tlvs {
609         description
610           "List of SID range TLVs. Note that the order of advertised
611             SID ranges is implementation dependent.";

Please update "Note that the order of advertised SID ranges is
implementation dependent." - the ordering is pretty important and MUST be as
per what has been received in the LSA on the wire. This is the SRGB.

612         list sid-range-tlv {
613           description
614             "SID range TLV.";
615           leaf range-size {
616             type rt-types:uint24;
617             description
618               "SID range.";
619           }
620           uses sid-sub-tlv;
621         }
622       }
623     }

625     grouping local-block-tlvs {
626       description
627         "The SR local block TLV contains the
628           range of labels reserved for local SIDs.";
629       reference
630         "RFC 8665: OSPF Extensions for Segment Routing
631           (Section 3.3)";
632       container local-block-tlvs {
633         description
634           "List of SRLB TLVs.";

Here too the ordering has to be as on the wire for SRLB - if similar
text is clarified above for SRGB.

635         list local-block-tlv {
636           description
637             "SRLB TLV.";
638           leaf range-size {
639             type rt-types:uint24;
640             description
641               "SID range. The return of a zero value would indicate
642                 an error.";
643           }
644           uses sid-sub-tlv;
645         }
646       }
647     }


1561   Author affiliation with The MITRE Corporation is provided for
1562   identification purposes only, and is not intended to convey or imply
1563   MITRE's concurrence with, or support for, the positions, opinions or
1564   viewpoints expressed.  MITRE has approved this document for Public
1565   Release, Distribution Unlimited, with Public Release Case Number
1566   18-3281.

With the text above (which applies MITRE has some sort of an approval
authority over this document), it seems more appropriate for this author to drop
their MITRE Corporation affiliation.

[Ballot comment]
Thank you to Gyan Mishra for the GENART review.

** Section 5.
  MITRE has approved this document for Public
  Release, Distribution Unlimited, with Public Release Case Number
  18-3281.

While I appreciate the need to acknowledge those that fund an author’s time, and that some employers have strict release review requirements, is the above text necessary or can it be removed?  It implies that the named entity has authority to approve the publication of the RFC once the content is in an I-D (which it does not).

[Ballot comment]

Thank you to Corey Bonnell for his secdir review.

I do agree that the lack of narrative text makes this difficult to review.

Section 3:  If the template is changed (see M. Boucadair's review), then  (or Paul) will re-review this section.

Section 3, para 1:  If TLS is used, is mutual authentication mandated?  If not, why not?

[Ballot discuss]
Hi Yingzhen, Acee, Jeffrey, and Helen,

Thank you for the effort put into this specification, especially for your perseverance to progress the spec for almost ten years. I hope we could produce device YANG modules quicker.

The augmentations are overall adhering to the base specifications defined in RFC8665/RFC8666. There are minor issues (but many, though) that can be easily fixed. I found it unfortunate that we are mixing message format vs. what can be managed (e.g., data nodes are mirroring TLVs, etc.).

I will be definitely balloting “Yes” for this specification, but I’d like to DISCUSS some few points.

# Lack of narrative text

I would expect a minimum of narrative text to explain the set of management function supported by the model. For example, I can’t tell whether we can store the algo capabilities of adj SR routers, etc.

Please remember that RFC8407 says the following:

3.5.  Narrative Sections

  The narrative part MUST include an overview section that describes
  the scope and field of application of the module(s) defined by the
  specification and that specifies the relationship (if any) of these
  modules to other standards, particularly to standards containing
  other YANG modules.  The narrative part SHOULD include one or more
  sections to briefly describe the structure of the modules defined in
  the specification.

# Implicit SID types

CURRENT:
      container sid-sub-tlv {
        description
          "Used to advertise the SID/Label associated with a
            prefix or adjacency.";
        leaf length {
          type uint16;
          description
            "Length of the SID value. YANG model specification
              is necessary since it dictates the semantics of the
              SID.";
        }
        leaf sid {
          type uint32;
          description
            "Segment Identifier (SID) - A 20 bit label or
              32 bit SID. If the length is set to 3, then the
              20 rightmost bits represent a label.  If the length
              is set to 4, then the value represents a 32-bit SID.";

It is unfortunate to mix the wire encoding vs manageability function. Why a type is not used here instead of implicitly inferring it form a length?

BTW, should that type (or length in the current version) be mandatory? especially that the description says "is necessary"?

# Ordering control of SID/Label

How to control the order of SID/Label to follow this part from RFC8665?

  *  The originating router decides the order in which the set of SID/
      Label Range TLVs are advertised inside the Router Information
      Opaque LSA.

# Overlapping prefixes

RFC8665 states that:
  The originating router MUST NOT advertise overlapping ranges.

How the model enforces this check on SID/Label Range?

# SR capabilities

It seems that this is defined only for OSPFv3 in the module, but rfc8665#section-3 says the following:

  These SR capabilities are advertised in the Router Information Opaque
  LSA (defined in [RFC7770]).  The TLVs defined below are applicable to
  both OSPFv2 and OSPFv3; see also [RFC8666].

Maybe I’m missing something.

[Ballot comment]
# Abstract: “configure” is covered by “manage” (remember the FCAPS functions)

OLD:
  This document defines a YANG data module that can be used to
  configure and manage OSPF Extensions for Segment Routing for the MPLS
  data plane.

NEW :
  This document defines a YANG data module that can be used to
  manage OSPF Extensions for Segment Routing (SR) for the MPLS
  data plane.

# Introduction: Simplify + remove “configure” as this is covered by “manage”

OLD:
  This document defines a YANG data model [RFC7950] that can be used to
  configure and manage OSPFv2 extensions for Segment Routing [RFC8665]
  and OSPFv3 extensions for Segment Routing [RFC8666] for the MPLS data
  plane.  It is an augmentation to the OSPF YANG data model [RFC9129].

NEW:
  This document defines a YANG data model [RFC7950] that can be used to
  manage Segment Routing (SR) for OSPFv2 [RFC8665]
  and OSPFv3 [RFC8666] for the MPLS data
  plane.  It is an augmentation to the OSPF YANG data model [RFC9129].

# Section 2

## (redundant) I would delete the following as this was stated few lines above.

CURRENT:
  It is an augmentation of the OSPF base model.

## The module is not only for configuration, but for state retrieval. The document says that it adheres to the NMDA ;-)

Please update the following accordingly:

CURRENT:
  The OSPF SR YANG module requires support for the base segment routing
  module [RFC9020], which defines the global segment routing
  configuration independent of any specific routing protocol
  configuration, and support of OSPF base model [RFC9129] which defines
  basic OSPF configuration and state.

## Long tree diagram

Please move the full tree to an appendix but consider snippets to help readers go through the model.

Refer to Section 3.4 of 8407bis for more guidance.

# Section 2.1: Check references

CURRENT:
  [RFC2328], [RFC4750], [RFC4915], [RFC5340], [RFC5643], [RFC5838],
  [RFC6991], [RFC8102], [RFC8294], [RFC8343], [RFC8476], [RFC8349],
  [RFC9587], and [I-D.ietf-rtgwg-segment-routing-ti-lfa] are referenced
  in the YANG data model.

For example, I failed to find where these ones are cited [RFC4750],  [RFC5643], [RFC5838], [RFC8343 ], [RFC8476].

# Section 2.2

## Please use the template at https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-22#name-template-for-ietf-modules

## Description issues

CURRENT:
        This YANG module defines the generic configuration
        and operational state for OSPF Segment Routing (SR), which
        is common across all of the vendor implementations. It is
        intended that the module will be extended by vendors to
        define vendor-specific OSPF Segment Routing configuration
        and operational parameters for the MPLS data plane.

* How you checked this part “is common across all of the vendor implementations”?

* I would remove the last sentence. It is weird to make assumption about what proprietary extensions in a STD spec!

## Consistent referencing style: The module include a mix of styles for the reference statements. Please update accordingly. For example,

OLD: "RFC 6991 - Common YANG Data Types";
NEW: "RFC 6991: Common YANG Data Types";

## Lack of references:

For example, consider adding the following for all prefix-sid-flag

NEW:
    reference
      "RFC 8665: OSPF Extensions for Segment Routing, Section 5
        RFC 8666: OSPFv3 Extensions for Segment Routing, Section 6";

## Some description are copied from the base spec, while the statement does not make sense for a given type.

For example, the following is included for an identity, but 'if set, ..' does not make sense for an identity. This is not a flag bit. An example is provided below (but other similar constructs are included in the module)

OLD:
      "Inter-Area flag. If set, advertisement is of
        inter-area type.";
NEW:
      "Inter-Area flag.";

## Lack of mapping between some identities and the flag names as defined in the base spec. For example, the description for vi-flag should indicate that this corresponds to the V-Flag as there is no VI-Flag in 8665/8666:

OLD:
      "Value/Index flag.";

NEW:
      "Value/Index flag. Corresponds to the Adj-SID V-Flag.";
    reference
      "RFC 8665: OSPF Extensions for Segment Routing, Section 6.1
        RFC 8666: OSPFv3 Extensions for Segment Routing, Section 7.1";

Idem, please indicate that lo-flag corresponds to the L-Flag defined in 8665/8666 as there is no LO-Flag in 8665/8666.

OLD:
      "Local/Global flag.";

NEW:
      "Local/Global flag. Corresponds to the Adj-SID L-Flag.";
    reference
      "RFC 8665: OSPF Extensions for Segment Routing, Section 6.1
        RFC 8666: OSPFv3 Extensions for Segment Routing, Section 7.1";

## No need to repeat the parent node prefix. There are many occurrences of this in the module.

OLD: list prefix-sid-sub-tlv {
NEW: list prefix-sid {

OLD: list extended-prefix-range-tlv {
NEW: list extended-prefix-range {

OLD: container extended-prefix-range-flags {
NEW: container flags {

Etc.

## Use Singular for list/leaf-list per rfc8407bis, for example:

OLD: leaf-list flags {
NEW: leaf-list flag {

There are many occurrences in the text.

## Defaults: Please provide an authoritative reference where the default is defined + indicate the meaning of this default.

For example, it is not clear for the definition the meaning of this value:

CURRENT:
          leaf priority {
            type uint8;
            default "128";

## Restrict using range: restrict the range rather than having this in the description.

CURRENT:
        leaf mt-id {
          type uint8;
          description
            "Multi-topology ID. Topologies range from 0-127 and
              return of any other value would indicate an error.";

# Section 3: Security template

Please follow the template defined in https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-22#name-security-considerations-sect

# Section 5: Indicate whether this is maintained by IANA or not

OLD:
        name: ietf-ospf-sr-mpls
        namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-sr-mpls
        prefix: ospf-sr-mpls
        reference: RFC XXXX

NEW:
        name: ietf-ospf-sr-mpls
        namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-sr-mpls
        prefix: ospf-sr-mpls
        maintained by IANA? N
        reference: RFC XXXX

# Section 6: Issues with classifying references

RFC6241, RFC6242, RFC8040, RFC8343, RFC8446, and RFC8476 are cited as normative, while they shouldn’t. Please move those to be listed as Informative.

# Appendix

## Redundant examples

Do we really need to have the xml example given that the JSON encoding for the same example is provided?

## Broken JSON example

Please validate the example using yanglint, etc.

OLD:
  {
    "routing": {
      "router-id": "1.1.1.1",
      "control-plane-protocols": {
        "control-plane-protocol": {
          "type": "ospf:ospfv2",
          "name": "OSPFv2",
          "ospf": {
            "areas": {
              "area": {
                "area-id": "0.0.0.0",
                "interfaces": {
                  "interface": {
                    "name": "eth0",
                    "segment-routing": {
                      "adjacency-sid": {
                        "adj-sids": {
                          "value": 3888
                        }
                      }
                    }
                  }
                }
              }
            },
            "segment-routing": {
              "enabled": true
            },
            "protocol-srgb": {
              "srgb": {
                "lower-bound": 4000,
                "upper-bound": 5000
              }
            }
          }
        }
      }
    }
  }

NEW:
  {
    "ietf-routing:routing": {
      "router-id": "1.1.1.1",
      "control-plane-protocols": {
        "control-plane-protocol": {
          "type": "ietf-ospf:ospfv2",
          "name": "OSPFv2",
          "ietf-ospf:ospf": {
            "areas": {
              "area": {
                "area-id": "0.0.0.0",
                "interfaces": {
                  "interface": {
                    "name": "eth0",
                    "ietf-ospf-sr-mpls:segment-routing": {
                      "adjacency-sid": {
                        "adj-sids": {
                          "value": 3888
                        }
                      }
                    }
                  }
                }
              }
            },
            "ietf-ospf-sr-mpls:segment-routing": {
              "enabled": true
            },
            "ietf-ospf-sr-mpls:protocol-srgb": {
              "srgb": {
                "lower-bound": 4000,
                "upper-bound": 5000
              }
            }
          }
        }
      }
    }
  }

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-ospf-sr-yang-33. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a new namespace will be registered as follows:

ID: yang:ietf-ospf-sr-mpls
URI: urn:ietf:params:xml:ns:yang:ietf-ospf-sr-mpls
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a new YANG module will be registered as follows:

Name: ietf-ospf-sr-mpls
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-sr-mpls
Prefix: ospf-sr-mpls
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2025-01-30):

From: The IESG
To: IETF-Announce
CC: Christian Hopps , chopps@chopps.org, draft-ietf-ospf-sr-yang@ietf.org, gunter@vandevelde.cc, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A YANG Data Model for OSPF Segment Routing for the MPLS Data Plane) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'A YANG Data Model for OSPF Segment
Routing for the MPLS Data Plane'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-01-30. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a YANG data module that can be used to
  configure and manage OSPF Extensions for Segment Routing for the MPLS
  data plane.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

    1. Does the working group (WG) consensus represent the strong concurrence of
      a few individuals, with others being silent, or did it reach broad
      agreement?

Concurrence of a few experts

    2. Was there controversy about particular points, or were there decisions
      where the consensus was particularly rough?

No

    3. Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarize the areas of conflict in separate
      email messages to the responsible Area Director. (It should be in a
      separate email because this questionnaire is publicly available.)

No

    4. For protocol documents, are there existing implementations of the
      contents of the document? Have a significant number of potential
      implementers indicated plans to implement? Are any existing
      implementations reported somewhere, either in the document itself (as
      [RFC 7942][3] recommends) or elsewhere (where)?
N/A

    ## Additional Reviews

    5. Do the contents of this document closely interact with technologies in
      other IETF working groups or external organizations, and would it
      therefore benefit from their review? Have those reviews occurred? If yes,
      describe which reviews took place.

No

    6. Describe how the document meets any required formal expert review
      criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
      reviews.

YANG doctor review completed

    7. If the document contains a YANG module, has the final version of the
      module been checked with any of the [recommended validation tools][4] for
      syntax and formatting validation? If there are any resulting errors or
      warnings, what is the justification for not fixing them at this time?
      Does the YANG module comply with the Network Management Datastore
      Architecture (NMDA) as specified in [RFC 8342][5]?

Checked, and NMDA yes

    8. Describe reviews and automated checks performed to validate sections of
      the final version of the document written in a formal language, such as
      XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

    ## Document Shepherd Checks

    9. Based on the shepherd's review of the document, is it their opinion that
      this document is needed, clearly written, complete, correctly designed,
      and ready to be handed off to the responsible Area Director?

Yes.

    10. Several IETF Areas have assembled [lists of common issues that their
        reviewers encounter][6]. For which areas have such issues been
        identified and addressed? For which does this still need to happen in
        subsequent reviews?

No.

    11. What type of RFC publication is being requested on the IETF stream
        ([Best Current Practice][12], [Proposed Standard, Internet
        Standard][13], [Informational, Experimental or Historic][14])? Why is
        this the proper type of RFC? Do all Datatracker state attributes
        correctly reflect this intent?

Proposed Standard, appropriate as defines standardized yang module.

    12. Have reasonable efforts been made to remind all authors of the
        intellectual property rights (IPR) disclosure obligations described in
        [BCP 79][7]? To the best of your knowledge, have all required
        disclosures been filed? If not, explain why. If yes, summarize any
        relevant discussion, including links to publicly-available messages when
        applicable.

Yes.

    13. Has each author, editor, and contributor shown their willingness to be
        listed as such? If the total number of authors and editors on the front
        page is greater than five, please provide a justification.

Yes.

    14. Document any remaining I-D nits in this document. Simply running the
        [idnits tool][8] is not enough; please review the ["Content Guidelines"
        on authors.ietf.org][15]. (Also note that the current idnits tool
        generates some incorrect warnings; a rewrite is underway.)

None.

    15. Should any informative references be normative or vice-versa? See the
        [IESG Statement on Normative and Informative References][16].

No.

    16. List any normative references that are not freely available to anyone.
        Did the community have sufficient access to review any such normative
        references?

None.

    17. Are there any normative downward references (see [RFC 3967][9] and [BCP
        97][10]) that are not already listed in the [DOWNREF registry][17]? If
        so, list them.

No.

    18. Are there normative references to documents that are not ready to be
        submitted to the IESG for publication or are otherwise in an unclear
        state? If so, what is the plan for their completion?

No, one ref is submitted to IESG but not yet RFC.

    19. Will publication of this document change the status of any existing
        RFCs? If so, does the Datatracker metadata correctly reflect this and
        are those RFCs listed on the title page, in the abstract, and discussed
        in the introduction? If not, explain why and point to the part of the
        document where the relationship of this document to these other RFCs is
        discussed.

No

    20. Describe the document shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of the
        document. Confirm that all aspects of the document requiring IANA
        assignments are associated with the appropriate reservations in IANA
        registries. Confirm that any referenced IANA registries have been
        clearly identified. Confirm that each newly created IANA registry
        specifies its initial contents, allocations procedures, and a reasonable
        name (see [RFC 8126][11]).

Standard YANG update looks good.

    21. List any new IANA registries that require Designated Expert Review for
        future allocations. Are the instructions to the Designated Expert clear?
        Please include suggestions of designated experts, if appropriate.

None

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

    1. Does the working group (WG) consensus represent the strong concurrence of
      a few individuals, with others being silent, or did it reach broad
      agreement?

Concurrence of a few experts

    2. Was there controversy about particular points, or were there decisions
      where the consensus was particularly rough?

No

    3. Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarize the areas of conflict in separate
      email messages to the responsible Area Director. (It should be in a
      separate email because this questionnaire is publicly available.)

No

    4. For protocol documents, are there existing implementations of the
      contents of the document? Have a significant number of potential
      implementers indicated plans to implement? Are any existing
      implementations reported somewhere, either in the document itself (as
      [RFC 7942][3] recommends) or elsewhere (where)?
N/A

    ## Additional Reviews

    5. Do the contents of this document closely interact with technologies in
      other IETF working groups or external organizations, and would it
      therefore benefit from their review? Have those reviews occurred? If yes,
      describe which reviews took place.

No

    6. Describe how the document meets any required formal expert review
      criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
      reviews.

YANG doctor review completed

    7. If the document contains a YANG module, has the final version of the
      module been checked with any of the [recommended validation tools][4] for
      syntax and formatting validation? If there are any resulting errors or
      warnings, what is the justification for not fixing them at this time?
      Does the YANG module comply with the Network Management Datastore
      Architecture (NMDA) as specified in [RFC 8342][5]?

Checked, and NMDA yes

    8. Describe reviews and automated checks performed to validate sections of
      the final version of the document written in a formal language, such as
      XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

    ## Document Shepherd Checks

    9. Based on the shepherd's review of the document, is it their opinion that
      this document is needed, clearly written, complete, correctly designed,
      and ready to be handed off to the responsible Area Director?

Yes.

    10. Several IETF Areas have assembled [lists of common issues that their
        reviewers encounter][6]. For which areas have such issues been
        identified and addressed? For which does this still need to happen in
        subsequent reviews?

No.

    11. What type of RFC publication is being requested on the IETF stream
        ([Best Current Practice][12], [Proposed Standard, Internet
        Standard][13], [Informational, Experimental or Historic][14])? Why is
        this the proper type of RFC? Do all Datatracker state attributes
        correctly reflect this intent?

Proposed Standard, appropriate as defines standardized yang module.

    12. Have reasonable efforts been made to remind all authors of the
        intellectual property rights (IPR) disclosure obligations described in
        [BCP 79][7]? To the best of your knowledge, have all required
        disclosures been filed? If not, explain why. If yes, summarize any
        relevant discussion, including links to publicly-available messages when
        applicable.

Yes.

    13. Has each author, editor, and contributor shown their willingness to be
        listed as such? If the total number of authors and editors on the front
        page is greater than five, please provide a justification.

Yes.

    14. Document any remaining I-D nits in this document. Simply running the
        [idnits tool][8] is not enough; please review the ["Content Guidelines"
        on authors.ietf.org][15]. (Also note that the current idnits tool
        generates some incorrect warnings; a rewrite is underway.)

None.

    15. Should any informative references be normative or vice-versa? See the
        [IESG Statement on Normative and Informative References][16].

No.

    16. List any normative references that are not freely available to anyone.
        Did the community have sufficient access to review any such normative
        references?

None.

    17. Are there any normative downward references (see [RFC 3967][9] and [BCP
        97][10]) that are not already listed in the [DOWNREF registry][17]? If
        so, list them.

No.

    18. Are there normative references to documents that are not ready to be
        submitted to the IESG for publication or are otherwise in an unclear
        state? If so, what is the plan for their completion?

No, one ref is submitted to IESG but not yet RFC.

    19. Will publication of this document change the status of any existing
        RFCs? If so, does the Datatracker metadata correctly reflect this and
        are those RFCs listed on the title page, in the abstract, and discussed
        in the introduction? If not, explain why and point to the part of the
        document where the relationship of this document to these other RFCs is
        discussed.

No

    20. Describe the document shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of the
        document. Confirm that all aspects of the document requiring IANA
        assignments are associated with the appropriate reservations in IANA
        registries. Confirm that any referenced IANA registries have been
        clearly identified. Confirm that each newly created IANA registry
        specifies its initial contents, allocations procedures, and a reasonable
        name (see [RFC 8126][11]).

Standard YANG update looks good.

    21. List any new IANA registries that require Designated Expert Review for
        future allocations. Are the instructions to the Designated Expert clear?
        Please include suggestions of designated experts, if appropriate.

None