draft-ietf-netmod-rfc7223bis-01.txt   draft-ietf-netmod-rfc7223bis-02.txt 
Network Working Group M. Bjorklund Network Working Group M. Bjorklund
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Obsoletes: rfc7223 (if approved) December 17, 2017 Obsoletes: rfc7223 (if approved) January 9, 2018
Intended status: Standards Track Intended status: Standards Track
Expires: June 20, 2018 Expires: July 13, 2018
A YANG Data Model for Interface Management A YANG Data Model for Interface Management
draft-ietf-netmod-rfc7223bis-01 draft-ietf-netmod-rfc7223bis-02
Abstract Abstract
This document defines a YANG data model for the management of network This document defines a YANG data model for the management of network
interfaces. It is expected that interface-type-specific data models interfaces. It is expected that interface-type-specific data models
augment the generic interfaces data model defined in this document. augment the generic interfaces data model defined in this document.
The data model includes definitions for configuration and system The data model includes definitions for configuration and system
state (status information and counters for the collection of state (status information and counters for the collection of
statistics). This document obsoletes RFC 7223. statistics). This document obsoletes RFC 7223.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 20, 2018. This Internet-Draft will expire on July 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 26 skipping to change at page 2, line 26
3.2. Interface References . . . . . . . . . . . . . . . . . . 8 3.2. Interface References . . . . . . . . . . . . . . . . . . 8
3.3. Interface Layering . . . . . . . . . . . . . . . . . . . 8 3.3. Interface Layering . . . . . . . . . . . . . . . . . . . 8
4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . 9 4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . 9
5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . 10 5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Normative References . . . . . . . . . . . . . . . . . . 35 9.1. Normative References . . . . . . . . . . . . . . . . . . 35
9.2. Informative References . . . . . . . . . . . . . . . . . 36 9.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Example: Ethernet Interface Module . . . . . . . . . 36 Appendix A. Example: Ethernet Interface Module . . . . . . . . . 37
Appendix B. Example: Ethernet Bonding Interface Module . . . . . 38 Appendix B. Example: Ethernet Bonding Interface Module . . . . . 38
Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 38 Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 39
Appendix D. Example: NETCONF <get-config> Reply . . . . . . . . 40 Appendix D. Example: NETCONF <get-config> Reply . . . . . . . . 41
Appendix E. Example: NETCONF <get-data> Reply . . . . . . . . . 41 Appendix E. Example: NETCONF <get-data> Reply . . . . . . . . . 42
Appendix F. Examples: Interface Naming Schemes . . . . . . . . . 43 Appendix F. Examples: Interface Naming Schemes . . . . . . . . . 44
F.1. Router with Restricted Interface Names . . . . . . . . . 43 F.1. Router with Restricted Interface Names . . . . . . . . . 44
F.2. Router with Arbitrary Interface Names . . . . . . . . . . 44 F.2. Router with Arbitrary Interface Names . . . . . . . . . . 45
F.3. Ethernet Switch with Restricted Interface Names . . . . . 45 F.3. Ethernet Switch with Restricted Interface Names . . . . . 46
F.4. Generic Host with Restricted Interface Names . . . . . . 45 F.4. Generic Host with Restricted Interface Names . . . . . . 46
F.5. Generic Host with Arbitrary Interface Names . . . . . . . 46 F.5. Generic Host with Arbitrary Interface Names . . . . . . . 47
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
This document defines a YANG [RFC7950] data model for the management This document defines a YANG [RFC7950] data model for the management
of network interfaces. It is expected that interface-type-specific of network interfaces. It is expected that interface-type-specific
data models augment the generic interfaces data model defined in this data models augment the generic interfaces data model defined in this
document. document.
Network interfaces are central to the management of many Internet Network interfaces are central to the management of many Internet
protocols. Thus, it is important to establish a common data model protocols. Thus, it is important to establish a common data model
skipping to change at page 8, line 8 skipping to change at page 8, line 8
to which a network interface may be attached or removed, it may be to which a network interface may be attached or removed, it may be
impossible for an implementation to provide predictable and impossible for an implementation to provide predictable and
consistent names for system-controlled interfaces across insertion/ consistent names for system-controlled interfaces across insertion/
removal cycles as well as in anticipation of initial insertion. The removal cycles as well as in anticipation of initial insertion. The
ability to provide configurations for such interfaces is therefore ability to provide configurations for such interfaces is therefore
dependent on the implementation and cannot be assumed in all cases. dependent on the implementation and cannot be assumed in all cases.
3.2. Interface References 3.2. Interface References
An interface is identified by its name, which is unique within the An interface is identified by its name, which is unique within the
server. This property is captured in the "interface-ref" and server. This property is captured in the "interface-ref" typedef,
typedef, which other YANG modules SHOULD use when they need to which other YANG modules SHOULD use when they need to reference an
reference an interface. interface.
3.3. Interface Layering 3.3. Interface Layering
There is no generic mechanism for how an interface is configured to There is no generic mechanism for how an interface is configured to
be layered on top of some other interface. It is expected that be layered on top of some other interface. It is expected that
interface-type-specific models define their own data nodes for interface-type-specific models define their own data nodes for
interface layering by using "interface-ref" types to reference lower interface layering by using "interface-ref" types to reference lower
layers. layers.
Below is an example of a model with such nodes. For a more complete Below is an example of a model with such nodes. For a more complete
skipping to change at page 9, line 38 skipping to change at page 9, line 38
The ifMtu object from the IF-MIB is not mapped to the The ifMtu object from the IF-MIB is not mapped to the
"ietf-interfaces" module. It is expected that interface-type- "ietf-interfaces" module. It is expected that interface-type-
specific YANG modules provide interface-type-specific MTU leafs by specific YANG modules provide interface-type-specific MTU leafs by
augmenting the "ietf-interfaces" model. augmenting the "ietf-interfaces" model.
There are a number of counters in the IF-MIB that exist in two There are a number of counters in the IF-MIB that exist in two
versions: one with 32 bits and one with 64 bits. The 64-bit versions versions: one with 32 bits and one with 64 bits. The 64-bit versions
were added to support high-speed interfaces with a data rate greater were added to support high-speed interfaces with a data rate greater
than 20,000,000 bits/second. Today's implementations generally than 20,000,000 bits/second. Today's implementations generally
support such high-speed interfaces, and hence only 64-bit counters support such high-speed interfaces, and hence only 64-bit counters
are provided in this data model. Note that NETCONF and SNMP may are provided in this data model. Note that the server that
differ in the time granularity in which they provide access to the implements this module and an SNMP agent may differ in the time
counters. For example, it is common that SNMP implementations cache granularity in which they provide access to the counters. For
counter values for some time. example, it is common that SNMP implementations cache counter values
for some time.
The objects ifDescr and ifConnectorPresent from the IF-MIB are not The objects ifDescr and ifConnectorPresent from the IF-MIB are not
mapped to the "ietf-interfaces" module. mapped to the "ietf-interfaces" module.
The following tables list the YANG data nodes with corresponding The following tables list the YANG data nodes with corresponding
objects in the IF-MIB. objects in the IF-MIB.
+--------------------------------------+----------------------------+ +--------------------------------------+----------------------------+
| YANG data node in | IF-MIB object | | YANG data node in | IF-MIB object |
| /interfaces/interface | | | /interfaces/interface | |
skipping to change at page 10, line 42 skipping to change at page 10, line 42
| out-discards | ifOutDiscards | | out-discards | ifOutDiscards |
| out-errors | ifOutErrors | | out-errors | ifOutErrors |
+--------------------------------------+----------------------------+ +--------------------------------------+----------------------------+
YANG Data Nodes and Related IF-MIB Objects YANG Data Nodes and Related IF-MIB Objects
5. Interfaces YANG Module 5. Interfaces YANG Module
This YANG module imports typedefs from [RFC6991]. This YANG module imports typedefs from [RFC6991].
<CODE BEGINS> file "ietf-interfaces@2017-12-16.yang" <CODE BEGINS> file "ietf-interfaces@2018-01-09.yang"
module ietf-interfaces { module ietf-interfaces {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
prefix if; prefix if;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
organization organization
skipping to change at page 11, line 18 skipping to change at page 11, line 18
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
Editor: Martin Bjorklund Editor: Martin Bjorklund
<mailto:mbj@tail-f.com>"; <mailto:mbj@tail-f.com>";
description description
"This module contains a collection of YANG definitions for "This module contains a collection of YANG definitions for
managing network interfaces. managing network interfaces.
Copyright (c) 2017 IETF Trust and the persons identified as Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2017-12-16 { revision 2018-01-09 {
description description
"Updated to support NMDA."; "Updated to support NMDA.";
reference reference
"RFC XXXX: A YANG Data Model for Interface Management"; "RFC XXXX: A YANG Data Model for Interface Management";
} }
revision 2014-05-08 { revision 2014-05-08 {
description description
"Initial revision."; "Initial revision.";
reference reference
skipping to change at page 34, line 35 skipping to change at page 34, line 35
This document registers a YANG module in the "YANG Module Names" This document registers a YANG module in the "YANG Module Names"
registry [RFC6020]. registry [RFC6020].
name: ietf-interfaces name: ietf-interfaces
namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces
prefix: if prefix: if
reference: RFC XXXX reference: RFC XXXX
7. Security Considerations 7. Security Considerations
The YANG module defined in this memo is designed to be accessed via The YANG module defined in this document is designed to be accessed
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the via network management protocols such as NETCONF [RFC6241] or
secure transport layer and the mandatory-to-implement secure RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport
transport is SSH [RFC6242]. The NETCONF access control model layer, and the mandatory-to-implement secure transport is Secure
[RFC6536] provides the means to restrict access for particular Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the
NETCONF users to a pre-configured subset of all available NETCONF mandatory-to-implement secure transport is TLS [RFC5246].
protocol operations and content.
The NETCONF access control model [RFC6536] provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
There are a number of data nodes defined in the YANG module which are There are a number of data nodes defined in the YANG module which are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., <edit-config>) in some network environments. Write operations (e.g., <edit-config>)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
/interfaces/interface: This list specifies the configured interfaces /interfaces/interface: This list specifies the configured interfaces
skipping to change at page 35, line 30 skipping to change at page 35, line 32
9.1. Normative References 9.1. Normative References
[I-D.ietf-netmod-revised-datastores] [I-D.ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore and R. Wilton, "Network Management Datastore
Architecture", draft-ietf-netmod-revised-datastores-07 Architecture", draft-ietf-netmod-revised-datastores-07
(work in progress), November 2017. (work in progress), November 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, <https://www.rfc-editor.org/info/ DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
rfc2119>. editor.org/info/rfc2119>.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<https://www.rfc-editor.org/info/rfc2863>. <https://www.rfc-editor.org/info/rfc2863>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <https://www.rfc- DOI 10.17487/RFC3688, January 2004, <https://www.rfc-
editor.org/info/rfc3688>. editor.org/info/rfc3688>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
editor.org/info/rfc5246>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, <https://www.rfc- DOI 10.17487/RFC6020, October 2010, <https://www.rfc-
editor.org/info/rfc6020>. editor.org/info/rfc6020>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc- and A. Bierman, Ed., "Network Configuration Protocol
editor.org/info/rfc6991>. (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012, <https://www.rfc-
editor.org/info/rfc6536>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-netmod-yang-tree-diagrams] [I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-02 (work in progress), ietf-netmod-yang-tree-diagrams-02 (work in progress),
October 2017. October 2017.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
and A. Bierman, Ed., "Network Configuration Protocol RFC 7224, DOI 10.17487/RFC7224, May 2014,
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc7224>.
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, DOI
10.17487/RFC6536, March 2012, <https://www.rfc-
editor.org/info/rfc6536>.
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC
7224, DOI 10.17487/RFC7224, May 2014, <https://www.rfc-
editor.org/info/rfc7224>.
Appendix A. Example: Ethernet Interface Module Appendix A. Example: Ethernet Interface Module
This section gives a simple example of how an Ethernet interface This section gives a simple example of how an Ethernet interface
module could be defined. It demonstrates how media-specific module could be defined. It demonstrates how media-specific
configuration parameters can be conditionally augmented to the configuration parameters can be conditionally augmented to the
generic interface list. It also shows how operational state generic interface list. It also shows how operational state
parameters can be conditionally augmented to the operational parameters can be conditionally augmented to the operational
interface list. The example is not intended as a complete module for interface list. The example is not intended as a complete module for
Ethernet configuration. Ethernet configuration.
module ex-ethernet { module example-ethernet {
namespace "http://example.com/ethernet"; namespace "http://example.com/ethernet";
prefix "eth"; prefix "eth";
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
} }
import iana-if-type { import iana-if-type {
prefix ianaift; prefix ianaift;
} }
skipping to change at page 38, line 4 skipping to change at page 38, line 20
type enumeration { type enumeration {
enum "half"; enum "half";
enum "full"; enum "full";
} }
config false; config false;
} }
} }
// other Ethernet-specific params... // other Ethernet-specific params...
} }
} }
} }
Appendix B. Example: Ethernet Bonding Interface Module Appendix B. Example: Ethernet Bonding Interface Module
This section gives an example of how interface layering can be This section gives an example of how interface layering can be
defined. An Ethernet bonding interface that bonds several Ethernet defined. An Ethernet bonding interface that bonds several Ethernet
interfaces into one logical interface is defined. interfaces into one logical interface is defined.
module ex-ethernet-bonding { module example-ethernet-bonding {
namespace "http://example.com/ethernet-bonding"; namespace "http://example.com/ethernet-bonding";
prefix "bond"; prefix "bond";
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
} }
import iana-if-type { import iana-if-type {
prefix ianaift; prefix ianaift;
} }
skipping to change at page 39, line 5 skipping to change at page 40, line 5
} }
// other bonding config params, failover times, etc. // other bonding config params, failover times, etc.
} }
} }
Appendix C. Example: VLAN Interface Module Appendix C. Example: VLAN Interface Module
This section gives an example of how a VLAN interface module can be This section gives an example of how a VLAN interface module can be
defined. defined.
module ex-vlan { module example-vlan {
namespace "http://example.com/vlan"; namespace "http://example.com/vlan";
prefix "vlan"; prefix "vlan";
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
} }
import iana-if-type { import iana-if-type {
prefix ianaift; prefix ianaift;
} }
skipping to change at page 41, line 11 skipping to change at page 42, line 11
</interfaces> </interfaces>
</data> </data>
</rpc-reply> </rpc-reply>
Appendix E. Example: NETCONF <get-data> Reply Appendix E. Example: NETCONF <get-data> Reply
This section gives an example of a reply to the NETCONF <get-data> This section gives an example of a reply to the NETCONF <get-data>
request for <operational> for a device that implements the example request for <operational> for a device that implements the example
data models above. data models above.
This example uses the "origin" annotation, which is defined in the
module "ietf-origin" [I-D.ietf-netmod-revised-datastores].
<rpc-reply <rpc-reply
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101"> message-id="101">
<data> <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-datastores">
<interfaces <interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type" xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
xmlns:vlan="http://example.com/vlan" xmlns:vlan="http://example.com/vlan"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
<interface or:origin="or:intended"> <interface or:origin="or:intended">
<name>eth0</name> <name>eth0</name>
<type>ianaift:ethernetCsmacd</type> <type>ianaift:ethernetCsmacd</type>
<enabled>false</enabled> <enabled>false</enabled>
skipping to change at page 43, line 16 skipping to change at page 44, line 18
</interface> </interface>
</interfaces> </interfaces>
</data> </data>
</rpc-reply> </rpc-reply>
Appendix F. Examples: Interface Naming Schemes Appendix F. Examples: Interface Naming Schemes
This section gives examples of some implementation strategies. This section gives examples of some implementation strategies.
The examples make use of the example data model "ex-vlan" (see The examples make use of the example data model "example-vlan" (see
Appendix C) to show how user-controlled interfaces can be configured. Appendix C) to show how user-controlled interfaces can be configured.
F.1. Router with Restricted Interface Names F.1. Router with Restricted Interface Names
In this example, a router has support for 4 line cards, each with 8 In this example, a router has support for 4 line cards, each with 8
ports. The slots for the cards are physically numbered from 0 to 3, ports. The slots for the cards are physically numbered from 0 to 3,
and the ports on each card from 0 to 7. Each card has Fast Ethernet and the ports on each card from 0 to 7. Each card has Fast Ethernet
or Gigabit Ethernet ports. or Gigabit Ethernet ports.
The device-specific names for these physical interfaces are The device-specific names for these physical interfaces are
 End of changes. 25 change blocks. 
62 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/