NETMOD WG                                                      I. Farrer
Internet-Draft                                                    Q. Sun
Intended status: Informational                                  S. Zoric
Expires: April 18, 2016 September 14, 2017                          Deutsche Telekom AG
                                                          M. Abrahamsson
                                                               T-Systems
                                                        October 16, 2015
                                                          March 13, 2017

   YANG Models Required for Managing Customer Premises Equipment (CPE) Residential Gateway (RG) Devices
                  draft-faq-netmod-cpe-yang-profile-00
                  draft-faq-netmod-cpe-yang-profile-01

Abstract

   This document collects together the set of YANG models necessary for
   managing NETCONF-enabled Customer Premises Equipment (CPE) Residential Gateway (RG) devices.

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 April 18, 2016. September 14, 2017.

Copyright Notice

   Copyright (c) 2015 2017 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Management Requirements . . . . . . . . . . . . . . . . . . .   3
     3.1.  Interfaces  . . . . .  General Requirements  . . . . . . . . . . . . . . . . . .   3
       3.1.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   4
       3.1.2.  Development Status of Relevant YANG Models  . . . . .   4
     3.2.  IP Management  Interfaces  . . . . . . . . . . . . . . . . . . . . . .   5 .   4
       3.2.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   5   4
       3.2.2.  Development Status of Relevant YANG Models  . . . . .   5
     3.3.  IP Management . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.
       3.3.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   5
       3.3.2.  Development Status of Relevant YANG Models  . . . . .   6
     3.4.  Routing and Multicast Management  . . . . . . . . . . . .   5
       3.3.1.   6
       3.4.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   5
       3.3.2.   6
       3.4.2.  Development of Relevant YANG Models . . . . . . . . .   6
     3.4.  CPE
     3.5.  RG NETCONF Server Management  . . . . . . . . . . . . . .   6
       3.4.1.   7
       3.5.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   6
       3.4.2.   7
       3.5.2.  Development Status of Relevant YANG Models  . . . . .   6
     3.5.   7
     3.6.  DHCP/SLAAC/ND Management  . . . . . . . . . . . . . . . .   7
       3.5.1.
       3.6.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   7
       3.5.2.
       3.6.2.  Development Status of Relevant YANG Models  . . . . .   7
     3.6.   8
     3.7.  NAT Management  . . . . . . . . . . . . . . . . . . . . .   8
       3.6.1.
       3.7.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   8
       3.6.2.
       3.7.2.  Development Status of Relevant YANG Models  . . . . .   8
     3.7.   9
     3.8.  IPv6 Transition Mechanisms Management . . . . . . . . . .   8
       3.7.1.   9
       3.8.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   8
       3.7.2.   9
       3.8.2.  Development of Relevant YANG Models . . . . . . . . .   9
     3.8.
     3.9.  Management of Specific Services . . . . . . . . . . . . .   9
       3.8.1.  10
       3.9.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   9
       3.8.2.  10
       3.9.2.  Development of Relevant YANG Models . . . . . . . . .   9
     3.9.  10
     3.10. Management of Security Components . . . . . . . . . . . .  10
       3.9.1.
       3.10.1.  Requirements . . . . . . . . . . . . . . . . . . . .  10
       3.9.2.
       3.10.2.  Development of Relevant YANG Models  . . . . . . . . .  10
     3.10.  11
     3.11. Remote CPE RG Software Upgrade  . . . . . . . . . . . . . . .  10
       3.10.1.  11
       3.11.1.  Requirements . . . . . . . . . . . . . . . . . . . .  10
       3.10.2.  11
       3.11.2.  Development of Relevant YANG Models  . . . . . . . .  11
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11  12
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11  12
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11  12
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11  12
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15  16

