A YANG Data Model for Network Topologies
RFC 8345

Received changes through RFC Editor sync (created alias RFC 8345, changed title to 'A YANG Data Model for Network Topologies', changed abstract to 'This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories.  The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.', changed pages to 57, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-03-16, changed IESG state to RFC Published)

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 comment]
Regarding the version 18, please engage in the discussion with Qin Wu (OPS DIR reviewer). He has some good questions.

Below is my feedback on version 16, which has not been addressed.

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

    The data model obeys the requirements for the ephemeral state found
      in the document [I-D.draft-ietf-i2rs-ephemeral-state].  For ephemeral
      topology data that is system controlled, the process tasked with
      maintaining topology information will load information from the
      routing process (such as OSPF) into the  without relying
      on a configuration datastore.

    =>  operational state datastore,
    according to https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/

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

The IANA Services Operator has completed its review of draft-ietf-i2rs-yang-network-topo-18. 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/

four new registrations are to be made:

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

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

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

ID: yang:ietf-network-topology-state
URI: urn:ietf:params:xml:ns:yang:ietf-network-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 is 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/

four new YANG Modules are to be registered:

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

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

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

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

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

The IANA Services Operator understands that these two actions are the only ones 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: i2rs@ietf.org, Susan Hares , draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, akatlas@gmail.com, shares@ndzh.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Data Model for Network 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 Data Model for Network
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 an abstract (generic) YANG data model for
  network/service topologies and inventories.  The data model serves as
  a base model which is augmented with technology-specific details in
  other, more specific topology and inventory data models.




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

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


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

Template date: 2/24/2012
status date: 11/11/2017:

(1) 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 an abstract (generic) YANG data model for
  network/service topologies and inventories.  The model serves as a
  base model which is augmented with technology-specific details in
  other, more specific topology and inventory models.

Working Group Summary

Working Group has talked about this for 3 years.
Final discussion - was ship it.
https://www.ietf.org/mail-archive/web/i2rs/current/msg04009.html

Document Quality
  Are there existing implementations of the protocol?
  ODL implementation has existed for over 2 years
  Vendors planning to implement: Cisco, Ericsson, Huawei, Packet Design, Juniper, some Data Center
  RTG-DIR:

  Yang doctors review: by Kent Watsen:
  https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html
  https://mailarchive.ietf.org/arch/msg/yang-doctors/LJKO3wVjbD_cFSYsAeYNTrx9U64


  Routing-Directorate:  by Ines Robles
  https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02913.html
    https://mailarchive.ietf.org/arch/msg/rtg-dir/FZHolhPKIJeJHAlI0JQzeTGtk10

  GEN-ART: Stewart Bryant
    https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-network-topo-14-genart-lc-bryant-2017-07-25/

  IPR call
    https://mailarchive.ietf.org/arch/msg/i2rs/gzC5-AXJI-YuttTP9ZCON3UMCLs

Nits:
    1) XML2RFC - template has pre- pre-RFC5378 work - need guidance how to fix

Personnel
  Document Shepherd/WG Chair:
  Responsible AD: Alia Atlas
  NM AD for Yang: Benoit Claise
Yang doctors review: Kent Watsen:
Routing-Directorate:  by Ines Robles
GEN-ART: Stewart Bryant


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

Shepherd did: NITS, IPR check, IANA check, RFC 2119 change, check for interaction with other documents.
Shepherd resolved all comments, discussed repeated, debated.

This model is both capable for NMDA.  It can be deployed in ephemeral datastore or configuration datastore.
It is created with an awareness of TEAS.     

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

RTG-DIR Review: Ines Robles
https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02913.html

Yang Doctor's review: Kent Watsen
https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html

OPS-DIR and SEC-DIR should review this model in the normal course of IETF-LC

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

Yang Doctors (already done), RTG-DIR (already done),
OPS-DIR, SEC-DIR, GEN-ART (already done).

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

NMDA model - allowed to be used in config or dynamic datastore.
Designed for ephmeral 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.

IPR call
https://www.ietf.org/mail-archive/web/i2rs/current/msg04088.html

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

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

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

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

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

Xufeng Liu:
https://www.ietf.org/mail-archive/web/i2rs/current/msg04094.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 IPR filed on the draft.


