A YANG Data Model for Layer 3 Topologies
draft-ietf-i2rs-yang-l3-topology-16

Request for posting confirmation emailed to previous authors: Hariharan Ananthakrishnan , Xufeng Liu , Jan Medved , Alexander Clemm , i2rs-chairs@ietf.org, Nitin Bahadur , Robert Varga

Request for posting confirmation emailed to previous authors: Hariharan Ananthakrishnan , Xufeng Liu , Jan Medved , Alexander Clemm , i2rs-chairs@ietf.org, Nitin Bahadur , Robert Varga

[Ballot discuss]
We're making progress. Thanks.


>>
>> 4.
>>
>>        leaf-list router-id {
>>            type inet:ip-address;
>>            description
>>              "Router-id for the node";
>>          }
>>
>> My initial DISCUSS was: We don't want to wait for
>> https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, we
>> should expedite this publication), but any good reason why this is
>> aligned with its definition?
>>      typedef router-id {
>>        type yang:dotted-quad;
>>        description
>>          "A 32-bit number in the dotted quad format assigned to each
>>            router. This number uniquely identifies the router within an
>>            Autonomous System.";
>>      }
>>
>> My NEW DISCUSS: since is in IETF LC and on the telechat on Oct 12th,
>> it makes sense to import its router-id
>
>  This is only used in the example.  The point of the example is to
> show how the model can be extended, not to define something normative, hence
> I don't think there is a need to introduce a dependency here which would
> only be distracting.
>
Can you help me understand how this is an example?
Section 5

  module: ietf-l3-unicast-topology
    augment /nw:networks/nw:network/nw:network-types:
      +--rw l3-unicast-topology!
    augment /nw:networks/nw:network:
      +--rw l3-topology-attributes
          +--rw name?  string
          +--rw flag*  l3-flag-type
    augment /nw:networks/nw:network/nw:node:
      +--rw l3-node-attributes
          +--rw name?        inet:domain-name
          +--rw flag*        node-flag-type
          +--rw router-id*  inet:ip-address
          +--rw prefix* [prefix]
            +--rw prefix    inet:ip-prefix
            +--rw metric?  uint32
            +--rw flag*    prefix-flag-type

And section 6:

    grouping l3-node-attributes {
      description "L3 node scope attributes";
      container l3-node-attributes {
        description
          "Containing node attributes";
        leaf name {
          type inet:domain-name;
          description
            "Node name";
        }
        leaf-list flag {
          type node-flag-type;
          description
            "Node flags";
        }
        leaf-list router-id {
          type inet:ip-address;
          description
            "Router-id for the node";
        }
        list prefix {
          key "prefix";
          description
            "A list of prefixes along with their attributes";
          uses l3-prefix-attributes;
        }
      }
    }

A different view at https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-l3-unicast-topology#

Request for posting confirmation emailed to previous authors: Nitin Bahadur , Xufeng Liu , Jan Medved , Alexander Clemm , i2rs-chairs@ietf.org, Hariharan Ananthakrishnan , Robert Varga

[Ballot comment]
I have nothing substantive - obviously, Benoit's discuss needs to be addressed.

