RFC 3535, 20 Years Later: An Update of Operators Requirements on Network Management Protocols and Modelling
draft-boucadair-nmop-rfc3535-20years-later-02
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Mohamed Boucadair , Luis M. Contreras , Oscar Gonzalez de Dios , Thomas Graf , Reshad Rahman | ||
| Last updated | 2024-03-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-boucadair-nmop-rfc3535-20years-later-02
Network Working Group M. Boucadair
Internet-Draft Orange
Intended status: Informational L. M. C. Murillo
Expires: 21 September 2024 O. G. D. Dios
Telefonica
T. Graf
Swisscom
R. Rahman
Equinix
20 March 2024
RFC 3535, 20 Years Later: An Update of Operators Requirements on Network
Management Protocols and Modelling
draft-boucadair-nmop-rfc3535-20years-later-02
Abstract
The IAB has organized an important workshop to establish a dialog
between network operators and protocol developers, and to guide the
IETF focus on work regarding network management. The outcome of that
workshop was documented in the "IAB Network Management Workshop" (RFC
3535) which was instrumental for developing NETCONF and YANG, in
particular.
20 years later, it is time to evaluate what has been achieved since
then and identify the operational barriers for making these
technologies widely implemented. Also, this document intends to
capture new requirements for network management operations.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/boucadair/rfc3535-20years-later.
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 https://datatracker.ietf.org/drafts/current/.
Boucadair, et al. Expires 21 September 2024 [Page 1]
Internet-Draft RFC 3535, 20 Years Later March 2024
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 21 September 2024.
Copyright Notice
Copyright (c) 2024 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 (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Summary of Technology Advances Since RFC 3535 . . . . . . . . 3
3. Assessment of RFC 3535 Recommendations . . . . . . . . . . . 4
4. Some Observations . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Fragmented Ecosystem . . . . . . . . . . . . . . . . . . 6
4.2. Lack of Profiling . . . . . . . . . . . . . . . . . . . . 6
4.3. Lack of Agile Process for (The Maintenance of) YANG
Modules . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Integration Complexity . . . . . . . . . . . . . . . . . 7
4.5. YANG-formatted Data Manipulation . . . . . . . . . . . . 8
4.6. Translation and Mapping Between Service/Network and Device
Models . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. (In)Consistent Data Structures in Network Protocols for
Data Export . . . . . . . . . . . . . . . . . . . . . . 8
4.8. Proprietary YANG Modules, CLI, and Limited Abstraction . 9
4.9. Distinct Networks, Distinct Management Requirements . . . 9
4.10. Implications of External Dependency . . . . . . . . . . . 10
4.11. Too Much Time Between Publication of New Networking
Functionality and the Associated YANG . . . . . . . . . 11
4.12. Open-source Tools . . . . . . . . . . . . . . . . . . . . 11
4.13. Another Item . . . . . . . . . . . . . . . . . . . . . . 11
5. Perspectives & Recommendations . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Informative References . . . . . . . . . . . . . . . . . . . 11
Boucadair, et al. Expires 21 September 2024 [Page 2]
Internet-Draft RFC 3535, 20 Years Later March 2024
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The IAB has organized a workshop (June 4-June 6, 2002) to establish a
dialog between network operators and protocol developers, and to
guide the IETF focus on work regarding network management. The
outcome of that workshop was documented in the "IAB Network
Management Workshop" [RFC3535] which was instrumental for developing
NETCONF [RFC6241], YANG [RFC6020][RFC7950], and RESTCONF [RFC8040].
20 years later, new requirements on network management operations are
emerging from the operators. This document intends to capture these
requirements that reflect the progress in this area. The document
also provide an assessment of the RFC3535 recommendations and to what
extend that roadmap was driving network management efforts within the
IETF.
Early version of the document includes *many placeholders on purpose*
as the intent is to collect inputs from interested parties. Items
listed in Section 4 are provided to exemplify candidate items to
discuss in that section.
2. Summary of Technology Advances Since RFC 3535
To be further elaborated:
* NETCONF [RFC6241]
* YANG [RFC7950]
* RESTCONF [RFC8040]
* SDN & Programmable Networks [RFC7149][RFC7426]
* Automation [RFC8969]
* Virtualization [RFC8568]
* Containerization [I-D.ietf-bmwg-containerized-infra]
* Intent-based [RFC9315]
* Network APIs
* Telemetry [RFC9232]
Boucadair, et al. Expires 21 September 2024 [Page 3]
Internet-Draft RFC 3535, 20 Years Later March 2024
* JSON Encoding of Data Modeled with YANG [RFC7951]
* CoAP Management Interface (CORECONF) [I-D.ietf-core-comi]
* YANG to CBOR mapping [RFC9254]
* YANG Schema Item iDentifier (YANG SID) [I-D.ietf-core-sid]
See also "An Overview of the IETF Network Management Standards"
[RFC6632].
3. Assessment of RFC 3535 Recommendations
Section 6 of [RFC3535] includes the following recommendations:
1. The workshop recommends that the IETF stop forcing working groups
to provide writable MIB modules. It should be the decision of
the working group whether they want to provide writable objects
or not.
*Status Update*: In 2014, the IESG published a statement
Writable MIB Module, which states that:
SNMP MIB modules creating and modifying configuration state
should only be produced by working groups in cases of clear
utility and consensus to use SNMP write operations for
configuration, and in consultation with the OPS ADs/MIB
doctors.
2. The workshop recommends that a group be formed to investigate why
current MIB modules do not contain all the objects needed by
operators to monitor their networks.
*Status Update*: xxx
3. The workshop recommends that a group be formed to investigate why
the current SNMP protocol does not satisfy all the monitoring
requirements of operators.
*Status Update*: xxx
4. The workshop recommends, with strong consensus from both protocol
developers and operators, that the IETF focus resources on the
standardization of configuration management mechanisms.
*Status Update*: NETCONF [RFC6241], RESTCONF [RFC8040], CORECONF
[I-D.ietf-core-comi], YANG.
Boucadair, et al. Expires 21 September 2024 [Page 4]
Internet-Draft RFC 3535, 20 Years Later March 2024
YANG is a transport-independent data modeling language. It
can be used independently of NETCONF/RESTCONF. For example,
YANG can be used to define abstract data structures [RFC8791]
that can be manipulated by other protocols (e.g., [RFC9132]).
5. The workshop recommends, with strong consensus from the operators
and rough consensus from the protocol developers, that the IETF/
IRTF should spend resources on the development and
standardization of XML-based device configuration and management
technologies (such as common XML configuration schemas, exchange
protocols and so on).
*Status Update*: OK. This recommendation was also mirrored in
other documents such as [RFC5706].
6. The workshop recommends, with strong consensus from the operators
and rough consensus from the protocol developers, that the IETF/
IRTF should not spend resources on developing HTML-based or HTTP-
based methods for configuration management.
*Status Update*: The IETF deviated from this recommendation,
e.g., RESTCONF [RFC8040] or CoAP Management Interface
(CORECONF) [I-D.ietf-core-comi].
7. The workshop recommends, with rough consensus from the operators
and strong consensus from the protocol developers, that the IETF
should continue to spend resources on the evolution of the SMI/
SPPI data definition languages as being done in the SMIng working
group.
*Status Update*: SMIng WG was concluded in 2003-04-04.
8. The workshop recommends, with split consensus from the operators
and rough consensus from the protocol developers, that the IETF
should spend resources on fixing the MIB development and
standardization processs.
*Status Update*: The IETF dedicated some resources to fix some
SNMP shortcomings with a focus on security (e.g., Transport
Layer Security (TLS) Transport Model for the SNMP [RFC6353] or
[RFC9456], HMAC-SHA-2 Authentication Protocols in User-Based
Security Model (USM) for SNMPv3 [RFC7860]).
Section 6 of [RFC3535] also includes the following but without
tagging them as recommendations:
Boucadair, et al. Expires 21 September 2024 [Page 5]
Internet-Draft RFC 3535, 20 Years Later March 2024
1. The workshop had split consensus from the operators and rough
consensus from the protocol developers, that the IETF should not
focus resources on CIM extensions.
*Status Update*: The IETF didn't dedicate any resources on CIM
extensions.
2. The workshop had rough consensus from the protocol developers
that the IETF should not spend resources on COPS-PR development.
So far, the operators have only very limited experience with
COPS-PR. In general, however, they felt that further development
of COPS-PR might be a waste of resources as they assume that
COPS-PR does not really address their requirements.
*Status Update*: The IETF has reclassified COPS Usage for Policy
Provisioning [RFC3084] to Historic status.
3. The workshop had rough consensus from the protocol developers
that the IETF should not spend resources on SPPI PIB definitions.
The operators had rough consensus that they do not care about
SPPI PIBs.
*Status Update*: The IETF has reclassified Structure of Policy
Provisioning Information [RFC3159], as well as three Policy
Information Bases ([RFC3317], [RFC3318], and [RFC3571]) to
Historic status.
4. Some Observations
4.1. Fragmented Ecosystem
The current YANG device models ecosystem is *fragmented*: some
standards models are defined in the IETF while similar ones are
defined in other fora such as Openconfig or ONF. Unlike service and
network models, IETF-defined device models are not widely
implemented. There is a need to rationalize this space and avoid
redundant efforts.
4.2. Lack of Profiling
Many NETCONF-related features are (being) specified by the IETF, but
these features are not widely supported (e.g., Push). Editing a
profile document with a set of recommendations about core/key
features with the appropriate justification will help the emergence
of more implementations that meet the operators’ needs.
Boucadair, et al. Expires 21 September 2024 [Page 6]
Internet-Draft RFC 3535, 20 Years Later March 2024
Examples of such profile documents are the various RFCs that were
published by the behave WG [BCP127]. Another approach is to
consider an approach similar to the "Roadmap for Transmission
Control Protocol (TCP) Specification Documents" [RFC7414]. Such a
document would serve as a guide and reference for implementers and
any other parties who desire information contained in the
'NETCONF/RESTCONF/YANG'-related RFCs.
Likewise, reassess the value of some IETF proposals vs. competing/
emerging solutions would be useful (e.g., gRPC vs. YANG-Push).
4.3. Lack of Agile Process for (The Maintenance of) YANG Modules
RFCs might not be suited for documenting YANG modules (it takes much
too long, especiallly for updates). In the meantime, there is a need
for "reference models" and "sufficiently stable models". An hybrid
approach might be investigated for documenting IETF- endorsed YANG
modules, such as considering an RFC to describe the initial module
sketch and objectives and an official IETF repository for maintaining
intermediate YANG versions.
4.4. Integration Complexity
Section 3 of [RFC3535] describes a set of network operator
requirements. One of the requirements is the ease of use which,
according to Section 3.2 of [RFC6244], is addressed by NETCONF and
YANG. For configuration this holds true, for network observability
it is unfortunately not yet. This has been confirmed with a set of
network operators asking how long it takes from subscribing YANG data
to make it accessible to the operator. Minutes, Hours, Days, or
Weeks. None of them answered Minutes or Hours. All of them
responded Days or Weeks. Hinting manual post processing of YANG
data.
Collecting YANG metrics from networks is already a struggle due to
late arrival of [RFC8639], [RFC8640], [RFC8641],
[I-D.ietf-netconf-https-notif], and [I-D.ietf-netconf-udp-notif] for
configured subscription transport protocols which defined YANG-Push
in the industry. This caused network vendors to implement
alternative solutions to collect real-time streaming data in the
meanwhile, such as gNMI which was proposed in 2018 in
[I-D.openconfig-rtgwg-gnmi-spec] to the IETF but not followed up on.
Unfortunately, these implementations differ between network Operating
Systems due to the lack of standardization, specifically for the
metadata which would ensure machine readability.
Boucadair, et al. Expires 21 September 2024 [Page 7]
Internet-Draft RFC 3535, 20 Years Later March 2024
When a set of network operators where asked to where operational YANG
data needs to be integrated to, the answer homogeneously was Apache
Kafka Message Broker and Time Series Databases. There is a need to
specify how YANG-Push can be integrated into Apache Kafka and
references needed YANG-Push extensions and YANG schema registry
development. The YANG-Push extensions addressing needs to make YANG-
Push messages machine readable and against semantic validate able to
ensure a consistent data processing.
Another challenge is that the subscribed YANG data referenced with
datastore-subtree-filter or datastore-xpath-filter breaks semantic
integrity which needs to be addressed by either updating Section 4 of
[RFC8641] or proposing a new YANG module being used at the YANG-Push
receiver.
4.5. YANG-formatted Data Manipulation
The use of a flat tree hierarchy in YANG models may induce some
performance issues compared to other graph models. See, for example,
[ODL].
4.6. Translation and Mapping Between Service/Network and Device Models
TBC.
4.7. (In)Consistent Data Structures in Network Protocols for Data
Export
Network Telemetry, as described in [RFC9232], involve a set of
protocols. Due to the different requirements, one Network Telemetry
protocol doesn't address all needs. This is mainly due to the nature
of the subscribed data. BGP Monitoring Protocol (BMP) [RFC7854] adds
monitoring and tracing capabilities natively to the BGP process to
minimize the processing overhead. While IPFIX [RFC7011][RFC7012] can
be applied according to [RFC5472] to gain visibility into the data
and forwarding planes, due to the amount of data, sampling as defined
in [RFC5476] and applied to IPFIX in [RFC5477] and aggregation as
defined in [RFC7015] for IPFIX is needed to reduce the amount of
exposed data. While YANG-Push focuses on exposing already YANG
modelled data, which eases the correlation among network
configuration and operational data.
[RFC9232] is an informational document and does not specify what
these Network Telemetry protocols should have in common to ensure
consistent data structures for data export. While data types are
fairly good aligned, a lack of metadata standardization among the
Network Telemetry protocols is observed. In particular describing
from where the metrics has been exported from and timestamping. In
Boucadair, et al. Expires 21 September 2024 [Page 8]
Internet-Draft RFC 3535, 20 Years Later March 2024
Section 4.2 of [RFC7854] timestamps are optional and sysName
[RFC1213] is only carried in the BMP initiation message (Section 4.3
of [RFC7854]), while the message header of IPFIX defined in
Section 4.3 of [RFC7011] lacks the sysName definition.
The lack of information from where the data is being pushed from is
only known to the Network Telemetry data collection due to the
transport session being established from the network node exporting
the information. When Network Telemetry messages are being
transformed and forwarded, this information is being lost.
Therefore, it is common among network operators to augment sysName
and other metadata at the data collection.
The same common principle applies to when observation timestamping is
missing in the Network Telemetry message. Since the data collection
is the closest element to the network, a time stamp is added to give
the network operator at least the information when the Network
Telemetry message was collected. However, since Network Telemetry
addresses real-time streaming needs, this is often not accurate
enough for data correlation.
4.8. Proprietary YANG Modules, CLI, and Limited Abstraction
Pluggins/Proxy YANG/CLI is still the rule in many operations.
Complexity in dev the pluggins (as you need to cover many OS/
vendors).
Network models for the realization provides some "level" of
abstraction and then automations.
TBC.
4.9. Distinct Networks, Distinct Management Requirements
From the time RFC 3535 was released up to now, new kind of services
and applications have been developed and deployed over the time, with
very diverse, and some times contradicting, requirements. Those
services have been engineered on top of multi-service networks for
the sake of efficiency and simplicity, accommodating such a variety
of needs. As a result, services requiring mobility, data
replication, large capacity, adaptability, multi-path support,
determinism, etc., coexist on the same shared network, needing from
it mechanisms for graceful operation.
Boucadair, et al. Expires 21 September 2024 [Page 9]
Internet-Draft RFC 3535, 20 Years Later March 2024
Likewise, such diversity of services also require different
management capabilities. For example, session continuity,
distribution trees, traffic engineering, congestion status
notification, reordering, or on-time delivery impose very different
management needs to be satisfied.
This reality is different from the one existing at the time of
[RFC3535], and as such, the new identified needs can require from
novel approaches to guarantee the aforementioned co-existence of
services.
Also, some networks have specific network management requirements
such as the need for asynchronous operations or constraints on data
compactness. An example of such networks is Delay-Tolerant
Networking (DTN) [RFC838].
4.10. Implications of External Dependency
Networks are being updated to abandon the silo approach from the past
towards an increasing convergence. Specifically, there are trends
towards a tighter interaction and integration of different
technologies previously considered as totally separated from an
operational perspective. Examples of that trends are the IP and
Optical integration (e.g., the introduction of colored interfaces on
routers), or the extension of deterministic-behavior features to
Layer 3 networks. This kind of convergence in most cases creates
dependencies on the conventional network management features, which
require to incorporate or integrate functionality from other
technological domains.
Furthermore, such convergence is also reflected on the need of
interacting and interworking with distinct network parts
participating in the end-to-end service delivery. Mobile access,
fixed access, data center, enterprise, radio functional split (i.e.,
fronthaul and midhaul), neutral exchanges, intensive data networks
(e.g., scientific academic networks), content distribution, etc.,
represent network parts constituent of end-to-end services that can
impose dependencies of the management of an intermediate network.
That convergence shown the last years also implies the need of an up-
to-date refresh of management capabilities and tooling of the
conventional networks. Also, it highlights the need to easily map
the data models that are used to manage each specific segment.
Boucadair, et al. Expires 21 September 2024 [Page 10]
Internet-Draft RFC 3535, 20 Years Later March 2024
4.11. Too Much Time Between Publication of New Networking Functionality
and the Associated YANG
For example, [RFC8667] (IS-IS extensions for SR) was published in
December 2019, while [I-D.ietf-isis-sr-yang] will be published ~5
years after.
Consider having YANG as part of the protocol specification/change
where possible, or have the YANG document progress in parallel. That
may slow down the protocol specification, though.
4.12. Open-source Tools
While there are open-source implementations for NETCONF (e.g.,
NETOPEER), the gRPC/gNMI suite seems to have more support for tools
on the client side. For example, "ygot" generates structures from
YANG models and these can easily be used by a client to configure a
device with gNMI. NETCONF is not supported though (we need the XML
tags).
4.13. Another Item
TBC.
5. Perspectives & Recommendations
TBC
6. Security Considerations
TBC.
7. IANA Considerations
This document has no IANA actions.
8. Informative References
[BCP127] Best Current Practice 127,
<https://www.rfc-editor.org/info/bcp127>.
At the time of writing, this BCP comprises the following:
Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>.
Boucadair, et al. Expires 21 September 2024 [Page 11]
Internet-Draft RFC 3535, 20 Years Later March 2024
Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common Requirements for Carrier-Grade
NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
April 2013, <https://www.rfc-editor.org/info/rfc6888>.
Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar,
S., and K. Naito, "Updates to Network Address Translation
(NAT) Behavioral Requirements", BCP 127, RFC 7857,
DOI 10.17487/RFC7857, April 2016,
<https://www.rfc-editor.org/info/rfc7857>.
[I-D.ietf-bmwg-containerized-infra]
Ngọc, T. M., Rao, S., Lee, J., and Y. Kim, "Considerations
for Benchmarking Network Performance in Containerized
Infrastructures", Work in Progress, Internet-Draft, draft-
ietf-bmwg-containerized-infra-00, 19 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bmwg-
containerized-infra-00>.
[I-D.ietf-core-comi]
Veillette, M., Van der Stok, P., Pelov, A., Bierman, A.,
and C. Bormann, "CoAP Management Interface (CORECONF)",
Work in Progress, Internet-Draft, draft-ietf-core-comi-17,
4 March 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-comi-17>.
[I-D.ietf-core-sid]
Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M.
Richardson, "YANG Schema Item iDentifier (YANG SID)", Work
in Progress, Internet-Draft, draft-ietf-core-sid-24, 22
December 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-sid-24>.
[I-D.ietf-isis-sr-yang]
Litkowski, S., Qu, Y., Sarkar, P., Chen, H., and J.
Tantsura, "A YANG Data Model for IS-IS Segment Routing for
the MPLS Data Plane", Work in Progress, Internet-Draft,
draft-ietf-isis-sr-yang-21, 22 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-isis-sr-
yang-21>.
[I-D.ietf-netconf-https-notif]
Jethanandani, M. and K. Watsen, "An HTTPS-based Transport
for YANG Notifications", Work in Progress, Internet-Draft,
draft-ietf-netconf-https-notif-15, 1 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
https-notif-15>.
Boucadair, et al. Expires 21 September 2024 [Page 12]
Internet-Draft RFC 3535, 20 Years Later March 2024
[I-D.ietf-netconf-udp-notif]
Zheng, G., Zhou, T., Graf, T., Francois, P., Feng, A. H.,
and P. Lucente, "UDP-based Transport for Configured
Subscriptions", Work in Progress, Internet-Draft, draft-
ietf-netconf-udp-notif-12, 21 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
udp-notif-12>.
[I-D.openconfig-rtgwg-gnmi-spec]
Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack,
C., and C. Morrow, "gRPC Network Management Interface
(gNMI)", Work in Progress, Internet-Draft, draft-
openconfig-rtgwg-gnmi-spec-01, 5 March 2018,
<https://datatracker.ietf.org/doc/html/draft-openconfig-
rtgwg-gnmi-spec-01>.
[ODL] "Graph Model Overview", 2023,
<https://docs.opendaylight.org/projects/bgpcep/en/latest/
graph/graph-user-guide-graph-model.html#>.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991,
<https://www.rfc-editor.org/rfc/rfc1213>.
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A.
Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
RFC 3084, DOI 10.17487/RFC3084, March 2001,
<https://www.rfc-editor.org/rfc/rfc3084>.
[RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn,
S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure
of Policy Provisioning Information (SPPI)", RFC 3159,
DOI 10.17487/RFC3159, August 2001,
<https://www.rfc-editor.org/rfc/rfc3159>.
[RFC3317] Chan, K., Sahita, R., Hahn, S., and K. McCloghrie,
"Differentiated Services Quality of Service Policy
Information Base", RFC 3317, DOI 10.17487/RFC3317, March
2003, <https://www.rfc-editor.org/rfc/rfc3317>.
[RFC3318] Sahita, R., Ed., Hahn, S., Chan, K., and K. McCloghrie,
"Framework Policy Information Base", RFC 3318,
DOI 10.17487/RFC3318, March 2003,
<https://www.rfc-editor.org/rfc/rfc3318>.
Boucadair, et al. Expires 21 September 2024 [Page 13]
Internet-Draft RFC 3535, 20 Years Later March 2024
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, DOI 10.17487/RFC3535, May
2003, <https://www.rfc-editor.org/rfc/rfc3535>.
[RFC3571] Rawlins, D., Kulkarni, A., Ho Chan, K., Bokaemper, M., and
D. Dutt, "Framework Policy Information Base for Usage
Feedback", RFC 3571, DOI 10.17487/RFC3571, August 2003,
<https://www.rfc-editor.org/rfc/rfc3571>.
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP
Flow Information Export (IPFIX) Applicability", RFC 5472,
DOI 10.17487/RFC5472, March 2009,
<https://www.rfc-editor.org/rfc/rfc5472>.
[RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet
Sampling (PSAMP) Protocol Specifications", RFC 5476,
DOI 10.17487/RFC5476, March 2009,
<https://www.rfc-editor.org/rfc/rfc5476>.
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
Carle, "Information Model for Packet Sampling Exports",
RFC 5477, DOI 10.17487/RFC5477, March 2009,
<https://www.rfc-editor.org/rfc/rfc5477>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions",
RFC 5706, DOI 10.17487/RFC5706, November 2009,
<https://www.rfc-editor.org/rfc/rfc5706>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/rfc/rfc6020>.
[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,
<https://www.rfc-editor.org/rfc/rfc6241>.
[RFC6244] Shafer, P., "An Architecture for Network Management Using
NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June
2011, <https://www.rfc-editor.org/rfc/rfc6244>.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)",
STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011,
<https://www.rfc-editor.org/rfc/rfc6353>.
Boucadair, et al. Expires 21 September 2024 [Page 14]
Internet-Draft RFC 3535, 20 Years Later March 2024
[RFC6632] Ersue, M., Ed. and B. Claise, "An Overview of the IETF
Network Management Standards", RFC 6632,
DOI 10.17487/RFC6632, June 2012,
<https://www.rfc-editor.org/rfc/rfc6632>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/rfc/rfc7011>.
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012,
DOI 10.17487/RFC7012, September 2013,
<https://www.rfc-editor.org/rfc/rfc7012>.
[RFC7015] Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation
for the IP Flow Information Export (IPFIX) Protocol",
RFC 7015, DOI 10.17487/RFC7015, September 2013,
<https://www.rfc-editor.org/rfc/rfc7015>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/rfc/rfc7149>.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
Zimmermann, "A Roadmap for Transmission Control Protocol
(TCP) Specification Documents", RFC 7414,
DOI 10.17487/RFC7414, February 2015,
<https://www.rfc-editor.org/rfc/rfc7414>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/rfc/rfc7426>.
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/rfc/rfc7854>.
[RFC7860] Merkle, J., Ed. and M. Lochter, "HMAC-SHA-2 Authentication
Protocols in User-Based Security Model (USM) for SNMPv3",
RFC 7860, DOI 10.17487/RFC7860, April 2016,
<https://www.rfc-editor.org/rfc/rfc7860>.
Boucadair, et al. Expires 21 September 2024 [Page 15]
Internet-Draft RFC 3535, 20 Years Later March 2024
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/rfc/rfc7950>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/rfc/rfc7951>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/rfc/rfc8040>.
[RFC838] Smallberg, D., "Who talks TCP?", RFC 838,
DOI 10.17487/RFC0838, January 1983,
<https://www.rfc-editor.org/rfc/rfc838>.
[RFC8568] Bernardos, CJ., Rahman, A., Zuniga, JC., Contreras, LM.,
Aranda, P., and P. Lynch, "Network Virtualization Research
Challenges", RFC 8568, DOI 10.17487/RFC8568, April 2019,
<https://www.rfc-editor.org/rfc/rfc8568>.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications",
RFC 8639, DOI 10.17487/RFC8639, September 2019,
<https://www.rfc-editor.org/rfc/rfc8639>.
[RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Dynamic Subscription to YANG Events
and Datastores over NETCONF", RFC 8640,
DOI 10.17487/RFC8640, September 2019,
<https://www.rfc-editor.org/rfc/rfc8640>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/rfc/rfc8641>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/rfc/rfc8667>.
[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
June 2020, <https://www.rfc-editor.org/rfc/rfc8791>.
Boucadair, et al. Expires 21 September 2024 [Page 16]
Internet-Draft RFC 3535, 20 Years Later March 2024
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
L. Geng, "A Framework for Automating Service and Network
Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
January 2021, <https://www.rfc-editor.org/rfc/rfc8969>.
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
"Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification", RFC 9132,
DOI 10.17487/RFC9132, September 2021,
<https://www.rfc-editor.org/rfc/rfc9132>.
[RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and
A. Wang, "Network Telemetry Framework", RFC 9232,
DOI 10.17487/RFC9232, May 2022,
<https://www.rfc-editor.org/rfc/rfc9232>.
[RFC9254] Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann,
C., and M. Richardson, "Encoding of Data Modeled with YANG
in the Concise Binary Object Representation (CBOR)",
RFC 9254, DOI 10.17487/RFC9254, July 2022,
<https://www.rfc-editor.org/rfc/rfc9254>.
[RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
Tantsura, "Intent-Based Networking - Concepts and
Definitions", RFC 9315, DOI 10.17487/RFC9315, October
2022, <https://www.rfc-editor.org/rfc/rfc9315>.
[RFC9456] Vaughn, K., Ed., "Updates to the TLS Transport Model for
SNMP", RFC 9456, DOI 10.17487/RFC9456, November 2023,
<https://www.rfc-editor.org/rfc/rfc9456>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Mohamed Boucadair
Orange
Email: mohamed.boucadair@orange.com
Luis Miguel Contreras Murillo
Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com
Boucadair, et al. Expires 21 September 2024 [Page 17]
Internet-Draft RFC 3535, 20 Years Later March 2024
Oscar Gonzalez de Dios
Telefonica
Email: oscar.gonzalezdedios@telefonica.co
Thomas Graf
Swisscom
Email: thomas.graf@swisscom.com
Reshad Rahman
Equinix
Email: rrahman@equinix.com
Boucadair, et al. Expires 21 September 2024 [Page 18]