[Nml-wg] Dealing with unknown relations

[Freek Dijkstra]

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