A nit (which the RFC Editor would have / will catch:
Section 9.  Security Considerations
l3-topology-attributes: A malicious client could attempt to
      sabotage the configuration of any of the ctonained attributes,
      i.e. the name or the flag data nodes.
"ctonained " is a typo.

[Ballot discuss]
Here is another validation issue, on the latest v13, that must be corrected. Actually multiple mistakes, all with the same root cause.
Note that those warnings were reported in the datatracker:
  - Yang catalog entry for ietf-l3-unicast-topology-state@2017-11-15.yang
  - Yang catalog entry for ietf-l3-unicast-topology@2017-11-15.yang

Thanks to Michal, here is the detailed explanation.
Hi Benoit,
firstly, you see the output only with -V because it changes verbosity to 'warnings' instead of the default one 'errors'. So, the warnings are valid and the when conditions are wrong. In short, in these cases the local module is not ietf-l3-unicast-topology, but ietf-network (despite being defined in ietf-l3-unicast-topology) - "ietf-network:network-types/l3-unicast-topology" should be "ietf-network:network-types/ietf-l3-unicast-topology:l3-unicast-topology" or even "network-types/ietf-l3-unicast-topology:l3-unicast-topology".

To explain, here is the (long) justification. I will use the first warning as an example, all the other warnings are caused by the same mistake. We are dealing with a when condition "nw:network-types/l3-unicast-topology" in an augment "/nw:networks/nw:network" in the module ietf-l3-unicast-topology. As per [1], the context node of the XPath expression (when condition) is the augment target node "/nw:networks/nw:network". If you notice, the warning warns about not finding the node "l3-unicast-topology", not "nw:network-types". So, what node is actually referenced by "l3-unicast-topology"? Looking at [2], second bullet point, the namespace (prefix) should that of the "current node". Sadly, there is no (I have found none) formal definition of "current node" but I dared to assume it to be the node returned by the "current()" [3] function. As was said at the beginning, the "initial context node" is "/nw:networks/nw:network". Finally, we can now decide that "l3-unicast-topology" actually takes the prefix of the module "ietf-network" and there is no such node, this node is defined in the module "ietf-l3-unicast-topology".

I hope it is clear now.

Kind regards,
Michal

[1] https://tools.ietf.org/html/rfc7950#page-137
[2] https://tools.ietf.org/html/rfc7950#section-6.4.1
[3] https://tools.ietf.org/html/rfc7950#section-10.1.1

On Tuesday, December 12, 2017 16:49 CET, Benoit Claise  wrote:

> Hi Radek,
>
> I'm looking at warnings for
> ietf-l3-unicast-topology-state@2017-11-15.yang and
> ietf-l3-unicast-topology-state@2017-11-15.yang
> See http://www.claise.be/IETFYANGPageCompilation.html
>
> Here is something interesting: the warnings only appear with the -V option.
>
> bclaise@bclaise-VirtualBox:~/ietf/YANG-all$ yanglint
> ietf-l3-unicast-topology@2017-11-15.yang
> bclaise@bclaise-VirtualBox:~/ietf/YANG-all$ yanglint -i
> ietf-l3-unicast-topology@2017-11-15.yang
> bclaise@bclaise-VirtualBox:~/ietf/YANG-all$ yanglint -i -V
> ietf-l3-unicast-topology@2017-11-15.yang
> warn: Schema node "l3-unicast-topology" not found
> (ietf-network:network-types/l3-unicast-topology) with context node
> "/ietf-network:networks/network".
> warn: Schema node "l3-unicast-topology" not found
> (../ietf-network:network-types/l3-unicast-topology) with context node
> "/ietf-network:networks/network/node".
> warn: Schema node "l3-unicast-topology" not found
> (../ietf-network:network-types/l3-unicast-topology) with context node
> "/ietf-network:networks/ietf-network:network/link".
> warn: Schema node "l3-unicast-topology" not found
> (../../ietf-network:network-types/l3-unicast-topology) with context node
> "/ietf-network:networks/ietf-network:network/ietf-network:node/termination-point".
> bclaise@bclaise-VirtualBox:~/ietf/YANG-all$ yanglint -v
> yanglint 0.13.79
> bclaise@bclaise-VirtualBox:~/ietf/YANG-all$
>
> bclaise@bclaise-VirtualBox:~/ietf/YANG-all$ yanglint
> ietf-l3-unicast-topology-state@2017-11-15.yang
> bclaise@bclaise-VirtualBox:~/ietf/YANG-all$ yanglint -i
> ietf-l3-unicast-topology-state@2017-11-15.yang
> bclaise@bclaise-VirtualBox:~/ietf/YANG-all$ yanglint -i -V
> ietf-l3-unicast-topology-state@2017-11-15.yang
> warn: Schema node "l3-unicast-topology" not found
> (ietf-network:network-types/l3-unicast-topology) with context node
> "/ietf-network:networks/network".
> warn: Schema node "l3-unicast-topology" not found
> (../ietf-network:network-types/l3-unicast-topology) with context node
> "/ietf-network:networks/network/node".
> warn: Schema node "l3-unicast-topology" not found
> (../ietf-network:network-types/l3-unicast-topology) with context node
> "/ietf-network:networks/ietf-network:network/link".
> warn: Schema node "l3-unicast-topology" not found
> (../../ietf-network:network-types/l3-unicast-topology) with context node
> "/ietf-network:networks/ietf-network:network/ietf-network:node/termination-point".
> warn: Schema node "l3-unicast-topology" not found
> (ietf-network-state:network-types/l3-unicast-topology) with context node
> "/ietf-network-state:networks/network".
> warn: Schema node "l3-unicast-topology" not found
> (../ietf-network-state:network-types/l3-unicast-topology) with context
> node "/ietf-network-state:networks/network/node".
> warn: Schema node "l3-unicast-topology" not found
> (../ietf-network-state:network-types/l3-unicast-topology) with context
> node "/ietf-network-state:networks/ietf-network-state:network/link".

> warn: Schema node "l3-unicast-topology" not found
> (../../ietf-network-state:network-types/l3-unicast-topology) with
> context node
> "/ietf-network-state:networks/ietf-network-state:network/ietf-network-state:node/termination-point".
> bclaise@bclaise-VirtualBox:~/ietf/YANG-all$
>
> Should we pay attention to those?
>
> Regards, Benoit

====================================================
Preliminary note: I hope I'm doing the right thing by updating this DISCUSS
point as  I understand that the document is back to the WG. However, since I
reviewed the version 11, since some of my ballot points have been addressed
(thank you), and since I wanted to share my feedback publicly, here is my
feedback.

1. The examples.
In the AUTH48 for the RESTCONF RFC, the example YANG module discussion came up (again).  And the examples in draft-ietf-i2rs-yang-l3-topology were also discussed. Here is the feedback from one YANG doctor, from a couple of days ago.

Look at this:

  module example-ietf-ospf-topology {
    ...
    namespace
      "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology";
    ...
    description
      "This module defines a model for OSPF network topologies.
        Copyright (c) 2017 IETF Trust and the persons identified as
        authors of the code.


They are using the IANA-controlled namespace w/o registering it.

This module *really* looks like a proper normative module, rather than an
example.  They went to far in trying to mimic a real module.

It is clear that we need more guidelines in 6087 for how to write
example modules.

I was going to ask if this module passed YANG doctor review - then I
checked and saw that version -02 was reviewed, which didn't include
this example.  How should we (the YANG doctors) handle such a case?

In this case they should:

  1.  change the name to example-ospf-topology
  2.  change the namespace to urn:example:ospf-topology
  3.  remove the top-level statements:
          organization, contact, revision

  4.  change the top-level description to what the text in the draft
      says:

      description
        "This module is intended as an example for how the
        Layer 3 Unicast topology model can be extended to cover
        OSFP topologies.";

(same for the other example module)


As I mentioned to the authors, respective chairs and AD already, we should follow the decision in this NETMOD email thread
https://www.ietf.org/mail-archive/web/netmod/current/msg17428.html
This will hopefully resolve fast. Once settled, the examples should be updated.

4.

      leaf-list router-id {
          type inet:ip-address;
          description
            "Router-id for the node";
        }

My initial DISCUSS was: We don't want to wait for https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, we should expedite this publication), but any good reason why this is aligned with its definition?
    typedef router-id {
      type yang:dotted-quad;
      description
        "A 32-bit number in the dotted quad format assigned to each
          router. This number uniquely identifies the router within an
          Autonomous System.";
    }

My NEW DISCUSS: since is in IETF LC and on the telechat on Oct 12th, it makes sense to import its router-id

[Ballot comment]
- YANG definition "YANG: A data definition language for NETCONF"
I would use:
  YANG is a data modeling language used to model configuration data,
  state data, Remote Procedure Calls, and notifications for network
  management protocols [RFC7950]

- There are multiple slightly different definitions of the datastore in
the different RFCs.
Let's not add to the confusion.
Pick one (RFC6241 should be the latest one) and mention the reference.

I'm copying Lada, as the responsible YANG doctor, in case he wants to add anything.
- section 7
OLD:
The moodel defines
NEW:
The model defines

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

The IANA Services Operator has completed its review of draft-ietf-i2rs-yang-l3-topology-13. If any part of this review is inaccurate, please let us know.

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

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

First, in the ns registry of the IETF XML Registry located at

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

two new registrations are to be made:

ID: yang:ietf-l3-unicast-topology
URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-l3-unicast-topology-state
URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should 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 are to be registered:

Name: ietf-l3-unicast-topology
File: [ TBD-at-registration ]
Maintained by IANA?:
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology
Prefix: l3t
Module:
Reference: [ RFC-to-be ]
Notes:

Name: ietf-l3-unicast-topology-state
File: [ TBD-at-registration ]
Maintained by IANA?:
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state
Prefix: l3t-s
Module:
Reference: [ RFC-to-be ]
Notes:

IANA Question --> What should be the value for "Maintained by IANA?" for these two new YANG modules?

The IANA Services Operator understands that only these two actions are required upon approval of this document.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-12-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com, akatlas@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A YANG Data Model for Layer 3 Topologies) to Proposed Standard


The IESG has received a request from the Interface to the Routing System WG
(i2rs) to consider the following document: - 'A YANG Data Model for Layer 3
Topologies'
  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 2017-12-11. 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 model for layer 3 network
  topologies.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ballot/


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

Template version:  (RFC 4858)  2/24/2012: 
Status: Send to AD, More than 5 authors all of whom worked on Yang model

Nits:  indication of pre-RFC5378 work seems to be error in general XML. 
          Aid sought to fix.  Revision -06 will fix this plus ephemeral-state update

(1) What type of RFC: Standard. 
  Why? Yang data model

(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 data model for layer 3 network  topologies.

Working Group Summary
https://www.ietf.org/mail-archive/web/i2rs/current/msg04009.html
Clear consensus.  Talk about for over a year so the last discussion just has "ship it". 

Document Quality
The data model has been implemented in the open Daylight.  Used as part of their network.  People are planning to pick up the implementation from ODL.  Vendors planning implementations included:  Packet Design (client), Huawei, and Cisco.

Reviewers:

Routing directorate review: Matt Richarsdon, Chris Hopps
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-10-rtgdir-early-richardson-2017-07-19/
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-10-rtgdir-early-hopps-2017-07-08/

Yang doctors: Ladislav Lhotka
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-10-yangdoctors-early-lhotka-2017-07-26/

Gen-ART: Paul Kyzivat
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-08-genart-lc-kyzivat-2017-01-13/

SEC-DIR:Hilarie Orman
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-08-secdir-telechat-orman-2017-01-19/

OPS-DIR: Ron Bonica
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-08-opsdir-telechat-bonica-2017-01-25/

Personnel
Document Shepherd: Susan Hares
WG chairs: Susan Hares and Russ White
Responsible AD: Alia Atlas
OPS AD for Yang: Benoit Claise
RTG-DIR reviewer: Matt Richardson, Chris Hopps
Yang-Doctors reviewer:  Ladislav Lhotka
OPS-DIR Reviewer: Ron Bonica
SEC-DIR Reviewer: Hilarie Orman
Gen-ART: Paul Kyzivat

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

3 years of review and debate, creation of the NMDA by NETMOD by
I2RS requirements, Review of every comment by shepherd,
Discussion with all parties. 

It is validated, debated, check, re-check, and - everyone says ship it.

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

All reviews and reviwers have been have been top quality.


(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, OPS-DIR, GEN-ART,  SEC-DIR, RTG-DIR - all have reviewed prior to submission.

(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 implementations and wide-spread vendor support.  It is key for other topology yang models. 
NMDA capable model that can be deployed in configuration datastore or dynamic datastore.

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

All IPR completed

Alex Clemm IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04091.html

Jan Medved IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04102.html

Xuefeng Liu
https://www.ietf.org/mail-archive/web/i2rs/current/msg04128.html
https://www.ietf.org/mail-archive/web/i2rs/current/msg04098.html


Robert Varga
https://mailarchive.ietf.org/arch/msg/i2rs/aG9MF8kiD5PCUIRnsPicTufE8iU

Nitin Bahadur IPR
https://mailarchive.ietf.org/arch/msg/i2rs/6vbrtxJJdrVvW_IHrBA7ffO8ONA.

I. Bryskin
https://www.ietf.org/mail-archive/web/i2rs/current/msg04129.html

A. Guo
https://www.ietf.org/mail-archive/web/i2rs/current/msg04126.html

Hariharan Ananthakrishnan
https://www.ietf.org/mail-archive/web/i2rs/current/msg04096.html

Vishnu Pavan Beeram
https://www.ietf.org/mail-archive/web/i2rs/current/msg04099.html


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

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

Solid with lots of discussion.  Model desired by other WGs as base model. 
ADs, WGs (netmod, netconf, I2RS) want it shipped.

(10) 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 appeals.  Everyone in the WG and in the NETCONF/NETMOD, and Benoit Claise wants draft shipped.

(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 reported seem to be a bug.  AD and Shepherd should discuss the
NITS so other ADs do not have problem.

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

  [I-D.draft-ietf-i2rs-yang-network-topo] - is being forwarded at the same time
All other normative references exist.

(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 changes to existing RFCs. This is 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).

all ready.

(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. Registers namespace URIs

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

Yang has automated checks on the yang text prior to submission.
All passed at this time.

Template version:  (RFC 4858)  2/24/2012: 
Status: Send to AD, More than 5 authors all of whom worked on Yang model

Nits:  indication of pre-RFC5378 work seems to be error in general XML. 
          Aid sought to fix.  Revision -06 will fix this plus ephemeral-state update

(1) What type of RFC: Standard. 
  Why? Yang data model

(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 data model for layer 3 network  topologies.

Working Group Summary
https://www.ietf.org/mail-archive/web/i2rs/current/msg04009.html
Clear consensus.  Talk about for over a year so the last discussion just has "ship it". 

Document Quality
The data model has been implemented in the open Daylight.  Used as part of their network.  People are planning to pick up the implementation from ODL.  Vendors planning implementations included:  Packet Design (client), Huawei, and Cisco.

Reviewers:

Routing directorate review: Matt Richarsdon, Chris Hopps
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-10-rtgdir-early-richardson-2017-07-19/
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-10-rtgdir-early-hopps-2017-07-08/

Yang doctors: Ladislav Lhotka
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-10-yangdoctors-early-lhotka-2017-07-26/

Gen-ART: Paul Kyzivat
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-08-genart-lc-kyzivat-2017-01-13/

SEC-DIR:Hilarie Orman
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-08-secdir-telechat-orman-2017-01-19/

OPS-DIR: Ron Bonica
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-08-opsdir-telechat-bonica-2017-01-25/

Personnel
Document Shepherd: Susan Hares
WG chairs: Susan Hares and Russ White
Responsible AD: Alia Atlas
OPS AD for Yang: Benoit Claise
RTG-DIR reviewer: Matt Richardson, Chris Hopps
Yang-Doctors reviewer:  Ladislav Lhotka
OPS-DIR Reviewer: Ron Bonica
SEC-DIR Reviewer: Hilarie Orman
Gen-ART: Paul Kyzivat

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

3 years of review and debate, creation of the NMDA by NETMOD by
I2RS requirements, Review of every comment by shepherd,
Discussion with all parties. 

It is validated, debated, check, re-check, and - everyone says ship it.

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

All reviews and reviwers have been have been top quality.


(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, OPS-DIR, GEN-ART,  SEC-DIR, RTG-DIR - all have reviewed prior to submission.

(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 implementations and wide-spread vendor support.  It is key for other topology yang models. 
NMDA capable model that can be deployed in configuration datastore or dynamic datastore.

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

All IPR completed

Alex Clemm IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04091.html

Jan Medved IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04102.html

Xuefeng Liu
https://www.ietf.org/mail-archive/web/i2rs/current/msg04128.html
https://www.ietf.org/mail-archive/web/i2rs/current/msg04098.html


Robert Varga
https://mailarchive.ietf.org/arch/msg/i2rs/aG9MF8kiD5PCUIRnsPicTufE8iU

Nitin Bahadur IPR
https://mailarchive.ietf.org/arch/msg/i2rs/6vbrtxJJdrVvW_IHrBA7ffO8ONA.

I. Bryskin
https://www.ietf.org/mail-archive/web/i2rs/current/msg04129.html

A. Guo
https://www.ietf.org/mail-archive/web/i2rs/current/msg04126.html

Hariharan Ananthakrishnan
https://www.ietf.org/mail-archive/web/i2rs/current/msg04096.html

Vishnu Pavan Beeram
https://www.ietf.org/mail-archive/web/i2rs/current/msg04099.html


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

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

Solid with lots of discussion.  Model desired by other WGs as base model. 
ADs, WGs (netmod, netconf, I2RS) want it shipped.

(10) 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 appeals.  Everyone in the WG and in the NETCONF/NETMOD, and Benoit Claise wants draft shipped.

(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 reported seem to be a bug.  AD and Shepherd should discuss the
NITS so other ADs do not have problem.

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

  [I-D.draft-ietf-i2rs-yang-network-topo] - is being forwarded at the same time
All other normative references exist.

(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 changes to existing RFCs. This is 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).

all ready.

(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. Registers namespace URIs

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

Yang has automated checks on the yang text prior to submission.
All passed at this time.

Template version:  (RFC 4858)  2/24/2012: 
Status: Send to AD, More than 5 authors all of whom worked on Yang model

Nits:  indication of pre-RFC5378 work seems to be error in general XML. 
          Aid sought to fix.  Revision -06 will fix this plus ephemeral-state update

(1) What type of RFC: Standard. 
  Why? Yang data model

(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 data model for layer 3 network  topologies.

Working Group Summary
https://www.ietf.org/mail-archive/web/i2rs/current/msg04009.html
Clear consensus.  Talk about for over a year so the last discussion just has "ship it". 

Document Quality
The data model has been implemented in the open Daylight.  Used as part of their network.  People are planning to pick up the implementation from ODL.  Vendors planning implementations included:  Packet Design (client), Huawei, and Cisco.

Reviewers:

Routing directorate review: Matt Richarsdon, Chris Hopps
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-10-rtgdir-early-richardson-2017-07-19/
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-10-rtgdir-early-hopps-2017-07-08/

Yang doctors: Ladislav Lhotka
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-10-yangdoctors-early-lhotka-2017-07-26/

Gen-ART: Paul Kyzivat
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-08-genart-lc-kyzivat-2017-01-13/

SEC-DIR:
https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-l3-topology-08-secdir-telechat-orman-2017-01-19/

Personnel
Document Shepherd: Susan Hares
WG chairs: Susan Hares and Russ White
Responsible AD: Alia Atlas
OPS AD for Yang: Benoit Claise
RTG-DIR reviewer: Tony Przygienda
Yang-Doctors reviewer:  Carl Moberg
OPS-DIR Reviewer: TBD
SEC-DIR Reviewer: TBD

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


Nits errors:
1) pre-RFC5378 work - error in general template
2) XML2RFC errors mis-identify errors (223, 249, 253, 262, 692) due to ascii figures.
3) Delay in posting (due to shepherd's illness (11/19-11/28).

Interaction with other Yang models:
-------------------------------------------
This is a protocol independent yang model with topology information by design it does not link to the following configuration models; 
2)  ietf-interfaces model [RFC7223]
3)  ietf-routing yang model [RFC8022] 
4)  OSPF configuration yang module ( ietf-ospf or the ospf bfd) [draft-ietf-ospf-yang]
5) ISIS configuration yang module (idraft-ietf-isis-yang-isis-cfg)
6) I2RS RIB (ephemeral state RIB) or configuration extended RIB  ( draft-acee-rtgwg-yang-rib-extend)

It does important OSPF, ISIS, and statically configured topology information into the model without linking to these models. 

Why this is useful in ephemeral state:  The approach to not link to any configuration model but to let topology process load information from OSPF into the data model means that there is no model link between configuration state and topology.  The assumption is the routing process uploading the topology model knows how to do this.  The NETCONF or RESTCONF processes simply reads, reports notifications, and logs the data.

Writes from ephemeral state to the data models: These data models allow the the NETCCONF/RESTCONF process to write a logical topology link.  Exactly how this write operates depends on the routing process.  This model obeys the requirements for the ephemeral state found in the document draft-ietf-i2rs-ephemeral-state. 

Is this ephemeral state + topology independent approach reasonable:
The ODL implementation and TEAS (traffic engineeering) have OKed this approach.  The IESG in its review of draft-ietf-i2rs-yang-network-topo and this document should review this approach for the independent data models.  There is support for this approach in TEAS and I2RS, and other models have found this approach useful.

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

All reviewers (RTG-DIR, Yang Doctors, shepherd) have been top quality.
Normal OPS-DIR and Security review should be done on the yang model.

The IESG should consider the protocol independent model has no links to configuration model, and operates under the ephemeral state requirements.  See comments in section 3 from shepherd.

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

A routing yang model needs RTG-DIR, Yang-doctors, OPS-DIR, and security directorate.
RTG-DIR and Yang Doctors is done.  OPS-DIR and SEC-DIR should be done as part of IETF LC process. 

(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 implementations and wide-spread vendor support.  It is key for other topology yang models. 

On the wide-spread interaction - please review the above comments on interaction with other yang models. This is the first of the protocol independent yang modules from I2RS that adhere to the ephemeral state requirements.  The ephemeral state requirements have been discussed by I2RS for 5 years, and for the I2RS-NETCONF/NETMOD for 2 years.  Please note that ephemeral state and OPSTATE are not aligned.  The agreement with the NETMOD chairs was to finish the OPSTATE work without ephemeral state and then to add ephemeral state.

The topology model has no links to the configuration state except in the routing process.  This approach minimizes the interaction with OPSTATE issues or real code.  Once the OPSTATE work has completed, then this document can be updated to align with the IETF conceptual comments. It is doubtful this conceptual change will alter the code.

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

IPR call was missed during WG LC .  Call done on 11/11/2016.
https://mailarchive.ietf.org/arch/msg/i2rs/icWr3JeW0OCzgkRMPY75sxWcQd0

Alex Clemm IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04091.html

Jan Medved IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04102.html

Xuefeng Liu
https://www.ietf.org/mail-archive/web/i2rs/current/msg04128.html
https://www.ietf.org/mail-archive/web/i2rs/current/msg04098.html


Robert Varga
https://mailarchive.ietf.org/arch/msg/i2rs/aG9MF8kiD5PCUIRnsPicTufE8iU

Nitin Bahadur IPR
https://mailarchive.ietf.org/arch/msg/i2rs/6vbrtxJJdrVvW_IHrBA7ffO8ONA.

I. Bryskin
https://www.ietf.org/mail-archive/web/i2rs/current/msg04129.html

A. Guo
https://www.ietf.org/mail-archive/web/i2rs/current/msg04126.html

Hariharan Ananthakrishnan
https://www.ietf.org/mail-archive/web/i2rs/current/msg04096.html

Vishnu Pavan Beeram
https://www.ietf.org/mail-archive/web/i2rs/current/msg04099.html


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

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

Solid with lots of discussion.  Model desired by other WGs as base model.  ODL implementations for 2 years.

(10) 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 appeals.  Everyone in the WG and in the NETCONF/NETMOD, and Benoit Claise wants draft shipped.

(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 errors:
1) pre-RFC5378 work - error in general template
2) XML2RFC errors mis-identify errors (223, 249, 253, 262, 692) due to ascii figures.
3) Delay in posting (due to shepherd's illness (11/19-11/27)

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

1) Automatic check of yang modules. 
2) RTG-DIR and Yang Doctor's review done.
3) Shepherd check the high-logic against the routing-configuration, OPSTATE, and ephemeral state requirements

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

[NITS fixes must be done for this text to be accurate ]
  yes.  One non-rfc draft (  [I-D.draft-ietf-i2rs-yang-network-topo]) is being forwarded with this document as a document group.

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

  [I-D.draft-ietf-i2rs-yang-network-topo] - is being forwarded at the same time
All other normative references exist.

(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 changes to existing RFCs. This is 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).

IANA section was left out.  As soon as new IANA section is writtten, it will be sent to IANA for pre-review.

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

Yang has automated checks on the yang text prior to submission.
All passed at this time.

Request for posting confirmation emailed to previous authors: Nitin Bahadur , Jan Medved , Alexander Clemm , i2rs-chairs@ietf.org, Hariharan Ananthakrishnan , Xufeng Liu , Robert Varga

[Ballot discuss]
Preliminary note: I hope I'm doing the right thing by updating this DISCUSS
point as  I understand that the document is back to the WG. However, since I
reviewed the version 11, since some of my ballot points have been addressed
(thank you), and since I wanted to share my feedback publicly, here is my
feedback.

1. The examples.
In the AUTH48 for the RESTCONF RFC, the example YANG module discussion came up (again).  And the examples in draft-ietf-i2rs-yang-l3-topology were also discussed. Here is the feedback from one YANG doctor, from a couple of days ago.

Look at this:

  module example-ietf-ospf-topology {
    ...
    namespace
      "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology";
    ...
    description
      "This module defines a model for OSPF network topologies.
        Copyright (c) 2017 IETF Trust and the persons identified as
        authors of the code.


They are using the IANA-controlled namespace w/o registering it.

This module *really* looks like a proper normative module, rather than an
example.  They went to far in trying to mimic a real module.

It is clear that we need more guidelines in 6087 for how to write
example modules.

I was going to ask if this module passed YANG doctor review - then I
checked and saw that version -02 was reviewed, which didn't include
this example.  How should we (the YANG doctors) handle such a case?

In this case they should:

  1.  change the name to example-ospf-topology
  2.  change the namespace to urn:example:ospf-topology
  3.  remove the top-level statements:
          organization, contact, revision

  4.  change the top-level description to what the text in the draft
      says:

      description
        "This module is intended as an example for how the
        Layer 3 Unicast topology model can be extended to cover
        OSFP topologies.";

(same for the other example module)


As I mentioned to the authors, respective chairs and AD already, we should follow the decision in this NETMOD email thread
https://www.ietf.org/mail-archive/web/netmod/current/msg17428.html
This will hopefully resolve fast. Once settled, the examples should be updated.

4.

      leaf-list router-id {
          type inet:ip-address;
          description
            "Router-id for the node";
        }

My initial DISCUSS was: We don't want to wait for https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, we should expedite this publication), but any good reason why this is aligned with its definition?
    typedef router-id {
      type yang:dotted-quad;
      description
        "A 32-bit number in the dotted quad format assigned to each
          router. This number uniquely identifies the router within an
          Autonomous System.";
    }

My NEW DISCUSS: since is in IETF LC and on the telechat on Oct 12th, it makes sense to import its router-id

[Ballot comment]
- YANG definition "YANG: A data definition language for NETCONF"
I would use:
  YANG is a data modeling language used to model configuration data,
  state data, Remote Procedure Calls, and notifications for network
  management protocols [RFC7950]

- There are multiple slightly different definitions of the datastore in
the different RFCs.
Let's not add to the confusion.
Pick one (RFC6241 should be the latest one) and mention the reference.

- section 7
OLD:
The moodel defines
NEW:
The model defines

[Ballot discuss]
1. The examples.
In the AUTH48 for the RESTCONF RFC, the example YANG module discussion came up (again).  And the examples in draft-ietf-i2rs-yang-l3-topology were also discussed. Here is the feedback from one YANG doctor, from a couple of days ago.

Look at this:

  module example-ietf-ospf-topology {
    ...
    namespace
      "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology";
    ...
    description
      "This module defines a model for OSPF network topologies.
        Copyright (c) 2017 IETF Trust and the persons identified as
        authors of the code.


They are using the IANA-controlled namespace w/o registering it.

This module *really* looks like a proper normative module, rather than an
example.  They went to far in trying to mimic a real module.

It is clear that we need more guidelines in 6087 for how to write
example modules.

I was going to ask if this module passed YANG doctor review - then I
checked and saw that version -02 was reviewed, which didn't include
this example.  How should we (the YANG doctors) handle such a case?

In this case they should:

  1.  change the name to example-ospf-topology
  2.  change the namespace to urn:example:ospf-topology
  3.  remove the top-level statements:
          organization, contact, revision

  4.  change the top-level description to what the text in the draft
      says:

      description
        "This module is intended as an example for how the
        Layer 3 Unicast topology model can be extended to cover
        OSFP topologies.";

(same for the other example module)


As I mentioned to the authors, respective chairs and AD already, we should follow the decision in this NETMOD email thread
https://www.ietf.org/mail-archive/web/netmod/current/msg17428.html
This will hopefully resolve fast. Once settled, the examples should be updated.

2. The security considerations should be better aligned with https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as mentioned by others.

3. Carl Moberg, as YANG doctor, reviewed v1 of the draft.
https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00031.html
I'm waiting for final blessing on v8 any time soon. Hence this late DISCUSS.

4.

      leaf-list router-id {
          type inet:ip-address;
          description
            "Router-id for the node";
        }

We don't want to wait for https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, we should expedite this publication), but any good reason why
this is aligned with its definition?
    typedef router-id {
      type yang:dotted-quad;
      description
        "A 32-bit number in the dotted quad format assigned to each
          router. This number uniquely identifies the router within an
          Autonomous System.";
    }

[Ballot comment]
- YANG definition "YANG: A data definition language for NETCONF"
I would use:
  YANG is a data modeling language used to model configuration data,
  state data, Remote Procedure Calls, and notifications for network
  management protocols [RFC7950]

- There are multiple slightly different definitions of the datastore in
the different RFCs.
Let's not add to the confusion.
Pick one (RFC6241 should be the latest one) and mention the reference.

- Instead of:

  Brackets
  enclose list keys, "rw" means configuration, "ro" operational state
  data, "?" designates optional nodes, "*" designates nodes that can
  have multiple instances.  Parantheses enclose choice and case nodes.

Use the cut/paste from RFC8022 and
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09]

  o  Brackets "[" and "]" enclose list keys.

  o  Curly braces "{" and "}" contain names of optional features that
      make the corresponding node conditional.

  o  Abbreviations before data node names: "rw" means configuration
      (read-write), "ro" state data (read-only), "-x" RPC operations or
      actions, and "-n" notifications.

  o  Symbols after data node names: "?" means an optional node, "!" a
      container with presence, and "*" denotes a "list" or "leaf-list".

  o  Parentheses enclose choice and case nodes, and case nodes are
also
      marked with a colon (":").

  o  Ellipsis ("...") stands for contents of subtrees that are not
      shown.

Btw, no need to repeat this convention in section 6.1.1 and 6.2.1

- I agree with Suresh: "OSPF and IS-IS are used later in the document as examples but this section (especially Figure 1) seems to treat them as more than examples"
Either modify figure 1, or even better, stress in section 3 that ospf-topology and isis-topology are examples, and defined as such in this document

- section 7
OLD:
The moodel defines
NEW:
The model defines

[Ballot comment]
* Section 3

OSPF and IS-IS are used later in the document as examples but this section (especially Figure 1) seems to treat them as more than examples. What is the actual intent? Is this draft supposed to be the canonical definition of ospf-topology and isis-topology? Please clarify.

* Section 4

Is there a reason that router-id is defined as capable of having multiple instances?

[Ballot comment]
I agree with Alissa's comment that the YANG module security consideration section guidelines need to be followed and this shouldn't go forward until that is corrected.  I'm told it will be, thanks.

[Ballot comment]
I think that Section 6 (Extending the Model) causes confusion: why aren't these extensions fully specified here?  There seem to be no active efforts in the ospf/isis WGs.  Suggestion: move the examples to an Appendix.

[Ballot comment]
= Section 2 =

HTTP and ReST are defined, but they aren't used anywhere else in the
document in a way that requires definition.

= Section 5 =

"case interface-name {
            leaf interface-name {
              type string;
              description
                "A name of the interface.  The name can (but does not
                  have to) correspond to an interface reference of a
                  containing node's interface, i.e. the path name of a
                  corresponding interface data node on the containing
                  node reminiscent of data type if-ref defined in
                  RFC 7223. It should be noted that data type if-ref of
                  RFC 7223 cannot be used directly, as this data type
                  is used to reference an interface in a datastore of
                  a single node in the network, not to uniquely
                  reference interfaces across a network.";
            }
          }"

In RFC 7223 the data type appears to be called interface-ref, not if-ref. Would an example of this in this document be, say, a MAC address?

= Section 6.1.1 and 6.2.1 =

While notational explanations are given for "?," "*," etc., none is given for "!".

= Section 9 =

This section is missing a discussion of the potential sensitivity of the data this module exposes even in a read-only use case. Filling in the template at https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines and adding the text to this section should get that covered.

[Ballot comment]
Two high level comments (please note that I’m not a yang expert and if this model is considered right by the vendor community that want to use it, I’m fine with it):
1) I’m not sure about the usefulness of the flag attribute, given that’s a very general reference to some kind of unspecified information (and it’s also not used in the examples as far as I can see)
2) Why are the is-is and ospf models only given as examples instead of also specifying them completely in this draft. These parts atually seem to me to be the more interesting bits of work…

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