(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 discussion for 3+ years.  The IETF has exhausted the I2RS group
as it pushed the NMDA architecture along before this model.
The victory of finally getting all this work done is sweet to the WG and the WG chair.

This is a critical model for yang models.

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

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

No real ones.  Yang validates.  The nits tool needs to be fixed.

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

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?

All normative references are valid.

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

None

(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 change to existing status.  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 needs to be fixed.  Once it is fixed, an early IANA review will be requested.

(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 registry added in this document.

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

Check on the Yang is automated at submission. 

Template date: 2/24/2012
status date: 11/11/2017:

(1) 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 an abstract (generic) YANG data model for
  network/service topologies and inventories.  The model serves as a
  base model which is augmented with technology-specific details in
  other, more specific topology and inventory models.

Working Group Summary

Working Group has talked about this for 3 years.
Final discussion - was ship it.
https://www.ietf.org/mail-archive/web/i2rs/current/msg04009.html

Document Quality
  Are there existing implementations of the protocol?
  ODL implementation has existed for over 2 years
  Vendors planning to implement: Cisco, Ericsson, Huawei, Packet Design, Juniper, some Data Center
  RTG-DIR:

  Yang doctors review: by Kent Watsen:
  https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html
  https://mailarchive.ietf.org/arch/msg/yang-doctors/LJKO3wVjbD_cFSYsAeYNTrx9U64


  Routing-Directorate:  by Ines Robles
  https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02913.html
    https://mailarchive.ietf.org/arch/msg/rtg-dir/FZHolhPKIJeJHAlI0JQzeTGtk10

  GEN-ART: Stewart Bryant
    https://datatracker.ietf.org/doc/review-ietf-i2rs-yang-network-topo-14-genart-lc-bryant-2017-07-25/

  IPR call
    https://mailarchive.ietf.org/arch/msg/i2rs/gzC5-AXJI-YuttTP9ZCON3UMCLs

Nits:
    1) XML2RFC - template has pre- pre-RFC5378 work - need guidance how to fix

Personnel
  Document Shepherd/WG Chair:
  Responsible AD: Alia Atlas
  NM AD for Yang: Benoit Claise
Yang doctors review: Kent Watsen:
Routing-Directorate:  by Ines Robles
GEN-ART: Stewart Bryant


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

Shepherd did: NITS, IPR check, IANA check, RFC 2119 change, check for interaction with other documents.
Shepherd resolved all comments, discussed repeated, debated.

This model is both capable for NMDA.  It can be deployed in ephemeral datastore or configuration datastore.
It is created with an awareness of TEAS.     

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

RTG-DIR Review: Ines Robles
https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02913.html

Yang Doctor's review: Kent Watsen
https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html

OPS-DIR and SEC-DIR should review this model in the normal course of IETF-LC

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

Yang Doctors (already done), RTG-DIR (already done),
OPS-DIR, SEC-DIR, GEN-ART (already done).

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

NMDA model - allowed to be used in config or dynamic datastore.
Designed for ephmeral 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.

IPR call
https://www.ietf.org/mail-archive/web/i2rs/current/msg04088.html

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

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

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

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

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

Xufeng Liu:
https://www.ietf.org/mail-archive/web/i2rs/current/msg04094.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 IPR filed on the draft.


(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 discussion for 3+ years.  The IETF has exhausted the I2RS group
as it pushed the NMDA architecture along before this model.
The victory of finally getting all this work done is sweet to the WG and the WG chair.

This is a critical model for yang models.

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

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

No real ones.  Yang validates.  The nits tool needs to be fixed.

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

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?

All normative references are valid.

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

None

(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 change to existing status.  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 needs to be fixed.  Once it is fixed, an early IANA review will be requested.

(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 registry added in this document.

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

Check on the Yang is automated at submission. 

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

Template date: 2/24/2012
status date: 11/11/2017:

(1) 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 an abstract (generic) YANG data model for
  network/service topologies and inventories.  The model serves as a
  base model which is augmented with technology-specific details in
  other, more specific topology and inventory models.

Working Group Summary

Working Group has talked about this for 3 years.
Final discussion - was ship it.
https://www.ietf.org/mail-archive/web/i2rs/current/msg04009.html

Document Quality
  Are there existing implementations of the protocol?
  ODL implementation has existed for over 2 years
  Vendors planning to implement: Cisco, Ericsson, Huawei, Packet Design, Juniper, some Data Center
  RTG-DIR review:

  Yang doctors review: by Kent Watsen:
  https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html

  Routing-Directorate:  by Ines Robles
  https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02913.html

  IPR call
    https://mailarchive.ietf.org/arch/msg/i2rs/gzC5-AXJI-YuttTP9ZCON3UMCLs

Nits:
    1) XML2RFC - template has pre- pre-RFC5378 work - need guidance how to fix

Personnel
  Document Shepherd:
  Responsible AD: Alia Atlas
  NM AD for Yang: Benoit Claise
Yang doctors review: Kent Watsen:
Routing-Directorate:  by Ines Robles
OPS-DIR: (during IETF LC):
SEC-DIR: (during IETF LC):

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

Shepherd did: NITS, IPR check, IANA check, RFC 2119 change, check for interaction with other documents.

[Shepherd's things that must be resolved]
      1) IPR call (not completed during WG LC)
    https://mailarchive.ietf.org/arch/msg/i2rs/gzC5-AXJI-YuttTP9ZCON3UMCLs
 


   

----- more comments on #5
#5 - Add interaction section with the following information:

Review of links to other yang models:
1) links to ietf-yang-types [rfc6991, ietf-inet-types [RFC6991]
2) links to topology model - ietf-network, ietf-network-topology - (draft-ietf-i2rs-yang-network-topo-06)

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] 
6) I2RS RIB (ephemeral state RIB) or configuration extended RIB  ( draft-acee-rtgwg-yang-rib-extend)

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?

RTG-DIR Review: Ines Robles
https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02913.html

Yang Doctor's review: Kent Watsen
https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html

OPS-DIR and SEC-DIR should review this model in the normal course of IETF-LC

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

See comments about I2RS topology independent drafts and ephemeral state above.

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

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
https://www.ietf.org/mail-archive/web/i2rs/current/msg04088.html

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

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

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

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

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

Xufeng Liu:
https://www.ietf.org/mail-archive/web/i2rs/current/msg04094.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 IPR filed on the draft.


(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 discussion for 2 years.  Do to the delay with the requirements - WG response to last call was light.  Benoit suggests it is a key data model.

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

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

1) Line 250 - notification is error in XML2RFC
2) pre-2780 - is problemn with XML2RFC template, seeking help for revision of template.
3) draft-ietf-i2rs-ephemeral-state-22 - reference is back-dated - will be fixed in update of template.

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

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?

All normative references are valid.

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

refers to draft-ietf-i2rs-ephemeral-state-22.txt
(current version is -23.txt) which is at IESG review. 

(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 change to existing status.  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 needs to be fixed.  Once it is fixed, an early IANA review will be requested.

(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 registry added in this document.

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

Check on the Yang is automated at submission. 

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]
Preliminary note: I hope I'm doing the right thing by updating my ballot as  I understand that the document is back to the WG. However, since I reviewed the versions 15 and 16, since some of my ballot points have been addressed (thank you), and since I wanted to share my feedback publicly, here is my feedback.
Editorial:

    The data model obeys the requirements for the ephemeral state found
      in the document [I-D.draft-ietf-i2rs-ephemeral-state].  For ephemeral
      topology data that is system controlled, the process tasked with
      maintaining topology information will load information from the
      routing process (such as OSPF) into the  without relying
      on a configuration datastore.

    =>  operational state datastore,
    according to https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/

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 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 15, since some of my ballot points have been addressed (thank you), and since I wanted to share my feedback publicly, here is my feedback.

Please follow the YANG security guidelines template at https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

        There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:

       

        -- for all YANG modules you must evaluate whether any readable data -- nodes (those are all the "config false" nodes, but also all other -- nodes, because they can also be read via operations like get or -- get-config) are sensitive or vulnerable (for instance, if they -- might reveal customer information or violate personal privacy -- laws such as those of the European Union if exposed to -- unauthorized parties)

        Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:

       

        -- if your YANG module has defined any rpc operations -- describe their specific sensitivity or vulnerability.

        Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability:

       

I don't understand why the security considerations section of a YANG module document speaks about this:

    Rules expressed in NACM can be applied analogously also to other
      protocols that attempt access to YANG-defined data.  In fact, it
      needs to be applied in the same way and should, like YANG, thus be
      considered independent of any particular protocol that is used to
      access YANG-defined data.  Otherwise, access control rules defined by
      NACM could be very easily circumvented simply by using another access
      mechanism which does not enforce NACM.  The alternative of mandating
      the introduction of mechanisms parallel to NACM that specify the same
      access control rules for other transports is clearly undesirable, as
      this would not only inhibit ease-of-use of systems that implement
      multiple protocols to access YANG data, but also open the specter of
      security holes due to inconsistencies in articulation and enforcement
      of rules across mechanisms that are essentially redundant.

This is even confusing to speak about other protocols before/without specifying those protocols.
You should remove this.


OLD DISCUSS, FOR INFORMATION ONLY:
To make sure both draft-ietf-i2rs-yang-network-topo and draft-ietf-i2rs-yang-l3-topology are treated the same way, here is my DISCUSS.
As background, email sent to I2RS/IESG on Jan 24th 2017

Let me repeat what I mentioned already on the I2RS mailing list:

    This document contains a YANG model, a generic YANG model that could be accessed by NETCONF, RESTCONF, or the future I2RS protocol.
    This document doesn't say (and that would be a mistake IMO if it would) that this YANG model can only be accessed by the I2RS protocol.
    Hence I'm advocating that the security considerations diligently follow https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they don't go in the I2RS protocol specific details.

This comment was made for draft-ietf-i2rs-yang-network-topo, but is equally applicable to this draft-ietf-i2rs-yang-l3-topology draft.
I still maintain this point of view: it would be a mistake to limit a data model usage to a particular protocol. These topology documents are not I2RS YANG models, these are YANG models, which can be used in different contexts. I'm very concerned if we start having per-WG or per context data models in the IETF.
Btw, I haven't seen a RFC specifying what the I2RS protocol is, only the requirements.
We can't modify the current generic YANG security considerations for an I2RS control plane and a new datastore that are not yet specified. If you want to describe how I2RS will be using those topology YANG models (and any YANG models btw), then it's suitable to include this part of the I2RS protocol spec or part of an I2RS applicability statement. This is typically where you would describe some protocol specific information such as "write contention for two clients writing a node using I2RS priority (linked to I2RS User-ID)".

Let me make my point differently. Let's assume for a moment that I2RS needs to use the IETF interface YANG model, does it mean that you will require RFC 7223bis with an updated security considerations? This can't be.

I still think the generic YANG security guidelines is suitable, as it relates to IETF specified protocols NETCONF and RESTCONF. Addition of some generic information about the data model (not I2RS protocol) might be useful though. For example, text around "there is a risk that a write to a topology may create a looping topology or overload a particular node". Note that I don't think the the security considerations is the best section for this though.

Regards, Benoit

[Ballot comment]
Editorial:

    The data model obeys the requirements for the ephemeral state found
      in the document [I-D.draft-ietf-i2rs-ephemeral-state].  For ephemeral
      topology data that is system controlled, the process tasked with
      maintaining topology information will load information from the
      routing process (such as OSPF) into the  without relying
      on a configuration datastore.

    =>  operational state datastore,
    according to https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/

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

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

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]
To make sure both draft-ietf-i2rs-yang-network-topo and draft-ietf-i2rs-yang-l3-topology are treated the same way, here is my DISCUSS.
As background, email sent to I2RS/IESG on Jan 24th 2017

