RFC 7408
Forwarding and Control Element Separation (ForCES) Model Extension
RFC 7408: Forwarding and Control Element Separation (ForCES) Model Extension 🦋
Okay bestie, let's get into RFC 7408 💖 It's called "Forwarding and Control Element Separation (ForCES) Model Extension." E. Haleplidis from the University of Patras wrote it, and it came out in November 2014 as a Standards Track document (ISSN 2070-1721). It updates RFC 5812, and the header doesn't list anything it obsoletes. This is part 1 of 6 ✨
Abstract 🌸
So this memo glows up the ForCES model from RFC 5812 💅 It updates that RFC so you can use complex data types for metadata, optional default values for data types, and optional access types for structures. It also fixes a problem with Logical Functional Block (LFB) inheritance and adds two new features: a new event condition called eventBecomesEqualTo, and LFB properties. The best part? None of this changes the protocol, and older LFB models still work 🫶
Status of This Memo 📜
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7408.
Copyright Notice ⚖️
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents 🗺️
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
1.2. Terminology ................................................3
2. ForCES Model Extensions .........................................3
2.1. Complex Data Types for Metadata ............................3
2.2. Optional Default Values for Data Types .....................5
2.3. Optional Access Types for Structs ..........................8
2.4. New Event Condition: eventBecomesEqualTo ..................11
2.5. LFB Properties ............................................12
2.6. LFB Class Inheritance .....................................14
2.7. Enhancing XML Validation ..................................15
3. XML Extension Schema for LFB Class Library Documents ...........15
4. IANA Considerations ............................................29
5. Security Considerations ........................................29
6. References .....................................................30
6.1. Normative References ......................................30
6.2. Informative References ....................................30
Acknowledgements ..................................................31
Author's Address ..................................................311. Introduction 🌈
The ForCES model [RFC5812] gives you a formal way to define Forwarding Element (FE) Logical Functional Blocks (LFBs) using the eXtensible Markup Language (XML). [RFC5812] came out several years before this document, and using it in the real world showed us that we need to add some new modeling concepts and change some existing ones.
Specifically, this document updates the ForCES model [RFC5812] to allow complex data types for metadata (Section 2.1), optional default values for data types (Section 2.2), and optional access types for structures (Section 2.3). It also fixes an issue with LFB class inheritance (Section 2.6). On top of that, the document introduces two new features: a new event condition named eventBecomesEqualTo (Section 2.4) and LFB properties (Section 2.5).
These extensions are an update to the ForCES model [RFC5812] and do not require any changes to the ForCES protocol [RFC5810], because they're simply changes to the schema definition. Backward compatibility is also ensured, since XML libraries made with the earlier schema are still valid with the new one. Here's the catch 👀 For XML libraries made with the new schema to work with existing ForCES implementations, the XML libraries MUST NOT include any of the features described in this document.
Extensions to the schema, and excerpts of the schema, include the tags <!-- Extension RFC 7408 --> and <!-- /Extension RFC 7408 -->. These mark the beginning and end of the extension text this document specifies, relative to the schema in the original ForCES model [RFC5812].
1.1. Requirements Language 📏
Time for the rules-lawyer bit 🤓 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
1.2. Terminology 📖
This document uses the terminology defined in the ForCES model [RFC5812]. In particular, the reader is expected to be familiar with the following terms:
- FE Model
- LFB (Logical Functional Block) Class (or type)
- LFB Instance
- LFB Model
- Element
- Attribute
- LFB Metadata
- ForCES Component
- LFB Class Library
2. ForCES Model Extensions 💅
2.1. Complex Data Types for Metadata 🎀
Section 4.6 ("<metadataDefs> Element for Metadata Definitions") of the ForCES model [RFC5812] limits the data type use in metadata to only atomic types. Figure 1 shows the XML schema excerpt where only typeRef and atomic are allowed for a metadata definition.
<xsd:complexType name="metadataDefsType">
<xsd:sequence>
<xsd:element name="metadataDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="metadataID" type="xsd:integer"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>Figure 1: Initial metadataDefsType Definition in the Schema
However, there are cases where complex metadata gets used in the datapath 🚀 For example, two simple use cases are described in version 1.1.0 (and subsequent versions) of the OpenFlow Switch Specification [OpenFlowSpec1.1]:
- The Action Set metadata is an array of actions descriptors, which traverses the processing pipeline along with the packet data.
- When a packet is received from a controller, it may be accompanied by a list of actions, as metadata, to be performed on it prior to being sent on the processing pipeline. This list of actions is also an array.
With the extension shown in Figure 2, complex data types are also allowed, specifically structs and arrays as metadata. The key declarations are required to check for validity of content keys in arrays and componentIDs in structs. ✨
<xsd:complexType name="metadataDefsType">
<xsd:sequence>
<xsd:element name="metadataDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="metadataID" type="xsd:integer"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/>
<!-- Extension RFC 7408 -->
<xsd:element name="array" type="arrayType">
<xsd:key name="contentKeyID1">
<xsd:selector xpath="lfb:contentKey"/>
<xsd:field xpath="@contentKeyID"/>
</xsd:key>
</xsd:element>
<xsd:element name="struct" type="structType">
<xsd:key name="structComponentID1">
<xsd:selector xpath="lfb:component"/>
<xsd:field xpath="@componentID"/>
</xsd:key>
</xsd:element>
<!-- /Extension RFC 7408 -->
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>Figure 2: New metadataDefsType Definition in the Schema
2.2. Optional Default Values for Data Types ✨
okay so the original schema is kinda strict here 😭 default values only work for data types defined inside LFB components, NOT inside structs or arrays. so if you keep reusing something like a counter that starts at 0, you have to respecify that 0 every single time. and you can't give a counter inside a struct a default value either. literally so annoying 💀
this extension fixes that by letting you add default values to data types themselves 🎀 then you can reference them as simple components or inside complex types like structs. the simplest use case is a struct where one of the parts is a counter that starts at zero. to do that, you define the counter as a data type with its default value first, then reference it in the struct. slay 💅
Default values MUST adhere the following formal restrictions:
- Default values MUST be ignored if the data type is not an atomic or a base data type.
- When a data type X with default value A is referenced from a data type Y with a default value B, the default value of the data type that references overrides the referenced default value, e.g., in this case, Y's default value will be B.
- Default values of LFB components override any default value specified from the dataTypeDef definition.
- Default values of data types referenced in capabilities or metadata MUST be ignored.
this extension just adds to the dataTypeDefsType definition in the XML schema (the one in Figure 3) so that dataTypeDefsType can take default values 🌸 the updated version is in Figure 4.
<xsd:complexType name="dataTypeDefsType">
<xsd:sequence>
<xsd:element name="dataTypeDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element name="derivedFrom" type="xsd:NMTOKEN"
minOccurs="0"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>Figure 3: Initial Excerpt of dataTypeDefsType Definition in the Schema
<xsd:complexType name="dataTypeDefsType">
<xsd:sequence>
<xsd:element name="dataTypeDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element name="derivedFrom" type="xsd:NMTOKEN"
minOccurs="0"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
<!-- Extension RFC 7408 -->
<xsd:element name="defaultValue" type="xsd:token"
minOccurs="0"/>
<!-- /Extension RFC 7408 -->
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>Figure 4: New Excerpt of dataTypeDefsType Definition in the Schema
here's what using default values looks like, shown in Figure 5 🧚
<dataTypeDef>
<name>ZeroCounter</name>
<synopsis>A counter with default 0</synopsis>
<typeRef>uint32</typeRef>
<defaultValue>0</defaultValue>
</dataTypeDef>
<dataTypeDef>
<name>CounterValues</name>
<synopsis>Example default values in struct</synopsis>
<struct>
<component componentID="1">
<name>GoodPacketCounter</name>
<synopsis>A counter for good packets</synopsis>
<typeRef>ZeroCounter</typeRef>
</component>
<component componentID="2">
<name>BadPacketCounter</name>
<synopsis>A counter for bad packets</synopsis>
<typeRef>ZeroCounter</typeRef>
</component>
</struct>
</dataTypeDef>Figure 5: Example of Optional Default Values
2.3. Optional Access Types for Structs 🦋
okay so in the original, the access type can only be set on components of an LFB, NOT on components inside structs or arrays 😤 which means if you've got a struct, you can't fine-tune the access type for each part of it. the simple use case: you've got a read-write struct, and one of its parts is a counter that should be read-reset or read-only. like, a read-only counter living inside a struct 🥺
this extension lets you define the access type for a struct component either in the data type definitions or in the LFB component definitions.
When optional access types for components within a struct are defined, the access types for these components MUST override the access type of the struct. For example, if a struct has an access type of read-write but has a component that is a read-only counter, the counter's access type MUST be read-only.
Per [RFC5812], the access type for a component in a capability is always read-only. If an access type is provided for a component in a capability, the access type MUST be ignored. Similarly, if an access type is provided for a struct in a metadata, the access type MUST be ignored.
this extension changes the struct definition in the XML schema from the original version (Figure 6) to the new one (Figure 7) 💜
<xsd:complexType name="structType">
<xsd:sequence>
<xsd:element name="derivedFrom" type="typeRefNMTOKEN"
minOccurs="0"/>
<xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
<xsd:attribute name="componentID" type="xsd:unsignedInt"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>Figure 6: Initial XML for the Struct Definition in the Schema
<xsd:complexType name="structType">
<xsd:sequence>
<xsd:element name="derivedFrom" type="typeRefNMTOKEN"
minOccurs="0"/>
<xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
<!-- Extension RFC 7408 -->
<xsd:attribute name="access" use="optional"
default="read-write">
<xsd:simpleType>
<xsd:list itemType="accessModeType"/>
</xsd:simpleType>
</xsd:attribute>
<!-- /Extension RFC 7408 -->
<xsd:attribute name="componentID" type="xsd:unsignedInt"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>Figure 7: New XML for the Struct Definition in the Schema
and here's an example of optional access types for structs, Figure 8 🌈
<component componentID="1" access="read-write">
<name>PacketFlows</name>
<synopsis>Packet Flows, match and counter</synopsis>
<struct>
<component componentID="1">
<name>FlowMatch</name>
<synopsis>Flow Match</synopsis>
<typeRef>MatchType</typeRef>
</component>
<component componentID="2" access="read-only">
<name>MatchCounter</name>
<synopsis>Packets matching the flow match</synopsis>
<typeRef>ZeroCounter</typeRef>
</component>
</struct>
</component>Figure 8: Example of Optional Access Types for Struct
2.4. New Event Condition: eventBecomesEqualTo 🔥
this extension adds one more event condition to the model schema: eventBecomesEqualTo 👑 it's different from eventGreaterThan and eventLessThan because the event fires when the value is exactly equal to the eventBecomesEqualTo threshold. it's super useful when you need to watch one or more states of an LFB or the FE. like, in the Control Element High Availability (CEHA) document [RFC7121], the master CE might want to know which backup CEs have just become associated so it can connect to them and start syncing the FE state. the master CE could always poll for that, but getting an event is faster, and it's handy for other state monitoring too 🫶
The event MUST be triggered only when the value of the targeted component becomes equal to the event condition value. Implementations MUST NOT generate subsequent events while the targeted component's value remains equal to the event condition's value.
eventBecomesEqualTo gets appended to the schema like in Figure 9 🍓
<xsd:element name="eventBecomesEqualTo"
substitutionGroup="eventCondition"/>Figure 9: New Excerpt of eventBecomesEqualTo Event Condition Definition in the Schema
sometimes the CE also needs to know when the state changes after an eventBecomesEqualTo has fired. like, the CE might need to know when a backup CE has lost association 😭 you can get that in one of two ways: define a second event on the same component (an eventChanged), or just reuse eventBecomesEqualTo with event properties (especially eventHysteresis). we append the following definition to the eventHysteresis from Section 4.8.5.2 of [RFC5812], with V being the hysteresis value:
- For an eventBecomesEqualTo condition, after the last notification, a new eventBecomesEqualTo notification MUST be generated only one time once the value has changed by +/- V.
for example, using a value of 1 for V will basically create a singular event that tells the CE the value has changed by at least 1 🦋
a developer of a CE should consider using count or time filtering so they don't get overrun with messages, especially if the state changes rapidly 💖
2.5. LFB Properties 💖
okay so LFBs have components with their own properties, right? 🧚 Experience has shown that, at least for debugging, it would be super useful to have statistics for each LFB instance that track messages and errors sent and received between a CE and an FE. 📊 These properties are read-only, so nobody gets to mess with them 🙅♀️
Now the important part 👑 To avoid any confusion about what a protocol path means, this document says that LFB componentID 0 specifically MUST refer to LFB properties, and ID 0 MUST NOT be used for any component definition 🫶 This is backward compatible because no known LFB definition uses componentID 0, so nothing breaks. ✨ Any command whose path starts from LFB componentID 0 refers to LFB properties. Figures 10 and 11 show how the XML schema changes to rule out componentID 0 💅
<xsd:attribute name="componentID" type="xsd:unsignedInt"
use="required">Figure 10: Initial XML for LFB componentIDs
<!-- Extension added restriction to componentID -->
<xsd:attribute name="componentID" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:unsignedInt">
<xsd:minExclusive value="0"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<!-- End of extension -->Figure 11: New XML to Disallow Usage of LFB componentID 0
The following data type definitions are to be used as properties for LFB instances 🌸
<dataTypeDef>
<name>LFBProperties</name>
<synopsis>LFB Properties definition</synopsis>
<struct>
<component componentID="1">
<name>PacketsSentToCE</name>
<synopsis>Packets sent to CE</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>SentErrorPacketsToCE</name>
<synopsis>Error Packets sent to CE</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>BytesSentToCE</name>
<synopsis>Bytes sent to CE</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>SentErrorBytesToCE</name>
<synopsis>Error Bytes sent to CE</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="5">
<name>PacketsReceivedFromCE</name>
<synopsis>Packets received from CE</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="6">
<name>ReceivedErrorPacketsFromCE</name>
<synopsis>Error Packets received from CE</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="7">
<name>BytesReceivedFromCE</name>
<synopsis>Bytes received from CE</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="8">
<name>ReceivedErrorBytesFromCE</name>
<synopsis>Error Bytes received from CE</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>Figure 12: Properties for LFB Instances
2.6. LFB Class Inheritance
okay so the ForCES model [RFC5812] lets LFB classes inherit from each other 🦋 The catch is that the XML schema only says which LFB class is the parent, not which version of it. 🙈 Recent implementations ran into trouble when different versions of the parent class existed, because it got ambiguous. So this document adds an optional version attribute to the derivedFrom part of the LFB class definition, but only when derivedFrom is used 💜
Why optional? Because it keeps backward compatibility with the XML schema in [RFC5812] 🫶 But heads up: if you leave the version out, derivedFrom will always point to the first version of the parent LFB class, which is usually version 1.0 ⭐
This extension changes the derivedFrom definition in the XML schema from the original in Figure 13 to the new one in Figure 14 🎀
<xsd:element name="derivedFrom" minOccurs="0"/>Figure 13: Initial XML for LFB Class Inheritance
<xsd:element name="derivedFrom" minOccurs="0">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKEN">
<xsd:attribute name="version"
type="versionType" use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>Figure 14: New XML for LFB Class Inheritance
Here's how the version attribute looks in use, from Figure 15 🍓
<derivedFrom version="1.0">EtherPHYCop</derivedFrom>Figure 15: Example of Use of New XML for LFB Class Inheritance
2.7. Enhancing XML Validation
as we said earlier, this isn't really an extension, it's an enhancement to the schema that adds extra validation rules 🔍 It includes new key declarations to give uniqueness, as defined by the ForCES model [RFC5812]. These checks only work inside the same XML file, so keep that in mind 🧐
This document introduces these validation rules, which did not exist in the original schema in [RFC5812]:
- Each metadataID must be unique.
- LFBClassIDs must be unique.
- componentID, capabilityID, and Event baseID must be unique per LFB.
- eventIDs must be unique per LFB.
- Special values in atomic data types must be unique per atomic data type.
3. XML Extension Schema for LFB Class Library Documents ✨
okay the new XML schema is right here 🌈 Note that the namespace number has been bumped from 1.0 to 1.1 🦋
The extensions in this document are backwards compatible when it comes to how the ForCES protocol operates 🫶 For the XML, anything that was valid under the old namespace is still valid under the new one. Just note that any auxiliary tools processing XML definitions written under both namespaces will need to understand both 💅
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
xmlns:lfb="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
targetNamespace="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:annotation>
<xsd:documentation xml:lang="en">
Schema for Defining LFB Classes and associated types
(frames, data types for LFB attributes, and metadata).
</xsd:documentation>
</xsd:annotation>
<xsd:element name="description" type="xsd:string"/>
<xsd:element name="synopsis" type="xsd:string"/>
<!-- Document root element: LFBLibrary -->
<xsd:element name="LFBLibrary">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="load" type="loadType"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="frameDefs" type="frameDefsType"
minOccurs="0"/>
<xsd:element name="dataTypeDefs" type="dataTypeDefsType"
minOccurs="0"/>
<xsd:element name="metadataDefs" type="metadataDefsType"
minOccurs="0"/>
<xsd:element name="LFBClassDefs" type="LFBClassDefsType"
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="provides" type="xsd:Name"
use="required"/>
</xsd:complexType>
<!-- Uniqueness constraints -->
<xsd:key name="frame">
<xsd:selector xpath="lfb:frameDefs/lfb:frameDef"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="dataType">
<xsd:selector xpath="lfb:dataTypeDefs/lfb:dataTypeDef"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="metadataDef">
<xsd:selector xpath="lfb:metadataDefs/lfb:metadataDef"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="metadataDefID">
<xsd:selector xpath="lfb:metadataDefs/lfb:metadataDef"/>
<xsd:field xpath="lfb:metadataID"/>
</xsd:key>
<xsd:key name="LFBClassDef">
<xsd:selector xpath="lfb:LFBClassDefs/lfb:LFBClassDef"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="LFBClassDefID">
<xsd:selector xpath="lfb:LFBClassDefs/lfb:LFBClassDef"/>
<xsd:field xpath="@LFBClassID"/>
</xsd:key>
</xsd:element>
<xsd:complexType name="loadType">
<xsd:attribute name="library" type="xsd:Name" use="required"/>
<xsd:attribute name="location" type="xsd:anyURI"
use="optional"/>
</xsd:complexType>
<xsd:complexType name="frameDefsType">
<xsd:sequence>
<xsd:element name="frameDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="dataTypeDefsType">
<xsd:sequence>
<xsd:element name="dataTypeDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element name="derivedFrom" type="xsd:NMTOKEN"
minOccurs="0"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description"
minOccurs="0"/>okay bestie, we're still in the schema world 🎀 and this part is the Extension RFC 7408 bits. Anything wrapped in those Extension RFC 7408 comments is what this RFC adds on top of the base schema, so keep an eye out for them ✨ key constraints that make IDs unique, a new access attribute, and a defaultValue element 💅
<xsd:group ref="typeDeclarationGroup"/>
<!-- Extension RFC 7408 -->
<xsd:element name="defaultValue" type="xsd:token"
minOccurs="0"/>
<!-- /Extension RFC 7408 -->
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<!-- Predefined (built-in) atomic data-types are: char, uchar,
int16, uint16, int32, uint32, int64, uint64, string[N], string,
byte[N], boolean, octetstring[N], float32, float64 -->
<xsd:group name="typeDeclarationGroup">
<xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/>
<xsd:element name="array" type="arrayType">
<!-- Extension RFC 7408 -->
<!-- declare keys to have unique IDs -->
<xsd:key name="contentKeyID">
<xsd:selector xpath="lfb:contentKey"/>
<xsd:field xpath="@contentKeyID"/>
</xsd:key>
<!-- /Extension RFC 7408 -->
</xsd:element>
<xsd:element name="struct" type="structType">
<!-- Extension RFC 7408 -->
<!-- key declaration to make componentIDs
unique in a struct -->
<xsd:key name="structComponentID">
<xsd:selector xpath="lfb:component"/>
<xsd:field xpath="@componentID"/>
</xsd:key>
<!-- /Extension RFC 7408 -->
</xsd:element>
<xsd:element name="union" type="structType"/>
<xsd:element name="alias" type="typeRefNMTOKEN"/>
</xsd:choice>
</xsd:group>
<xsd:simpleType name="typeRefNMTOKEN">
<xsd:restriction base="xsd:token">
<xsd:pattern value="\c+"/>
<xsd:pattern value="string\[\d+\]"/>
<xsd:pattern value="byte\[\d+\]"/>
<xsd:pattern value="octetstring\[\d+\]"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="atomicType">
<xsd:sequence>
<xsd:element name="baseType" type="typeRefNMTOKEN"/>
<xsd:element name="rangeRestriction"
type="rangeRestrictionType" minOccurs="0"/>
<xsd:element name="specialValues" type="specialValuesType"
minOccurs="0">
<!-- Extension RFC 7408 -->
<xsd:key name="SpecialValue">
<xsd:selector xpath="specialValue"/>
<xsd:field xpath="@value"/>
</xsd:key>
<!-- /Extension RFC 7408 -->
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="rangeRestrictionType">
<xsd:sequence>
<xsd:element name="allowedRange" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="min" type="xsd:integer"
use="required"/>
<xsd:attribute name="max" type="xsd:integer"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="specialValuesType">
<xsd:sequence>
<xsd:element name="specialValue" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
</xsd:sequence>
<xsd:attribute name="value" type="xsd:token"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="arrayType">
<xsd:sequence>
<xsd:group ref="typeDeclarationGroup"/>
<xsd:element name="contentKey" minOccurs="0"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="contentKeyField"
type="xsd:string" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="contentKeyID" type="xsd:integer"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="type" use="optional" default="variable-size">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="fixed-size"/>
<xsd:enumeration value="variable-size"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="length" type="xsd:integer"
use="optional"/>
<xsd:attribute name="maxLength" type="xsd:integer"
use="optional"/>
</xsd:complexType>
<xsd:complexType name="structType">
<xsd:sequence>
<xsd:element name="derivedFrom" type="typeRefNMTOKEN"
minOccurs="0"/>
<xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description"
minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
<!-- Extension RFC 7408 -->
<xsd:attribute name="access" use="optional"
default="read-write">
<xsd:simpleType>
<xsd:list itemType="accessModeType"/>
</xsd:simpleType>
</xsd:attribute>
<!-- Extension RFC 7408 -->
<xsd:attribute name="componentID" type="xsd:unsignedInt"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="metadataDefsType">
<xsd:sequence>
<xsd:element name="metadataDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="metadataID" type="xsd:integer"/>
<xsd:element ref="description"
minOccurs="0"/>
<xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/>
<!-- Extension RFC 7408 -->
<xsd:element name="array" type="arrayType">
<!--declare keys to have unique IDs -->
<xsd:key name="contentKeyID1">
<xsd:selector xpath="lfb:contentKey"/>
<xsd:field xpath="@contentKeyID"/>
</xsd:key>
<!-- /Extension RFC 7408 -->
</xsd:element>
<xsd:element name="struct" type="structType">
<!-- Extension RFC 7408 -->
<!-- key declaration to make componentIDs
unique in a struct -->
<xsd:key name="structComponentID1">
<xsd:selector xpath="lfb:component"/>
<xsd:field xpath="@componentID"/>
</xsd:key>
<!-- /Extension RFC 7408 -->
</xsd:element>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="LFBClassDefsType">
<xsd:sequence>
<xsd:element name="LFBClassDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="version" type="versionType"/>
<xsd:element name="derivedFrom" minOccurs="0">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKEN">
<xsd:attribute name="version"
type="versionType" use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="inputPorts"
type="inputPortsType" minOccurs="0"/>
<xsd:element name="outputPorts"
type="outputPortsType" minOccurs="0"/>
<xsd:element name="components"
type="LFBComponentsType" minOccurs="0"/>
<xsd:element name="capabilities"
type="LFBCapabilitiesType" minOccurs="0"/>
<xsd:element name="events" type="eventsType"
minOccurs="0"/>
<xsd:element ref="description"
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="LFBClassID" type="xsd:unsignedInt"
use="required"/>
</xsd:complexType>
<!-- Key constraint to ensure unique attribute names
within a class: -->
<xsd:key name="components">
<xsd:selector xpath="lfb:components/lfb:component"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="capabilities">
<xsd:selector xpath="lfb:capabilities/lfb:capability"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="events">
<xsd:selector xpath="lfb:events/lfb:event"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="eventsIDs">
<xsd:selector xpath="lfb:events/lfb:event"/>
<xsd:field xpath="@eventID"/>
</xsd:key>
<xsd:key name="componentIDs">
<xsd:selector xpath="lfb:components/lfb:component"/>
<xsd:field xpath="@componentID"/>
</xsd:key>
<xsd:key name="capabilityIDs">okay bestie, the schema keeps going 💖 Here's the next chunk of the ForCES LFB XML schema, with the code copied exactly so every attribute, enum and comment lands right ✨
<xsd:selector xpath="lfb:capabilities/lfb:capability"/>
<xsd:field xpath="@componentID"/>
</xsd:key>
<xsd:key name="ComponentCapabilityComponentIDUniqueness">
<xsd:selector
xpath="lfb:components/lfb:component|
lfb:capabilities/lfb:capability|lfb:events"/>
<xsd:field xpath="@componentID|@baseID"/>
</xsd:key>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="versionType">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="[1-9][0-9]*\.([1-9][0-9]*|0)"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="inputPortsType">
<xsd:sequence>
<xsd:element name="inputPort" type="inputPortType"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="inputPortType">
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="expectation" type="portExpectationType"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="group" type="xsd:boolean"
use="optional" default="0"/>
</xsd:complexType>
<xsd:complexType name="portExpectationType">
<xsd:sequence>
<xsd:element name="frameExpected" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<!-- ref must refer to a name of a defined
frame type -->
<xsd:element name="ref" type="xsd:string"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="metadataExpected" minOccurs="0">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<!--ref must refer to a name of a defined metadata-->
<xsd:element name="ref" type="metadataInputRefType"/>
<xsd:element name="one-of"
type="metadataInputChoiceType"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="metadataInputChoiceType">
<xsd:choice minOccurs="2" maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="xsd:NMTOKEN"/>
<xsd:element name="one-of" type="metadataInputChoiceType"/>
<xsd:element name="metadataSet" type="metadataInputSetType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="metadataInputSetType">
<xsd:choice minOccurs="2" maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="metadataInputRefType"/>
<xsd:element name="one-of" type="metadataInputChoiceType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="metadataInputRefType">
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKEN">
<xsd:attribute name="dependency" use="optional"
default="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="required"/>
<xsd:enumeration value="optional"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="defaultValue" type="xsd:token"
use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="outputPortsType">
<xsd:sequence>
<xsd:element name="outputPort" type="outputPortType"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="outputPortType">
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="product" type="portProductType"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="group" type="xsd:boolean"
use="optional" default="0"/>
</xsd:complexType>
<xsd:complexType name="portProductType">
<xsd:sequence>
<xsd:element name="frameProduced" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<!-- ref must refer to a name of a defined
frame type -->
<xsd:element name="ref" type="xsd:NMTOKEN"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="metadataProduced" minOccurs="0">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<!-- ref must refer to a name of a
defined metadata -->
<xsd:element name="ref"
type="metadataOutputRefType"/>
<xsd:element name="one-of"
type="metadataOutputChoiceType"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="metadataOutputChoiceType">
<xsd:choice minOccurs="2" maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="xsd:NMTOKEN"/>
<xsd:element name="one-of" type="metadataOutputChoiceType"/>
<xsd:element name="metadataSet" type="metadataOutputSetType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="metadataOutputSetType">
<xsd:choice minOccurs="2" maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="metadataOutputRefType"/>
<xsd:element name="one-of" type="metadataOutputChoiceType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="metadataOutputRefType">
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKEN">
<xsd:attribute name="availability" use="optional"
default="unconditional">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="unconditional"/>
<xsd:enumeration value="conditional"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="LFBComponentsType">
<xsd:sequence>
<xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description"
minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
<xsd:element name="defaultValue" type="xsd:token"
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="access" use="optional"
default="read-write">
<xsd:simpleType>
<xsd:list itemType="accessModeType"/>
</xsd:simpleType>
</xsd:attribute>
<!-- Extension added restriction to componentID -->
<xsd:attribute name="componentID" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:unsignedInt">
<xsd:minExclusive value="0"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<!-- End of extension -->
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="accessModeType">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="read-only"/>
<xsd:enumeration value="read-write"/>
<xsd:enumeration value="write-only"/>
<xsd:enumeration value="read-reset"/>
<xsd:enumeration value="trigger-only"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="LFBCapabilitiesType">
<xsd:sequence>
<xsd:element name="capability" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description"
minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
<xsd:attribute name="componentID" type="xsd:integer"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="eventsType">
<xsd:sequence>
<xsd:element name="event" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="eventTarget"
type="eventPathType"/>
<xsd:element ref="eventCondition"/>
<xsd:element name="eventReports"
type="eventReportsType" minOccurs="0"/>
<xsd:element ref="description"
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="eventID" type="xsd:integer"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="baseID" type="xsd:integer"
use="optional"/>
</xsd:complexType>
<!-- the substitution group for the event conditions -->
<xsd:element name="eventCondition" abstract="true"/>
<xsd:element name="eventCreated"
substitutionGroup="eventCondition"/>
<xsd:element name="eventDeleted"
substitutionGroup="eventCondition"/>
<xsd:element name="eventChanged"
substitutionGroup="eventCondition"/>
<xsd:element name="eventGreaterThan"
substitutionGroup="eventCondition"/>
<xsd:element name="eventLessThan"
substitutionGroup="eventCondition"/>
<!-- Extension RFC 7408 -->
<xsd:element name="eventBecomesEqualTo"
substitutionGroup="eventCondition"/>
<!-- /Extension RFC 7408 -->
<xsd:complexType name="eventPathType">
<xsd:sequence>
<xsd:element ref="eventPathPart" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<!-- the substitution group for the event path parts -->
<xsd:element name="eventPathPart" type="xsd:string"
abstract="true"/>
<xsd:element name="eventField" type="xsd:string"
substitutionGroup="eventPathPart"/>
<xsd:element name="eventSubscript" type="xsd:string"
substitutionGroup="eventPathPart"/>
<xsd:complexType name="eventReportsType">
<xsd:sequence>
<xsd:element name="eventReport" type="eventPathType"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="booleanType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="0"/>
<xsd:enumeration value="1"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>Schema's wrapped up on this part, so the next chunk picks up right where this one leaves off 🦋
4. IANA Considerations ✨
okay so IANA registered a brand new XML namespace 🎀 (following the guidelines in RFC 3688 [RFC3688], obviously, bestie 💅)
URI: the namespace URI is:
urn:ietf:params:xml:ns:forces:lfbmodel:1.1Registrant Contact: IESG 👑
XML: none, this is an XML namespace 🌸
5. Security Considerations 🔐
okay this section is lowkey the most important vibe check 😭 so the document adds only a few constructs to the initial model in [RFC5812], namely a new event 🦋, some new properties 💖, and a way to define optional access types and complex metadata 🧚. on top of that, it fixes up an issue with the inheritance model by introducing the version of the derivedFrom LFB class 🌈. none of these constructs, or the update to the inheritance model, change the nature of the initial model. no cap 💅
so the security considerations from [RFC5812] apply here too 🫶, because these changes are just constructs for writing XML library definitions, the same way [RFC5812] does it. the changes, plus the clarification of the inheritance issue in the initial model, have no effect on the security semantics of the protocol 🔥
now the pervasive monitoring part 👀 (see [RFC7258] for the full tea on PM). this spec defines ways to expose more complex information, namely metadata, that gets exchanged between LFBs and between CEs and FEs, plus a new event 💜. these changes have very little or no effect on making PM simpler or more effective for an attacker who controls the LFBs. the new metadata might make PM slightly more elegant 🙈, but it doesn't open any new ways to (ab)use LFBs for PM. same deal for the new event 💀
last thing, and it's a big one ⭐: this document does not provide any protocol specification, so it does not specify how information gets transmitted between the entities. which means PM mitigation for a passive attacker who just wants to eavesdrop on the information being exchanged is out of scope here 😭🫶
main takeaway: this doc is a library-definition spec, not a wire protocol, so it doesn't fix eavesdropping. go check the protocol specs for that 🎀
6. References 📚
6.1. Normative References 💖
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010, <http://www.rfc-editor.org/info/rfc5810>.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010, <http://www.rfc-editor.org/info/rfc5812>.
[RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim, "High Availability within a Forwarding and Control Element Separation (ForCES) Network Element", RFC 7121, February 2014, <http://www.rfc-editor.org/info/rfc7121>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
6.2. Informative References 🌷
[OpenFlowSpec1.1] ONF, "OpenFlow Switch Specification", February 2011, <https://www.opennetworking.org/images/stories/downloads/ sdn-resources/onf-specifications/openflow/ openflow-spec-v1.1.0.pdf>.
Acknowledgements 🫶
the author wants to give a huge thank you to Joel Halpern, Jamal Hadi Salim, and Dave Hood for their comments and discussion that made this doc better 🌈. special shoutouts to Joel Halpern for resolving the issue with the default values, Adrian Farrel for the AD review, Ben Campbell for the Gen-ART review, and Tom Yu for the security review, all of which leveled up the quality 👑. reviews and comments from these IESG members also shaped the final version: Stephen Farrel, Barry Leiba, and Ted Lemon 💅. finally, the author thanks Julian Reschke for input on the namespace change issue and Joel Halpern for helping resolve it 🦋
Author's Address 📮
Evangelos Haleplidis University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece
EMail: ehalep@ece.upatras.gr
📦 where this page comes from
- ietf: rfc7408 2014-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms