A YANG Data Model for Alarm Management
draft-ietf-ccamp-alarm-module-09

[Ballot comment]
To me it appear that this document is a part in a system that lacks mechanisms for handling overload situations in a way that maintains goodput in the system. The system design appears to rest on that principle that there will allways be sufficient resources to process and handle the events and that misconfigurations or operator errors do not result in that the system exceeeds the considered load that it was deployed to handle. This alarm module is only a component that from my perspective do require some thought of how alarms that has interactions are reported and with which priority to minimize delay until they can be acted on. However, the general framework appears to lack the necessary hook for such thoughts to be meaningful. Therefore I abstain on this document.

[Ballot discuss]
§6:

>        If the type is given as an UUID or a string, it is interpreted
>        as a W3C regular expression, which matches a resource of type
>        'yang:uuid' or 'string' if the given regular expression
>        matches the resource string.

This needs a citation for what is meant by "W3C regular expression." I'm making
a wild guess that this refers to the regular expressions defined for use with
XSD? If so, the reference is presumably this document:
https://www.w3.org/TR/xmlschema11-2/

[Ballot comment]
— Section 3.2 —

A nit:
  For example, a system with digital inputs that allows users to
  connects detectors (e.g., smoke detector) to the inputs.

This is a sentence fragment ans also has a number error in “connects”.

NEW
An example is a system with digital inputs that allows users to connect detectors, such as smoke detectors, to the inputs.
END

[Ballot comment]
I support Roman's DISCUSS, especially #2.

Also, please see the OpsDir review here -- I believe that you have already discussed it with the reviewer (Thank you, Joe Clarke!), but wanted to make sure that you also catch the nits.

Like Joe, and others, I find the term "Alarm Shelving" to be confusing -  it may be a formal term of art, but I've working in / with many NOCs, and have never heard the term used; if anything the terminology I'm familiar with "Shut up stupid alarm! I'll suppress it for now....". Shelving evokes memories of https://pics.me.me/10-ill-just-put-this-over-here-with-the-rest-32772452.png
I would suggest introducing the term earlier, and more fully describing it as a courtesy to other readers.

"X.733 and especially 3GPP were not really clear on this point." - this sounds (unncessarily) rude - I would suggest perhaps "The X.733 and 3GPP Alarm IRP documents are not really clear ..."

Nits:
"For example, a system with digital inputs that allows users to connects detectors"
s/connects/connect/
I would also think that a better term is "sensors"

"A potential drawback of this is that there is a big risk that alarm operators will receive alarm types as a surprise, ..."
"big" reads oddly - I would suggest "significant" instead.

"Alarm deletion (using the action "purge-alarms"), can use this state as a criterion." - superfluous comma.

[Ballot discuss]
I think we may need to double-check that the example in Appendix C is
fully compliant with the main spec.  In particular, are the
elments properly sorted?  (I'm less sure whether the
time needs to match a  or whether the
is good enough for that.)

[Ballot comment]
Section 1.1

  o  Fault: A fault is the underlying cause of an undesired behaviour.
      There is no trivial one-to-one mapping between faults and alarms.
      One fault may result in several alarms in case the system lacks
      root-cause and correlation capabilities.  An alarm might not have
      an underlying fault as a cause, imagine a bad MOS score alarm from
      a VOIP probe and the cause being non-optimal QoS configuration.

nit: this is a comma splice

  o  Alarm Type: An alarm type identifies a possible unique alarm state
      for a resource.  Alarm types are names to identify the state like
      "link-alarm", "jitter-violation", "high-disk-utilization".

Are these only intended for human consumption?

  o  Cleared alarm: A cleared alarm is an alarm where the system/server
      considers the undesired state to be cleared.  Operators can not
      clear alarms, clearance is managed by the system.  A linkUp
      notification can be considered a clear condition for a linkDown
      state.

nit: I'd suggest "For example, " before "a linkUp notification [...]"

  o  Corrective Action: An action taken by an operator or automation
      routine in order to minimize the impact of the alarm or resolving
      the root cause.

nit: "or resolve the root cause"

Section 2

  o  Clear definition of "alarm" in order to exclude general events
      that should not be forwarded as alarm notifications.