The IANA Services Operator has completed its review of draft-ietf-i2rs-yang-l3-topology-07.txt. If any part of this review is inaccurate, please let us know.

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

First, in the ns subregistry of the IETF XML Registry located at:

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

a single, new namespace will be registered as follows:

ID: yang:ietf-l3-unicast-topology
URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names subregistry of the YANG Parameters registry located at:

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

a single, new module name will be registered as follows:

Name: ietf-l3-unicast-topology
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology
Prefix: l3t
Module:
Reference: [ RFC-to-be ]

The IANA Services Operator understands that these two actions are the only ones 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 only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com, akatlas@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A YANG Data Model for Layer 3 Topologies) to Proposed Standard


The IESG has received a request from the Interface to the Routing System
WG (i2rs) to consider the following document:
- 'A YANG Data Model for Layer 3 Topologies'
  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 2017-01-17. 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 model for layer 3 network
  topologies.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ballot/


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

Request for posting confirmation emailed to previous authors: "Nitin Bahadur" , "Igor Bryskin" , "Jan Medved" , "Alexander Clemm" , "Xufeng Liu" , i2rs-chairs@ietf.org, "Robert Varga" , "Hariharan Ananthakrishnan" , "Aihua Guo" , "Vishnu Beeram"

Please move to a few editors instead of 9 authors!