1.  Introduction

   This document defines the requirements and specifies the necessary
   YANG models for managing residential CPE RG devices using NETCONF [RFC6241] and
   YANG. YANG
   [RFC6020].  Implementing NETCONF on CPE RG devices, along with the
   relevant YANG models, provides operators with a flexible and
   extensible management interface.

   Many of the YANG models referenced here are in various stages in the
   development process.  In some cases there is currently no existing
   work.  The aim of this document is to catalog which models are
   necessary, and for each referenced YANG model, provide information
   about the current status of the existing work.  It is intended as a
   'living document', which will be updated as the required / referenced
   YANG models progress.  Once finalised, the goal of the document is to
   serve as a CPE RG YANG 'Device profile' that can be used as a reference
   for operators and implementors who are adding YANG management
   capabilities to their devices.

2.  Terminology

   CPE               Customer Premises Equipment;

   RG                Residential Gateway; provides access between a
                     customer's LAN connected devices and their ISP's
                     network.  In the context of this document, the CPE RG
                     device implements NETCONF/YANG.  This document
                     focuses on the type of residential
                     CPE Residential Gateway that
                     typically exists between the Internet Service
                     Provider access line and residential customer home, doing similar
                     performing functions that for
                     example [RFC7084] lists. such as those described in
                     [RFC7084].
   Existing RFCs     Lists YANG models defined in published RFCs.
   Work In Progress  YANG models under development in active Internet
                     Drafts, or relevant documents being produced by
                     SDOs other than the IETF.
   To Be Defined     YANG models that are identified as necessary for
                     CPE RG
                     management, but are not currently known to be in
                     development at the time of writing.

3.  Management Requirements

3.1.  General Requirements

   The following requirements are necessary for basic RG hardware
   management.

3.1.1.  Requirements

   GEN-1  The RG YANG implementation MUST provide a model for the
          management of hardware.

3.1.2.  Development Status of Relevant YANG Models

   Existing RFCs:

   o  None

   Work In Progress:

   o  A YANG Data Model for Hardware Management:
      [I-D.han-netmod-intf-ext-ppp-yang]

   To Be Defined (and SDOs that might be responsible for the standards)

   o  None

3.2.  Interfaces

   A CPE RG has a number of network interfaces, usually including some of
   the following interface types: Ethernet LAN, Ethernet WAN, Ethernet
   802.1q, Ethernet 802.1ag, and WLAN (802.11a/b/n/g/ac).  [RFC7223]
   defines a YANG model for general interface management, which
   identifies these (and other) interface types.  However, Ethernet
   standardisation is carried out by the IEEE, so it is probable where
   YANG models for managing these interfaces would be developed.

   NB - The list of interface types necessary for a complete, general
   HGW model needs to include xDSL (BBF) and DOCSIS (ITU) interfaces.
   These will be included in a future version of this document.

3.1.1.

3.2.1.  Requirements

   The following requirements are necessary for basic CPE RG interface
   management functionality.

   INT-1: The CPE RG YANG implementation MUST implement general interface
          management.
   INT-2: The CPE RG YANG implementation MUST enable the configuration and
          management (incl operational information) for the following
          interface types:
           o  Ethernet LAN
           o  Ethernet 802.1q
           o  Ethernet 802.1ag (including Ethernet CFM)
           o  Ethernet WAN
           o  WLAN (802.11a/b/n/g/ac)

   INT-3: The CPE RG YANG implementation MUST provide support for optical
          parameter configuration for the Ethernet WAN interface YANG
          model.

3.1.2.
   INT-4  The RG YANG implementation MUST provide a model for the
          management of hardware.

