< draft-ietf-forces-model-extension-04.txt		draft-ietf-forces-model-extension-05.txt >
	Internet Engineering Task Force E. Haleplidis		Internet Engineering Task Force E. Haleplidis
	Internet-Draft University of Patras		Internet-Draft University of Patras
	Updates: 5812 (if approved) August 21, 2014		Updates: 5812 (if approved) September 11, 2014
	Intended status: Standards Track		Intended status: Standards Track
	Expires: February 22, 2015		Expires: March 15, 2015
	ForCES Model Extension		ForCES Model Extension
	draft-ietf-forces-model-extension-04		draft-ietf-forces-model-extension-05
	Abstract		Abstract
	Forwarding and Control Element Separation (ForCES) defines an		This memo extends the Forwarding and Control Element Separation
	architectural framework and associated protocols to standardize		(ForCES) model defined in RFC 5812 and updates RFC5812 to allow
	information exchange between the control plane and the forwarding		complex datatypes for metadata, optional default values for
	plane in a ForCES Network Element (ForCES NE). RFC5812 has defined		datatypes, optional access types for structures. It fixes an issue
	the ForCES Model that provides a formal way to represent the		with Logical Functional Block (LFB) inheritance. It also introduces
	capabilities, state, and configuration of forwarding elements within		two new features a new event condition BecomesEqualTo and LFB
	the context of the ForCES protocol, so that control elements (CEs)		properties. The changes introduced in this memo do not alter the
	can control the FEs accordingly. More specifically, the model		protocol and retain backward compatibility with older LFB models.
	describes the logical functions that are present in a forwarding
	element (FE), what capabilities these functions support, and how
	these functions are or can be interconnected.
	RFC5812 has been around for two years and experience in its use has
	shown room for small extensions without a need to alter the protocol
	while retaining backward compatibility with older xml libraries.
	This document updates RFC5812 and extends the model to allow complex
	datatypes for metadata, optional default values for datatypes,
	optional access types for structures and fixes an issue with Logical
	Functional Block (LFB) inheritance. The document also introduces two
	new features a new event condition BecomesEqualTo and LFB properties.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 22, 2015.
			This Internet-Draft will expire on March 15, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 14 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
	2. ForCES Model Extensions . . . . . . . . . . . . . . . . . . . 4		2. ForCES Model Extensions . . . . . . . . . . . . . . . . . . . 3
	2.1. Complex datatypes for Metadata . . . . . . . . . . . . . 4		2.1. Complex datatypes for Metadata . . . . . . . . . . . . . 3
	2.2. Optional Default Value for Datatypes . . . . . . . . . . 5		2.2. Optional Default Value for Datatypes . . . . . . . . . . 5
	2.3. Optional Access Type for Structs . . . . . . . . . . . . 8		2.3. Optional Access Type for Structs . . . . . . . . . . . . 8
	2.4. New Event Condition: BecomesEqualTo . . . . . . . . . . . 11		2.4. New Event Condition: BecomesEqualTo . . . . . . . . . . . 11
	2.5. LFB Properties . . . . . . . . . . . . . . . . . . . . . 12		2.5. LFB Properties . . . . . . . . . . . . . . . . . . . . . 12
	2.6. LFB class inheritance . . . . . . . . . . . . . . . . . . 14		2.6. LFB class inheritance . . . . . . . . . . . . . . . . . . 14
	2.7. Enhancing XML Validation . . . . . . . . . . . . . . . . 15		2.7. Enhancing XML Validation . . . . . . . . . . . . . . . . 15
	3. XML Extension Schema for LFB Class Library Documents . . . . 15		3. XML Extension Schema for LFB Class Library Documents . . . . 15
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29		4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 29		6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
	7.1. Normative References . . . . . . . . . . . . . . . . . . 29		7.1. Normative References . . . . . . . . . . . . . . . . . . 30
	7.2. Informative References . . . . . . . . . . . . . . . . . 30		7.2. Informative References . . . . . . . . . . . . . . . . . 30
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
	1. Introduction		1. Introduction
	The ForCES Model [RFC5812] presents a formal way to define Forwarding		The ForCES Model [RFC5812] presents a formal way to define Forwarding
	Elements (FE) Logical Function Blocks (LFBs) using the eXtensible		Elements (FE) Logical Function Blocks (LFBs) using the eXtensible
	Markup Language (XML). [RFC5812] has been published a more than two		Markup Language (XML). [RFC5812] has been published a more than two
	years and current experience in its use has demonstrated need for		years and current experience in its use has demonstrated need for
	adding new and changing existing modeling concepts.		adding new and changing existing modeling concepts.
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 5 ¶
	inheritance (Section 2.6). Additionally the document introduces two		inheritance (Section 2.6). Additionally the document introduces two
	new features, a new event condition BecomesEqualTo (Section 2.4) and		new features, a new event condition BecomesEqualTo (Section 2.4) and
	LFB properties (Section 2.5).		LFB properties (Section 2.5).
	These extensions are an update to the ForCES model [RFC5812] and do		These extensions are an update to the ForCES model [RFC5812] and do
	not require any changes on the ForCES protocol [RFC5810] as they are		not require any changes on the ForCES protocol [RFC5810] as they are
	simply changes of the schema definition. Additionally backward		simply changes of the schema definition. Additionally backward
	compatibility is ensured as XML libraries produced with the earlier		compatibility is ensured as XML libraries produced with the earlier
	schema are still valid with the new one. In order for XML libraries		schema are still valid with the new one. In order for XML libraries
	produced by the new schema to be compatible with existing ForCES		produced by the new schema to be compatible with existing ForCES
	implementations, the XML Libraries MUST NOT include any of the		implementations, the XML libraries MUST NOT include any of the
	features described in this document, else the old implementation will		features described in this document.
	be unable to parse the XML library.
			Extensions to the schema and excerpts of the schema include the tags
			<!-- Extension RFC XXXX --> and <!-- /Extension RFC XXXX --> which
			designates the beginning and ending of extension text specified by
			this document in respect to the original ForCES Model [RFC5812]
			schema.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.2. Definitions		1.2. Definitions
	This document uses the terminology defined in the ForCES Model in		This document uses the terminology defined in the ForCES Model in
	skipping to change at page 4, line 11 ¶		skipping to change at page 3, line 50 ¶
	ForCES Component		ForCES Component
	LFB Class Library		LFB Class Library
	2. ForCES Model Extensions		2. ForCES Model Extensions
	2.1. Complex datatypes for Metadata		2.1. Complex datatypes for Metadata
	Section 4.6. (Element for Metadata Definitions) in the ForCES Model		Section 4.6. (Element for Metadata Definitions) in the ForCES Model
	[RFC5812] limits the datatype use in metadata to only atomic types.		[RFC5812] limits the datatype use in metadata to only atomic types.
	Figure 1 shows the xml schema excerpt where ony typeRef and atomic		Figure 1 shows the xml schema excerpt where only typeRef and atomic
	are allowed for a metadata definition.		are allowed for a metadata definition.
	<xsd:complexType name="metadataDefsType">		<xsd:complexType name="metadataDefsType">
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="metadataDef" maxOccurs="unbounded">		<xsd:element name="metadataDef" maxOccurs="unbounded">
	<xsd:complexType>		<xsd:complexType>
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="name" type="xsd:NMTOKEN"/>		<xsd:element name="name" type="xsd:NMTOKEN"/>
	<xsd:element ref="synopsis"/>		<xsd:element ref="synopsis"/>
	<xsd:element name="metadataID" type="xsd:integer"/>		<xsd:element name="metadataID" type="xsd:integer"/>
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 17 ¶
	<xsd:element name="metadataDef" maxOccurs="unbounded">		<xsd:element name="metadataDef" maxOccurs="unbounded">
	<xsd:complexType>		<xsd:complexType>
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="name" type="xsd:NMTOKEN"/>		<xsd:element name="name" type="xsd:NMTOKEN"/>
	<xsd:element ref="synopsis"/>		<xsd:element ref="synopsis"/>
	<xsd:element name="metadataID" type="xsd:integer"/>		<xsd:element name="metadataID" type="xsd:integer"/>
	<xsd:element ref="description" minOccurs="0"/>		<xsd:element ref="description" minOccurs="0"/>
	<xsd:choice>		<xsd:choice>
	<xsd:element name="typeRef" type="typeRefNMTOKEN"/>		<xsd:element name="typeRef" type="typeRefNMTOKEN"/>
	<xsd:element name="atomic" type="atomicType"/>		<xsd:element name="atomic" type="atomicType"/>
			<!-- Extension RFC XXXX -->
	<xsd:element name="array" type="arrayType">		<xsd:element name="array" type="arrayType">
	<xsd:key name="contentKeyID1">		<xsd:key name="contentKeyID1">
	<xsd:selector xpath="lfb:contentKey"/>		<xsd:selector xpath="lfb:contentKey"/>
	<xsd:field xpath="@contentKeyID"/>		<xsd:field xpath="@contentKeyID"/>
	</xsd:key>		</xsd:key>
	</xsd:element>		</xsd:element>
	<xsd:element name="struct" type="structType">		<xsd:element name="struct" type="structType">
	<xsd:key name="structComponentID1">		<xsd:key name="structComponentID1">
	<xsd:selector xpath="lfb:component"/>		<xsd:selector xpath="lfb:component"/>
	<xsd:field xpath="@componentID"/>		<xsd:field xpath="@componentID"/>
	</xsd:key>		</xsd:key>
	</xsd:element>		</xsd:element>
			<!-- /Extension RFC XXXX -->
	</xsd:choice>		</xsd:choice>
	</xsd:sequence>		</xsd:sequence>
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>		</xsd:element>
	</xsd:sequence>		</xsd:sequence>
	</xsd:complexType>		</xsd:complexType>
	Figure 2: New MetadataDefType Definition for the schema		Figure 2: New MetadataDefType Definition for the schema
	2.2. Optional Default Value for Datatypes		2.2. Optional Default Value for Datatypes
	In the original schema, default values can only be defined for		In the original schema, default values can only be defined for
	datatypes defined inside LFB components and not inside structures or		datatypes defined inside LFB components and not inside structures or
	arrays. Therefore default values of datatypes that are constantly		arrays. Therefore default values of datatypes that are constantly
	being reused, e.g. counters with default value of 0, have to be		being reused, e.g. counters with default value of 0, have to be
	constantly respecified. Additionally, datatypes inside complex		constantly respecified. Additionally, datatypes inside complex
	datatypes cannot be defined with a default value, e.g. a counter		datatypes cannot be defined with a default value, e.g. a counter
	inside a struct that has a default value of 0.		inside a struct that has a default value of 0.
	This extension allows the option to add default values to atomic and		This extension allows the option to add default values to datatypes.
	typeref types, whether they are as simple or complex datatypes. A		These datatypes can then be referenced as simple components or within
	simple use case would be to have a struct component where one of the		complex datatypes such as structs. A simple use case would be to
	components is a counter which the default value would be zero.		have a struct component where one of the components is a counter
			which the default value would be zero. To achieve that the counter
	This extension alters the definition of the typeDeclarationGroup in		must first be defined as a datatype with the required default value
	the XML schema from Figure 3 to Figure 4 to allow default values to		and then referenced in the struct. Default values MUST adhere the
	TypeRef.		following formal restrictions:
	<xsd:element name="typeRef" type="typeRefNMTOKEN"/>		1. Default Values MUST be ignored if the data type is not an atomic
			or a base data type.
	Figure 3: Initial Excerpt of typeDeclarationGroup Definition in the		2. When a datatype X with default value A is referenced from a
	schema		datatype Y with a default value B, the default value of the
			datatype that references overrides the referenced default value,
			e.g. in this case Y's default value will be B.
	<xsd:sequence>		3. Default Values of LFB components overrides any default value
	<xsd:element name="typeRef" type="typeRefNMTOKEN"/>		specified from the dataTypeDef definition.
	<xsd:element name="DefaultValue" type="xsd:token"
	minOccurs="0"/>
	</xsd:sequence>
	Figure 4: New Excerpt of typeDeclarationGroup Definition in the		4. Default Values of datatypes reference in capabilities or metadata
	schema		MUST be ignored.
	Additionally this document appends to the initial declaration of the		This extension simply appends to the definition of the
	AtomicType, Figure 5, an optional defaultValue, Figure 6, to allow		dataTypeDefsType in the XML schema from Figure 3 to Figure 4 to allow
	default values to Atomic datatypes. Note that both declarations		default values to dataTypeDefsType.
	include the new special value validation described in Section 2.7
	<xsd:complexType name="atomicType">		<xsd:complexType name="dataTypeDefsType">
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="baseType" type="typeRefNMTOKEN"/>		<xsd:element name="dataTypeDef" maxOccurs="unbounded">
	<xsd:element name="rangeRestriction" type="rangeRestrictionType"		<xsd:complexType>
	minOccurs="0"/>		<xsd:sequence>
	<xsd:element name="specialValues" type="specialValuesType"		<xsd:element name="name" type="xsd:NMTOKEN"/>
	minOccurs="0">		<xsd:element name="derivedFrom" type="xsd:NMTOKEN"
	<!-- Extension -->		minOccurs="0"/>
	<xsd:key name="SpecialValue">		<xsd:element ref="synopsis"/>
	<xsd:selector xpath="specialValue"/>		<xsd:element ref="description" minOccurs="0"/>
	<xsd:field xpath="@value"/>		<xsd:group ref="typeDeclarationGroup"/>
	</xsd:key>		</xsd:sequence>
	<!-- /Extension -->		</xsd:complexType>
	</xsd:element>		</xsd:element>
	</xsd:sequence>		</xsd:sequence>
			</xsd:complexType>
	Figure 5: Initial Excerpt of AtomicType Definition in the schema		Figure 3: Initial Excerpt of dataTypeDefsType Definition in the
			schema
	<xsd:complexType name="atomicType">		<xsd:complexType name="dataTypeDefsType">
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="baseType" type="typeRefNMTOKEN"/>		<xsd:element name="dataTypeDef" maxOccurs="unbounded">
	<xsd:element name="rangeRestriction" type="rangeRestrictionType"		<xsd:complexType>
	minOccurs="0"/>		<xsd:sequence>
	<xsd:element name="specialValues" type="specialValuesType"		<xsd:element name="name" type="xsd:NMTOKEN"/>
	minOccurs="0">		<xsd:element name="derivedFrom" type="xsd:NMTOKEN"
	<!-- Extension -->		minOccurs="0"/>
	<xsd:key name="SpecialValue">		<xsd:element ref="synopsis"/>
	<xsd:selector xpath="specialValue"/>		<xsd:element ref="description" minOccurs="0"/>
	<xsd:field xpath="@value"/>		<xsd:group ref="typeDeclarationGroup"/>
	</xsd:key>		<!-- Extension RFC XXXX -->
	<!-- /Extension -->		<xsd:element name="defaultValue" type="xsd:token"
	</xsd:element>		minOccurs="0"/>
	<!-- Extension -->		<!-- /Extension RFC XXXX -->
	<xsd:element name="defaultValue" type="xsd:token"		</xsd:sequence>
	minOccurs="0"/>		</xsd:complexType>
	<!-- /Extension -->		</xsd:element>
	</xsd:sequence>		</xsd:sequence>
			</xsd:complexType>
	Figure 6: New Excerpt of AtomicType Definition in the schema		Figure 4: New Excerpt of dataTypeDefsType Definition in the schema
	Examples of using default values is depicted in Figure 7.		Examples of using default values is depicted in Figure 5.
	<dataTypeDef>		<dataTypeDef>
	<name>Counter Values</name>		<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>		<synopsis>Example default values in struct</synopsis>
	<struct>		<struct>
	<component componentID="1">		<component componentID="1">
	<name>GoodPacketCoutner</name>		<name>GoodPacketCoutner</name>
	<synopsis>A counter for good packets</synopsis>		<synopsis>A counter for good packets</synopsis>
	<typeRef>uint32</typeRef>		<typeRef>ZeroCounter</typeRef>
	<DefaultValue>0</DefaultValue>
	</component>		</component>
	<component componentID="2">		<component componentID="2">
	<name>BadPacketCoutner</name>		<name>BadPacketCoutner</name>
	<synopsis>A counter for bad packets</synopsis>		<synopsis>A counter for bad packets</synopsis>
	<typeRef>uint32</typeRef>		<typeRef>ZeroCounter</typeRef>
	<DefaultValue>0</DefaultValue>
	</component>		</component>
	</struct>		</struct>
	</dataTypeDef>		</dataTypeDef>
	Figure 7: Example of optional default values		Figure 5: Example of optional default values
	2.3. Optional Access Type for Structs		2.3. Optional Access Type for Structs
	In the original schema, the access type can only be defined on		In the original schema, the access type can only be defined on
	components of an LFB and not on components within structs or arrays.		components of an LFB and not on components within structs or arrays.
	That means that when it is a struct datatype it is not possible to		That means that when it is a struct datatype it is not possible to
	fine-tune access type per component within the struct. A simple use		fine-tune access type per component within the struct. A simple use
	case would be to have a read-write struct component where one of the		case would be to have a read-write struct component where one of the
	components is a counter where the access-type could be read-reset or		components is a counter where the access-type could be read-reset or
	read-only, e.g. a read-reset or a read-only counter inside a struct.		read-only, e.g. a read-reset or a read-only counter inside a struct.
	skipping to change at page 8, line 32 ¶		skipping to change at page 9, line 8 ¶
	has a component that is a read-only counter, the counter's access		has a component that is a read-only counter, the counter's access
	type MUST be read-only.		type MUST be read-only.
	The access type for a component in a capability is always read-only		The access type for a component in a capability is always read-only
	per [RFC5812]. If an access type is provided for a component in a		per [RFC5812]. If an access type is provided for a component in a
	capability, the access type MUST be ignored. Similarly if an access		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		type is provided for a struct in a metadata the access type MUST be
	ignored.		ignored.
	This extension alters the definition of the struct in the xml schema		This extension alters the definition of the struct in the xml schema
	from Figure 8 to Figure 9.		from Figure 6 to Figure 7.
	<xsd:complexType name="structType">		<xsd:complexType name="structType">
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="derivedFrom" type="typeRefNMTOKEN"		<xsd:element name="derivedFrom" type="typeRefNMTOKEN"
	minOccurs="0"/>		minOccurs="0"/>
	<xsd:element name="component" maxOccurs="unbounded">		<xsd:element name="component" maxOccurs="unbounded">
	<xsd:complexType>		<xsd:complexType>
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="name" type="xsd:NMTOKEN"/>		<xsd:element name="name" type="xsd:NMTOKEN"/>
	<xsd:element ref="synopsis"/>		<xsd:element ref="synopsis"/>
	skipping to change at page 9, line 25 ¶		skipping to change at page 9, line 30 ¶
	<xsd:element name="optional" minOccurs="0"/>		<xsd:element name="optional" minOccurs="0"/>
	<xsd:group ref="typeDeclarationGroup"/>		<xsd:group ref="typeDeclarationGroup"/>
	</xsd:sequence>		</xsd:sequence>
	<xsd:attribute name="componentID" type="xsd:unsignedInt"		<xsd:attribute name="componentID" type="xsd:unsignedInt"
	use="required"/>		use="required"/>
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>		</xsd:element>
	</xsd:sequence>		</xsd:sequence>
	</xsd:complexType>		</xsd:complexType>
	Figure 8: Initial xml for the struct definition in the schema		Figure 6: Initial xml for the struct definition in the schema
	<xsd:complexType name="structType">		<xsd:complexType name="structType">
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="derivedFrom" type="typeRefNMTOKEN"		<xsd:element name="derivedFrom" type="typeRefNMTOKEN"
	minOccurs="0"/>		minOccurs="0"/>
	<xsd:element name="component" maxOccurs="unbounded">		<xsd:element name="component" maxOccurs="unbounded">
	<xsd:complexType>		<xsd:complexType>
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="name" type="xsd:NMTOKEN"/>		<xsd:element name="name" type="xsd:NMTOKEN"/>
	<xsd:element ref="synopsis"/>		<xsd:element ref="synopsis"/>
	<xsd:element ref="description" minOccurs="0"/>		<xsd:element ref="description" minOccurs="0"/>
	<xsd:element name="optional" minOccurs="0"/>		<xsd:element name="optional" minOccurs="0"/>
	<xsd:group ref="typeDeclarationGroup"/>		<xsd:group ref="typeDeclarationGroup"/>
	</xsd:sequence>		</xsd:sequence>
			<!-- Extension RFC XXXX -->
	<xsd:attribute name="access" use="optional"		<xsd:attribute name="access" use="optional"
	default="read-write">		default="read-write">
	<xsd:simpleType>		<xsd:simpleType>
	<xsd:list itemType="accessModeType"/>		<xsd:list itemType="accessModeType"/>
	</xsd:simpleType>		</xsd:simpleType>
	</xsd:attribute>		</xsd:attribute>
			<!-- /Extension RFC XXXX -->
	<xsd:attribute name="componentID" type="xsd:unsignedInt"		<xsd:attribute name="componentID" type="xsd:unsignedInt"
	use="required"/>		use="required"/>
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>		</xsd:element>
	</xsd:sequence>		</xsd:sequence>
	</xsd:complexType>		</xsd:complexType>
	Figure 9: New xml for the struct definition in the schema		Figure 7: New xml for the struct definition in the schema
	An example of using optional access types for structs can be depicted		An example of using optional access types for structs can be depicted
	in Figure 10		in Figure 8
	<component componentID="1" access="read-write">		<component componentID="1" access="read-write">
	<name>PacketFlows</name>		<name>PacketFlows</name>
	<synopsis>Packet Flows, match and counter</synopsis>		<synopsis>Packet Flows, match and counter</synopsis>
	<struct>		<struct>
	<component componentID="1">		<component componentID="1">
	<name>FlowMatch</name>		<name>FlowMatch</name>
	<synopsis>Flow Match</synopsis>		<synopsis>Flow Match</synopsis>
	<typeRef>MatchType</typeRef>		<typeRef>MatchType</typeRef>
	</component>		</component>
	<component componentID="2" access="read-only">		<component componentID="2" access="read-only">
	<name>MatchCounter</name>		<name>MatchCounter</name>
	<synopsis>Packets matching the flow match</synopsis>		<synopsis>Packets matching the flow match</synopsis>
	<typeRef>uint32</typeRef>		<typeRef>ZeroCounter</typeRef>
	<DefaultValue>0</DefaultValue>
	</component>		</component>
	</struct>		</struct>
	</component>		</component>
	Figure 10: Example of optional access types for struct		Figure 8: Example of optional access types for struct
	2.4. New Event Condition: BecomesEqualTo		2.4. New Event Condition: BecomesEqualTo
	This extensions adds one more event condition in the model schema,		This extensions adds one more event condition in the model schema,
	that of BecomesEqualTo. The difference between Greater Than and Less		that of BecomesEqualTo. The difference between Greater Than and Less
	Than, is that when the value becomes exactly that of the		Than, is that when the value becomes exactly that of the
	BecomesEqualTo, the event is triggered. This event condition is		BecomesEqualTo, the event is triggered. This event condition is
	particularly useful when there is a need to monitor one or more		particularly useful when there is a need to monitor one or more
	states of an LFB or the FE. For example in the CE High Availability		states of an LFB or the FE. For example in the CE High Availability
	(CEHA) [RFC7121] RFC it may be useful for the master CE to know which		(CEHA) [RFC7121] RFC it may be useful for the master CE to know which
	skipping to change at page 11, line 50 ¶		skipping to change at page 11, line 49 ¶
	component becomes equal to the event condition value.		component becomes equal to the event condition value.
	Implementations MUST NOT generate subsequent events while the		Implementations MUST NOT generate subsequent events while the
	targeted component's value remains equal to the event condition's		targeted component's value remains equal to the event condition's
	value.		value.
	The BecomesEqualTo is appended to the schema as follows:		The BecomesEqualTo is appended to the schema as follows:
	<xsd:element name="eventBecomesEqualTo"		<xsd:element name="eventBecomesEqualTo"
	substitutionGroup="eventCondition"/>		substitutionGroup="eventCondition"/>
	Figure 11: New Excerpt of BecomesEqualTo event condition definition		Figure 9: New Excerpt of BecomesEqualTo event condition definition in
	in the schema		the schema
	It can become useful for the CE to be notified when the state has		It can become useful for the CE to be notified when the state has
	changed once the BecomesEqualTo event has been triggered, e.g. the CE		changed once the BecomesEqualTo event has been triggered, e.g. the CE
	may need to know when a backup CE has lost association. Such an		may need to know when a backup CE has lost association. Such an
	event can be generated either by defining a second event on the same		event can be generated either by defining a second event on the same
	component, namely an Event Changed, or by simply reusing		component, namely an Event Changed, or by simply reusing
	BecomesEqualTo and use event properties, in particular event		BecomesEqualTo and use event properties, in particular event
	hysteresis. We append the following definition for the event		hysteresis. We append the following definition for the event
	hysteresis defined in section 4.8.5.2 in [RFC5812], with V being the		hysteresis defined in section 4.8.5.2 in [RFC5812], with V being the
	hysteresis value:		hysteresis value:
	skipping to change at page 12, line 47 ¶		skipping to change at page 12, line 47 ¶
	LFB properties and ID 0 MUST NOT be used for any component		LFB properties and ID 0 MUST NOT be used for any component
	definition. This disallowment is backwards compatible as no known		definition. This disallowment is backwards compatible as no known
	LFB definition uses LFB component with ID 0. Any command with a path		LFB definition uses LFB component with ID 0. Any command with a path
	starting from LFB component 0 refers to LFB properties. The		starting from LFB component 0 refers to LFB properties. The
	following change in the xml schema disallows usage of LFB component		following change in the xml schema disallows usage of LFB component
	0:		0:
	<xsd:attribute name="componentID" type="xsd:unsignedInt"		<xsd:attribute name="componentID" type="xsd:unsignedInt"
	use="required">		use="required">
	Figure 12: Initial xml for LFB Component IDs		Figure 10: Initial xml for LFB Component IDs
	<!-- Extension Added restriction to component ID -->		<!-- Extension Added restriction to component ID -->
	<xsd:attribute name="componentID" use="required">		<xsd:attribute name="componentID" use="required">
	<xsd:simpleType>		<xsd:simpleType>
	<xsd:restriction base="xsd:unsignedInt">		<xsd:restriction base="xsd:unsignedInt">
	<xsd:minExclusive value="0"/>		<xsd:minExclusive value="0"/>
	</xsd:restriction>		</xsd:restriction>
	</xsd:simpleType>		</xsd:simpleType>
	</xsd:attribute>		</xsd:attribute>
	<!-- End of extension -->		<!-- End of extension -->
	Figure 13: New xml to disallow usage of 0 as LFB Component		Figure 11: New xml to disallow usage of 0 as LFB Component
	The following datatype definitions are to be used as properties for		The following datatype definitions are to be used as properties for
	LFB instances.		LFB instances.
	<dataTypeDef>		<dataTypeDef>
	<name>LFBProperties</name>		<name>LFBProperties</name>
	<synopsis>LFB Properties definition</synopsis>		<synopsis>LFB Properties definition</synopsis>
	<struct>		<struct>
	<component componentID="1">		<component componentID="1">
	<name>PacketsSentToCE</name>		<name>PacketsSentToCE</name>
	skipping to change at page 14, line 38 ¶		skipping to change at page 14, line 38 ¶
	definition with an optional version attribute when the derivedFrom		definition with an optional version attribute when the derivedFrom
	field is used.		field is used.
	Having the version attribute as optional was a decision based on the		Having the version attribute as optional was a decision based on the
	need to maintain backwards compatibility with the XML schema defined		need to maintain backwards compatibility with the XML schema defined
	in [RFC5812]. However if the version is omitted then the derivedFrom		in [RFC5812]. However if the version is omitted then the derivedFrom
	will always specify the first version of the parent LFB class, which		will always specify the first version of the parent LFB class, which
	usually is version 1.0.		usually is version 1.0.
	This extension alters the definition of the derivedFrom in the xml		This extension alters the definition of the derivedFrom in the xml
	schema from Figure 14 to Figure 15.		schema from Figure 12 to Figure 13.
	<xsd:element name="derivedFrom" minOccurs="0"/>		<xsd:element name="derivedFrom" minOccurs="0"/>
	Figure 14: Initial xml for the LFB class inheritance		Figure 12: Initial xml for the LFB class inheritance
	<xsd:element name="derivedFrom" minOccurs="0">		<xsd:element name="derivedFrom" minOccurs="0">
	<xsd:complexType>		<xsd:complexType>
	<xsd:simpleContent>		<xsd:simpleContent>
	<xsd:extension base="xsd:NMTOKEN">		<xsd:extension base="xsd:NMTOKEN">
	<xsd:attribute name="version"		<xsd:attribute name="version"
	type="versionType" use="optional"/>		type="versionType" use="optional"/>
	</xsd:extension>		</xsd:extension>
	</xsd:simpleContent>		</xsd:simpleContent>
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>		</xsd:element>
	Figure 15: New xml for the LFB class inheritance		Figure 13: New xml for the LFB class inheritance
	An example of the use of the version attribute is given in Figure 16		An example of the use of the version attribute is given in Figure 14
	<derivedFrom version="1.0">EtherPHYCop</derivedFrom>		<derivedFrom version="1.0">EtherPHYCop</derivedFrom>
	Figure 16: Example of use of new xml for LFB class Inheritance		Figure 14: Example of use of new xml for LFB class Inheritance
	2.7. Enhancing XML Validation		2.7. Enhancing XML Validation
	As specified earlier this is not an extension but an enhancement of		As specified earlier this is not an extension but an enhancement of
	the schema to provide additional validation rules. This includes		the schema to provide additional validation rules. This includes
	adding new key declarations to provide uniqueness as defined by the		adding new key declarations to provide uniqueness as defined by the
	ForCES Model [RFC5812]. Such validations work only on within the		ForCES Model [RFC5812]. Such validations work only on within the
	same xml file.		same xml file.
	This document introduces the following validation rules that did not		This document introduces the following validation rules that did not
	skipping to change at page 17, line 46 ¶		skipping to change at page 17, line 46 ¶
	<xsd:element name="dataTypeDef" maxOccurs="unbounded">		<xsd:element name="dataTypeDef" maxOccurs="unbounded">
	<xsd:complexType>		<xsd:complexType>
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="name" type="xsd:NMTOKEN"/>		<xsd:element name="name" type="xsd:NMTOKEN"/>
	<xsd:element name="derivedFrom" type="xsd:NMTOKEN"		<xsd:element name="derivedFrom" type="xsd:NMTOKEN"
	minOccurs="0"/>		minOccurs="0"/>
	<xsd:element ref="synopsis"/>		<xsd:element ref="synopsis"/>
	<xsd:element ref="description"		<xsd:element ref="description"
	minOccurs="0"/>		minOccurs="0"/>
	<xsd:group ref="typeDeclarationGroup"/>		<xsd:group ref="typeDeclarationGroup"/>
			<!-- Extension RFC XXXX -->
			<xsd:element name="defaultValue" type="xsd:token"
			minOccurs="0"/>
			<!-- /Extension RFC XXXX -->
	</xsd:sequence>		</xsd:sequence>
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>		</xsd:element>
	</xsd:sequence>		</xsd:sequence>
	</xsd:complexType>		</xsd:complexType>
	<!-- Predefined (built-in) atomic data-types are: char, uchar,		<!-- Predefined (built-in) atomic data-types are: char, uchar,
	int16, uint16, int32, uint32, int64, uint64, string[N], string,		int16, uint16, int32, uint32, int64, uint64, string[N], string,
	byte[N], boolean, octetstring[N], float32, float64 -->		byte[N], boolean, octetstring[N], float32, float64 -->
	<xsd:group name="typeDeclarationGroup">		<xsd:group name="typeDeclarationGroup">
	<xsd:choice>		<xsd:choice>
	<!-- Extension -->		<xsd:element name="typeRef" type="typeRefNMTOKEN"/>
	<xsd:sequence>
	<!-- /Extension -->
	<xsd:element name="typeRef" type="typeRefNMTOKEN"/>
	<!-- Extension -->
	<xsd:element name="DefaultValue" type="xsd:token"
	minOccurs="0"/>
	</xsd:sequence>
	<!-- /Extension -->
	<xsd:element name="atomic" type="atomicType"/>		<xsd:element name="atomic" type="atomicType"/>
	<xsd:element name="array" type="arrayType">		<xsd:element name="array" type="arrayType">
	<!-- Extension -->		<!-- Extension RFC XXXX -->
	<!--declare keys to have unique IDs -->		<!--declare keys to have unique IDs -->
	<xsd:key name="contentKeyID">		<xsd:key name="contentKeyID">
	<xsd:selector xpath="lfb:contentKey"/>		<xsd:selector xpath="lfb:contentKey"/>
	<xsd:field xpath="@contentKeyID"/>		<xsd:field xpath="@contentKeyID"/>
	</xsd:key>		</xsd:key>
	<!-- /Extension -->		<!-- /Extension RFC XXXX -->
	</xsd:element>		</xsd:element>
	<xsd:element name="struct" type="structType">		<xsd:element name="struct" type="structType">
	<!-- Extension -->		<!-- Extension RFC XXXX -->
	<!-- key declaration to make componentIDs		<!-- key declaration to make componentIDs
	unique in a struct -->		unique in a struct -->
	<xsd:key name="structComponentID">		<xsd:key name="structComponentID">
	<xsd:selector xpath="lfb:component"/>		<xsd:selector xpath="lfb:component"/>
	<xsd:field xpath="@componentID"/>		<xsd:field xpath="@componentID"/>
	</xsd:key>		</xsd:key>
	<!-- /Extension -->		<!-- /Extension RFC XXXX -->
	</xsd:element>		</xsd:element>
	<xsd:element name="union" type="structType"/>		<xsd:element name="union" type="structType"/>
	<xsd:element name="alias" type="typeRefNMTOKEN"/>		<xsd:element name="alias" type="typeRefNMTOKEN"/>
	</xsd:choice>		</xsd:choice>
	</xsd:group>		</xsd:group>
	<xsd:simpleType name="typeRefNMTOKEN">		<xsd:simpleType name="typeRefNMTOKEN">
	<xsd:restriction base="xsd:token">		<xsd:restriction base="xsd:token">
	<xsd:pattern value="\c+"/>		<xsd:pattern value="\c+"/>
	<xsd:pattern value="string\[\d+\]"/>		<xsd:pattern value="string\[\d+\]"/>
	<xsd:pattern value="byte\[\d+\]"/>		<xsd:pattern value="byte\[\d+\]"/>
	<xsd:pattern value="octetstring\[\d+\]"/>		<xsd:pattern value="octetstring\[\d+\]"/>
	</xsd:restriction>		</xsd:restriction>
	</xsd:simpleType>		</xsd:simpleType>
	<xsd:complexType name="atomicType">		<xsd:complexType name="atomicType">
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="baseType" type="typeRefNMTOKEN"/>		<xsd:element name="baseType" type="typeRefNMTOKEN"/>
	<xsd:element name="rangeRestriction"		<xsd:element name="rangeRestriction"
	type="rangeRestrictionType" minOccurs="0"/>		type="rangeRestrictionType" minOccurs="0"/>
	<xsd:element name="specialValues" type="specialValuesType"		<xsd:element name="specialValues" type="specialValuesType"
	minOccurs="0">		minOccurs="0">
	<!-- Extension -->		<!-- Extension RFC XXXX -->
	<xsd:key name="SpecialValue">		<xsd:key name="SpecialValue">
	<xsd:selector xpath="specialValue"/>		<xsd:selector xpath="specialValue"/>
	<xsd:field xpath="@value"/>		<xsd:field xpath="@value"/>
	</xsd:key>		</xsd:key>
	<!-- /Extension -->		<!-- /Extension RFC XXXX -->
	</xsd:element>		</xsd:element>
	<!-- Extension -->
	<xsd:element name="defaultValue" type="xsd:token"
	minOccurs="0"/>
	<!-- /Extension -->
	</xsd:sequence>		</xsd:sequence>
	</xsd:complexType>		</xsd:complexType>
	<xsd:complexType name="rangeRestrictionType">		<xsd:complexType name="rangeRestrictionType">
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="allowedRange" maxOccurs="unbounded">		<xsd:element name="allowedRange" maxOccurs="unbounded">
	<xsd:complexType>		<xsd:complexType>
	<xsd:attribute name="min" type="xsd:integer"		<xsd:attribute name="min" type="xsd:integer"
	use="required"/>		use="required"/>
	<xsd:attribute name="max" type="xsd:integer"		<xsd:attribute name="max" type="xsd:integer"
	use="required"/>		use="required"/>
	skipping to change at page 20, line 39 ¶		skipping to change at page 20, line 31 ¶
	<xsd:element name="component" maxOccurs="unbounded">		<xsd:element name="component" maxOccurs="unbounded">
	<xsd:complexType>		<xsd:complexType>
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="name" type="xsd:NMTOKEN"/>		<xsd:element name="name" type="xsd:NMTOKEN"/>
	<xsd:element ref="synopsis"/>		<xsd:element ref="synopsis"/>
	<xsd:element ref="description"		<xsd:element ref="description"
	minOccurs="0"/>		minOccurs="0"/>
	<xsd:element name="optional" minOccurs="0"/>		<xsd:element name="optional" minOccurs="0"/>
	<xsd:group ref="typeDeclarationGroup"/>		<xsd:group ref="typeDeclarationGroup"/>
	</xsd:sequence>		</xsd:sequence>
			<!-- Extension RFC XXXX -->
	<xsd:attribute name="access" use="optional"		<xsd:attribute name="access" use="optional"
	default="read-write">		default="read-write">
	<xsd:simpleType>		<xsd:simpleType>
	<xsd:list itemType="accessModeType"/>		<xsd:list itemType="accessModeType"/>
	</xsd:simpleType>		</xsd:simpleType>
	</xsd:attribute>		</xsd:attribute>
			<!-- Extension RFC XXXX -->
	<xsd:attribute name="componentID" type="xsd:unsignedInt"		<xsd:attribute name="componentID" type="xsd:unsignedInt"
	use="required"/>		use="required"/>
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>		</xsd:element>
	</xsd:sequence>		</xsd:sequence>
	</xsd:complexType>		</xsd:complexType>
	<xsd:complexType name="metadataDefsType">		<xsd:complexType name="metadataDefsType">
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="metadataDef" maxOccurs="unbounded">		<xsd:element name="metadataDef" maxOccurs="unbounded">
	<xsd:complexType>		<xsd:complexType>
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="name" type="xsd:NMTOKEN"/>		<xsd:element name="name" type="xsd:NMTOKEN"/>
	<xsd:element ref="synopsis"/>		<xsd:element ref="synopsis"/>
	<xsd:element name="metadataID" type="xsd:integer"/>		<xsd:element name="metadataID" type="xsd:integer"/>
	<xsd:element ref="description"		<xsd:element ref="description"
	minOccurs="0"/>		minOccurs="0"/>
	<xsd:choice>		<xsd:choice>
	<xsd:element name="typeRef" type="typeRefNMTOKEN"/>		<xsd:element name="typeRef" type="typeRefNMTOKEN"/>
	<xsd:element name="atomic" type="atomicType"/>		<xsd:element name="atomic" type="atomicType"/>
	<!-- Extension -->		<!-- Extension RFC XXXX -->
	<xsd:element name="array" type="arrayType">		<xsd:element name="array" type="arrayType">
	<!--declare keys to have unique IDs -->		<!--declare keys to have unique IDs -->
	<xsd:key name="contentKeyID1">		<xsd:key name="contentKeyID1">
	<xsd:selector xpath="lfb:contentKey"/>		<xsd:selector xpath="lfb:contentKey"/>
	<xsd:field xpath="@contentKeyID"/>		<xsd:field xpath="@contentKeyID"/>
	</xsd:key>		</xsd:key>
	<!-- /Extension -->		<!-- /Extension RFC XXXX -->
	</xsd:element>		</xsd:element>
	<xsd:element name="struct" type="structType">		<xsd:element name="struct" type="structType">
	<!-- Extension -->		<!-- Extension RFC XXXX -->
	<!-- key declaration to make componentIDs		<!-- key declaration to make componentIDs
	unique in a struct -->		unique in a struct -->
	<xsd:key name="structComponentID1">		<xsd:key name="structComponentID1">
	<xsd:selector xpath="lfb:component"/>		<xsd:selector xpath="lfb:component"/>
	<xsd:field xpath="@componentID"/>		<xsd:field xpath="@componentID"/>
	</xsd:key>		</xsd:key>
	<!-- /Extension -->		<!-- /Extension RFC XXXX -->
	</xsd:element>		</xsd:element>
	</xsd:choice>		</xsd:choice>
	</xsd:sequence>		</xsd:sequence>
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>		</xsd:element>
	</xsd:sequence>		</xsd:sequence>
	</xsd:complexType>		</xsd:complexType>
	<xsd:complexType name="LFBClassDefsType">		<xsd:complexType name="LFBClassDefsType">
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="LFBClassDef" maxOccurs="unbounded">		<xsd:element name="LFBClassDef" maxOccurs="unbounded">
	skipping to change at page 28, line 10 ¶		skipping to change at page 28, line 4 ¶
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>		</xsd:element>
	</xsd:sequence>		</xsd:sequence>
	<xsd:attribute name="baseID" type="xsd:integer"		<xsd:attribute name="baseID" type="xsd:integer"
	use="optional"/>		use="optional"/>
	</xsd:complexType>		</xsd:complexType>
	<!-- the substitution group for the event conditions -->		<!-- the substitution group for the event conditions -->
	<xsd:element name="eventCondition" abstract="true"/>		<xsd:element name="eventCondition" abstract="true"/>
	<xsd:element name="eventCreated"		<xsd:element name="eventCreated"
	substitutionGroup="eventCondition"/>		substitutionGroup="eventCondition"/>
	<xsd:element name="eventDeleted"		<xsd:element name="eventDeleted"
	substitutionGroup="eventCondition"/>		substitutionGroup="eventCondition"/>
	<xsd:element name="eventChanged"		<xsd:element name="eventChanged"
	substitutionGroup="eventCondition"/>		substitutionGroup="eventCondition"/>
	<xsd:element name="eventGreaterThan"		<xsd:element name="eventGreaterThan"
	substitutionGroup="eventCondition"/>		substitutionGroup="eventCondition"/>
	<xsd:element name="eventLessThan"		<xsd:element name="eventLessThan"
	substitutionGroup="eventCondition"/>		substitutionGroup="eventCondition"/>
	<!-- Extension -->		<!-- Extension RFC XXXX -->
	<xsd:element name="eventBecomesEqualTo"		<xsd:element name="eventBecomesEqualTo"
	substitutionGroup="eventCondition"/>		substitutionGroup="eventCondition"/>
	<!-- /Extension -->		<!-- /Extension RFC XXXX -->
	<xsd:complexType name="eventPathType">		<xsd:complexType name="eventPathType">
	<xsd:sequence>		<xsd:sequence>
	<xsd:element ref="eventPathPart" maxOccurs="unbounded"/>		<xsd:element ref="eventPathPart" maxOccurs="unbounded"/>
	</xsd:sequence>		</xsd:sequence>
	</xsd:complexType>		</xsd:complexType>
	<!-- the substitution group for the event path parts -->		<!-- the substitution group for the event path parts -->
	<xsd:element name="eventPathPart" type="xsd:string"		<xsd:element name="eventPathPart" type="xsd:string"
	abstract="true"/>		abstract="true"/>
	<xsd:element name="eventField" type="xsd:string"		<xsd:element name="eventField" type="xsd:string"
	substitutionGroup="eventPathPart"/>		substitutionGroup="eventPathPart"/>
	skipping to change at page 29, line 9 ¶		skipping to change at page 28, line 49 ¶
	</xsd:restriction>		</xsd:restriction>
	</xsd:simpleType>		</xsd:simpleType>
	</xsd:schema>		</xsd:schema>
	ForCES LFB XML Schema		ForCES LFB XML Schema
	4. Acknowledgements		4. Acknowledgements
	The author would like to acknowledge Joel Halpern, Jamal Hadi Salim		The author would like to acknowledge Joel Halpern, Jamal Hadi Salim
	and Dave Hood for their comments and discussion that helped shape		and Dave Hood for their comments and discussion that helped shape
	this document in a better way. Adrian Farrel for his AD review and		this document in a better way. Special acknowledgements to Joel
	Ben Campbell for his Gen-ART review which both improved the quality		Halpern for resolving the issue with the default values. Adrian
	of this document.		Farrel for his AD review, Ben Campbell for his Gen-ART review and Tom
			Yu for his security review, all of which improved the quality of this
			document. Additionally the following members of the IESG Stephen
			Farrel, Barry Leiba and Ted Lemon for their reviews and comments that
			shaped the final version of this document.
	5. IANA Considerations		5. IANA Considerations
	IANA has registered a new XML namespace, as per the guidelines in RFC		IANA has registered a new XML namespace, as per the guidelines in RFC
	3688 [RFC3688].		3688 [RFC3688].
	URI: The URI for this namespace is		URI: The URI for this namespace is
	urn:ietf:params:xml:ns:forces:lfbmodel:1.1		urn:ietf:params:xml:ns:forces:lfbmodel:1.1
	Registrant Contact: IESG		Registrant Contact: IESG
	XML: none, this is an XML namespace		XML: none, this is an XML namespace
	6. Security Considerations		6. Security Considerations
	This document adds only a few constructs to the initial model defined		This specification adds only a few constructs to the initial model
	in [RFC5812], namely namely a new event, some new properties and a		defined in [RFC5812], namely namely a new event, some new properties
	way to define optional access types and complex metadata. In		and a way to define optional access types and complex metadata. In
	addition this document addresses and clarifies an issue with the		addition this document addresses and clarifies an issue with the
	inheritance model by introducing the version of the derivedFrom LFB		inheritance model by introducing the version of the derivedFrom LFB
	class. These constructs and the inheritance model change do not		class. These constructs and the inheritance model change do not
	change the nature of the initial model.		change the nature of the initial model.
	Thus the security considerations defined in [RFC5812] applies to this		Thus the security considerations defined in [RFC5812] apply to this
	document as well as the changes proposed here are simply constructs		specification as well, as the changes proposed here are simply
	to write XML library definitions, as where in [RFC5812] and clarifies		constructs to write XML library definitions, as in [RFC5812]. These
	the inheritance issue of the initial model and both have no effect on		changes, as well as the clarification of the inheritance issue of the
	security semantics with the protocol.		initial model, have no effect on the security semantics of the
			protocol.
			In regards to pervasive monitoring (PM), as discussed in [RFC7258],
			this specification defines ways to expose more complex information,
			namely metadata, exchanged between LFBs and between CEs and FEs and a
			new event. These changes have very little or no effect in terms of
			making PM simpler or more effective to an attacker who controls the
			LFBs. The new metadata might make for slightly more elegant PM, but
			does not enable any really new way to (ab)use LFBs for PM. The same
			applies for the new event.
			Finally, this document does not provide any protocol specification
			and as such does not specifies how information will be transmitted
			between respective entities, thus PM mitigation for a passive
			attacker that simply wants to eavesdrop on the information exchanged
			is out of scope.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	skipping to change at page 30, line 19 ¶		skipping to change at page 30, line 29 ¶
	[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control		[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
	Element Separation (ForCES) Forwarding Element Model", RFC		Element Separation (ForCES) Forwarding Element Model", RFC
	5812, March 2010.		5812, March 2010.
	[RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim,		[RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim,
	"High Availability within a Forwarding and Control Element		"High Availability within a Forwarding and Control Element
	Separation (ForCES) Network Element", RFC 7121, February		Separation (ForCES) Network Element", RFC 7121, February
	2014.		2014.
			[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
			Attack", BCP 188, RFC 7258, May 2014.
	7.2. Informative References		7.2. Informative References
	[OpenFlowSpec1.1]		[OpenFlowSpec1.1]
	http://www.OpenFlow.org/, "The OpenFlow 1.1		http://www.OpenFlow.org/, "The OpenFlow 1.1
	Specification.", <http://www.OpenFlow.org/documents/		Specification.", <http://www.OpenFlow.org/documents/
	OpenFlow-spec-v1.1.0.pdf>.		OpenFlow-spec-v1.1.0.pdf>.
	Author's Address		Author's Address
	Evangelos Haleplidis		Evangelos Haleplidis
End of changes. 66 change blocks.
	151 lines changed or deleted		173 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/