--- 1/draft-ietf-ospf-yang-13.txt 2018-08-28 10:13:11.691014359 -0700 +++ 2/draft-ietf-ospf-yang-14.txt 2018-08-28 10:13:11.879018912 -0700 @@ -1,122 +1,131 @@ Internet D. Yeung Internet-Draft Arrcus Intended status: Standards Track Y. Qu -Expires: January 27, 2019 Huawei +Expires: March 1, 2019 Huawei J. Zhang Juniper Networks I. Chen Jabil A. Lindem Cisco Systems - July 26, 2018 + August 28, 2018 Yang Data Model for OSPF Protocol - draft-ietf-ospf-yang-13 + draft-ietf-ospf-yang-14 Abstract This document defines a YANG data model that can be used to configure - and manage OSPF. + and manage OSPF. The model is based on YANG 1.1 as defined in RFC + 7950 and conforms to the Network Management Datastore Architecture + (NDMA) as described in RFC 8342. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 27, 2019. + This Internet-Draft will expire on March 1, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 2. Design of Data Model . . . . . . . . . . . . . . . . . . . . 3 2.1. OSPF Operational State . . . . . . . . . . . . . . . . . 3 - 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. OSPFv2 and OSPFv3 . . . . . . . . . . . . . . . . . . . . 5 2.4. Optional Features . . . . . . . . . . . . . . . . . . . . 5 - 2.5. OSPF Router Configuration/Operational State . . . . . . . 5 - 2.6. OSPF Area Configuration/Operational State . . . . . . . . 8 - 2.7. OSPF Interface Configuration/Operational State . . . . . 13 - 2.8. OSPF notification . . . . . . . . . . . . . . . . . . . . 16 - 2.9. OSPF RPC Operations . . . . . . . . . . . . . . . . . . . 19 - 3. OSPF Yang Module . . . . . . . . . . . . . . . . . . . . . . 20 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 104 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 106 - 7. Normative References . . . . . . . . . . . . . . . . . . . . 106 - Appendix A. Contributors' Addreses . . . . . . . . . . . . . . . 112 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 112 + 2.5. OSPF Router Configuration/Operational State . . . . . . . 7 + 2.6. OSPF Area Configuration/Operational State . . . . . . . . 10 + 2.7. OSPF Interface Configuration/Operational State . . . . . 15 + 2.8. OSPF notification . . . . . . . . . . . . . . . . . . . . 17 + 2.9. OSPF RPC Operations . . . . . . . . . . . . . . . . . . . 21 + 3. OSPF Yang Module . . . . . . . . . . . . . . . . . . . . . . 22 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 106 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 107 + 7. Normative References . . . . . . . . . . . . . . . . . . . . 108 + Appendix A. Contributors' Addreses . . . . . . . . . . . . . . . 114 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114 1. Overview - YANG [RFC6020] is a data definition language used to define the - contents of a conceptual data store that allows networked devices to - be managed using NETCONF [RFC6241]. YANG is proving relevant beyond - its initial confines, as bindings to other interfaces (e.g., ReST) - and encodings other than XML (e.g., JSON) are being defined. + YANG [RFC6020][RFC7950] is a data definition language used to define + the contents of a conceptual data store that allows networked devices + to be managed using NETCONF [RFC6241]. YANG is proving relevant + beyond its initial confines, as bindings to other interfaces (e.g., + ReST) and encodings other than XML (e.g., JSON) are being defined. Furthermore, YANG data models can be used as the basis for implementation of other interfaces, such as CLI and programmatic APIs. This document defines a YANG data model that can be used to configure and manage OSPF and it is an augmentation to the core routing data - model. A core routing data model is defined in [RFC8349], and it - provides the basis for the development of data models for routing - protocols. The interface data model is defined in [RFC8343] and is - used for referencing interfaces from the routing protocol. The key- - chain data model used for OSPF authentication is defined in [RFC8177] - and provides both a reference to configured key-chains and an - enumeration of cryptographic algorithms. + model. If fully conforms to the Network Management Datastore + Architecture (NDMA) [RFC8342]. A core routing data model is defined + in [RFC8349], and it provides the basis for the development of data + models for routing protocols. The interface data model is defined in + [RFC8343] and is used for referencing interfaces from the routing + protocol. The key-chain data model used for OSPF authentication is + defined in [RFC8177] and provides both a reference to configured key- + chains and an enumeration of cryptographic algorithms. Both OSPFv2 [RFC2328] and OSPFv3 [RFC5340] are supported. In addition to the core OSPF protocol, features described in other OSPF RFCs are also supported. These includes demand circuit [RFC1793], traffic engineering [RFC3630], multiple address family [RFC5838], graceful restart [RFC3623] [RFC5187], NSSA [RFC3101], and OSPF(v3) as a PE-CE Protocol [RFC4577], [RFC6565]. These non-core features are optional in the OSPF data model. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. +1.2. Tree Diagrams + + This document uses the graphical representation of data models + defined in [RFC8340]. + 2. Design of Data Model Although the basis of OSPF configuration elements like routers, areas, and interfaces remains the same, the detailed configuration model varies among router vendors. Differences are observed in terms of how the protocol engine is tied to the routing domain, how multiple protocol engines are be instantiated among others. The goal of this document is to define a data model that provides a common user interface to the OSPFv2 and OSPFv3 protocols. There is @@ -194,21 +203,90 @@ The field 'version' is used to indicate the OSPF version and is mandatory. Based on the configured version, the data model varies to accommodate the differences between OSPFv2 and OSPFv3. 2.4. Optional Features Optional features are beyond the basic OSPF configuration and it is the responsibility of each vendor to decide whether to support a given feature on a particular device. - This model defines a number of features, such as NSR, max-LSA, etc. + This model defines the following optional features: + + 1. multi-topology: Support Multiple-Topolgy Routing (MTR) + [RFC4915]. + + 2. multi-area-adj: Support OSPF multi-area adjacency [RFC5185]. + + 3. explicit-router-id: Support explicit per-instance Router-ID + specification. + + 4. demand-circuit: Support OSPF demand circuits [RFC1793]. + + 5. mtu-ignore: Support disabling OSPF Database Description packet + MTU mismatch checking. + + 6. lls: Support OSPF link-local signaling (LLS) [RFC5613]. + + 7. prefix-suppression: Support OSPF prefix advertisement + suppression [RFC6860]. + + 8. ttl-security: Support OSPF Time to Live (TTL) security check + suppression [RFC5082]. + + 9. nsr: Support OSPF Non-Stop Routing (NSR). + + 10. graceful-restart: Support Graceful OSPF Restart [RFC3623], + [RFC5187]. + + 11. admin-control> Support Administrative control of the protocol + state. + + 12. auto-cost: Support OSPF interface cost calculation according to + reference bandwidth [RFC2328]. + + 13. max-ecmp: Support configuration of the maximum number of Equal- + Cost Multi-Path (ECMP) paths. + + 14. max-lsa: Support configuration of the maximum number of LSAs the + OSPF instance will accept [RFC1765]. + + 15. te-rid: Support configuration of the Traffic Engineering (TE) + Router-ID [RFC3630], [RFC5329]. + + 16. ldp-igp-sync: Support LDP IGP synchronization [RFC5443]. + + 17. ospfv3-authentication-ipsec: Support IPsec for OSPFv3 + authentication [RFC4552]. + + 18. fast-reroute: Support IP Fast Reroute (IP-FRR) [RFC5714]. + + 19. node-flag: Support node-flag for OSPF prefixes. [RFC7684]. + + 20. node-tag: Support node admin tag for OSPF instances [RFC7777]. + + 21. lfa: Support Loop-Free Alternates (LFAs) [RFC5286]. + + 22. remote-lfa: Support Remote Loop-Free Alternates (R-LFA) + [RFC7490]. + + 23. stub-router: Support RFC 6987 OSPF Stub Router advertisement + [RFC6987]. + + 24. pe-ce-protocol: Support OSPF as a PE-CE protocol [RFC4577], + [RFC6565]. + + 25. ietf-spf-delay: Support IETF SPF delay algorithm [RFC8405]. + + 26. bfd: Support BFD detection of OSPF neighbor reachability + [RFC5880], xref target="RFC5881"/> + It is expected that vendors will support additional features through vendor-specific augmentations. 2.5. OSPF Router Configuration/Operational State The ospf container is the top level container in this data model. It represents an OSPF protocol engine instance and contains the router level configuration and operational state. The operational state includes the instance statistics, IETF SPF delay statistics, AS- Scoped Link State Database, local RIB, SPF Log, and the LSA log. @@ -366,21 +444,21 @@ | +--ro received-timestamp? yang:timestamp | +--ro reason? identityref . . 2.6. OSPF Area Configuration/Operational State The area container contains OSPF area configuration and the list of interface containers representing all the OSPF interfaces in the area. The area operational state includes the area statistics and - the area Link State Database (LSDB). + the Area Link State Database (LSDB). module: ietf-ospf augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw ospf . . +--rw areas | +--rw area* [area-id] | +--rw area-id area-id-type @@ -601,21 +679,21 @@ | | +--ro link-scope-lsa-type* [lsa-type] | | +--ro lsa-type uint16 | | +--ro link-scope-lsas . . . . 2.7. OSPF Interface Configuration/Operational State The interface container contains OSPF interface configuration and operational state. The interface operational state includes the - statistics, list of neighbors, and link-local Link State database + statistics, list of neighbors, and Link-Local Link State Database (LSDB). module: ietf-ospf augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw ospf . . +--rw areas | +--rw area* [area-id] @@ -896,48 +974,46 @@ + [rt:name=current()/../routing-protocol-name]/ + ospf:ospf/af +--ro status? restart-status-type +--ro restart-interval? uint16 +--ro exit-reason? restart-exit-reason-type 2.9. OSPF RPC Operations The "ietf-ospf" module defines two RPC operations: - o clear-database: reset the content of a particular OSPF database. + o clear-database: reset the content of a particular OSPF Link State + Database. o clear-neighbor: restart a particular set of OSPF neighbor. rpcs: +---x clear-neighbor | +---w input | +---w routing-protocol-name | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +---w interface? if:interface-ref +---x clear-database +---w input +---w routing-protocol-name -> /rt:routing/control-plane-protocols/ control-plane-protocol/name 3. OSPF Yang Module The following RFCs and drafts are not referenced in the document text but are referenced in the ietf-ospf.yang module: [RFC0905], - [RFC1765], [RFC4552], [RFC4576], [RFC4915], [RFC5082], [RFC5185], - [RFC5250], [RFC5286], [RFC5329], [RFC5443], [RFC5613], [RFC5714], - [RFC5880], [RFC5881], [RFC6021], [RFC6860], [RFC6987], [RFC7490], - [RFC7684], [RFC7770], [RFC7777], [RFC8294], [RFC8343], [RFC8349], - [I-D.ietf-bfd-yang], and [RFC8405]. + [RFC4576], [RFC5250], [RFC5881], [RFC6021], [RFC7770], [RFC8294], and + [I-D.ietf-bfd-yang]. - file "ietf-ospf@2018-07-27.yang" + file "ietf-ospf@2018-08-28.yang" module ietf-ospf { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ospf"; prefix ospf; import ietf-inet-types { prefix "inet"; reference "RFC 6021 - Common YANG Data Types"; } @@ -963,29 +1039,28 @@ prefix "iana-rt-types"; reference "RFC 8294 - Common YANG Data Types for the Routing Area"; } import ietf-routing { prefix "rt"; reference "RFC 8349 - A YANG Data Model for Routing Management (NMDA Version)"; } - import ietf-key-chain { prefix "key-chain"; reference "RFC 8177 - YANG Data Model for Key Chains"; } import ietf-bfd-types { prefix "bfd-types"; - reference "RFC XXXX - YANG Data Model for Bidirectional + reference "RFC YYYY - YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } organization "IETF OSPF - OSPF Working Group"; contact "WG Web: WG List: @@ -1021,21 +1096,21 @@ Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision 2018-07-27 { + revision 2018-08-28 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for OSPF."; } feature multi-topology { description "Support Multiple-Topolgy Routing (MTR)."; reference "RFC 4915 - Multi-Topology Routing"; @@ -1185,23 +1263,24 @@ reference "RFC 4577 - OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) RFC 6565 - OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol"; } feature ietf-spf-delay { description "Support for IETF SPF delay algorithm."; - reference "RFC XXXX - SPF Back-off algorithm for link + reference "RFC 8405 - SPF Back-off algorithm for link state IGPs"; } + feature bfd { description "Support for BFD detection of OSPF neighbor reachability."; reference "RFC 5880 - Bidirectional Forwarding Detection (BFD) RFC 5881 - Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)"; } identity ospf-protocol { base "rt:routing-protocol"; @@ -1618,41 +1700,41 @@ "Describes the outcome of the last attempt at a graceful restart, either by itself or acting as a helper."; } typedef packet-type { type enumeration { enum hello { value "1"; description - "OSPF hello packet."; + "OSPF Hello packet."; } enum database-descripton { value "2"; description - "OSPF database description packet."; + "OSPF Database Description packet."; } enum link-state-request { value "3"; description - "OSPF link state request packet."; + "OSPF Link State Request packet."; } enum link-state-update { value "4"; description - "OSPF link state update packet."; + "OSPF Link State Update packet."; } enum link-state-ack { value "5"; description - "OSPF link state acknowlegement packet."; + "OSPF Link State Acknowlegement packet."; } } description "OSPF packet type."; } typedef nssa-translator-state-type { type enumeration { enum enabled { value "1"; @@ -1698,21 +1781,21 @@ pattern '(0x)?[0-9a-fA-F]{4}'; } description "Fletcher 16-bit checksum in hex-string format 0xXXXX."; reference "RFC 905 - ISO Transport Protocol specification ISO DP 8073"; } grouping tlv { description - "TLV"; + "Type-Length-Value (TLV)"; leaf type { type uint16; description "TLV type."; } leaf length { type uint16; description "TLV length (octets)."; } leaf value { type yang:hex-string; @@ -2494,25 +2577,26 @@ description "LSA length including the header."; } } grouping ospfv2-lsa { description "OSPFv2 LSA - LSAs are uniquely identified by the tuple with the sequence number differentiating LSA instances."; + container header { - must "(derived-from-or-self(type, " + must "(derived-from(type, " + "'ospfv2-opaque-lsa-type') and " + "opaque-id and opaque-type) or " - + "(not(derived-from-or-self(type, " + + "(not(derived-from(type, " + "'ospfv2-opaque-lsa-type')) " + "and not(opaque-id) and not(opaque-type))" { description "Opaque type and ID only apply to Opaque LSAs."; } description "Decoded OSPFv2 LSA header data."; leaf option { type bits { bit MT { @@ -2811,20 +2894,21 @@ global parameters for Loop-Free Alternatives (LFA). Container creation has no effect on LFA activation."; } } } grouping instance-fast-reroute-state { description "IPFRR state data grouping"; container protected-routes { + if-feature fast-reroute; config false; description "Instance protection statistics"; list af-stats { key "af prefix alternate"; description "Per AF protected prefix information"; leaf af { type iana-rt-types:address-family; description @@ -2928,22 +3011,22 @@ description "Metric from PLR to the alternate node"; } leaf alternate-metric3 { type uint32; description "Metric from alternate node to the destination"; } } } - container unprotected-routes { + if-feature fast-reroute; config false; description "List of prefixes that are not protected"; list af-stats { key "af prefix"; description "Per AF unprotected prefix statistics."; leaf af { type iana-rt-types:address-family; @@ -3443,25 +3532,25 @@ leaf neighbor-router-id { type rt-types:router-id; description "Neighbor Router ID."; } uses neighbor-state; } } container database { config false; - description "Link-scope LSA database."; + description "Link-scope Link State Database."; list link-scope-lsa-type { key "lsa-type"; description - "List OSPF link-scope LSA databases."; + "List OSPF link-scope LSAs."; leaf lsa-type { type uint16; description "OSPF link-scope LSA type."; } container link-scope-lsas { description "All link-scope LSAs of this LSA type."; list link-scope-lsa { key "lsa-id adv-router"; description "List of OSPF link-scope LSAs"; @@ -3617,24 +3707,24 @@ "OSPF area operational state."; container statistics { config false; description "Per-area statistics"; uses area-stat; } container database { config false; - description "Area-scope LSA database."; + description "Area-scope Link State Database."; list area-scope-lsa-type { key "lsa-type"; - description "List OSPF area-scope LSA databases."; + description "List OSPF area-scope LSAs."; leaf lsa-type { type uint16; description "OSPF area-scope LSA type."; } container area-scope-lsas { description "All area-scope LSAs of an area-scope LSA type."; list area-scope-lsa { key "lsa-id adv-router"; @@ -3884,21 +3975,21 @@ description "Enable/Disable NSR."; } } container graceful-restart { if-feature graceful-restart; description "Graceful restart config state."; reference "RFC 3623 - OSPF Graceful Restart - RFC 5178 - OSPFv3 Graceful Restart"; + RFC 5187 - OSPFv3 Graceful Restart"; leaf enable { type boolean; description "Enable/Disable graceful restart as defined in RFC 3623 for OSPFv2 and RFC 5187 for OSPFv3."; } leaf helper-enable { type boolean; description "Enable graceful restart helper support for restarting @@ -4055,24 +4144,24 @@ uses local-rib; container statistics { config false; description "Per-instance statistics"; uses instance-stat; } container database { config false; - description "AS-scope LSA database."; + description "AS-scope Link State Database."; list as-scope-lsa-type { key "lsa-type"; - description "List OSPF AS-scope LSA databases."; + description "List OSPF AS-scope LSAs."; leaf lsa-type { type uint16; description "OSPF AS scope LSA type."; } container as-scope-lsas { description "All AS-scope of LSA of this LSA type."; list as-scope-lsa { key "lsa-id adv-router"; description "List of OSPF AS-scope LSAs"; uses lsa-key; @@ -4628,22 +4719,22 @@ If the referenced OSPF interface doesn't exist, then this operation SHALL fail with error-tag 'data-missing' and error-app-tag 'ospf-interface-not-found'."; } } } rpc clear-database { description - "This RPC request clears a particular OSPF link-state - database. If the operation fails for OSPF internal reason, + "This RPC request clears a particular OSPF Link State + Database. If the operation fails for OSPF internal reason, then error-tag and error-app-tag should be set to a meaningful value."; input { leaf routing-protocol-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } mandatory "true"; description @@ -4891,42 +4983,41 @@ cannot be parsed is received on an OSPF interface."; } notification lsdb-approaching-overflow { uses notification-instance-hdr; leaf ext-lsdb-limit { type uint32; description "The maximum number of non-default AS-external LSAs - entries that can be stored in the link state database."; + entries that can be stored in the Link State Database."; } description "This notification is sent when the number of LSAs - in the router's link state database has exceeded + in the router's Link State Database has exceeded ninety percent of the AS-external limit (ext-lsdb-limit)."; } - notification lsdb-overflow { uses notification-instance-hdr; leaf ext-lsdb-limit { type uint32; description "The maximum number of non-default AS-external LSAs - entries that can be stored in the link state database."; + entries that can be stored in the Link State Database."; } description "This notification is sent when the number of LSAs - in the router's link state database has exceeded the + in the router's Link State Database has exceeded the AS-external limit (ext-lsdb-limit)."; } notification nssa-translator-status-change { uses notification-instance-hdr; leaf area-id { type area-id-type; description "Area ID."; } @@ -4979,21 +5070,21 @@ 4. Security Considerations The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. - The NETCONF access control model [RFC6536] provides the means to + The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre- configured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in ietf-ospf.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. For OSPF, the ability to @@ -5044,20 +5135,23 @@ namespace: urn:ietf:params:xml:ns:yang:ietf-ospf prefix: ospf reference: RFC XXXX 6. Acknowledgements The authors wish to thank Yi Yang, Alexander Clemm, Gaurav Gupta, Ladislav Lhotka, Stephane Litkowski, Greg Hankins, Manish Gupta and Alan Davey for their thorough reviews and helpful comments. + Thanks to Tom Petch for last call review and improvement of the + document organization. + This document was produced using Marshall Rose's xml2rfc tool. 7. Normative References [I-D.ietf-bfd-yang] Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", draft-ietf-bfd-yang-16 (work in progress), June 2018. @@ -5203,25 +5297,20 @@ [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . - [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration - Protocol (NETCONF) Access Control Model", RFC 6536, - DOI 10.17487/RFC6536, March 2012, . - [RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, June 2012, . [RFC6860] Yang, Y., Retana, A., and A. Roy, "Hiding Transit-Only Networks in OSPF", RFC 6860, DOI 10.17487/RFC6860, January 2013, . [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. @@ -5242,38 +5331,51 @@ [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, . [RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. Decraene, "Advertising Node Administrative Tags in OSPF", RFC 7777, DOI 10.17487/RFC7777, March 2016, . + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + . + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10.17487/RFC8177, June 2017, . [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, . + [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", + BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, + . + + [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration + Access Control Model", STD 91, RFC 8341, + DOI 10.17487/RFC8341, March 2018, . + [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for