Let me repeat what I mentioned already on the I2RS mailing list:

    This document contains a YANG model, a generic YANG model that could be accessed by NETCONF, RESTCONF, or the future I2RS protocol.
    This document doesn't say (and that would be a mistake IMO if it would) that this YANG model can only be accessed by the I2RS protocol.
    Hence I'm advocating that the security considerations diligently follow https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they don't go in the I2RS protocol specific details.

This comment was made for draft-ietf-i2rs-yang-network-topo, but is equally applicable to this draft-ietf-i2rs-yang-l3-topology draft.
I still maintain this point of view: it would be a mistake to limit a data model usage to a particular protocol. These topology documents are not I2RS YANG models, these are YANG models, which can be used in different contexts. I'm very concerned if we start having per-WG or per context data models in the IETF.
Btw, I haven't seen a RFC specifying what the I2RS protocol is, only the requirements.
We can't modify the current generic YANG security considerations for an I2RS control plane and a new datastore that are not yet specified. If you want to describe how I2RS will be using those topology YANG models (and any YANG models btw), then it's suitable to include this part of the I2RS protocol spec or part of an I2RS applicability statement. This is typically where you would describe some protocol specific information such as "write contention for two clients writing a node using I2RS priority (linked to I2RS User-ID)".

Let me make my point differently. Let's assume for a moment that I2RS needs to use the IETF interface YANG model, does it mean that you will require RFC 7223bis with an updated security considerations? This can't be.