3.2.2.  Development Status of Relevant YANG Models

   Existing RFCs:

   o  YANG Data Model for Interface Management [RFC7223].
   o  IANA Interface Type YANG Module [RFC7224].

   Work In Progress:

   o  IEEE 802.1q YANG Model [IEEE-ETH-YANG]
   o  Common  Interface Extension VLAN YANG Data Models:
      [I-D.wilton-netmod-intf-ext-yang].
      [I-D.ietf-netmod-sub-intf-vlan-model].
   o  Common Interface VLAN Extension YANG Data Models:
      [I-D.wilton-netmod-intf-vlan-yang].
      [I-D.ietf-netmod-intf-ext-yang]
   o  YANG Model for the PPP Protocol:
      [I-D.han-netmod-intf-ext-ppp-yang]
   o  A YANG Data Model for Hardware Management:
      [I-D.han-netmod-intf-ext-ppp-yang]

   To Be Defined: Defined (and SDOs that might be responsible for the standards)

   o  Ethernet WAN (IEEE/BBF)
   o  Ethernet 802.1ag (IEEE)
   o  Ethernet LAN (IEEE/BBF)
   o  WLAN (802.11a/b/n/g/ac)

3.2. (IEEE/WFA/BBF)

3.3.  IP Management

3.2.1.

3.3.1.  Requirements

   The following requirements are necessary for the management and
   configuration of IPv4 and IPv6.

   IP-1: The CPE RG YANG implementation MUST enable the configuration and
         management of IPv4 addresses and associated parameters on L3
         interfaces.
   IP-2: The CPE RG YANG implementation MUST enable the configuration and
         management of IPv6 addresses and associated parameters on L3
         interfaces.

3.2.2.
   IP-3  The RG YANG implementation MUST allow for the configuration of
         differentiated services [RFC2474] related parameters on its
         interfaces.

3.3.2.  Development Status of Relevant YANG Models

   Existing RFCs:

   o  YANG Data Model for IP Management [RFC7277].

   Work In Progress:

   o  YANG Model for DiffServ: [I-D.asechoud-netmod-diffserv-model].

   To Be Defined:

   o  None

3.3.

3.4.  Routing and Multicast Management

3.3.1.

3.4.1.  Requirements

   The following requirements are necessary for routing management.

   ROUT-1: The CPE RG YANG implementation MUST provide support for the
           configuration and management of relevant IPv4/IPv6 dynamic
           routing protocols (for instance the ones relevant to IETF
           HOMENET WG).
   ROUT-2: The CPE RG YANG implementation MUST include YANG models for the
           management of static IPv4/IPv6 routes.
   ROUT-3: The CPE RG YANG implementation MUST provide support for the
           management of Protocol Independent Multicast (PIM).
   ROUT-4: The CPE RG YANG implementation MUST provide support for the
           management of static multicast routes.

3.3.2.

3.4.2.  Development of Relevant YANG Models

   Existing RFCs:

   o  None

   Work In Progress:

   o  YANG Data Model for Routing Management:
      [I-D.ietf-netmod-routing-cfg]. [RFC8022].
   o  YANG model for static IPv4/IPv6 route: Appendix B in
      [I-D.ietf-netmod-routing-cfg]. [RFC8022].
   o  YANG Data Model for ISIS protocol: [I-D.ietf-isis-yang-isis-cfg].
   o  YANG model for PIM: [I-D.mcallister-pim-yang]. [I-D.ietf-pim-yang].
   o  YANG model for IGMP and MLD: [I-D.liu-pim-igmp-mld-yang]. [I-D.ietf-pim-igmp-mld-yang].

   To Be Defined:

   o  Static Multicast Route
   o  What is the HOMENET relevant dynamic routing protocol.

3.4.  CPE protocol(s).

3.5.  RG NETCONF Server Management

3.4.1.

3.5.1.  Requirements

   The following requirements are necessary for management of the CPE's RG's
   NETCONF Server.

   NETCONF-1:  The CPE RG YANG implementation MUST provide support for
               management and configuration of its local NETCONF server
               using the NETCONF protocol.
   NETCONF-2:  The CPE RG YANG implementation MUST provide support for the
               base notification function in order to allow a NETCONF
               client to retrieve notifications for common system
               events.
   NETCONF-3:  The CPE RG YANG implementation MUST be able to retrieve
               NETCONF server configuration automatically during the
               bootstrap process (ZeroTouch).
   NETCONF-4:  The CPE RG YANG implementation as a NETCONF server MUST
               provide support for the Call Home function so that a
               secure connection to a NETCONF client can be initiated.