Major:

a) Please clarify whether there are existing WG models that depend on this module.

b) "augment /nd:networks/nd:network/nd:node/lnk:termination-point:

      +--rw l3-termination-point-attributes
        +--rw (termination-point-type)?
            +--:(ip)
            |  +--rw ip-address*      inet:ip-address
            +--:(unnumbered)
              +--rw unnumbered-id?  uint32 "
Is the unnumbered-id an ifIndex?  Can you declare it with that type?
Similarly in the model on p. 12: 
"case unnumbered {

            leaf unnumbered-id {
              type uint32;
              description
                "Unnumbered interface identifier";
            }"
why isn't this an ifIndex?!?

Minor:

1) Intro: Please clean up paragraphs 2&3.  When this is an RFC, it wont matter what the logic was for pulling the L3 topology model out. That can go.  Similarly, there are existing WG drafts for IS-IS and OSPF models.  Rather than "expecting", how about a reference?  Are there such models?

2) Intro:  Do we really need the paragraph on why to choose YANG?

3)Intro:  How about an informative reference to the TED topology model?

4) Sec 2: Datastore definition -  please add a pointer to the NetMod RFC that defines it or at least indicate that this isn't a new definition & where it comes from.

5) On p. 9:  " typedef link-flag-type {

      type identityref {
        base "flag-identity";
      }
      description "Prefix flag attributes";  "
