Hi, Forgot life-cycle issues.... There does not appear to be any notion of a module revision in ForCES. There does not seem to be any way to identify a particular definition as either current, deprecated, or obsolete.
Is a library used with the <load> element ever allowed to change? If so, how are new revisions identified? Is there any text explaining how these modules are allowed to change over time? Was this considered by the WG? Andy On Mon, Apr 21, 2014 at 2:44 PM, Andy Bierman <[email protected]> wrote: > Hi, > > > On Mon, Apr 21, 2014 at 8:10 AM, Jamal Hadi Salim <[email protected]>wrote: > >> On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman <[email protected]> >> wrote: >> > >> > I think Jan and others have explained why they think they can leverage >> > the NC/RC/YANG technology to implement I2RS. There are tool >> > and data model management requirements in addition to the protocol >> > in order to have a workable solution. >> > >> > Unless the RIB data is one monolithic blob implemented without >> > variation on every router, then issues such as modularity, conformance >> > model, data lifecycle, distributed naming authority, data augmentation, >> > and language extensibility are going to matter. >> > >> >> So lets put all that in a requirement list somewhere and work around a gap >> analysis. >> >> > So how does ForCES support these things? > Where is the language specification in RFC 5812? > Section 4 describes LFB classes, which appear to represent the only > supported data > for the protocol. Is the entire normative language specification contained > in the XSD in sec. 4.9? > > What happens if multiple <load> elements pull in definitions with the > same local name? The examples do not show any use of prefixes > and the <load> element has no prefix mapping. > > <load library="a_library"/> > <load library="another_library" location="another_lib.xml"/> > <load library="yetanother_library" > location="http://www.example.com/forces/1.0/lfbmodel/lpm.xml"/> > > > There does not appear to be any conformance information like what is > mandatory or conditional on a user-defined feature. How are logical groups > of conditional objects defined and advertised in the protocol? (e.g., YANG > features) > > Are there examples of the augmentation described in sec. 4.5.7? > There does not appear to be any way for 1 module to add elements to another > <dataTypeDef> without controlling the naming for all modules. > > How does a vendor implement the unique naming requirements in ForCES > without controlling the names of all possible ForCES files? Are they > supposed to > rewrite modules when a naming collision occurs because modules X and Y are > being loaded > into module Z, which causes a new naming collision that did not occur > before? > > YANG supports groupings that can be refined in each use/expansion. > How are complex <dataTypeDef> statements reused and refined? > Where are examples of that in the RFC? > > > > How would I2RS use <frameDefs>? > > <frameDefs> > <frameDef> > <name>ipv4</name> > <synopsis>IPv4 packet</synopsis> > <description> > This frame type refers to an IPv4 packet. > </description> > </frameDef> > <frameDef> > <name>ipv6</name> > <synopsis>IPv6 packet</synopsis> > <description> > This frame type refers to an IPv6 packet. > </description> > </frameDef> > ... > </frameDefs> > > > Is this like a YANG identity statement, except this causes naming > collisions, > so it is more like a specialized distributed enumeration type? > > > To compare readability, here are the same type definitions in ForCES and > YANG: > > ForCES: (RFC 5812, pg. 80) > > <dataTypeDef> > <name>accessPermissionValues</name> > <synopsis> > The possible values of component access permission > </synopsis> > <atomic> > <baseType>uchar</baseType> > <specialValues> > <specialValue value="0"> > <name>None</name> > <synopsis>Access is prohibited</synopsis> > </specialValue> > <specialValue value="1"> > <name> Read-Only </name> > <synopsis> > Access to the component is read only > </synopsis> > </specialValue> > <specialValue value="2"> > <name>Write-Only</name> > <synopsis> > The component MAY be written, but not read > </synopsis> > </specialValue> > <specialValue value="3"> > <name>Read-Write</name> > <synopsis> > The component MAY be read or written > </synopsis> > </specialValue> > </specialValues> > </atomic> > </dataTypeDef> > > > YANG: > > > typedef accessPermissionValues { > > description > > "The possible values of component access permission"; > > type enumeration { > > enum None { > > value 0; > > description "Access is prohibited"; > > } > > enum Read-Only { > > value 1; > > description "Access to the component is read only"; > > } > > enum Write-Only { > > value 2; > > description "The component MAY be written, but not read"; > > } > > enum Read-Write { > > value 3; > > description "The component MAY be read or written"; > > } > > } > > } > > > > > How are new protocol operations defined? Are they part of the language. > > > How are language extensions done? This does not appear to be supported. > > How are existence constraints between objects expressed? (e.g., > must/when/unique) > > How does a vendor add arbitrary data to notification events? > Can event definitions be augmented? > If so, how is this done so nodes can be conditional? (e.g., if-feature, > when) > > The <eventCondition> element is one of many that seems very ForCES > specific. > How are new events added? > > I don't see an event definition for the "Goof1changed" example: > > > </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"/> > <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> > > > <event eventID="8"> > <name>Goof1changed</name> > <synopsis> > An example event for a complex structure > </synopsis> > <eventTarget> > <!-- target is goo.f1 --> > <eventField>goo</eventField> > <eventField>f1</eventField> > </eventTarget> > <eventChanged/> > <eventReports> > <!-- report the new state of goo.f1 --> > <eventReport> > <eventField>goo</eventField> > <eventField>f1</eventField> > </eventReport> > </eventReports> > </event> > > > I am still confused about the <metadataDefs> general applicability. > E.g., how are <inputPorts>, <outputPorts> used in I2RS? > > > >> cheers, >> jamal >> > > > Andy > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