I still think the generic YANG security guidelines is suitable, as it relates to IETF specified protocols NETCONF and RESTCONF. Addition of some generic information about the data model (not I2RS protocol) might be useful though. For example, text around "there is a risk that a write to a topology may create a looping topology or overload a particular node". Note that I don't think the the security considerations is the best section for this though.

Regards, Benoit

[Ballot comment]
I agree with Kathleen's comments and always find it helpful when the security considerations templates are used in YANG documents as Juergen and Benoit suggested.

= Section 3 =

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

= Section 6.1 =

"leaf server-provided {
          type boolean;
          config false;
          description
            "Indicates whether the information concerning this
              particular network is populated by the server
              (server-provided true, the general case for network
              information discovered from the server),
              or whether it is configured by a client
              (server-provided true, possible e.g. for
              service overlays managed through a controller)."

I think the second instance of "server-provided true" is actually supposed to say "server-provided false," right?

[Ballot comment]

I agree with Kathleen's discuss points and have one
more aspect to offer that I hope you include in that
discussion:

This model I think will lead designers to only think
about the nodes that are supposed to have access to
traffic.  (See also below about broadcast media.) The
model will generally not capture the reality that some
other nodes can also actually see or influence traffic
and I think that will lead to vulnerabilities not
being recognised. I don't have a good suggestion for
how to fix that problem but I do think you ought
mention it as a security consideration, e.g. something
like: "For models such as these - the real world
network may allow additional communications or links
that are not represented in the model and such links
may enable vulnerabilities that are liable to be
missed when considering only the model. These models
don't really capture the security or privacy aspects
of the network."

- 4.2 and generally: It is not clear to me how to
represent broadcast media (e.g. radio) nor how IP
multicast would be reflected in this model. I assume
those can be done but as a bit of a hack. 

- nit: 6 authors and 4 contributors. I wish people
(esp chairs) would just enforce the 5 author guideline
and say why that's inappropriate in the few instances
in which that is the case.

[Ballot comment]
Reading this document one more time, some more editorial comment
-

OLD:
  At the same time, where data specific to a network type does comes
  into play

NEW:
  At the same time, where data specific to a network type does come
  into play

- The figure shows two Service Functions - X1 and X2 - mapping onto a
  single L3 network element; this could happen, for example, if two
  service functions reside in the same VM (or server) and share the
  same set of network interfaces.

You meant X1 and X3, mapping to the same Y2 L3 network element, right?

- please expand ROADM

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

- 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]

- OLD:
  The abstract (base) network model is defined in the network.yang
  module.  Its structure is shown in the following figure.  Brackets
  enclose list keys, "rw" means configuration data, "ro" means
  operational state data, and "?" designates optional nodes.  A "+"
  indicates a line break.

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

Note that you have two instances of this.

- Final comment: the security considerations should be better aligned with https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as replied to Kathleen's DISCUSS.

[Ballot discuss]
Thanks for your work on this draft.

I have a couple of things I'd like to discuss that may require some additional text, but should be easy to resolve.

1. Privacy considerations - I don't see any listed and the YANG module include a few identifiers as well as ways to group devices.  I think privacy considerations need to be added for use of this module.

2. Security - the network topology and inventory created by this module reveals information about systems and services.  This could be very helpful information to an attacker and should also be called out as a security consideration. The access and transport of this information is covered though in the considerations, just listing this threat would be helpful.

Thank you.

[Ballot comment]
Just a nit:  Several places in the text make reference to the network.yang or network-topology.yang models.  It would be nice to put a reference to the section where there are defined.

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

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

The IANA Services Operator has completed its review of draft-ietf-i2rs-yang-network-topo-09.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/

