RFC 7575
Autonomic Networking: Definitions and Design Goals
RFC 7575: Autonomic Networking: Definitions and Design Goals 🦋
Okay bestie, this one comes from the IRTF (Internet Research Task Force), not the IETF standards track. It's an Informational doc, so it's published for your information and isn't a standard. The lead author is M. Behringer, with M. Pritikin, S. Bjarnason, and A. Clemm, all at Cisco Systems. The other authors are B. Carpenter at Univ. of Auckland, S. Jiang at Huawei Technologies Co., Ltd, and L. Ciavaglia at Alcatel Lucent. It was published in June 2015, and its ISSN is 2070-1721. The title block doesn't list any RFC that it obsoletes or updates. 💅
Abstract ✨
Okay so, autonomic systems were first described way back in 2001. The big goal is self-management, which covers self-configuration, self-optimization, self-healing, and self-protection. An autonomic function gets there by needing very little help from human admins or centralized management systems, and it usually gets spread out across network elements too. 🌸
This doc sets up a shared vocabulary and lays out design goals, plus a list of what is not a design goal. It also includes a high-level reference model showing how the functional elements in an Autonomic Network work together. This document is a product of the IRTF's Network Management Research Group. 🧚
Status of This Memo 🎀
This document is not an Internet Standards Track specification. It's published for informational purposes only. 🫶
It's a product of the Internet Research Task Force (IRTF), which publishes the results of Internet-related research and development. Those results might not be suitable for deployment. This RFC represents the consensus of the Network Management Research Group of the IRTF. Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for the details.
You can find the current status of this document, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7575. 💜
Copyright Notice 🌈
Copyright (c) 2015 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, which you can find at http://trustee.ietf.org/license-info as they stand on the publication date. Please read these carefully, because they explain your rights and restrictions for this document. 👑
Table of Contents 🍓
1. Introduction to Autonomic Networking . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Self-Management . . . . . . . . . . . . . . . . . . . . . 5
3.2. Coexistence with Traditional Management . . . . . . . . . 6
3.3. Secure by Default . . . . . . . . . . . . . . . . . . . . 7
3.4. Decentralization and Distribution . . . . . . . . . . . . 8
3.5. Simplification of Autonomic Node Northbound Interfaces . 8
3.6. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8
3.7. Autonomic Reporting . . . . . . . . . . . . . . . . . . . 9
3.8. Common Autonomic Networking Infrastructure . . . . . . . 9
3.9. Independence of Function and Layer . . . . . . . . . . . 10
3.10. Full Life-Cycle Support . . . . . . . . . . . . . . . . . 10
4. Not among the Design Goals . . . . . . . . . . . . . . . . . 11
4.1. Eliminate Human Operators . . . . . . . . . . . . . . . . 11
4.2. Eliminate Emergency Fixes . . . . . . . . . . . . . . . . 11
4.3. Eliminate Central Control . . . . . . . . . . . . . . . . 11
5. An Autonomic Reference Model . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Informative References . . . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 151. Introduction to Autonomic Networking 🌸
Autonomic systems were first described in a manifesto by IBM in 2001 [Kephart]. The core idea is to take external systems out of a system's control loops and close those loops inside the autonomic system itself. The payoff is self-management: self-configuration, self-optimization, self-healing, and self-protection. ✨
IP networking was originally designed with similar properties in mind. An IP network should be distributed and redundant so it can survive outages in any part of the network. Routing protocols like OSPF and IS-IS show self-management, so they can be considered autonomic under this document's definition. 💖
Then IP networking evolved, and the ever-increasing intelligence of network elements often didn't go into the protocols to follow this paradigm. It went into external configuration systems instead. That made network elements depend on some process to manage them, either a human or a network management system. 😭
Autonomic functions can be defined in two ways:
- On a node level: Nodes interact with each other to form feedback loops.
- On a system level: Feedback loops include central elements as well.
System-level autonomy is implicitly or explicitly the subject in many IETF working groups, where interactions with controllers or network management systems get discussed. 🦋
This work focuses specifically on node-level autonomic functions. It's about making the algorithms at the node level smart enough to minimize dependency on human administrators and central management systems. 🫶
Some network deployments benefit from a fully autonomic approach, for example networks with a large number of relatively simple devices. Most networks that exist today, though, will need a mixed approach, where some functions are autonomic and others are centrally managed. Central management of networking functions clearly has advantages and will be chosen for many networking functions. This document doesn't decide which functions should be centralized or which should follow an autonomic approach. Instead, it should help you make that call for a given situation. 🧚
Autonomic function can't always discover all the information it needs. For example, policy-related information requires human input, because policy is by its nature derived and specified by humans. When input from some central intelligence is required, it arrives in a highly abstract, network-wide form. 🌈
Autonomic Computing in general, and Autonomic Networking in particular, have been academic study topics for many years. There's a lot of literature out there, including several useful overview papers (e.g., [Samaan], [Movahedi], and [Dobson]). This document focuses on concepts and definitions that seem mature enough to become the basis for interoperable specifications in the near future. Those specifications will need to coexist with traditional methods of network configuration and management, rather than replacing them with a fully autonomic system that has every property that would require. 💅
There's an important difference between "automatic" and "autonomic." "Automatic" refers to a predefined process, such as a script. "Autonomic" is used in the context of self-management. It includes feedback loops between elements, as well as northbound loops to central elements. See also the definitions in the next section. Generally, an automatic process works in a given environment but has to be adapted if the environment changes. An autonomic process can adapt to changing environments. 👑
This document provides the definitions and design goals for Autonomic Networking in the IETF and IRTF. It represents the consensus of the IRTF's Network Management Research Group (NMRG). 🍓
2. Definitions 💜
Here are the definitions we're using. 🎀
- Autonomic: Self-managing (self-configuring, self-protecting, self-healing, self-optimizing). It still allows high-level guidance from a central entity, through Intent (see below). An autonomic function adapts on its own to a changing environment. 👑
- Automatic: A process that happens without human intervention, with step-by-step execution of rules. However, it relies on humans defining the sequence of rules, so it isn't Autonomic in the full sense. For example, a start-up script is automatic but not autonomic. An automatic function may need manual adjustments if the environment changes. 🤖
- Intent: An abstract, high-level policy used to operate the network. Its scope is an autonomic domain, such as an enterprise network. It doesn't contain configuration or information for a specific node (see Section 3.2 on how Intent coexists with alternative management paradigms). It may contain information about a node with a specific role (for example, an edge switch) or a node running a specific function. Intent is typically defined and provided by a central entity. 🌸
- Autonomic Domain: A collection of autonomic nodes that instantiate the same Intent. 🦋
- Autonomic Function: A feature or function that requires no configuration and can derive all the information it needs through self-knowledge, discovery, or Intent. 🧚
- Autonomic Service Agent: An agent implemented on an autonomic node that implements an autonomic function, either in part (in the case of a distributed function) or in whole. 🫶
- Autonomic Node: A node that uses exclusively autonomic functions. It requires (!) no configuration. (Note that configuration can be used to override an autonomic function. See Section 3.2 for more details.) An Autonomic Node may operate on any layer of the networking stack. Examples are routers, switches, personal computers, call managers, etc. 💖
- Autonomic Network: A network containing exclusively autonomic nodes. It may contain one or several autonomic domains. 🌈
3. Design Goals 🎀
This section explains the high-level goals of Autonomic Networking, independent of any specific solutions. ✨
3.1. Self-Management 💖
okay so the original autonomic design goals from [Kephart] totally still apply to Autonomic Networks 🧚 the big goal is self-management, and it's made up of a bunch of "self" properties. the most commonly cited ones are:
- Self-configuration: functions don't need configuring by an admin or a management system. they configure themselves based on self-knowledge, discovery, and Intent ✨ discovery is the default way an autonomic function gets the info it needs to run 🔍
- Self-healing: autonomic functions adapt on their own to changes in the environment and fix problems automatically 🩹
- Self-optimizing: autonomic functions figure out on their own how to optimize their behavior against a set of well-defined goals 📈
- Self-protection: autonomic functions automatically secure themselves against potential attacks 🛡️
almost any network can be called "self-managing" as long as the definition of "self" is big enough 🌸 for example, a well-defined Software-Defined Networking (SDN) system, controller elements included, can be described overall as "autonomic" IF the controller gives the administrator an interface with the same properties as above (high level, network-wide, etc.) 💅
for the work in the IETF and IRTF, we define the "self" properties on the node level 🎀 the design goal is to make functions on network nodes self-managing, meaning minimally dependent on management systems or controllers, as well as human operators 🫶 self-managing functions on a node might need to swap info with other nodes to hit this goal 🦋
as mentioned in the intro, closed-loop control is a big deal for self-managing systems ✨ this implies peer-to-peer dialogues between the parties that make up the closed loop 💬 those dialogues need two-way "discussion" or "negotiation" between each pair or group of peers in the loop, so they can't easily use typical top-down command-response protocols 🙅♀️ also, a discovery phase is unavoidable before closed-loop control can happen 🔎 multiparty protocols are possible too, but they can be a LOT more complex 😭
3.2. Coexistence with Traditional Management 🎀
for the foreseeable future, autonomic nodes and networks will be the exception 🥹 autonomic behavior will start out being defined function by function, so coexistence with other network management paradigms has to be considered 🧩 examples are management by command line, SNMP, SDN (with related APIs), the Network Configuration Protocol (NETCONF), etc.
conflict resolution between a) autonomic default behavior and Intent and b) other methods is therefore required 🚦 this is handled through prioritization 💅 generally, autonomic mechanisms define a network-wide behavior, whereas the alternative methods are typically node by node 🖥️ node-based management concepts take a higher priority over autonomic methods 👑 this matches current autonomic functions, like routing, where a (statically configured) route beats the routing algorithm 🛣️ in short:
- lowest priority: autonomic default behavior
- medium priority: autonomic Intent
- highest priority: node-specific network management concepts, such as command line, SNMP, SDN, NETCONF, etc. How these concepts are prioritized is outside the scope of this document. 🫠
the above prioritization basically means a human administrator can always overrule autonomic behavior 🙋♀️ this is generally what network operators expect today, so it stays a design principle here ✨ in critical systems, such as atomic power plants, sometimes the opposite philosophy is used: the expectation is that a well-defined algorithm is more reliable than a human operator, especially in rare exception cases 🤖 networking generally doesn't follow that philosophy yet 🌈 still, warnings should be issued if node-specific overrides may conflict with autonomic behavior ⚠️
in other fields, autonomic mechanisms switch off automatically if certain conditions occur 🛫 like, the autopilot on a plane switches off if the plane is outside a predefined envelope of flight parameters 😳 the assumption is that the algorithms only work correctly if the input values are in expected ranges 📏 however, some opinions say that exceptional conditions are exactly the worst moment to switch off autonomic behavior, since pilots don't have the full picture at that point and may be super stressed 😰
for this reason, we suggest here to NOT generally disable autonomic functions when they hit unexpected conditions 🙅♀️ it's expected that doing so would add another level of unpredictability to networks, when the situation may already be hard to understand 🌀
3.3. Secure by Default 🔐
all autonomic interactions should be secure by default 🥰 this requires that any member of an autonomic domain can assert its membership using a domain identity, for example, a certificate issued by a domain certification authority 📜 this domain identity is used for nodes to learn about their neighboring nodes, to figure out the boundaries of the domain, and to cryptographically secure interactions within the domain 🔒 nodes from different domains can also mutually verify their identity and secure their interactions as long as they have a mutually respected trust anchor 🤝
a strong, cryptographically verifiable domain identity is a fundamental cornerstone of Autonomic Networking 🏛️ it can be leveraged to secure all communications, so it allows automatic security without traditional configuration, like preshared keys 🗝️ see also the document "Making The Internet Secure By Default" [Behringer] for more info 📚
autonomic functions must be able to adapt their behavior depending on the domain of the node they're interacting with 🦎
3.4. Decentralization and Distribution 🌐
the goal of Autonomic Networking is to minimize dependencies on central elements, so decentralization and distribution are fundamental to the concept 💫 if a problem can be solved in a distributed manner, it should not be centralized 🙌
in certain cases, it's operationally preferable today to keep a central repository of information, for example, a user database on an Authentication, Authorization, and Accounting (AAA) server 🗄️ an Autonomic Network should be able to use central systems like that in order to be deployable 🚀 it's also possible to distribute such databases, and those efforts should at least be considered 🧠 depending on the case, distribution may not be simple replication, and may involve more complex interactions and organization 🧩
3.5. Simplification of Autonomic Node Northbound Interfaces 🎈
even in a decentralized solution, certain information flows with central entities are required 📨 examples are high-level service definitions, as well as network status requests, audit information, logging, and aggregated reporting 📊
so nodes in an Autonomic Network require a northbound interface 🛎️ the design goal, though, is to keep this interface as simple and high level as possible 🍰
3.6. Abstraction 🪄
an administrator or autonomic management system interacts with an Autonomic Network on a high level of abstraction 🌤️ Intent is defined at a level of abstraction that's way higher than typical configuration parameters, for example, "optimize my network for energy efficiency" 💚 Intent must not be used to convey low-level commands or concepts, since those live on a different abstraction level 🙅♀️
for example, the administrator should not be exposed to the version of the IP protocol running in the network 🙈
also on the reporting and feedback side, an Autonomic Network abstracts information and provides high-level messages like "the link between node x and y is down" (possibly with an identifier for the specific link, in case there are multiple links) 🔗
3.7. Autonomic Reporting 📣
an Autonomic Network, while minimizing the need for user intervention, still needs to give users visibility like in traditional networks 👀 but in an Autonomic Network, reporting should happen on a network-wide basis 🌍 information about the network should be collected and aggregated by the network itself and presented in a consolidated way to the administrator 🗂️
the layers of abstraction provided via Intent need to be supported for reporting functions too, so users can tell how effective their Intent is 📈 for example, to assess how well the network performs against the Intent "optimize my network for energy efficiency", the network should provide aggregate info about the number of ports that were able to be shut down, plus the corresponding energy savings, while validating that current service levels are, on aggregate, still met ⚡
autonomic network events should concern the Autonomic Network as a whole, not individual systems in isolation 🧑🤝🧑 for example, the same failure symptom should not be reported from every system that observes it, but only once for the Autonomic Network as a whole ☝️ ultimately, the Autonomic Network should support exception-based management, where only events that truly need user attention actually notify the user 🔔 this requires capabilities that let systems within the network compare info and apply specific algorithms to decide what should be reported 🧮
3.8. Common Autonomic Networking Infrastructure 🏗️
[RFC7576] points out that there are already a number of autonomic functions available today 🙌 however, they're largely independent, and each has its own methods and protocols to communicate, discover, define, and distribute policy, etc. 🙃
so the goal of the work on Autonomic Networking in the IETF isn't just to create autonomic functions, but to define a common infrastructure that autonomic functions can use 🧱 this Autonomic Networking Infrastructure may contain common control and management functions such as messaging, service discovery, negotiation, Intent distribution, self-monitoring, and diagnostics, etc. 🧰 a common approach to define and manage Intent is also required 📋
refer to the reference model below 👇 all the components around the "Autonomic Service Agents" should be common components, so the Autonomic Service Agents don't have to replicate common tasks individually 💜
3.9. Independence of Function and Layer
okay so autonomic functions can live on literally any layer of the networking stack 🦋 Layer 2 switching is already kinda autonomic bc most switches can get plugged together in tons of ways and will automatically build a simple Layer 2 topology ✨ routing runs higher up and can be autonomic at Layer 3 💅 and even app-layer stuff like unified communications can be autonomic 🫶
"Autonomic" in this framework is a property of a function that's implemented on a node 💖 autonomic functions can be implemented on any node type, like a switch, router, server, or call manager 🌸
An Autonomic Network needs an overall control plane so autonomic nodes can talk to each other 🎀 just like regular IP networking, IP is the spanning layer that binds everything together, so autonomic functions here should operate at the IP layer 👑 this covers neighbor discovery protocols and other functions in the Autonomic Control Plane 🧚
3.10. Full Life-Cycle Support
an autonomic function doesn't depend on external input to operate 🙈 it needs to understand its current situation and surroundings and operate according to its current state ✨ so it has to understand the full life cycle of the device it runs on, from manufacturing and initial testing all the way through deployment, testing, troubleshooting, and decommissioning 💅
the life-cycle state of an autonomic node is reflected in a state model 🦋 and the behavior of an autonomic function may be different for different deployment states 💜
4. Not among the Design Goals ✨
this section lists stuff that's explicitly not a design goal for Autonomic Networks in the IETF and IRTF 💅 they're mentioned so nobody gets the wrong idea 🙈 they address some concerns network admins and architects keep bringing up 🫶
4.1. Eliminate Human Operators
okay so Section 3.1 says "It is the design goal to make functions [...] minimally dependent on [...] human operators". but it is NOT a design goal to completely get rid of them 😭 the problem Autonomic Networking is targeting is the error-prone, hard-to-scale model of configuring network elements one by one, traditionally with manual commands and today mostly with scripting and/or configuration management databases 🥱 that doesn't mean skilled human operators disappear 💖 they're still needed for oversight, policy management, diagnosis, reacting to help-desk tickets, etc. the main change for admins should be less tedious detailed work and more high-level work 👑 (they should become more like doctors than hospital orderlies 🩺✨)
4.2. Eliminate Emergency Fixes
however good the autonomous mechanisms are, there will still be fault conditions they can't handle correctly 💀 at that point skilled operators need to step in and fix or work around the problem 🎀 hopefully that can be done with high-level mechanisms (adapting the policy database somehow), but sometimes direct intervention at the device level is unavoidable 🙃 that's obviously true for hardware failures, even if the Autonomic Network has bypassed the fault for the time being 🔧 "Truck rolls" will not be eliminated when faulty equipment needs replacing 🚚 but it may be less urgent if the autonomic system automatically reconfigures to minimize the operational impact 🌈
4.3. Eliminate Central Control
it's a goal to simplify northbound interfaces (Section 3.5) ✨ but it's NOT a goal to eliminate central control, just to allow it at a higher abstraction level 💅 senior management might be scared of losing control of an Autonomic Network 😭 but that's no more likely than with a traditional network, and the emphasis on automatically applying general policy and security rules might even give more central control 👑
5. An Autonomic Reference Model 🦋
an Autonomic Network is made of Autonomic Nodes 💖 those nodes talk to each other through an Autonomic Control Plane, which is a robust and secure communications overlay 🫶 the Autonomic Control Plane is self-organizing and autonomic itself 🧚
an Autonomic Node has a bunch of elements, like autonomic service agents that implement autonomic functions 🎀 Figure 1 shows the reference model of an autonomic node 🌸 the elements and how they interact are:
- Autonomic Service Agents: They implement the autonomic behavior of a specific service or function.
- Self-knowledge: An autonomic node knows its own properties and capabilities
- Network Knowledge (Discovery): An Autonomic Service Agent may require various discovery functions in the network, such as service discovery.
- Feedback Loops: Control elements outside the node may interact with autonomic nodes through feedback loops.
- An Autonomic User Agent, providing a front-end to external users (administrators and management applications) through which they can receive reports and monitor the Autonomic Network.
- Autonomic Control Plane: Allows the node to communicate with other autonomic nodes. Autonomic functions such as Intent distribution, feedback loops, discovery mechanisms, etc., use the Autonomic Control Plane. The Autonomic Control Plane can run in-band, over a configured VPN, over a self-managing overlay network as described in [ACP], or over a traditional out-of-band network. Security is a requirement for the Autonomic Control Plane, which can be bootstrapped by a mechanism as described in [BOOTSTRAP].
+------------------------------------------------------------+
| +------------+ |
| | Feedback | |
| | Loops | |
| +------------+ |
| ^ |
| Autonomic User Agent |
| V |
| +-----------+ +------------+ +------------+ |
| | Self- | | Autonomic | | Network | |
| | knowledge |<------>| Service |<------>| Knowledge | |
| | | | Agents | | (Discovery)| |
| +-----------+ +------------+ +------------+ |
| ^ ^ |
| | | |
| V V |
|------------------------------------------------------------|
| Autonomic Control Plane |
|------------------------------------------------------------|
| Standard Operating System Functions |
+------------------------------------------------------------+Figure 1: Reference Model for an Autonomic Node
at the time this doc was finalized, the reference model was still being worked out in more detail 🛠️ see [Reference-Model] for more details 💅
6. Security Considerations 🔐
this document provides definitions and design goals for Autonomic Networking 💜 a full threat analysis will be required as part of developing solutions 😱 it has to take into account potential attacks from within the network as well as from outside 🚨
7. Informative References ✨
[ACP] Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An
Autonomic Control Plane", Work in Progress,
draft-behringer-anima-autonomic-control-plane-02, March
2015.
[Behringer]
Behringer, M., Pritikin, M., and S. Bjarnason, "Making The
Internet Secure By Default", Work in Progress,
draft-behringer-default-secure-00, January 2014.
[BOOTSTRAP]
Pritikin, M., Behringer, M., and S. Bjarnason,
"Bootstrapping Key Infrastructures", Work in Progress,
draft-pritikin-anima-bootstrapping-keyinfra-01, February
2015.
[Dobson] Dobson, S., Denazis, S., Fernandez, A., Gaiti, D.,
Gelenbe, E., Massacci, F., Nixon, P., Saffre, F., Schmidt,
N., and F. Zambonelli, "A survey of autonomic
communications", ACM Transactions on Autonomous and
Adaptive Systems (TAAS), Volume 1, Issue 2, Pages 223-259,
DOI 10.1145/1186778.1186782, December 2006.
[GANA] ETSI, "Autonomic network engineering for the self-managing
Future Internet (AFI); Generic Autonomic Network
Architecture (An Architectural Reference Model for
Autonomic Networking, Cognitive Networking and Self-
Management)", ETSI GS AFI 002, April 2013,
<http://www.etsi.org/deliver/etsi_gs/
AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf>.
[Kephart] Kephart, J. and D. Chess, "The Vision of Autonomic
Computing", IEEE Computer, vol. 36, no. 1, pp. 41-50,
DOI 10.1109/MC.2003.1160055, January 2003.
[Movahedi] Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A
Survey of Autonomic Network Architectures and Evaluation
Criteria", IEEE Communications Surveys & Tutorials, Volume
14, Issue 2, Pages 464-490,
DOI 10.1109/SURV.2011.042711.00078, 2012.
[Reference-Model]
Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
L., and B. Liu, "A Reference Model for Autonomic
Networking", Work in Progress, draft-behringer-anima-
reference-model-02, June 2015.
[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap
Analysis for Autonomic Networking", RFC 7576,
DOI 10.17487/RFC7576, June 2015,
<http://www.rfc-editor.org/info/rfc7576>.
[Samaan] Samaan, N. and A. Karmouch, "Towards Autonomic Network
Management: an Analysis of Current and Future Research
Directions", IEEE Communications Surveys and Tutorials,
Volume 11, Issue 3, Page(s) 22-36,
DOI 10.1109/SURV.2009.090303, 2009.Acknowledgements 💖
many parts of this work on Autonomic Networking came out of a big team project at Cisco Systems 🫶 in alphabetical order: Ignas Bagdonas, Parag Bhide, Balaji BL, Toerless Eckert, Yves Hertoghs, Bruno Klauser 🌸
we thank the following people for their input to this document: Dimitri Papadimitriou, Rene Struik, Kostas Pentikousis, Dave Oran, and Diego Lopez Garcia 🙌
the ETSI working group AFI <http://portal.etsi.org/afi> defines a similar framework for Autonomic Networking in the "General Autonomic Network Architecture" [GANA] 🧚 a lot of the concepts in this document can be mapped to the GANA framework, but the mapping is outside the scope of this document 🦋 special thanks to Ranganai Chaparadza for his comments and help on this document 💜
Authors' Addresses 💌
okay bestie, here are the humans behind this doc, and they're literally the reason it exists 🫶 Here's where you can find each of them.
Michael H. Behringer 🎀
Michael H. Behringer
Cisco Systems
Building D, 45 Allee des Ormes
Mougins 06250
France
EMail: mbehring@cisco.comMax Pritikin 💜
Max Pritikin
Cisco Systems
5330 Airport Blvd
Boulder, CO 80301
United States
EMail: pritikin@cisco.comSteinthor Bjarnason 🌸
Steinthor Bjarnason
Cisco Systems
Mail Stop LYS01/5
Philip Pedersens vei 1
LYSAKER, AKERSHUS 1366
Norway
EMail: sbjarnas@cisco.comAlexander Clemm 🦋
Alexander Clemm
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706
United States
EMail: alex@cisco.comBrian Carpenter 🍓
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland 1142
New Zealand
EMail: brian.e.carpenter@gmail.comSheng Jiang ⭐
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing 100095
China
EMail: jiangsheng@huawei.comLaurent Ciavaglia 👑
Laurent Ciavaglia
Alcatel Lucent
Route de Villejust
Nozay 91620
France
EMail: laurent.ciavaglia@alcatel-lucent.comThat's the whole squad, periodt 💅✨
📦 where this page comes from
- ietf: rfc7575 2015-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms