Interface to the Routing System (I2RS) Ephemeral State Requirements
draft-ietf-i2rs-ephemeral-state-23

[Ballot comment]

My previous DISCUSS, which was ...
  I read REQ3 and 4 multiple times. Isn't REQ 3 a subset of REQ4?

    Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints
      that refer to operational state, this includes potentially fast
      changing or short lived operational state nodes,


  Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non-
  ephemeral state as a constraint.  Non-ephemeral state can be
  configuration state or operational state.

I should be missing something. Examples would help me.
... as been solved with Sue's email:

“This change difference was suggested by
Juergen and Andy as two separate cases rather than the original one.
  Juergen and Andy have been concerned about the speed of testing
constraints that are in the operational state if the operational state
yang variables are fast changing and short-lived.    They believe this
requirement might not be doable in implementations.  They wanted this
split out from Ephemeral-REQ-04 that simply states that ephemeral state
MUST be able to refer to non-ephemeral state (configuration or
operational state).  Since we do not
know if the I2RS can handle the fast changing and short-lived ephemeral
state, I think this split is a good one.”


- Just one comment from Lionel's OPS DIR feedback left, that might need some clarifications.

  Ephemeral-REQ-11: The following requirements must be supported by the
  I2RS protocol I2RS Protocol (e.g.  NETCONF/RESTCONF + yang) in order
  to support I2RS client identity and priority:

  o  the data nodes MAY store I2RS client identity and not the
      effective priority at the time the data node is stored.

[LM] This requirement seems to be in contradiction with the one given in
section 2 i.e. "I2RS agent MUST record the client identity when a node is
created or modified.". If I'm correct, the "MAY" applies only to the
"effective priority" and not to the I2RS Id storage.

[Sue]: I do not understand your point.  The "MAY" Deals with the fact the
implementation may attach a priority to the I2RS client and choose to only
store the link to the I2RS client.  What is the concern here?

[Ballot discuss]
- 
I read the abstract and title: clearly this is about ephemeral state.

                  I2RS Ephemeral State Requirements
                draft-ietf-i2rs-ephemeral-state-19.txt

Abstract

  The I2RS (interface to the routing system) Architecture document
  (RFC7921) abstractly describes a number of requirements for ephemeral
  state (in terms of capabilities and behaviors) which any protocol
  suite attempting to meet the needs of I2RS has to provide.  This
  document describes, in detail, requirements for ephemeral state for
  those implementing the I2RS protocol.

