Template: 2/24/2012
Things for AD and shepherd to watch during WG LC
=============================================
1) authors add NMDA text and yang 1.1
2) authors change to align to yang high-level marking
draft-ietf-netmod-yang-tree-diagrams-06
3) making sure the Yang catalog gets unscrambled.
=================
(1)Type: Proposed Standard
Why? - It is a yang data model
(2) The IESG approval announcements:
Technical Summary
This document defines a YANG data model for Routing Information Base
(RIB) that aligns with the I2RS RIB information model.
This yang data model complies with the network management datastore
architecture. It can be loaded in configuration datastores or in dynamic
datastores.
Working Group Summary
I2RS has aided the transformation IETF network management
into the network management datastore architecture.
The journey has tested the IETF's ability to work cross area,
and across groups to support this data model.
The 3rd WG LC for the WG draft found the WG to be worn
out by this activity. The data model has not changed since the
early days, but WG group has change the world that it lives in.
If you are on the IESG, look at all the EMAILs regarding this draft.
You will not see anything in the last 3 years.
Benoit Claise and Alia Atlas wanted me to push to publish
this draft ahead of all of the NMDA work. As a nerd,
I wanted to make sure it aligned.
Benoit and Alia were right and I was wrong. If I had only
listened, we would not be closing I2RS because the
WG would not be as frustrated with the slow progress toward
the NMDA architecture.
Document Quality
Are there existing implementations of the protocol?
Some early implementations of this protocol existed as far back
as 3 years ago. I'm not sure how close they are to the
NMDA.
The thought and design in this RIB is better than
anything the IETF has come up within 15 years.
Personnel
Who is the Document Shepherd? Susan Hares
AD: Alia Atlas
RTG-DIR reviewers: John Scudder
SEC-DIR: Derrell Piper <ddp@electric-loft.org>
YANG-Doctors: Ebben Aries
(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.
Shepherd sent this draft to RTG-DIR early reviews, OPS-DIR
YANG Doctor's early reviews, and SEC-DIR reviews.
The RTG-DIR and OPS-DIR early reviews did not come back as
requested in January (1/4/2018). No amount of pushing
or begging and pleading seems to get more.
WG LC should shake some loose.
Authors have promised to be responsive.
The shepherd will keep updating the top of shepherd's review.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
This did not get the requested RTG-DIR, OPS-DIR, and Yang-Doctors reviews
in January. We can no longer wait - so these reviews should come during WG LC.
(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 doctors and RTG-DIR.
(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.
This document is the best example of a RIB I have observed.
It is capable of going to the dynamic datastore or configuration.
It aligns with the NMDA. Help it get out into the wild by
getting the appropriate reviews and NITs.
(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.
Lixing Wang
https://mailarchive.ietf.org/arch/msg/i2rs/ddXYGcITllYYPtXfSzCtu9Ft-OQ
Amit Dass
https://mailarchive.ietf.org/arch/msg/i2rs/hdngkBEhPO2mixlYuHfN3R4BxhU
Mach(Guoyi) Chen
https://mailarchive.ietf.org/arch/msg/i2rs/DCE6oh718znQLfTucfG3gcIh02M
H. Ananthakrishnan (Hari)
https://mailarchive.ietf.org/arch/msg/i2rs/OcRT7dcggU3c3mr_BGCmBkRuF0Q
Sriganesh Kini
https://mailarchive.ietf.org/arch/msg/i2rs/7x-r1VB4EWP-GXOCFbbW0cbZnMg
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
No
(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?
Solid enough to push the IETF concepts from its old config data model
to the NMDA model. Thanks Benoit and Alia for all the support!
(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.)
nope!
(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.
Line length (1 line)
outdated documents: (will be fixed during WG LC)
draft-ietf-netmod-yang-tree-diagrams-04draft-ietf-i2rs-rib-info-model-13
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
See Yang Doctors early review.
(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?
(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.
Nope - all normative are RFCs or in RFC editor's queue.
(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).
It aligns with yang model suggestions.
(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 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.