Shouldn't the description be "Link flag attributes"?

6)  Section 6 with the non-normative examples should be an Appendix.

7)  Contributors should be listed with at most address information (which usually includes affiliation) - but such affiliation should be correct!(e.g. Ken Gray) or just by name.  We are all participating as individuals - not company representatives.

Request for posting confirmation emailed to previous authors: "Nitin Bahadur" , "Igor Bryskin" , "Jan Medved" , "Alexander Clemm" , "Xufeng Liu" , i2rs-chairs@ietf.org, "Robert Varga" , "Hariharan Ananthakrishnan" , "Aihua Guo" , "Vishnu Beeram"

Template version:  (RFC 4858)  2/24/2012: 
Status: Send to AD, More than 5 authors all of whom worked on Yang model

Nits:  indication of pre-RFC5378 work seems to be error in general XML. 
          Aid sought to fix.  Revision -06 will fix this plus ephemeral-state update

(1) What type of RFC: Standard. 
  Why? Yang data model

(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 data model for layer 3 network  topologies.

Working Group Summary
https://www.ietf.org/mail-archive/web/i2rs/current/msg04009.html
Clear consensus.  Talk about for over a year so the last discussion just has "ship it". 

Document Quality
The data model has been implemented in the open Daylight.  Used as part of their network.  People are planning to pick up the implementation from ODL.  Vendors planning implementations included:  Packet Design (client), Huawei, and Cisco.

Reviewers:

Routing directorate review: Tony Przygienda
https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02912.html

Yang doctors: Carl Moberg
https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00031.html6

Personnel
Document Shepherd: Susan Hares
WG chairs: Susan Hares and Russ White
Responsible AD: Alia Atlas
OPS AD for Yang: Benoit Claise
RTG-DIR reviewer: Tony Przygienda
Yang-Doctors reviewer:  Carl Moberg
OPS-DIR Reviewer: TBD
SEC-DIR Reviewer: TBD

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


Nits errors:
1) pre-RFC5378 work - error in general template
2) XML2RFC errors mis-identify errors (223, 249, 253, 262, 692) due to ascii figures.
3) Delay in posting (due to shepherd's illness (11/19-11/28).

Interaction with other Yang models:
-------------------------------------------
This is a protocol independent yang model with topology information by design it does not link to the following configuration models; 
2)  ietf-interfaces model [RFC7223]
3)  ietf-routing yang model [RFC8022] 
4)  OSPF configuration yang module ( ietf-ospf or the ospf bfd) [draft-ietf-ospf-yang]
5) ISIS configuration yang module (idraft-ietf-isis-yang-isis-cfg)
6) I2RS RIB (ephemeral state RIB) or configuration extended RIB  ( draft-acee-rtgwg-yang-rib-extend)

It does important OSPF, ISIS, and statically configured topology information into the model without linking to these models. 

Why this is useful in ephemeral state:  The approach to not link to any configuration model but to let topology process load information from OSPF into the data model means that there is no model link between configuration state and topology.  The assumption is the routing process uploading the topology model knows how to do this.  The NETCONF or RESTCONF processes simply reads, reports notifications, and logs the data.

Writes from ephemeral state to the data models: These data models allow the the NETCCONF/RESTCONF process to write a logical topology link.  Exactly how this write operates depends on the routing process.  This model obeys the requirements for the ephemeral state found in the document draft-ietf-i2rs-ephemeral-state. 

Is this ephemeral state + topology independent approach reasonable:
The ODL implementation and TEAS (traffic engineeering) have OKed this approach.  The IESG in its review of draft-ietf-i2rs-yang-network-topo and this document should review this approach for the independent data models.  There is support for this approach in TEAS and I2RS, and other models have found this approach useful.

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

All reviewers (RTG-DIR, Yang Doctors, shepherd) have been top quality.
Normal OPS-DIR and Security review should be done on the yang model.

The IESG should consider the protocol independent model has no links to configuration model, and operates under the ephemeral state requirements.  See comments in section 3 from shepherd.

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

A routing yang model needs RTG-DIR, Yang-doctors, OPS-DIR, and security directorate.
RTG-DIR and Yang Doctors is done.  OPS-DIR and SEC-DIR should be done as part of IETF LC process. 

(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 implementations and wide-spread vendor support.  It is key for other topology yang models. 

On the wide-spread interaction - please review the above comments on interaction with other yang models. This is the first of the protocol independent yang modules from I2RS that adhere to the ephemeral state requirements.  The ephemeral state requirements have been discussed by I2RS for 5 years, and for the I2RS-NETCONF/NETMOD for 2 years.  Please note that ephemeral state and OPSTATE are not aligned.  The agreement with the NETMOD chairs was to finish the OPSTATE work without ephemeral state and then to add ephemeral state.

The topology model has no links to the configuration state except in the routing process.  This approach minimizes the interaction with OPSTATE issues or real code.  Once the OPSTATE work has completed, then this document can be updated to align with the IETF conceptual comments. It is doubtful this conceptual change will alter the code.

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

IPR call was missed during WG LC .  Call done on 11/11/2016.
https://mailarchive.ietf.org/arch/msg/i2rs/icWr3JeW0OCzgkRMPY75sxWcQd0

Alex Clemm IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04091.html

Jan Medved IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04102.html

Xuefeng Liu
https://www.ietf.org/mail-archive/web/i2rs/current/msg04128.html
https://www.ietf.org/mail-archive/web/i2rs/current/msg04098.html


Robert Varga
https://mailarchive.ietf.org/arch/msg/i2rs/aG9MF8kiD5PCUIRnsPicTufE8iU

Nitin Bahadur IPR
https://mailarchive.ietf.org/arch/msg/i2rs/6vbrtxJJdrVvW_IHrBA7ffO8ONA.

I. Bryskin
https://www.ietf.org/mail-archive/web/i2rs/current/msg04129.html

A. Guo
https://www.ietf.org/mail-archive/web/i2rs/current/msg04126.html

Hariharan Ananthakrishnan
https://www.ietf.org/mail-archive/web/i2rs/current/msg04096.html

Vishnu Pavan Beeram
https://www.ietf.org/mail-archive/web/i2rs/current/msg04099.html


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

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

Solid with lots of discussion.  Model desired by other WGs as base model.  ODL implementations for 2 years.

(10) 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 appeals.  Everyone in the WG and in the NETCONF/NETMOD, and Benoit Claise wants draft shipped.

(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 errors:
1) pre-RFC5378 work - error in general template
2) XML2RFC errors mis-identify errors (223, 249, 253, 262, 692) due to ascii figures.
3) Delay in posting (due to shepherd's illness (11/19-11/27)

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

1) Automatic check of yang modules. 
2) RTG-DIR and Yang Doctor's review done.
3) Shepherd check the high-logic against the routing-configuration, OPSTATE, and ephemeral state requirements

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

