[Nml-wg] Dealing with unknown relations

[Aaron Brown]

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 at 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120821/635d8833/attachment.html>