I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is Ready with (minor) issues

My apologies for the late review on this draft. Overall I found this document to be well-written, and concise.

General Comments:

This document uses a mix of case around RFC2119 language (e.g., MAY may). You should use text from RFC8174 to indicate that lowercase versions of the keywords are not normative, or adjust the case of the lowercase words to ensure there is no confusion.

Minor nit: There is some inconsistency in the use of "MSD-Type" (the value) and "MSD type" (the concept). Suggest cleaning this up.

Specific comments:

Section 1:

Para 1: s/to insure/to ensure/

Section 4:

The last paragraph establishes a requirement on the registration of an MSD Type to define what the absence of a given MSD Type means. This is an important requirement that must be addressed during registration of new MSD Types. IMHO, this requirement should be echoed in the registration information in section 6 to make sure it is not overlooked.

Section 6:

The "Base MPLS Imposition MSD" should reference section 5 of this document.

The registration for "Experimental" should be marked as "Reserved for Experimental Use" or just "Experimental Use" to align with RFC8126. RFC8126 states that "it is not appropriate for documents to select explicit values from registries or ranges with this policy". It might be good to add a note alongside the one on "Designated Experts" indicating that values from this range are not assignable.

The "Interior Gateway Protocol (IGP) Parameters" registry has the "Standards Action" policy assigned. The new "IGP MSD Types" sub-registry does not have the "Standards Action" policy. Was this intentional? If so, this should be explained. This is also confusing since the guidance for expert reviewers in RFC7370 implies that registrations are based on the "RFC Required" or "Standards Action" policies.

Section 7:

The security considerations in RFC7981 ask that security considerations around the disclosure and modification of this type of information is described in extensions. This has been done, but RFC7981 also asks that an integrity mechanism be provided if there is a high risk resulting from modification of capability information. There is no discussion in the document's security consideration about the nature of risk in this case and why an integrity mechanism is not needed. It seems like false information can be used to cause a denial of service regarding computed paths. This sounds like having this happen could be bad. I am not an expert on routing protocols, so I am not sure if this is an issue. How bad and likely is such a risk?