3.4.2.

3.5.2.  Development Status of Relevant YANG Models

   Existing RFCs:

   o  YANG Module for NETCONF Monitoring: [RFC6022].
   o  NETCONF Base Notifications: [RFC6470].

   Work In Progress:

   o  ZeroTouch: [I-D.ietf-netconf-zerotouch].
   o  NETCONF Call Home: [I-D.ietf-netconf-call-home]. [RFC8071].
   o  NETCONF Server Configuration Models:
      [I-D.ietf-netconf-server-model].
      [I-D.ietf-netconf-netconf-client-server].

   To Be Defined:

   o  None

3.5.

3.6.  DHCP/SLAAC/ND Management

3.5.1.

3.6.1.  Requirements

   The following requirements are necessary for management of DHCP,
   SLAAC and ND.

   V6CONF-1:  The CPE RG YANG implementation MUST provide support for
              management of its DHCPv4 server, which typically runs at
              the IPv4 LAN side.
   V6CONF-2:  The CPE RG YANG implementation MUST provide support for the
              management of its DHCPv6 server, which can run at the IPv6
              LAN side.
   V6CONF-3:  The CPE RG YANG implementation MUST provide support for the
              management of its DHCPv6 client, which typically runs at
              the IPv6 WAN side.
   V6CONF-4:  The CPE RG YANG implementation MUST provide support for the
              management of its DHCPv6 Prefix Delegation configuration
              (as a requesting router).
   V6CONF-5:  The CPE RG YANG implementation MUST provide support for the
              management of SLAAC for stateless IPv6 configuration.

3.5.2. configuration (as
              router on its LAN interfaces).

3.6.2.  Development Status of Relevant YANG Models

   Existing RFCs:

   o  None  IPv6 Router Advertisements: [RFC8022]

   Work In Progress:

   o  YANG models Data Model for DHCPv4: DHCPv4 Configuration:
      [I-D.liu-dhc-dhcp-yang-model].
   o  YANG Data Model for DHCPv6 Configuration:
      [I-D.cui-dhc-dhcpv6-yang].
      [I-D.ietf-dhc-dhcpv6-yang].

   To Be Defined:

   o  YANG model for SLAAC (Router Advertisement) Advertisement).  (IETF)
   o  YANG model for Neighbour Discovery Protocol (NDP) (NDP).  (IETF)
   o  YANG model for DHCPv6 Prefix Delegation (requesting router) router).
      (IETF)
   o  YANG model for IPCP.  (IETF)
   o  YANG model for IPv6CP.

3.6.  (IETF)

3.7.  NAT Management

3.6.1.

3.7.1.  Requirements

   The following requirements are necessary for NAT Management.

   NAT-1:  The CPE RG YANG implementation MUST provide support for
           management of NAT44 configuration, as well as NAPT44
           configuration.

3.6.2.

3.7.2.  Development Status of Relevant YANG Models

   Existing RFCs:

   o  None

   Work In Progress:

   o  YANG Data Model for NAT44 and stateful NAT64 function
      [I-D.sivakumar-yang-nat].

   To Be Defined:

   o  None

3.7.

3.8.  IPv6 Transition Mechanisms Management

3.7.1.

3.8.1.  Requirements

   The following requirements are necessary for management of IPv6
   Transition Mechanisms.

   TRAN-2:  The CPE RG YANG implementation must include configuration and
            management for 6rd [RFC5969].
   TRAN-2:  The CPE RG YANG implementation must include configuration and
            management for DS-Lite [RFC6333].
   TRAN-3:  The CPE RG YANG implementation must include configuration and
            management for Lightweight 4over6 [RFC7596].
   TRAN-4:  The CPE RG YANG implementation must include configuration and
            management for MAP-E [RFC7597].
   TRAN-5:  The CPE RG YANG implementation must include configuration and
            management for MAP-T [RFC7599].

3.7.2.

3.8.2.  Development of Relevant YANG Models

   Existing RFCs:

   o  None

   Work In Progress:

   o  YANG model for IPv4-in-IPv6 Softwire: [I-D.sun-softwire-yang]. [I-D.ietf-softwire-yang].
   o  YANG Data Model for the DS-Lite Address Family Transition Router
      (AFTR): [I-D.boucadair-softwire-dslite-yang]. [I-D.ietf-softwire-dslite-yang].

   To Be Defined:

   o  YANG model for 6rd.  (IETF)
   o  DHCP 4o6 client: May be combined in DHCPv6 YANG model as a
      feature.  (IETF)
   o  DNS64  DNS64.  (IETF)
   o  Stateless NAT64 (required for MAP-T and 464xlat).

3.8.  (IETF)

3.9.  Management of Specific Services

3.8.1.

3.9.1.  Requirements

   The following requirements are necessary for management of specific
   services which the CPE RG may offer.

   SERVICE-1:  The CPE RG YANG implementation MUST provide support for the
               management of a SIP client.
   SERVICE-2:  The CPE RG YANG implementation MUST provide support for the
               management of a the CPEs RG Web server (used to provide a
               local management interface).
   SERVICE-3:  The CPE RG YANG implementation MUST provide support for the
               management of an NTP client and server.
   SERVICE-4:  The CPE RG YANG implementation MUST provide support for the
               management of the SSH server.

3.8.2.

3.9.2.  Development of Relevant YANG Models

   Existing RFCs:

   o  NTP Client: [RFC7317]

   Work In Progress:

   o  None

   To Be Defined:

   o  SIP Client  SIP/VoIP Client.  (IETF)
   o  Web server, used by the customer for configuring their CPE device. RG. (?)
   o  NTP server server.  (IETF)
   o  SSH server

3.9. server.  (IETF)

3.10.  Management of Security Components

3.9.1.

3.10.1.  Requirements

   The following requirements are necessary for management of security
   components.

   SEC-1:  The CPE RG YANG implementation MUST provide support for the
           management of IPv4 firewall and ACL functions.

   SEC-1:  The CPE RG YANG implementation MUST provide support for the
           management of IPv6 firewall and ACL functions.

3.9.2.

3.10.2.  Development of Relevant YANG Models

   Existing RFCs:

   o  None

   Work In Progress:

   o  IPv4 Firewall configuration: [I-D.ietf-netmod-acl-model]
   o  IPv6 Firewall configuration: [I-D.ietf-netmod-acl-model]
   o  Access Control List (ACL): [I-D.ietf-netmod-acl-model]

   To Be Defined:

   o  IPv4/v6 Firewall (if needed in addition to the above) (IETF?)
   o  Parental controls

3.10. (?)

3.11.  Remote CPE RG Software Upgrade

3.10.1.

3.11.1.  Requirements

   The following requirements are necessary to perform remote CPE RG
   Software file transfer and software upgrades.

   SWUPG-1:  The CPE RG implementation must provide a YANG model for the
             upgrade of firmware and software packages in order to fix
             bugs, enable new features, and resolve security issues.
   SWUPG-2:  The CPE RG YANG implementation MUST enable RPCs for file
             transfer in order to retrieve files from an operator-
             managed data centre, or upload logging.

3.10.2.

3.11.2.  Development of Relevant YANG Models

   Existing RFCs:

   o  None

   Work In Progress:

   o  File transfer: [I-D.sf-netmod-file-transfer-yang]

   To Be Defined:

   o  YANG model for firmware upgrade RPCs RPCs.  (BBF?)

4.  Security Considerations

   A NETCONF/YANG managed CPE RG should follow the Section 3.9 3.10 for enabling
   and managing IPv4/IPv6 firewalls.  Security considerations from the
   related documents should be followed.

5.  IANA Considerations

   There are no IANA considerations for this document.

6.  Acknowledgements

   The authors would like to thank xxx for their contributions to this
   work.

7.  References

7.1.  Normative References

   [I-D.asechoud-netmod-diffserv-model]
              Choudhary, A., Shah, S., Jethanandani, M., Liu, B., and N.
              Strahle, "YANG Model for Diffserv", draft-asechoud-netmod-
              diffserv-model-03 (work in progress), June 2015.

   [I-D.boucadair-softwire-dslite-yang]
              Boucadair, M., Jacquenet, C.,

   [I-D.han-netmod-intf-ext-ppp-yang]
              Han, H., Gu, X., Lv, H., and S. Sivakumar, "YANG J. Zhang, "Yang Data Model
              for the DS-Lite Address Family Transition Router
              (AFTR)", draft-boucadair-softwire-dslite-yang-02 PPP Protocol", draft-han-netmod-intf-ext-ppp-yang-02
              (work in progress), September 2015.

   [I-D.cui-dhc-dhcpv6-yang] February 2017.

   [I-D.ietf-dhc-dhcpv6-yang]
              Cui, Y., Wang, H., Sun, L., Lemon, T., and I. Farrer, I., and S.
              Zoric, "YANG Data Model for DHCPv6 Configuration", draft-cui-dhc-
              dhcpv6-yang-04 draft-
              ietf-dhc-dhcpv6-yang-03 (work in progress), September 2015. June 2016.

   [I-D.ietf-isis-yang-isis-cfg]
              Litkowski, S., Yeung, D., Lindem, A., Zhang, J., Z., and L.
              Lhotka, "YANG Data Model for ISIS IS-IS protocol", draft-ietf-
              isis-yang-isis-cfg-06
              isis-yang-isis-cfg-15 (work in progress), September 2015. February 2017.

   [I-D.ietf-netconf-call-home]
              Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
              draft-ietf-netconf-call-home-11
              draft-ietf-netconf-call-home-17 (work in progress),
              September
              December 2015.

   [I-D.ietf-netconf-netconf-client-server]
              Watsen, K., Wu, G., and J. Schoenwaelder, "NETCONF Client
              and Server Models", draft-ietf-netconf-netconf-client-
              server-01 (work in progress), November 2016.

   [I-D.ietf-netconf-server-model]
              Watsen, K. and J. Schoenwaelder, "NETCONF Server and
              RESTCONF Server Configuration Models", draft-ietf-netconf-
              server-model-08
              server-model-09 (work in progress), October 2015. March 2016.

   [I-D.ietf-netconf-zerotouch]
              Watsen, K., Clarke, J., K. and M. Abrahamsson, "Zero Touch Provisioning
              for NETCONF Call Home (ZeroTouch)", draft-
              ietf-netconf-zerotouch-03 or RESTCONF based Management", draft-ietf-
              netconf-zerotouch-12 (work in progress), July 2015. January 2017.

   [I-D.ietf-netmod-acl-model]
              Bogdanovic, D., Sreenivasa, Koushik, K., Huang, L., and D. Blair,
              "Network Access Control List (ACL) YANG Data Model",
              draft-ietf-netmod-acl-model-03
              draft-ietf-netmod-acl-model-10 (work in progress), June
              2015.

   [I-D.ietf-netmod-routing-cfg]
              Lhotka, L. March
              2017.

   [I-D.ietf-netmod-intf-ext-yang]
              Wilton, R., Ball, D., tsingh@juniper.net, t., and A. Lindem, "A S.
              Sivaraj, "Common Interface Extension YANG Data Model for Routing
              Management", draft-ietf-netmod-routing-cfg-19 Models",
              draft-ietf-netmod-intf-ext-yang-04 (work in progress), May 2015.

   [I-D.liu-dhc-dhcp-yang-model]
              Liu, B.
              March 2017.

   [I-D.ietf-netmod-sub-intf-vlan-model]
              Wilton, R., Ball, D., tapsingh@cisco.com, t., and K. Lou, "A S.
              Sivaraj, "Sub-interface VLAN YANG Data Model for DHCP
              Configuration", draft-liu-dhc-dhcp-yang-model-01 Models", draft-
              ietf-netmod-sub-intf-vlan-model-00 (work in progress), July 2015.

   [I-D.liu-pim-igmp-mld-yang]
              February 2017.

   [I-D.ietf-pim-igmp-mld-yang]
              Liu, Y. and F. X., Guo, "Yang Model F., Sivakumar, M., McAllister, P., and A.
              Peter, "A YANG data model for Internet Group Management
              Protocol (IGMP) and Multicast Listener Discovery (MLD)", draft-liu-pim-igmp-mld-yang-01
              draft-ietf-pim-igmp-mld-yang-03 (work in progress), March 2015.

   [I-D.mcallister-pim-yang]
              2017.

   [I-D.ietf-pim-yang]
              Liu, X., McAllister, P., and A. Peter, A., Sivakumar, M., Liu,
              Y., and f. hu, "A YANG data model for Protocol-Independent
              Multicast (PIM)", draft-
              mcallister-pim-yang-00 draft-ietf-pim-yang-07 (work in
              progress), July 2015.

   [I-D.perrault-behave-natv2-mib]
              Perreault, S., Tsou, T., March 2017.

   [I-D.ietf-softwire-dslite-yang]
              Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG
              Data Model for the DS-Lite", draft-ietf-softwire-dslite-
              yang-02 (work in progress), January 2017.

   [I-D.ietf-softwire-yang]
              Sun, Q., Wang, H., Cui, Y., Farrer, I., Zoric, S.,
              Boucadair, M., and T. Taylor,
              "Definitions of Managed Objects R. Asati, "A YANG Data Model for Network Address
              Translators (NAT)", draft-perrault-behave-natv2-mib-05 IPv4-
              in-IPv6 Softwires", draft-ietf-softwire-yang-01 (work in
              progress), June 2015. October 2016.

   [I-D.liu-dhc-dhcp-yang-model]
              Liu, B., Lou, K., and C. Chen, "Yang Data Model for DHCP
              Protocol", draft-liu-dhc-dhcp-yang-model-06 (work in
              progress), March 2017.

   [I-D.sf-netmod-file-transfer-yang]
              Sun, Q. and I. Farrer, "A YANG Data Model for Transferring
              Files", draft-sf-netmod-file-transfer-yang-00 (work in
              progress), March 2015.

   [I-D.sivakumar-yang-nat]
              Sivakumar, S., Boucadair, M., and S. <>, "YANG Data Model
              for Network Address Translation (NAT)", draft-sivakumar-
              yang-nat-03
              yang-nat-05 (work in progress), September 2015.

   [I-D.sun-softwire-yang]
              Sun, Q., Wang, H., Cui, Y., Farrer, I., Boucadair, M., and
              R. Asati, "YANG Data Model for IPv4-in-IPv6 Softwire",
              draft-sun-softwire-yang-04 (work in progress), October
              2015.

   [I-D.wilton-netmod-intf-ext-yang]
              Wilton, R., Ball, D., Singh, T., and S. Sivaraj, "Common
              Interface Extension YANG Data Models", draft-wilton-
              netmod-intf-ext-yang-00 (work in progress), July 2015.

   [I-D.wilton-netmod-intf-vlan-yang]
              Wilton, R., Ball, D., Singh, T., and S. Sivaraj,
              "Interface VLAN YANG Data Models", draft-wilton-netmod-
              intf-vlan-yang-00 (work in progress), July 2015. 2016.

   [IEEE-ETH-YANG]
              "IEEE 802.1q YANG Model",
              <http://www.ieee802.org/1/files/public/docs2015/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/
              RFC2119, 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <http://www.rfc-editor.org/info/rfc6020>.

   [RFC6022]  Scott, M. and M. Bjorklund, "YANG Module for NETCONF
              Monitoring", RFC 6022, DOI 10.17487/RFC6022, October 2010,
              <http://www.rfc-editor.org/info/rfc6022>.

   [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,
              <http://www.rfc-editor.org/info/rfc6241>.

   [RFC6470]  Bierman, A., "Network Configuration Protocol (NETCONF)
              Base Notifications", RFC 6470, DOI 10.17487/RFC6470,
              February 2012, <http://www.rfc-editor.org/info/rfc6470>.

   [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
              <http://www.rfc-editor.org/info/rfc7223>.

   [RFC7224]  Bjorklund, M., "IANA Interface Type YANG Module",
              RFC 7224, DOI 10.17487/RFC7224, May 2014,
              <http://www.rfc-editor.org/info/rfc7224>.

   [RFC7277]  Bjorklund, M., "A YANG Data Model for IP Management",
              RFC 7277, DOI 10.17487/RFC7277, June 2014,
              <http://www.rfc-editor.org/info/rfc7277>.

   [RFC7317]  Bierman, A. and M. Bjorklund, "A YANG Data Model for
              System Management", RFC 7317, DOI 10.17487/RFC7317, August
              2014, <http://www.rfc-editor.org/info/rfc7317>.

   [RFC7659]  Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor,
              "Definitions of Managed Objects for Network Address
              Translators (NATs)", RFC 7659, DOI 10.17487/RFC7659,
              October 2015, <http://www.rfc-editor.org/info/rfc7659>.

   [RFC8022]  Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
              Management", RFC 8022, DOI 10.17487/RFC8022, November
              2016, <http://www.rfc-editor.org/info/rfc8022>.

   [RFC8071]  Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
              RFC 8071, DOI 10.17487/RFC8071, February 2017,
              <http://www.rfc-editor.org/info/rfc8071>.

7.2.  Informative References

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <http://www.rfc-editor.org/info/rfc2474>.

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd) -- Protocol Specification",
              RFC 5969, DOI 10.17487/RFC5969, August 2010,
              <http://www.rfc-editor.org/info/rfc5969>.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
              <http://www.rfc-editor.org/info/rfc6333>.

   [RFC7084]  Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
              Requirements for IPv6 Customer Edge Routers", RFC 7084,
              DOI 10.17487/RFC7084, November 2013,
              <http://www.rfc-editor.org/info/rfc7084>.

   [RFC7596]  Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
              Farrer, "Lightweight 4over6: An Extension to the Dual-
              Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
              July 2015, <http://www.rfc-editor.org/info/rfc7596>.

   [RFC7597]  Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, Ed., "Mapping of Address and
              Port with Encapsulation (MAP-E)", RFC 7597,
              DOI 10.17487/
              RFC7597, 10.17487/RFC7597, July 2015,
              <http://www.rfc-editor.org/info/rfc7597>.

   [RFC7599]  Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
              and T. Murakami, "Mapping of Address and Port using
              Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
              2015, <http://www.rfc-editor.org/info/rfc7599>.

Authors' Addresses

   Ian Farrer
   Deutsche Telekom AG
   CTO-ATI, Landgrabenweg 151
   Bonn, NRW  53227
   Germany

   Email: ian.farrer@telekom.de

   Qi Sun
   Deutsche Telekom AG
   CTO-ATI, Landgrabenweg 151
   Bonn, NRW  53227
   Germany

   Email: sunqi.ietf@gmail.com

   Sladjana Zoric
   Deutsche Telekom AG
   CTO-IPT,
   CTO-ATI, Landgrabenweg 151
   Bonn, NRW  53227
   Germany

   Email: sladjana.zoric@telekom.de
   Mikael Abrahamsson
   T-Systems

   Email: mikael.abrahamsson@t-systems.se