And in section 2, I see requirements "distilled" (btw, I agree with Alvaro's DISCUSS) from RFC7921 about the I2RS protocol, I2RS agent, I2RS client.
Why (re-hashing) requirements not related to ephemeral?
What the goal of this section 2?
It seems more like adding confusing that being helpful. Too many requirements from different documents in I2RS: "distilling" them between documents is looking for troubles.
note: section 9 title "
Pub/Sub Requirements Expanded for Ephemeral State" and content area clear




- I read REQ3 and 4 multiple times. Isn't REQ 3 a subset of REQ4?

    Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints
      that refer to operational state, this includes potentially fast
      changing or short lived operational state nodes,


  Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non-
  ephemeral state as a constraint.  Non-ephemeral state can be
  configuration state or operational state.

I should be missing something. Examples would help me.

[Ballot discuss]
-
  The I2RS Working Group has chosen to use the YANG data modeling
  language [RFC6020] as the basis to implement its mechanisms.

I guess you mean RFC 7950.
RFC7950 should be a normative reference.


- 
I read the abstract and title: clearly this is about ephemeral state.

                  I2RS Ephemeral State Requirements
                draft-ietf-i2rs-ephemeral-state-19.txt

Abstract

  The I2RS (interface to the routing system) Architecture document
  (RFC7921) abstractly describes a number of requirements for ephemeral
  state (in terms of capabilities and behaviors) which any protocol
  suite attempting to meet the needs of I2RS has to provide.  This
  document describes, in detail, requirements for ephemeral state for
  those implementing the I2RS protocol.

And in section 2, I see requirements "distilled" (btw, I agree with Alvaro's DISCUSS) from RFC7921 about the I2RS protocol, I2RS agent, I2RS client.
Why (re-hashing) requirements not related to ephemeral?
What the goal of this section 2?
It seems more like adding confusing that being helpful. Too many requirements from different documents in I2RS: "distilling" them between documents is looking for troubles.
note: section 9 title "
Pub/Sub Requirements Expanded for Ephemeral State" and content area clear




- I read REQ3 and 4 multiple times. Isn't REQ 3 a subset of REQ4?

    Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints
      that refer to operational state, this includes potentially fast
      changing or short lived operational state nodes,


  Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non-
  ephemeral state as a constraint.  Non-ephemeral state can be
  configuration state or operational state.

I should be missing something. Examples would help me.

- Clarification:
Ephemeral-REQ-12: When a collision occurs as two clients are trying
  to write the same data node

I2RS clients with the I2RS protocol, or NETCONF/RESTCONF clients?
Note: multiple instances of "clients" (as opposed to I2RS clients) in the doc.

[Ballot comment]
Editorial:
- Section 5 versus 6
For NETCONF:
  2.  The ephemeral state MUST support notification of write conflicts
      using the priority requirements defined in section 7 below (see
      requirements Ephemeral-REQ-11 through Ephemeral-REQ-14).
For RESTCONF:
  2.  The ephemeral state must support notification of write conflicts
      using the priority requirements defined in section 7 below (see
      requirements Ephemeral-REQ-11 through Ephemeral-REQ-14).

must versus MUST. If there are some language subtleties here, I didn't grasp them.

- "To support Multi-Headed Control,"
Multi-Headed Control? I guess I know what you mean, but expressed like this (capitalized), I'm looking for a well-known, well-defined term.
Later on, I see "Multi-headed control"

- s/yang/YANG

-
  Ephemeral-REQ-11: The following requirements must be supported by the
  I2RS protocol I2RS Protocol

remove one "I2RS protocol" instance

-
  Ephemeral-REQ-11: The following requirements must be supported by the
  I2RS protocol I2RS Protocol (e.g.  NETCONF/RESTCONF + yang) in order
  to support I2RS client identity and priority:

I would remove: "(e.g.  NETCONF/RESTCONF + yang)"


- "MUST BE" = MUST Belgium :-)

Pretty good feedback from Lionel Morand's OPS DIR review:

1. Introduction

  The I2RS Working Group has chosen to use the YANG data modeling
  language [RFC6020] as the basis to implement its mechanisms.

  Additionally, the I2RS Working group has chosen to re-use two
  existing protocols, NETCONF [RFC6241] and its similar but lighter-
  weight relative RESTCONF [I-D.ietf-netconf-restconf], as the
  protocols for carrying I2RS.

  What does re-use of a protocol mean?  Re-use means that while YANG,
  NETCONF and RESTCONF are a good starting basis for the I2RS protocol,
  the creation of the I2RS protocol implementations requires that the
  I2RS requirements

  1.  select features from YANG, NETCONF, and RESTCONF per version of
      the I2RS protocol (See sections 4, 5, and 6)

  2.  propose additions to YANG, NETCONF, and RESTCONF per version of
      the I2RS protocol for key functions (ephemeral state, protocol
      security, publication/subscription service, traceability),

  The purpose of these requirements is to ensure clarity during I2RS
  protocol creation.

[LM] The aim of the document is not so clear. The working assumption is : re-use but with "addition".
What does addition mean? Who is in charge to check that the proposed "additions" can be supported by YANG/NETCONF/RESTCONF without protocol updates? Where is the need to first derive specific requirements from RFC7921 and then check if they can be fulfilled by the model and the protocols, instead of doing both in the same document?

2.  Review of Requirements from I2RS architecture document

  The I2RS architecture defines important high-level requirements for
  the I2RS protocol.  The following are requirements distilled from
  [RFC7921] that provide context for the ephemeral data state
  requirements given in sections 3-8:

[LM] What is the meaning of "distilled" here? Are these requirements explicitly part of the RFC7921 or the requirements listed in this draft may be "relative" or even complementary requirements compared to the RFC7921?

  1.  The I2RS protocol SHOULD support a high bandwidth, asynchronous
      interface, with real-time guarantees on getting data from an I2RS
      agent by an I2RS client.

[LM] Is it a requirement related to the I2RS protocol or to the transport protocol?

  2.  I2RS agent MUST record the client identity when a node is created
      or modified.  The I2RS agent SHOULD to be able to read the client
      identity of a node and use the client identity's associated
      priority to resolve conflicts.  The secondary identity is useful
      for traceability and may also be recorded.

[LM] I think that the first sentence is not so related to the I2RS protocol but rather to the mechanism to provision the I2RS agent with this info (e.g. AAA).

  3.  An I2RS Client identity MUST have only one priority for the
      client's identifier.  A collision on writes is considered an
      error, but the priority associated with each client identifier is
      utilized to compare requests from two different clients in order
      to modify an existing node entry.  Only an entry from a client
      which is higher priority can modify an existing entry (First
      entry wins).  Priority only has meaning at the time of use

[LM] If I'm correct, "First entry wins" is for clients associated with the same priority, right? If it is, it is not only about 'higher' priority.

  4.  I2RS Client's secondary identity data is read-only meta-data that
      is recorded by the I2RS agent associated with a data model's node
      is written.  Just like the primary client identity, the secondary
      identity SHOULD only be recorded when the data node is written.

[LM] Not sure of the relevance of this requirement in the context of the I2RS protocol design if this info is opaque for the agent.

  5.  I2RS agent MAY have a lower priority I2RS client attempting to
      modify a higher priority client's entry in a data model.  The
      filtering out of lower priority clients attempting to write or
      modify a higher priority client's entry in a data model SHOULD be
      effectively handled and not put an undue strain on the I2RS
      agent.
 
[LM] This requirement seems to imply that the priority associated with the client ID is transitively associated with the client's entry in the I2RS agent. If it is, this requirement should be clarified along with Req 3 or just after.

3.1.  Persistence

  Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does
  not persist across reboots.  If state must be restored, it should be
  done solely by replay actions from the I2RS client via the I2RS
  agent.

[LM] this one is related to Req 8 and is about a "MUST" regarding the YANG model. As defined in RFC7950 (recently published), there are only two flavors of data managed with YANG: configuration data and state data, differentiated by the "config" statement with the argument the string "true" or "false". This requirement seems to imply a new "flavor" i.e. ephemeral state, which seems not compatible with the existing model that cannot be accommodated using a Boolean value. Does it mean that a new version of the YANG model would be required to fulfil this requirement?

[LM] Most of the other requirements are derived from and/or dependent on the req 1.

[LM] Other specific comments:

5.  NETCONF Features for Ephemeral State

  2.  The ephemeral state MUST support notification of write conflicts
      using the priority requirements defined in section 7 below (see
      requirements Ephemeral-REQ-11 through Ephemeral-REQ-14).

[LM] I wonder how this impacts the recommendation on the use of configuration lock mechanism when it is known that multiple instances may update the same configuration data as per RFC6241. Here, it seems that the priority is able to override the lock in place, which is not allowed in NETCONF.

  Ephemeral-REQ-11: The following requirements must be supported by the
  I2RS protocol I2RS Protocol (e.g.  NETCONF/RESTCONF + yang) in order
  to support I2RS client identity and priority:

  o  the data nodes MAY store I2RS client identity and not the
      effective priority at the time the data node is stored.

[LM] This requirement seems to be in contradiction with the one given in section 2 i.e. "I2RS agent MUST record the client identity when a node is created or modified.". If I'm correct, the "MAY" applies only to the "effective priority" and not to the I2RS Id storage.

  o  The priority MAY be dynamically changed by AAA, but the exact
      actions are part of the protocol definition as long as collisions
      are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13,
      and Ephemeral-REQ-14.

[LM] there are several references to the use of AAA-based solutions for priority handling. Does it require any action in RADEXT or Dime to support these requirements, at least as a default standard mechanism for I2RS?

[Ballot comment]
I am surprised to see MUST level requirements on YANG

"Ephemeral-REQ-06: YANG MUST have the ability to do the following:"

and further requirements on NETCONF (REQ-09) and RESTCONF (REQ-10) in this document.

Are there associated drafts in the respective WGs to make sure these requirements are met?

[Ballot comment]
Agree with Alvaro's Discuss. Not clear where Section 2 requirements are distilled from or if they are tied with supporting ephemeral state as RFC7921 did not require an active communication channel to be open at all times.

[Ballot discuss]
Section 2 (Review of Requirements from I2RS architecture document) presents a list of “requirements distilled from [RFC7921]”, which I initially assumed to mean that this list may have been a summary of the requirements in RFC7921.  However, I can’t find them in RFC7921; for example:

  1.  The I2RS protocol SHOULD support a high bandwidth, asynchronous
      interface, with real-time guarantees on getting data from an I2RS
      agent by an I2RS client.

…”high bandwidth” and “real-time” don’t even appear in RFC7921!  While I understand that distilling is not the same as copying, the use of rfc2119 language in this document makes me uncomfortable because it seems to be defining requirements that may or may not conflict with RFC7921.

If the requirements in Section 2 do come from RFC7921, please put the appropriate pointers in (and even better, use the same language to avoid confusion).  If by distilling the authors may have taken the liberty to interpret the requirements from RFC7921, please don’t use rfc2119 language.  If there are new or different requirements, please point them out.

[Ballot comment]
Two comments:

1) "I2RS requires ephemeral state; i.e. state that does
  not persist across reboots." -> why? Maybe add 1-2 sentences about the use (case) in the introduction.

2) Are all these requirements specific to ephemeral state? I would assume that some requirements are more general, e.g. don't you need priorities also for all other state updates?

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

The IANA Services Operator has reviewed draft-ietf-i2rs-ephemeral-state-19.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: i2rs@ietf.org, "Joe Clarke" , jclarke@cisco.com, i2rs-chairs@ietf.org, akatlas@gmail.com, draft-ietf-i2rs-ephemeral-state@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (I2RS Ephemeral State Requirements) to Informational RFC


The IESG has received a request from the Interface to the Routing System
WG (i2rs) to consider the following document:
- 'I2RS Ephemeral State Requirements'
  as Informational RFC

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 2016-10-19. 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


  The I2RS (interface to the routing system) Architecture document
  (RFC7921) abstractly describes a number of requirements for ephemeral
  state (in terms of capabilities and behaviors) which any protocol
  suite attempting to meet the needs of I2RS has to provide.  This
  document describes, in detail, requirements for ephemeral state for
  those implementing the I2RS protocol.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ballot/


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

Major:

1) Ephemeral-REQ-12:  This specifies that a notification be sent to the
original client, regardless of whether it won or lost the priority collision.
I had assumed that the notification would go to either the requesting client
or the original client depending on which one lost the priority comparison.
I have some concerns about an indirect flood of notifications caused by a
requesting client that has the lower priority.  Regardless, clarifying that
the lower-priority client is notified is important.



Minor:
a) Intro: Remove "3 suggest protocol strawman" as something that
  the I2RS requirements must do.  I know that is how the process
  has been working out - but it isn't dictated by the technology
  at all - as the other 2 are.  Similarly, replace the following
  paragraph "The purpose of these requirements and the suggested
  protocol strawman is to provide a quick turnaround on creating
  the I2RS protocol." with something like "The purpose of these
  requirements is to ensure clarity during I2RS protocol creation."

b) Section 2:  "The following are ten requirements that [RFC7921]
  contains which provide context for the ephemeral data state
  requirements given in sections 3-8:"
      How about "The following are requirements distilled from [RFC7921]
    that provide context for..."

    1)  Not relevant for ephemeral - this matters for pub/sub (suggest removal)
    2)  Relevant for ephemeral b/c of vague performance requirements on
        possible solutions.
    3)  What changes if the data model is protocol dependent?  Is this just that
        the model may be an augmentation/extension of an existing module?
    4)  Absolutely - keep
    5)  Absolutely - keep
    6)  Remove - not relevant for ephemeral just security requirements
    7)  Remove - not relevant for ephemeral just security requirements
    8)  Absolutely - keep (but says storing secondary identity on deletion when
        that isn't mentioned for (4) b/c it's about priority - so clarify slightly)
    9)  Absolutely - keep
  10)  Remove - not relevant for ephemeral

c) Sec 3.3 bullet 2:  This refers to YANG data model instead of YANG module as
  in bullet 1.  If there's a reason for the difference, please clarify and otherwise
  make consistent.

d) Sec 5 & 6 for NETCONF and RESTCONF are the same requirements.  Please
consolidate into a section of "The changes to NETCONF and the conceptual changes to RESTCONF are"

e) Sec 8:  I found this pull-out unclear.  "multiple operations in one
      or more messages; though errors in
      message or operation will have no effect on other messages or
      commands even they are related."

    I think you mean "Multiple operations in one message can be sent.  However
    an error in one operation MUST NOT stop additional operations from being
    carried out nor can it cause previous operations in the same message to
    be rolled back."