I'm not sure I am parsing this correctly.  Is the objective to *provide*
such a clear definition?  (Similarly for the next item.)  Part of my
confusion probably stems from the dual use of the word "clear" as a verb
and a noun in English.

Section 3.2

  In order to allow for dynamic addition of alarm types the alarm
  module allows for further qualification of the identity based alarm
  type using a string.  A potential drawback of this is that there is a
  big risk that alarm operators will receive alarm types as a surprise,
  they do not know how to resolve the problem since a defined alarm
  procedure does not necessarily exist.  [...]

nit: this is a comma splice.

Section 3.5.1

  From a resource perspective, an alarm can for example have the
  following life-cycle: raise, change severity, change severity, clear,

Is the duplicate "change severity" intentional?

For the alarm history functionality, a given 'time' leaf is clearly the
time that a change occurred, but are the sibling leafs the state before
that change or after that change?  (It looks like the actual YANG module
descriptions (e.g., for 'status-change') indicate that this is the state
after that change, but I don't know if it makes sense to also mention
that here or not.)

Section 3.7

  (blocked/filtered).  Shelved alarms appear in a dedicated shelved
  alarm list in order not to disturb the relevant alarms.  Shelved

nit: this sentence could probably be reworded for greater clarity (what
does "disturb" mean, and perhaps what "relevant alarms" is may not be
clear just from context).

Section 4.1

  The "/alarms/control/notify-status-changes" leaf controls if
  notifications are sent for all state changes, only raise and clear,
  or only notifications more severe than a configured level.  This
  feature in combination with alarm shelving corresponds to the ITU
  Alarm Report Control functionality.