[NITS fixes must be done for this text to be accurate ]
  yes.  One non-rfc draft (  [I-D.draft-ietf-i2rs-yang-network-topo]) is being forwarded with this document as a document group.

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

  [I-D.draft-ietf-i2rs-yang-network-topo] - is being forwarded at the same time
All other normative references exist.

(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 changes to existing RFCs. This is 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).

IANA section was left out.  As soon as new IANA section is writtten, it will be sent to IANA for pre-review.

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

Yang has automated checks on the yang text prior to submission.
All passed at this time.

Template version:  (RFC 4858)  2/24/2012: 
Status: Send to AD, IPR pending
IPR missing: Robert Varga,  I. Bryskin, N. Bahadur - will drop if they fail to respond
Nits:  indication of pre-RFC5378 work seems to be error in general XML. 
          Aid sought to fix.  Revision -06 will fix this plus ephemeral-state update

(1) What type of RFC: Standard. 
  Why? Yang data model

(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 data model for layer 3 network  topologies.

Working Group Summary
https://www.ietf.org/mail-archive/web/i2rs/current/msg04009.html
Clear consensus.  Talk about for over a year so the last discussion just has "ship it". 

Document Quality
The data model has been implemented in the open Daylight.  Used as part of their network.  People are planning to pick up the implementation from ODL.  Vendors planning implementations included:  Packet Design (client), Huawei, and Cisco.

Reviewers:

Routing directorate review: Tony Przygienda
https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02912.html

Yang doctors: Carl Moberg
https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00031.html6

Personnel
Document Shepherd: Susan Hares
WG chairs: Susan Hares and Russ White
Responsible AD: Alia Atlas
OPS AD for Yang: Benoit Claise
RTG-DIR reviewer: Tony Przygienda
Yang-Doctors reviewer:  Carl Moberg
OPS-DIR Reviewer: TBD
SEC-DIR Reviewer: TBD

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


Nits errors:
1) pre-RFC5378 work - error in general template
2) XML2RFC errors mis-identify errors (223, 249, 253, 262, 692) due to ascii figures.
3) Delay in posting (due to shepherd's illness (11/19-11/28).

Interaction with other Yang models:
-------------------------------------------
This is a protocol independent yang model with topology information by design it does not link to the following configuration models; 
2)  ietf-interfaces model [RFC7223]
3)  ietf-routing yang model [RFC8022] 
4)  OSPF configuration yang module ( ietf-ospf or the ospf bfd) [draft-ietf-ospf-yang]
5) ISIS configuration yang module (idraft-ietf-isis-yang-isis-cfg)
6) I2RS RIB (ephemeral state RIB) or configuration extended RIB  ( draft-acee-rtgwg-yang-rib-extend)

It does important OSPF, ISIS, and statically configured topology information into the model without linking to these models. 

Why this is useful in ephemeral state:  The approach to not link to any configuration model but to let topology process load information from OSPF into the data model means that there is no model link between configuration state and topology.  The assumption is the routing process uploading the topology model knows how to do this.  The NETCONF or RESTCONF processes simply reads, reports notifications, and logs the data.

Writes from ephemeral state to the data models: These data models allow the the NETCCONF/RESTCONF process to write a logical topology link.  Exactly how this write operates depends on the routing process.  This model obeys the requirements for the ephemeral state found in the document draft-ietf-i2rs-ephemeral-state. 

Is this ephemeral state + topology independent approach reasonable:
The ODL implementation and TEAS (traffic engineeering) have OKed this approach.  The IESG in its review of draft-ietf-i2rs-yang-network-topo and this document should review this approach for the independent data models.  There is support for this approach in TEAS and I2RS, and other models have found this approach useful.

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

All reviewers (RTG-DIR, Yang Doctors, shepherd) have been top quality.
Normal OPS-DIR and Security review should be done on the yang model.

The IESG should consider the protocol independent model has no links to configuration model, and operates under the ephemeral state requirements.  See comments in section 3 from shepherd.

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

A routing yang model needs RTG-DIR, Yang-doctors, OPS-DIR, and security directorate.
RTG-DIR and Yang Doctors is done.  OPS-DIR and SEC-DIR should be done as part of IETF LC process. 

(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 implementations and wide-spread vendor support.  It is key for other topology yang models. 

On the wide-spread interaction - please review the above comments on interaction with other yang models. This is the first of the protocol independent yang modules from I2RS that adhere to the ephemeral state requirements.  The ephemeral state requirements have been discussed by I2RS for 5 years, and for the I2RS-NETCONF/NETMOD for 2 years.  Please note that ephemeral state and OPSTATE are not aligned.  The agreement with the NETMOD chairs was to finish the OPSTATE work without ephemeral state and then to add ephemeral state.

The topology model has no links to the configuration state except in the routing process.  This approach minimizes the interaction with OPSTATE issues or real code.  Once the OPSTATE work has completed, then this document can be updated to align with the IETF conceptual comments. It is doubtful this conceptual change will alter the code.

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

IPR call was missed during WG LC .  Call done on 11/11/2016.
https://mailarchive.ietf.org/arch/msg/i2rs/icWr3JeW0OCzgkRMPY75sxWcQd0

Alex Clemm IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04091.html

Jan Medved IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04102.html

Xuefeng Liu
https://www.ietf.org/mail-archive/web/i2rs/current/msg04128.html
https://www.ietf.org/mail-archive/web/i2rs/current/msg04098.html


Robert Varga
https://mailarchive.ietf.org/arch/msg/i2rs/aG9MF8kiD5PCUIRnsPicTufE8iU

Nitin Bahadur IPR
(not received)  - will delete if not there by 11/30/2016.

I. Bryskin
https://www.ietf.org/mail-archive/web/i2rs/current/msg04129.html

A. Guo
https://www.ietf.org/mail-archive/web/i2rs/current/msg04126.html

Hariharan Ananthakrishnan
https://www.ietf.org/mail-archive/web/i2rs/current/msg04096.html

Vishnu Pavan Beeram
https://www.ietf.org/mail-archive/web/i2rs/current/msg04099.html


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

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

Solid with lots of discussion.  Model desired by other WGs as base model.  ODL implementations for 2 years.

(10) 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 appeals.  Everyone in the WG and in the NETCONF/NETMOD, and Benoit Claise wants draft shipped.

(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 errors:
1) pre-RFC5378 work - error in general template
2) XML2RFC errors mis-identify errors (223, 249, 253, 262, 692) due to ascii figures.
3) Delay in posting (due to shepherd's illness (11/19-11/27)

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

1) Automatic check of yang modules. 
2) RTG-DIR and Yang Doctor's review done.
3) Shepherd check the high-logic against the routing-configuration, OPSTATE, and ephemeral state requirements

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

[NITS fixes must be done for this text to be accurate ]
  yes.  One non-rfc draft (  [I-D.draft-ietf-i2rs-yang-network-topo]) is being forwarded with this document as a document group.

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

  [I-D.draft-ietf-i2rs-yang-network-topo] - is being forwarded at the same time
All other normative references exist.

(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 changes to existing RFCs. This is 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).

IANA section was left out.  As soon as new IANA section is writtten, it will be sent to IANA for pre-review.

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

Yang has automated checks on the yang text prior to submission.
All passed at this time.

Template version:  (RFC 4858)  2/24/2012: 
Status: Send to AD, IPR pending
IPR missing: Robert Varga,  I. Bryskin, N. Bahadur - will drop if they fail to respond
Nits:  indication of pre-RFC5378 work seems to be error in general XML. 
          Aid sought to fix.  Revision -06 will fix this plus ephemeral-state update

(1) What type of RFC: Standard. 
  Why? Yang data model