Nits:

i) Abstract: "attempting to meet I2RS needs has to provide"/
"attempting to meet the needs of I2RS has to provide"

ii) 3.2: "MPLS LSP-ID or BGP IN-RIB"  please expand acronyms

iii) Sec 5 last sentence:  Either missing a ( or has an unneeded ).

iv) Ephemeral-REQ-11:  "I2RS Protocol I2RS Protocol" repeated

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.  (version from 2/24/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?

Type of standard: Informational
Why:  Requirements from the I2RS WG to those wanting to create an I2RS higher-layer protocol (i.e., the netconf and netmod working groups)


(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 describes requirements for those implementing
  the I2RS higher-layer protocol (i.e., netconf and netmod IETF working
  groups) for functionality to support ephemeral state.

Working Group Summary

  Was there anything in WG process that is worth noting?

This draft has been debated over the past three years, and
at IETF 96 - netconf and i2rs WG straw-polls had no comments.
This was included in netmod's longer discussion on operational state.

The Working group process ran from August 2 to August 15, please see https://www.ietf.org/mail-archive/web/i2rs/current/msg03858.html

Conclusion of the WG LC is at:
https://www.ietf.org/mail-archive/web/i2rs/current/msg03984.html

Follow-up to WG LC is at:
https://www.ietf.org/mail-archive/web/i2rs/current/msg03989.html

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

  OpenDaylight, Juniper, and the IETF hackathon have created existing
  pre-standard work.  This draft documents the requirements around the ephemeral state concept that is core to the functionality of I2RS.  These requirements have been discussed at netmod, netconf, and i2rs working group meetings.

No other review is needed for requirements.

Personnel
  Document Shepherd:  Joe Clarke
  AD: Alia Atlas
Working Group Chairs: Sue Hares and Russ White
RTG-DIR QA Reviewer: Joel Halpern
https://mailarchive.ietf.org/arch/msg/i2rs/Jgv2VbvbUjZHUuAUMm2tiAqyKyc


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

1) I reviewed the document first for technical accuracy and provided comments.  Those comments were raised during in-person meetings and on the mailing list.  My final set of comments around technical accuracy were folded in to rev -18.

2) As a shepherd, I re-reviewed the draft for readability and consistency.  As a result of that review, I passed more comments to the authors.

At this point, and after reading the working group comments, I feel this document is ready for publication.

3) RTG-DIR QA Reviewer: Joel Halpern
https://mailarchive.ietf.org/arch/msg/i2rs/Jgv2VbvbUjZHUuAUMm2tiAqyKyc


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

None.  The document has gone through rigorous review not only in the i2rs WG but also in the netconf and netmod working groups.  It has underwent numerous revisions to address the comments that arose.  Additionally, this document has been presented and discussed at in-person meetings in i2rs, netconf and netmod working groups.  All comments have been addressed.

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

Normal reviews (OPS-DIR, SEC-DIR, RTG-DIR) should be sufficient.

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

I have no concerns.  I did have concerns as a WG participant, and I raised them in the proper forum (meetings and mailing lists).  They were addressed by the authors and through WG discussion.

(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, each author has replied.  Please see their individual replies with the links below.

Susan Hares:
https://mailarchive.ietf.org/arch/msg/i2rs/1haO5GEtj-NF4QZeHRDMF7LG7XQ

Jeff Haas:
https://mailarchive.ietf.org/arch/msg/i2rs/SaE73bR9QbUbchgyOj6GANJXItc

(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 disclosures.

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

Fairly solid with discussion being continuous for 2-3 years. 
Juergen Schoenwaelder comments have been continuous in opposition,
but he did not comment during WG LC.

(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 appeals.

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

Nits - nothing to mention.

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

standard reviews (SEC-DIR, RTG-DIR, OPS-DIR) should be sufficient
for these requirements.  Benoit Claise should be consulted to
determine if he feels Yang Doctors should be included.

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

Yes. 

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

Normative references are either RFCs or in the process of
becoming RFCs.

The two non-RFC normative references are:

I-D.ietf-i2rs-protocol-security-requirements : Currently going through IESG review

I-D.ietf-i2rs-security-environment-reqs :  WG LC (9/23 - 10/7)

(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 downward references.

(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.  New work.

(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).

No IANA considerations.

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

No IANA registries requested.

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

No additional checks for text.