At the call earlier today we shortly discussed how to deal with future extensibility of NML. Let me give two practical examples: 1) Topologies may change over time, and the "version" attributed is used as a serial number to distinguish between updates in the Topology description (akin to the serial number in DNS SOA records). Currently this version attribute is only allowed for Topologies; allowing it for each network object may complicate change management more than needed. However, we can envision a situation where a future NML version would allow this use. 2) the "hasTopology" relation is only allowed between two Topologies, but perhaps in the future NMLv2 allow it from a Service to a Topology. We hope that the following will work: * The schema (UML schema, RDF schema and XML schema) will be "loose": they will liberally allow all sorts of extensions. In the above examples, the version attribute can be part of all Network Objects, and hasTopology may relate any Network Object to a Topology. * In the text, we will add further restrictions about the behaviour of NML version 1 compliant agents. In the above examples, a NMLv1 generator SHOULD NOT add version attributes to non-Topology network objects; a NMLv1 parser SHOULD ignore version attributes for non-Topology network objects; the meaning of the "hasTopology" relation between a Service and a Topology is undefined, and SHOULD be ignored by NMLv1 parsers. * Specific application may pose further restrictions on the NML descriptions that are generated and parsed. For example, NSI may impose restrictions how a STP is described in NML. Is this a useful way forward that both allows extensibility, without allowing too many variations (and thus interoperability) of NML? Regards, Freek
On Jun 28, 2012, at 2:12 PM, Freek Dijkstra wrote:
At the call earlier today we shortly discussed how to deal with future extensibility of NML.
Let me give two practical examples:
1) Topologies may change over time, and the "version" attributed is used as a serial number to distinguish between updates in the Topology description (akin to the serial number in DNS SOA records). Currently this version attribute is only allowed for Topologies; allowing it for each network object may complicate change management more than needed. However, we can envision a situation where a future NML version would allow this use.
2) the "hasTopology" relation is only allowed between two Topologies, but perhaps in the future NMLv2 allow it from a Service to a Topology.
We hope that the following will work:
* The schema (UML schema, RDF schema and XML schema) will be "loose": they will liberally allow all sorts of extensions. In the above examples, the version attribute can be part of all Network Objects, and hasTopology may relate any Network Object to a Topology.
* In the text, we will add further restrictions about the behaviour of NML version 1 compliant agents. In the above examples, a NMLv1 generator SHOULD NOT add version attributes to non-Topology network objects; a NMLv1 parser SHOULD ignore version attributes for non-Topology network objects; the meaning of the "hasTopology" relation between a Service and a Topology is undefined, and SHOULD be ignored by NMLv1 parsers.
* Specific application may pose further restrictions on the NML descriptions that are generated and parsed. For example, NSI may impose restrictions how a STP is described in NML.
Is this a useful way forward that both allows extensibility, without allowing too many variations (and thus interoperability) of NML?
I think this is a general case of "undefined attributes or relationships are undefined". If someone adds a 'version' attribute to a Port, the fact that we've got an attribute for Topologies is immaterial. It should be treated in the same manner as if they'd added a 'is_on_fire' attribute to a Node. Same deal with the relationships. If someone adds a "hasTopology" for a service or whatever, then it's treated the same as if they'd added a "hasPortIfOnFire" relationship to a Node. We could probably get away with "NMLv1 parsers SHOULD ignore undefined attributes or relationships. NMLv1 generators MAY add attributes or relationships outside of the NMLv1 specification, but MUST NOT assume that other parsers will handle those attributes or relationships.", and the cases above would simply implicitly be part of this. Cheers, Aaron
Regards, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
ESCC/Internet2 Joint Techs July 15-19, 2012 - Palo Alto, California Hosted by Stanford University http://events.internet2.edu/2012/jt-stanford/
Freek Thanks, I very much appreciate this feedback. We seem to be on the same track (which is good), and gives some good textual suggestions. Also, I very much like to see that "is_on_fire" attribute be put into action some day ;) Freek
I think this is a general case of "undefined attributes or relationships are undefined". If someone adds a 'version' attribute to a Port, the fact that we've got an attribute for Topologies is immaterial. It should be treated in the same manner as if they'd added a 'is_on_fire' attribute to a Node. Same deal with the relationships. If someone adds a "hasTopology" for a service or whatever, then it's treated the same as if they'd added a "hasPortIfOnFire" relationship to a Node.
We could probably get away with "NMLv1 parsers SHOULD ignore undefined attributes or relationships. NMLv1 generators MAY add attributes or relationships outside of the NMLv1 specification, but MUST NOT assume that other parsers will handle those attributes or relationships.", and the cases above would simply implicitly be part of this.
Cheers, Aaron
Regards, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org mailto:nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
ESCC/Internet2 Joint Techs July 15-19, 2012 - Palo Alto, California Hosted by Stanford University http://events.internet2.edu/2012/jt-stanford/
participants (2)
-
Aaron Brown
-
Freek Dijkstra