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