(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 data model for layer 3 network  topologies.

Working Group Summary
https://www.ietf.org/mail-archive/web/i2rs/current/msg04009.html
Clear consensus.  Talk about for over a year so the last discussion just has "ship it". 

Document Quality
The data model has been implemented in the open Daylight.  Used as part of their network.  People are planning to pick up the implementation from ODL.  Vendors planning implementations included:  Packet Design (client), Huawei, and Cisco.

Reviewers:

Routing directorate review: Tony Przygienda
https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02912.html

Yang doctors: Carl Moberg
https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00031.html6

Personnel
Document Shepherd: Susan Hares
WG chairs: Susan Hares and Russ White
Responsible AD: Alia Atlas
OPS AD for Yang: Benoit Claise
RTG-DIR reviewer: Tony Przygienda
Yang-Doctors reviewer:  Carl Moberg
OPS-DIR Reviewer: TBD
SEC-DIR Reviewer: TBD

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


Nits errors:
1) pre-RFC5378 work - error in general template
2) XML2RFC errors mis-identify errors (223, 249, 253, 262, 692) due to ascii figures.
3) Delay in posting (due to shepherd's illness (11/19-11/28).

Interaction with other Yang models:
-------------------------------------------
This is a protocol independent yang model with topology information by design it does not link to the following configuration models; 
2)  ietf-interfaces model [RFC7223]
3)  ietf-routing yang model [RFC8022] 
4)  OSPF configuration yang module ( ietf-ospf or the ospf bfd) [draft-ietf-ospf-yang]
5) ISIS configuration yang module (idraft-ietf-isis-yang-isis-cfg)
6) I2RS RIB (ephemeral state RIB) or configuration extended RIB  ( draft-acee-rtgwg-yang-rib-extend)

It does important OSPF, ISIS, and statically configured topology information into the model without linking to these models. 

Why this is useful in ephemeral state:  The approach to not link to any configuration model but to let topology process load information from OSPF into the data model means that there is no model link between configuration state and topology.  The assumption is the routing process uploading the topology model knows how to do this.  The NETCONF or RESTCONF processes simply reads, reports notifications, and logs the data.

Writes from ephemeral state to the data models: These data models allow the the NETCCONF/RESTCONF process to write a logical topology link.  Exactly how this write operates depends on the routing process.  This model obeys the requirements for the ephemeral state found in the document draft-ietf-i2rs-ephemeral-state. 

Is this ephemeral state + topology independent approach reasonable:
The ODL implementation and TEAS (traffic engineeering) have OKed this approach.  The IESG in its review of draft-ietf-i2rs-yang-network-topo and this document should review this approach for the independent data models.  There is support for this approach in TEAS and I2RS, and other models have found this approach useful.

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

All reviewers (RTG-DIR, Yang Doctors, shepherd) have been top quality.
Normal OPS-DIR and Security review should be done on the yang model.

The IESG should consider the protocol independent model has no links to configuration model, and operates under the ephemeral state requirements.  See comments in section 3 from shepherd.

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

A routing yang model needs RTG-DIR, Yang-doctors, OPS-DIR, and security directorate.
RTG-DIR and Yang Doctors is done.  OPS-DIR and SEC-DIR should be done as part of IETF LC process. 

(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 implementations and wide-spread vendor support.  It is key for other topology yang models. 

On the wide-spread interaction - please review the above comments on interaction with other yang models. This is the first of the protocol independent yang modules from I2RS that adhere to the ephemeral state requirements.  The ephemeral state requirements have been discussed by I2RS for 5 years, and for the I2RS-NETCONF/NETMOD for 2 years.  Please note that ephemeral state and OPSTATE are not aligned.  The agreement with the NETMOD chairs was to finish the OPSTATE work without ephemeral state and then to add ephemeral state.

The topology model has no links to the configuration state except in the routing process.  This approach minimizes the interaction with OPSTATE issues or real code.  Once the OPSTATE work has completed, then this document can be updated to align with the IETF conceptual comments. It is doubtful this conceptual change will alter the code.

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

IPR call was missed during WG LC .  Call done on 11/11/2016.
https://mailarchive.ietf.org/arch/msg/i2rs/icWr3JeW0OCzgkRMPY75sxWcQd0

Alex Clemm IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04091.html

Jan Medved IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04102.html

Xuefeng Liu
(reposted to list, have in private email)

Robert Varga
(received) -updating the I2RS list

Nitin Bahadur IPR
(received) - updating list

I. Bryskin
(received) - updating on list

A. Guo
https://www.ietf.org/mail-archive/web/i2rs/current/msg04126.html

Hariharan Ananthakrishnan
https://www.ietf.org/mail-archive/web/i2rs/current/msg04096.html

Vishnu Pavan Beeram
https://www.ietf.org/mail-archive/web/i2rs/current/msg04099.html


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

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

Solid with lots of discussion.  Model desired by other WGs as base model.  ODL implementations for 2 years.

(10) 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 appeals.  Everyone in the WG and in the NETCONF/NETMOD, and Benoit Claise wants draft shipped.

(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 errors:
1) pre-RFC5378 work - error in general template
2) XML2RFC errors mis-identify errors (223, 249, 253, 262, 692) due to ascii figures.
3) Delay in posting (due to shepherd's illness (11/19-11/27)

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

1) Automatic check of yang modules. 
2) RTG-DIR and Yang Doctor's review done.
3) Shepherd check the high-logic against the routing-configuration, OPSTATE, and ephemeral state requirements

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

[NITS fixes must be done for this text to be accurate ]
  yes.  One non-rfc draft (  [I-D.draft-ietf-i2rs-yang-network-topo]) is being forwarded with this document as a document group.

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

  [I-D.draft-ietf-i2rs-yang-network-topo] - is being forwarded at the same time
All other normative references exist.

(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 changes to existing RFCs. This is 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).

IANA section was left out.  As soon as new IANA section is writtten, it will be sent to IANA for pre-review.

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

Yang has automated checks on the yang text prior to submission.
All passed at this time.

Template version:  (RFC 4858)  2/24/2012: 
Status: Send to AD, IPR pending
IPR missing: Robert Varga,  I. Bryskin, N. Bahadur - will drop if they fail to respond
Nits:  indication of pre-RFC5378 work seems to be error in general XML. 
          Aid sought to fix.  Revision -06 will fix this plus ephemeral-state update

(1) What type of RFC: Standard. 
  Why? Yang data model

(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 data model for layer 3 network  topologies.

Working Group Summary
https://www.ietf.org/mail-archive/web/i2rs/current/msg04009.html
Clear consensus.  Talk about for over a year so the last discussion just has "ship it". 

Document Quality
The data model has been implemented in the open Daylight.  Used as part of their network.  People are planning to pick up the implementation from ODL.  Vendors planning implementations included:  Packet Design (client), Huawei, and Cisco.

Reviewers:

Routing directorate review: Tony Przygienda
https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02912.html

Yang doctors: Carl Moberg
https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00031.html6

Personnel
Document Shepherd: Susan Hares
WG chairs: Susan Hares and Russ White
Responsible AD: Alia Atlas
OPS AD for Yang: Benoit Claise
RTG-DIR reviewer: Tony Przygienda
Yang-Doctors reviewer:  Carl Moberg
OPS-DIR Reviewer: TBD
SEC-DIR Reviewer: TBD

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


Nits errors:
1) pre-RFC5378 work - error in general template
2) XML2RFC errors mis-identify errors (223, 249, 253, 262, 692) due to ascii figures.
3) Delay in posting (due to shepherd's illness (11/19-11/28).

Interaction with other Yang models:
-------------------------------------------
This is a protocol independent yang model with topology information by design it does not link to the following configuration models; 
2)  ietf-interfaces model [RFC7223]
3)  ietf-routing yang model [RFC8022] 
4)  OSPF configuration yang module ( ietf-ospf or the ospf bfd) [draft-ietf-ospf-yang]
5) ISIS configuration yang module (idraft-ietf-isis-yang-isis-cfg)
6) I2RS RIB (ephemeral state RIB) or configuration extended RIB  ( draft-acee-rtgwg-yang-rib-extend)

It does important OSPF, ISIS, and statically configured topology information into the model without linking to these models. 

Why this is useful in ephemeral state:  The approach to not link to any configuration model but to let topology process load information from OSPF into the data model means that there is no model link between configuration state and topology.  The assumption is the routing process uploading the topology model knows how to do this.  The NETCONF or RESTCONF processes simply reads, reports notifications, and logs the data.

Writes from ephemeral state to the data models: These data models allow the the NETCCONF/RESTCONF process to write a logical topology link.  Exactly how this write operates depends on the routing process.  This model obeys the requirements for the ephemeral state found in the document draft-ietf-i2rs-ephemeral-state. 

Is this ephemeral state + topology independent approach reasonable:
The ODL implementation and TEAS (traffic engineeering) have OKed this approach.  The IESG in its review of draft-ietf-i2rs-yang-network-topo and this document should review this approach for the independent data models.  There is support for this approach in TEAS and I2RS, and other models have found this approach useful.

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

All reviewers (RTG-DIR, Yang Doctors, shepherd) have been top quality.
Normal OPS-DIR and Security review should be done on the yang model.

The IESG should consider the protocol independent model has no links to configuration model, and operates under the ephemeral state requirements.  See comments in section 3 from shepherd.

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

A routing yang model needs RTG-DIR, Yang-doctors, OPS-DIR, and security directorate.
RTG-DIR and Yang Doctors is done.  OPS-DIR and SEC-DIR should be done as part of IETF LC process. 