two new URIs are to be registered as follows:

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

ID: yang:ietf-topology
URI: urn:ietf:params:xml:ns:yang:ietf-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/

two new module names are to be registered as follows:

Name: ietf-network
Namespace: urn:ietf:params:xml:ns:yang:ietf-network
Prefix: nd
Module:
Reference: [ RFC-to-be ]

Name: ietf-network-topology
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology
Prefix: lnk
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: i2rs@ietf.org, "Susan Hares" , draft-ietf-i2rs-yang-network-topo@ietf.org, i2rs-chairs@ietf.org, akatlas@gmail.com, shares@ndzh.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Data Model for Network 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 Data Model for Network 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 2016-12-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines an abstract (generic) YANG data model for
  network/service topologies and inventories.  The model serves as a
  base model which is augmented with technology-specific details in
  other, more specific topology and inventory models.




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

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


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

AD review comments:

1) Section 5 mentions I-D.draft-acee-rtgwg-yang-rib-extend.  Since this is an individual draft, it's probably better not to include it as a reference.

2) On p. 25-26, in list link description:  "Layering dependencies on links in underlay topologies are
          not represented, as the layering information of nodes and of
          termination points is sufficient."  This seems to contradict earlier text and the exice of the list supporting link that is immediately after.  Could you please clean up or clarify?

Template date: 2/24/2012
Status:  missing IPR from Robert Varga and Igor Bryskin - planned to instruct lead author (Alex Clemm) to remove these 2 authors if they do not respond by the time you finsih editing.

(1) 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 an abstract (generic) YANG data model for
  network/service topologies and inventories.  The model serves as a
  base model which is augmented with technology-specific details in
  other, more specific topology and inventory models.

Working Group Summary

Working Group has talked about this for 2 years.
Final discussion - was ship it.
https://www.ietf.org/mail-archive/web/i2rs/current/msg04009.html

Document Quality
  Are there existing implementations of the protocol?
  ODL implementation has existed for over 2 years
  Vendors planning to implement: Cisco, Ericsson, Huawei, Packet Design, Juniper, some Data Center
  RTG-DIR review:

  Yang doctors review: by Kent Watsen:
  https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html

  Routing-Directorate:  by Ines Robles
  https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02913.html

  IPR call
    https://mailarchive.ietf.org/arch/msg/i2rs/gzC5-AXJI-YuttTP9ZCON3UMCLs

Nits:
    1) XML2RFC - template has pre- pre-RFC5378 work - need guidance how to fix

Personnel
  Document Shepherd:
  Responsible AD: Alia Atlas
  NM AD for Yang: Benoit Claise
Yang doctors review: Kent Watsen:
Routing-Directorate:  by Ines Robles
OPS-DIR: (during IETF LC):
SEC-DIR: (during IETF LC):

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

Shepherd did: NITS, IPR check, IANA check, RFC 2119 change, check for interaction with other documents.

[Shepherd's things that must be resolved]
      1) IPR call (not completed during WG LC)
    https://mailarchive.ietf.org/arch/msg/i2rs/gzC5-AXJI-YuttTP9ZCON3UMCLs
 


   

----- more comments on #5
#5 - Add interaction section with the following information:

Review of links to other yang models:
1) links to ietf-yang-types [rfc6991, ietf-inet-types [RFC6991]
2) links to topology model - ietf-network, ietf-network-topology - (draft-ietf-i2rs-yang-network-topo-06)

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] 
6) I2RS RIB (ephemeral state RIB) or configuration extended RIB  ( draft-acee-rtgwg-yang-rib-extend)

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?

RTG-DIR Review: Ines Robles
https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02913.html

Yang Doctor's review: Kent Watsen
https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html

OPS-DIR and SEC-DIR should review this model in the normal course of IETF-LC

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

See comments about I2RS topology independent drafts and ephemeral state above.

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

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
https://www.ietf.org/mail-archive/web/i2rs/current/msg04088.html

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

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

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

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

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

Xufeng Liu:
https://www.ietf.org/mail-archive/web/i2rs/current/msg04094.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 IPR filed on the draft.


