I like NML to be extensible. For example, if some NML publisher likes to add information that benefits monitoring or provisioning, that should be possible. A NML receiver should silently ignore this added information. However, we also don't want a receiver to just accept anything. If there is some obvious error in the NML, the receiver should still just reply with an error message. Imagine a receiver that receives some NML line containing a relation. 1. The relation is well-defined. e.g. Node N --hasService--> SwitchingService S 2. The relation is unknown e.g. Node N --hasDynamicService--> SwitchingService S 3. The relation is clearly invalid e.g. Node N --hasService--> Node Y 4. The relation is known, but the meaning is undefined e.g. Port P --hasService--> LabelService L Should we make a distinction between 3 and 4? For the purpose of extensibility, I would argue that it is useful to make this distinction. In fact, the current document makes this distinction. To quote the text on "hasService":
hasService relates a Network Object to a Service. This schema only defines the meaning of: • Port to AdaptationService, relating one server-layer Port to an adaptation function • Port to DeadaptationService, relating one server-layer Port to a deadaptation function • Node or Topology to SwitchingService, describing a switching capability of that Node or Topology.
So in this case "Port P --hasService--> LabelService L" would be syntactical VALID NML but with UNDEFINED meaning. "Node N --hasService--> Node Y" would simply be syntactically INVALID NML. Regardless if we think this distinction is useful, we should define how a NML receiver should handle the information. I can think of four situation what it should do with it: a) reject the line and reply with an error message b) accept the line and process it (for an known relation) c) silently drop the line d) store the line, even though it is unknown I'm not sure if (d) is ever a good idea. It means that a receiver will accept a Topology from T, and store all, including unknown statements, and if asked by someone else, it would faithfully replicate the original topology, including all unknown statements. My proposal is to: 1. The relation is well-defined. Requirement b: The receiver SHOULD accept and process the NML. 2. The relation is unknown Requirement c/d: The receiver MAY either silently drop or MAY accept the statement. 3. The relation is clearly invalid Requirement a: The receiver MUST NOT accept the NML, and SHOULD inform the sender of the error. 4. The relation is known, but the meaning is undefined Requirement c/d: The receiver MAY either silently drop or MAY accept the statement. (so I'd say that while we should distinguish between 3 and 4, in that situation 4 is processed the same as situation 2). Freek
Hi, On 17 Aug 2012, at 14:57, Freek Dijkstra <freek.dijkstra@sara.nl> wrote:
I like NML to be extensible. For example, if some NML publisher likes to add information that benefits monitoring or provisioning, that should be possible.
A NML receiver should silently ignore this added information. However, we also don't want a receiver to just accept anything. If there is some obvious error in the NML, the receiver should still just reply with an error message.
I am not entirely sure that we can reasonably make this distinction. And even if we can, without bloating the current schema into probably twice its current size.
Imagine a receiver that receives some NML line containing a relation.
1. The relation is well-defined. e.g. Node N --hasService--> SwitchingService S 2. The relation is unknown e.g. Node N --hasDynamicService--> SwitchingService S 3. The relation is clearly invalid e.g. Node N --hasService--> Node Y 4. The relation is known, but the meaning is undefined e.g. Port P --hasService--> LabelService L
Should we make a distinction between 3 and 4?
For the purpose of extensibility, I would argue that it is useful to make this distinction.
In fact, the current document makes this distinction. To quote the text on "hasService":
hasService relates a Network Object to a Service. This schema only defines the meaning of: • Port to AdaptationService, relating one server-layer Port to an adaptation function • Port to DeadaptationService, relating one server-layer Port to a deadaptation function • Node or Topology to SwitchingService, describing a switching capability of that Node or Topology.
So in this case "Port P --hasService--> LabelService L" would be syntactical VALID NML but with UNDEFINED meaning. "Node N --hasService--> Node Y" would simply be syntactically INVALID NML.
I am not sure how you make that distinction based on the description given above. For both Port and Node there is a possible "hasService" relation defined, and neither "LabelService" nor "Node" are defined as possible ranges of the hasService relation. Just the fact that "LabelService" is a new kind of object should not make it different.
Regardless if we think this distinction is useful, we should define how a NML receiver should handle the information. I can think of four situation what it should do with it: a) reject the line and reply with an error message b) accept the line and process it (for an known relation) c) silently drop the line d) store the line, even though it is unknown
I'm not sure if (d) is ever a good idea. It means that a receiver will accept a Topology from T, and store all, including unknown statements, and if asked by someone else, it would faithfully replicate the original topology, including all unknown statements.
D is a very well established way of handling things which is also applied to OSPFs extension fields for example. It is an excellent way of easing a new kind of relation into the system without having to rely on a flag-day where everyone switches over. Silently dropping is a really bad idea, which makes diagnostics a nightmare. I am very much in favor of always accepting and storing. Jeroen.
On 17-08-2012 16:37, Jeroen van der Ham wrote:
Hi,
On 17 Aug 2012, at 14:57, Freek Dijkstra <freek.dijkstra@sara.nl> wrote:
I like NML to be extensible. For example, if some NML publisher likes to add information that benefits monitoring or provisioning, that should be possible.
A NML receiver should silently ignore this added information. However, we also don't want a receiver to just accept anything. If there is some obvious error in the NML, the receiver should still just reply with an error message.
I am not entirely sure that we can reasonably make this distinction.
Regardless if we can or not (we can and in fact already do, by the way): is it useful? The alternative is that the receiver should accept anything, including obvious errors in the NML. That doesn't seem useful to me. Are you suggesting that accepting obvious errornous NML is useful, or merely stating that while it's useful you don't see how to make it happen?
And even if we can, without bloating the current schema into probably twice its current size.
We already did that. You even wrote down the text yourself. So no, it does not bloat it. Again, see this example:
In fact, the current document makes this distinction. To quote the text on "hasService":
hasService relates a Network Object to a Service. This schema only defines the meaning of: • Port to AdaptationService, relating one server-layer Port to an adaptation function • Port to DeadaptationService, relating one server-layer Port to a deadaptation function • Node or Topology to SwitchingService, describing a switching capability of that Node or Topology.
[..]
So in this case "Port P --hasService--> LabelService L" would be syntactical VALID NML but with UNDEFINED meaning. "Node N --hasService--> Node Y" would simply be syntactically INVALID NML.
I am not sure how you make that distinction based on the description given above. For both Port and Node there is a possible "hasService" relation defined, and neither "LabelService" nor "Node" are defined as possible ranges of the hasService relation.
Just the fact that "LabelService" is a new kind of object should not make it different.
If we write it as <nml:Service type="http://.../LabelService"> than it is obvious that this is a NML Service. Also, it is clear that a NML Node is not a subclass of Service, so I think they're different. Freek
On Aug 17, 2012, at 10:52 AM, Freek Dijkstra wrote:
On 17-08-2012 16:37, Jeroen van der Ham wrote:
Hi,
On 17 Aug 2012, at 14:57, Freek Dijkstra <freek.dijkstra@sara.nl> wrote:
I like NML to be extensible. For example, if some NML publisher likes to add information that benefits monitoring or provisioning, that should be possible.
A NML receiver should silently ignore this added information. However, we also don't want a receiver to just accept anything. If there is some obvious error in the NML, the receiver should still just reply with an error message.
I am not entirely sure that we can reasonably make this distinction.
Regardless if we can or not (we can and in fact already do, by the way): is it useful?
The alternative is that the receiver should accept anything, including obvious errors in the NML.
That doesn't seem useful to me. Are you suggesting that accepting obvious errornous NML is useful, or merely stating that while it's useful you don't see how to make it happen?
And even if we can, without bloating the current schema into probably twice its current size.
We already did that. You even wrote down the text yourself. So no, it does not bloat it. Again, see this example:
In fact, the current document makes this distinction. To quote the text on "hasService":
hasService relates a Network Object to a Service. This schema only defines the meaning of: • Port to AdaptationService, relating one server-layer Port to an adaptation function • Port to DeadaptationService, relating one server-layer Port to a deadaptation function • Node or Topology to SwitchingService, describing a switching capability of that Node or Topology.
The problem comes in extending relations in NML 1.1 or later. If we define a new "hasService" meaning (e.g. Node to ForwardingService, describing a packet forwarding capability of that Node), how do we make it so that the NML 1.0 client can ignore that relationship the same as if we'd defined this new meaning using a "hasForwardingService" relation instead of "hasService". If 1.0 clients will reject these changed relation meanings, we either have to put a version number on the relations, lose backward compatibility or never reuse relation names. I'm fine with either having clients accept relations that happen to have the same name but don't make sense to the client (e.g. hasService between Node and ForwardingService), or introducing a version number attribute for all relations (e.g. hasService/1.0 vs. hasService/1.1). Cheers, Aaron Internet2 Fall Member Meeting Sep 30-Oct 4, 2012 - Philadelphia, PA http://events.internet2.edu/2012/fall-mm/
participants (3)
-
Aaron Brown -
Freek Dijkstra -
Jeroen van der Ham