(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 implementations and wide-spread vendor support.  It is key for other topology yang models. 

On the wide-spread interaction - please review the above comments on interaction with other yang models. This is the first of the protocol independent yang modules from I2RS that adhere to the ephemeral state requirements.  The ephemeral state requirements have been discussed by I2RS for 5 years, and for the I2RS-NETCONF/NETMOD for 2 years.  Please note that ephemeral state and OPSTATE are not aligned.  The agreement with the NETMOD chairs was to finish the OPSTATE work without ephemeral state and then to add ephemeral state.

The topology model has no links to the configuration state except in the routing process.  This approach minimizes the interaction with OPSTATE issues or real code.  Once the OPSTATE work has completed, then this document can be updated to align with the IETF conceptual comments. It is doubtful this conceptual change will alter the code.

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

IPR call was missed during WG LC .  Call done on 11/11/2016.
https://mailarchive.ietf.org/arch/msg/i2rs/icWr3JeW0OCzgkRMPY75sxWcQd0

Alex Clemm IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04091.html

Jan Medved IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04102.html

Xuefeng Liu
(reposted to list, have in private email)

Robert Varga
(missing) - will drop as author if does not respond

Nitin Bahadur IPR
(missing)  - will drop as author if does not respond

I. Bryskin
(missing) - will drop as author if does not respond

A. Guo
https://www.ietf.org/mail-archive/web/i2rs/current/msg04126.html

Hariharan Ananthakrishnan
https://www.ietf.org/mail-archive/web/i2rs/current/msg04096.html

Vishnu Pavan Beeram
https://www.ietf.org/mail-archive/web/i2rs/current/msg04099.html


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

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

Solid with lots of discussion.  Model desired by other WGs as base model.  ODL implementations for 2 years.

(10) 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 appeals.  Everyone in the WG and in the NETCONF/NETMOD, and Benoit Claise wants draft shipped.

(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 errors:
1) pre-RFC5378 work - error in general template
2) XML2RFC errors mis-identify errors (223, 249, 253, 262, 692) due to ascii figures.
3) Delay in posting (due to shepherd's illness (11/19-11/27)

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

1) Automatic check of yang modules. 
2) RTG-DIR and Yang Doctor's review done.
3) Shepherd check the high-logic against the routing-configuration, OPSTATE, and ephemeral state requirements

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

[NITS fixes must be done for this text to be accurate ]
  yes.  One non-rfc draft (  [I-D.draft-ietf-i2rs-yang-network-topo]) is being forwarded with this document as a document group.

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

  [I-D.draft-ietf-i2rs-yang-network-topo] - is being forwarded at the same time
All other normative references exist.

(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 changes to existing RFCs. This is 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).

IANA section was left out.  As soon as new IANA section is writtten, it will be sent to IANA for pre-review.

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

Yang has automated checks on the yang text prior to submission.
All passed at this time.

Template version:  (RFC 4858)  2/24/2012: 
Status: Send to AD
Nits:  indication of pre-RFC5378 work seems to be error in general XML. 
          Aid sought to fix.  Revision -06 will fix this plus ephemeral-state update

(1) What type of RFC: Standard. 
  Why? Yang data model

(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 data model for layer 3 network  topologies.

Working Group Summary
https://www.ietf.org/mail-archive/web/i2rs/current/msg04009.html
Clear consensus.  Talk about for over a year so the last discussion just has "ship it". 

Document Quality
The data model has been implemented in the open Daylight.  Used as part of their network.  People are planning to pick up the implementation from ODL.  Vendors planning implementations included:  Packet Design (client), Huawei, and Cisco.

Reviewers:

Routing directorate review: Tony Przygienda
https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02912.html

Yang doctors: Carl Moberg
https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00031.html6

Personnel
Document Shepherd: Susan Hares
WG chairs: Susan Hares and Russ White
Responsible AD: Alia Atlas
OPS AD for Yang: Benoit Claise
RTG-DIR reviewer: Tony Przygienda
Yang-Doctors reviewer:  Carl Moberg
OPS-DIR Reviewer: TBD
SEC-DIR Reviewer: TBD

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


Nits errors:
1) pre-RFC5378 work - error in general template
2) XML2RFC errors mis-identify errors (223, 249, 253, 262, 692) due to ascii figures.
3) Delay in posting (due to shepherd's illness (11/19-11/28).

Interaction with other Yang models:
-------------------------------------------
This is a protocol independent yang model with topology information by design it does not link to the following configuration models; 
2)  ietf-interfaces model [RFC7223]
3)  ietf-routing yang model [RFC8022] 
4)  OSPF configuration yang module ( ietf-ospf or the ospf bfd) [draft-ietf-ospf-yang]
5) ISIS configuration yang module (idraft-ietf-isis-yang-isis-cfg)
6) I2RS RIB (ephemeral state RIB) or configuration extended RIB  ( draft-acee-rtgwg-yang-rib-extend)

It does important OSPF, ISIS, and statically configured topology information into the model without linking to these models. 

Why this is useful in ephemeral state:  The approach to not link to any configuration model but to let topology process load information from OSPF into the data model means that there is no model link between configuration state and topology.  The assumption is the routing process uploading the topology model knows how to do this.  The NETCONF or RESTCONF processes simply reads, reports notifications, and logs the data.

Writes from ephemeral state to the data models: These data models allow the the NETCCONF/RESTCONF process to write a logical topology link.  Exactly how this write operates depends on the routing process.  This model obeys the requirements for the ephemeral state found in the document draft-ietf-i2rs-ephemeral-state. 

Is this ephemeral state + topology independent approach reasonable:
The ODL implementation and TEAS (traffic engineeering) have OKed this approach.  The IESG in its review of draft-ietf-i2rs-yang-network-topo and this document should review this approach for the independent data models.  There is support for this approach in TEAS and I2RS, and other models have found this approach useful.

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

All reviewers (RTG-DIR, Yang Doctors, shepherd) have been top quality.
Normal OPS-DIR and Security review should be done on the yang model.

The IESG should consider the protocol independent model has no links to configuration model, and operates under the ephemeral state requirements.  See comments in section 3 from shepherd.

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

A routing yang model needs RTG-DIR, Yang-doctors, OPS-DIR, and security directorate.
RTG-DIR and Yang Doctors is done.  OPS-DIR and SEC-DIR should be done as part of IETF LC process. 

(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 implementations and wide-spread vendor support.  It is key for other topology yang models. 

On the wide-spread interaction - please review the above comments on interaction with other yang models. This is the first of the protocol independent yang modules from I2RS that adhere to the ephemeral state requirements.  The ephemeral state requirements have been discussed by I2RS for 5 years, and for the I2RS-NETCONF/NETMOD for 2 years.  Please note that ephemeral state and OPSTATE are not aligned.  The agreement with the NETMOD chairs was to finish the OPSTATE work without ephemeral state and then to add ephemeral state.

The topology model has no links to the configuration state except in the routing process.  This approach minimizes the interaction with OPSTATE issues or real code.  Once the OPSTATE work has completed, then this document can be updated to align with the IETF conceptual comments. It is doubtful this conceptual change will alter the code.

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

IPR call was missed during WG LC .  Call done on 11/11/2016.
https://mailarchive.ietf.org/arch/msg/i2rs/icWr3JeW0OCzgkRMPY75sxWcQd0

Alex Clemm IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04089.html

Xufeng Liu IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04094.html

Jan Medved IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04102.html

Nitin Bahadur IPR
https://www.ietf.org/mail-archive/web/i2rs/current/msg04105.html

Hariharan Ananthakrishnan
https://www.ietf.org/mail-archive/web/i2rs/current/msg04097.html

Robert Varga:
https://www.ietf.org/mail-archive/web/i2rs/current/msg04106.html

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

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

Solid with lots of discussion.  Model desired by other WGs as base model.  ODL implementations for 2 years.

(10) 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 appeals.  Everyone in the WG and in the NETCONF/NETMOD, and Benoit Claise wants draft shipped.

(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 errors:
1) pre-RFC5378 work - error in general template
2) XML2RFC errors mis-identify errors (223, 249, 253, 262, 692) due to ascii figures.
3) Delay in posting (due to shepherd's illness (11/19-11/27)

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

1) Automatic check of yang modules. 
2) RTG-DIR and Yang Doctor's review done.
3) Shepherd check the high-logic against the routing-configuration, OPSTATE, and ephemeral state requirements

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

[NITS fixes must be done for this text to be accurate ]
  yes.  One non-rfc draft (  [I-D.draft-ietf-i2rs-yang-network-topo]) is being forwarded with this document as a document group.

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

  [I-D.draft-ietf-i2rs-yang-network-topo] - is being forwarded at the same time
All other normative references exist.

(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 changes to existing RFCs. This is 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).

IANA section was left out.  As soon as new IANA section is writtten, it will be sent to IANA for pre-review.

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

Yang has automated checks on the yang text prior to submission.
All passed at this time.

Request for posting confirmation emailed to previous authors: "Igor Bryskin" , "Alexander Clemm" , "Nitin Bahadur" , "Tony Tkacik" , "Jan Medved" , "Xufeng Liu" , i2rs-chairs@ietf.org, "Robert Varga" , "Hariharan Ananthakrishnan" , "Aihua Guo" , "Vishnu Beeram"

Request for posting confirmation emailed to previous authors: "Igor Bryskin" , "Nitin Bahadur" , "Tony Tkacik" , "Jan Medved" , "Xufeng Liu" , i2rs-chairs@ietf.org, "Robert Varga" , "Hariharan Ananthakrishnan" , "Vishnu Pavan Beeram" , "Alex Clemm" , "Aihua Guo"