(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 discussion for 2 years.  Do to the delay with the requirements - WG response to last call was light.  Benoit suggests it is a key data model.

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

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

1) Line 250 - notification is error in XML2RFC
2) pre-2780 - is problemn with XML2RFC template, seeking help for revision of template.
3) draft-ietf-i2rs-ephemeral-state-22 - reference is back-dated - will be fixed in update of template.

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

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?

All normative references are valid.

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

refers to draft-ietf-i2rs-ephemeral-state-22.txt
(current version is -23.txt) which is at IESG review. 

(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 change to existing status.  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 needs to be fixed.  Once it is fixed, an early IANA review will be requested.

(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 registry added in this document.

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

Check on the Yang is automated at submission. 

Template date: 2/24/2012
Status:  missing IPR from Robert Varga and Igor Bryskin - planned to instruct lead author (Alex Clemm) to remove these 2 authors if they do not respond by the time you finsih editing.

(1) 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 an abstract (generic) YANG data model for
  network/service topologies and inventories.  The model serves as a
  base model which is augmented with technology-specific details in
  other, more specific topology and inventory models.

Working Group Summary

Working Group has talked about this for 2 years.
Final discussion - was ship it.
https://www.ietf.org/mail-archive/web/i2rs/current/msg04009.html

Document Quality
  Are there existing implementations of the protocol?
  ODL implementation has existed for over 2 years
  Vendors planning to implement: Cisco, Ericsson, Huawei, Packet Design, Juniper, some Data Center
  RTG-DIR review:

  Yang doctors review: by Kent Watsen:
  https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html

  Routing-Directorate:  by Ines Robles
  https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02913.html

  IPR call
    https://mailarchive.ietf.org/arch/msg/i2rs/gzC5-AXJI-YuttTP9ZCON3UMCLs

Nits:
    1) XML2RFC - template has pre- pre-RFC5378 work - need guidance how to fix

Personnel
  Document Shepherd:
  Responsible AD: Alia Atlas
  NM AD for Yang: Benoit Claise
Yang doctors review: Kent Watsen:
Routing-Directorate:  by Ines Robles
OPS-DIR: (during IETF LC):
SEC-DIR: (during IETF LC):

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

Shepherd did: NITS, IPR check, IANA check, RFC 2119 change, check for interaction with other documents.

[Shepherd's things that must be resolved]
      1) IPR call (not completed during WG LC)
    https://mailarchive.ietf.org/arch/msg/i2rs/gzC5-AXJI-YuttTP9ZCON3UMCLs
 


   

----- more comments on #5
#5 - Add interaction section with the following information:

Review of links to other yang models:
1) links to ietf-yang-types [rfc6991, ietf-inet-types [RFC6991]
2) links to topology model - ietf-network, ietf-network-topology - (draft-ietf-i2rs-yang-network-topo-06)

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] 
6) I2RS RIB (ephemeral state RIB) or configuration extended RIB  ( draft-acee-rtgwg-yang-rib-extend)

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?

RTG-DIR Review: Ines Robles
https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02913.html

Yang Doctor's review: Kent Watsen
https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00032.html

OPS-DIR and SEC-DIR should review this model in the normal course of IETF-LC

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

See comments about I2RS topology independent drafts and ephemeral state above.

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

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
https://mailarchive.ietf.org/arch/msg/i2rs/gzC5-AXJI-YuttTP9ZCON3UMCLs

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

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

Robert Varga
missing IPR

Igor Bryskin
(will remove if no response by time the AD reviews document)

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

Nitin Bahadur
(will remove as author if no response by time AD reviews document)

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

Xufeng Liu:
https://www.ietf.org/mail-archive/web/i2rs/current/msg04098.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 IPR filed on the draft.


(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 discussion for 2 years.  Do to the delay with the requirements - WG response to last call was light.  Benoit suggests it is a key data model.

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

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

1) Line 250 - notification is error in XML2RFC
2) pre-2780 - is problemn with XML2RFC template, seeking help for revision of template.
3) draft-ietf-i2rs-ephemeral-state-22 - reference is back-dated - will be fixed in update of template.

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

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?

All normative references are valid.

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

refers to draft-ietf-i2rs-ephemeral-state-22.txt
(current version is -23.txt) which is at IESG review. 

(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 change to existing status.  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 needs to be fixed.  Once it is fixed, an early IANA review will be requested.

(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 registry added in this document.

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

Check on the Yang is automated at submission. 

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

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