Is there a specific section reference for the ITU functionality?  (If
not, it's probably fine to leave this as-is).

Section 4.2

      The system might not instrument all defined alarm type identities,
      and some alarm identities are abstract.

I just wanted to double-check: the intent is indeed to use "instrument"
here (as opposed to, say, "implement")?

Section 4.7

  /alarms/alarm-list/purge-alarms:  Delete alarms from the "alarm-list"
      according to specific criteria, for example all cleared alarms
      older than a specific date.

  /alarms/alarm-list/compress-alarms:  Compress the "status-change"
      list for the alarms.

It's a bit confusing to me to have such different language for these two
action nodes, since as far as I can tell the compress-alarms action also
allows for specific criteria (e.g., resources) to be provided to limit
the scope of the action.  (Similarly for compress-shelved-alarms.)

Section 6

    feature service-impact-analysis {
      description
        "The system supports identifying candidate impacted
          resources for an alarm, for example a link being impacted
          by an interface alarm.";

nit: it feels a bit odd to say that the link is "impacted by an alarm",
since normally the causality flow would be the other way -- the link
state changes, and then an alarm stat changes.

I'm not sure I understand the distinction between 'warning' and 'minor'
severities -- it seems that neither is supposed to be indicating a
service-affecting fault.

For the 'age-spec' choice, am I reading RFC 7950 correctly that I choose
exactly one case of the choice, so I can't have both a "minute part"
and an "hours part"?  If so, then I would suggest using different
description text for the choices, since the current text implies that
you can combine parts with different units to assemble a compound
timespec.

        list alarm {
              [...]
              Entries appear in the alarm list the first time an alarm
              becomes active for a given alarm-type and resource.
              Entries do not get deleted when the alarm is cleared, this
              is a boolean state in the alarm.

nit: this is a comma splice.

Section 10

It's a bit of a stretch as far as an attack, but an attacker that can
temporarily reduce max-alarm-status-changes to a small value (e.g., one)
could use that to hide their tracks to some extent if they can cause the
alarm to clear after they've done what they intended to do.  (They could
then restore the max-alarm-status-changes value, too.)

It seems that the list of alarms itself may be potentially sensitive, in
that it potentially gives an attacker an authoritative picture of the
(broken) state of the network.

Appendix F.1

nit: We say that X.733 alarms "also use the basic criteria of deviation from
normal condition", but it's not entirely clear whether the "also"
indicates that they share this behavior with some external reference
point or is a synonym for "additionally".

nit: I think the semicolon in the ISA "comment" should be a regular
colon.

The paragraph at the end talks about "evolution" and "moves from" -- is
the table sorted chronologically?

Appendix G

Are tables 4 and 5 talking about alarm rates or notification rates?

[Ballot comment]
Thank you addressing the Gen-ART review.

This sentence in Section 4 does not parse properly: The rest of the data model are made conditional with YANG the features "operator-actions", "alarm-shelving", "alarm-history", "alarm-summary", "alarm-profile", and "severity-assignment".

In 4.1: s/corresponds to the ITU Alarm Report Control functionality/corresponds to the ITU X.733 Alarm Report Control functionality

[Ballot comment]
Easy to read and well-thought except for "shelving" alarms, it took me a while to understand that it was like "stashing" ;-)

Section 3.4, may I assume that the document fixes the problem "X.733 and especially 3GPP were not really clear on this point." ?

Perhaps did I miss the part where the alarm system could also fails: what alarm? status? does it generate? Or is it out of scope?

*minor NITS*
Section 1 s/north-bound/northbound/ ?

[Ballot discuss]
(1) Section 3.5, Alarm Life-Cycle.  The text states that “A server SHOULD describe how long it retains cleared/closed alarms: until manually purged or if it has an automatic removal policy.”
How is this retention policy described?  Is that in scope for this document?

(2) Section 4.2, Alarm Inventory.  The text states that “A server MUST implement the alarm inventory in order to enable controlled alarm procedures in the client.”
What is the expected server behavior if a client sends an alarm type not in the inventory (and it isn’t part of the dynamic addition process)?

(2) Section 10, Security Considerations.  It seems like “/alarms/alarm-list/alarm/set-operator-state” should be listed as an operation in the YANG model that presents a security issues (just like “purge-alarms”).  Consider if one altered the operator alert state causing the alarm management procedures to miss an alert (e.g., setting an alert to “closed” before any action is taken).

(3) Section 10, Security Considerations.  I don’t know must about the implementations, but wouldn’t compressing alerts (per compress-alarms and compress-shelved-alarms operations) remove them from consideration by alarm management procedures?  If so, these would be a sensitive operation that would need to be listed as the concern equivalent to the current text for purge-alarms.

[Ballot comment]
(1) Section 1.1, Terminology, “Fault”.  Consider expanding the acronym “MOS” (Mean Option Score?)

(2) Section 2, Objectives, Consider s/X.733/[X.733]/

(3) Section 3.2, Alarm Type, Consider s/identity based/identity-based/

(4) Section 3.2, Alarm Type, Typo, s/standard organization/standards organization/

(5) Section 3.4, Identifying Alarm Instances, Consider s/were not really clear/were not clear/

(6) Section 3.5.2, Operator Alarm Life-cycle, Consider s/can also act upon/act upon/

(7) Section 3.5.2, Operator Alarm Life-cycle, Consider s/A closed alarm is an alarm/For example, a closed alarm is an alarm/

(8) Section 3.6, Root Cause, Impacted Resources and Related Alarms, Consider s/Different systems have various various/Different systems have varying/

(9) Section 3.6, Root Cause, Impacted Resources and Related Alarms, Consider s/In some occasions/On some occasions/

(10) Section 3.6, Root Cause, Impacted Resources and Related Alarms, Consider s/needs to represent an alarm that indicates a situation that needs acting upon/raises an alarm to indicate a situation requiring attention/

(11) Section 4.1.1, Alarm Shelving, The text states “The instrumentation MUST move shelved alarms from the alarm list (/alarms/alarm-list) to the shelved alarm list (/alarms/shelved-alarms/).”  It wasn’t clear when these shelved alarms must be moved given the text.

(12) Section 4.4, The Alarm List, The sentence, “The alarm list (/alarms/alarm-list) is a function from (resource, alarm type, alarm type qualifier) to the current composite alarm state” is missing a word/phrase.  Removing the parenthetical remarks it reads a “The alarm list is a function from to the current composite alarm state” is does not parse.

(13) Consider s/Life-cycle/Lifecycle/g

[Ballot comment]
Minor editorial comment:
Appendix F.2.4.:
"G.7710 is different than the previous referenced alarm standards.  It
  does define a data-model for alarm reporting. "
Is this correct or is there a "not" missing?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ccamp-alarm-module-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator 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:

two, new namespaces will be registered as follows:

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

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

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate 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/

two, new YANG modules will be registered as follows:

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

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

IANA Question --> Is the module name a typo? For instance, should it be ietf-alarms-x733 instead?

While the YANG module names 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.

The IANA Functions Operator understands 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.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-03-20):

From: The IESG
To: IETF-Announce
CC: Daniele Ceccarelli , ccamp-chairs@ietf.org, db3546@att.com, ccamp@ietf.org, draft-ietf-ccamp-alarm-module@ietf.org, daniele.ceccarelli@ericsson.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (YANG Alarm Module) to Proposed Standard


The IESG has received a request from the Common Control and Measurement Plane
WG (ccamp) to consider the following document: - 'YANG Alarm Module'
  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
ietf@ietf.org mailing lists by 2019-03-20. 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 module for alarm management.  It
  includes functions for alarm list management, alarm shelving and
  notifications to inform management systems.  There are also
  operations to manage the operator state of an alarm and
  administrative alarm procedures.  The module carefully maps to
  relevant alarm standards.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/ballot/


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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

>Proposed standard. This is indicated in the title page header and approprited for the type of RFC.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document defines a YANG module for alarm management.  It
  includes functions for alarm list management, alarm shelving and
  notifications to inform management systems.  There are also
  operations to manage the operator state of an alarm and
  administrative alarm procedures.  The module carefully maps to
  relevant alarm standards.

Working Group Summary

The draft was first presented in Netmod working group as defining a genering alarm model, but then moved to CCAMP as the working group has the right competence to correctly progress this work. This was a successfull move as the draft was rapidly progressed with a very good support and also attracting new participants to the working group.

Document Quality

The draft has been discussed many times on the mailing list and been subject of many liaisons between the IETF and other SDOs. It is also supported by various telco vendors. The draft has already been reviewed by the YANG doctors with very positive feedbacks.
 
Personnel

Who is the Document Shepherd? Daniele Ceccarelli
Who is the Responsible Area Director? Deborah Brunghard.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The draft is ready for publication. THis is the Shepherd opinion as well as the YANG doctors' one.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

YANG doctor review already carried out.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG as a whole understands and agrees with the document. The draft also brought new participants to the wg which are not interested in usual CCAMP work but particularly interested on the topic.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Minor issues with references and spacing that can be solved during the next steps of reviews.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document passed the YANG doctor review.

(13) Have all references within this document been identified as
either normative or informative?

Yes. Two normative references need to be updated.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

None.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) 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 protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document registers two URIs in the IETF XML registry and  two YANG modules in the YANG Module Names registry. THis is properly identified in the IANA section.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

>Proposed standard. This is indicated in the title page header and approprited for the type of RFC.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document defines a YANG module for alarm management.  It
  includes functions for alarm list management, alarm shelving and
  notifications to inform management systems.  There are also
  operations to manage the operator state of an alarm and
  administrative alarm procedures.  The module carefully maps to
  relevant alarm standards.

Working Group Summary

The draft was first presented in Netmod working group as defining a genering alarm model, but then moved to CCAMP as the working group has the right competence to correctly progress this work. This was a successfull move as the draft was rapidly progressed with a very good support and also attracting new participants to the working group.

Document Quality

The draft has been discussed many times on the mailing list and been subject of many liaisons between the IETF and other SDOs. It is also supported by various telco vendors. The draft has already been reviewed by the YANG doctors with very positive feedbacks.
 
Personnel

Who is the Document Shepherd? Daniele Ceccarelli
Who is the Responsible Area Director? Deborah Brunghard.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The draft is ready for publication. THis is the Shepherd opinion as well as the YANG doctors' one.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

YANG doctor review already carried out.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG as a whole understands and agrees with the document. The draft also brought new participants to the wg which are not interested in usual CCAMP work but particularly interested on the topic.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Minor issues with references and spacing that can be solved during the next steps of reviews.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document passed the YANG doctor review.

(13) Have all references within this document been identified as
either normative or informative?

Yes. Two normative references need to be updated.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

None.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) 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 protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document registers two URIs in the IETF XML registry and  two YANG modules in the YANG Module Names registry. THis is properly identified in the IANA section.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.