[Nml-wg] References

[Aaron Brown]

I wasn't being clear with my idRef case. It wasn't specifically about having an 'idRef' syntax. It was about whether the elements defined in relationships can be defined with references to existing elements instead of being another definition of that element. If we're going to go this route, i'd vote for completely axing the idRef syntax completely. The "experimental" draft can define the "is-defined-by" relationship, and then we can talk about references there, and when the time comes, allow using anonymous elements with "is-defined-by" relations in them inside relations. However, if we're not going to have references, we have to include text to the effect that "if there are multiple definitions of A, including every relation definition of A, and the results of combining all definitions of A into one monster 'A' are ambiguous, that's your own fault", because every time there is a relation pointing to A, it creates a new definition of A to which attributes can be added, and the result of combining all the various A's can easily become ambiguous (e.g. my previous example where there are 3 "definitions" of A (i.e. 1 real definition, and 2 relation definitions), all with a different description attribute because each is looking at A from the perspective of a different network element).

All I really wanted was that there be *some* method for defining references, and allowing their use in relations to be able to remove the above ambiguity. i.e. to allow network elements to say "i'm telling you about A from my perspective" vs. "I'm telling you about A". This could even be orthogonal to Jeroen's proposal insofar as you could still have the rule "everything with an id=A gets combined into one huge thing" because the references could be in anonymous elements. At that point, there are just become 2 methods of defining references: define an element with id=A, define an anonymous element with an explicit reference to A.

Cheers,
Aaron

On Oct 17, 2012, at 6:23 AM, Freek Dijkstra wrote:

> Hi all,
> 
> The WG has been discussing the id/idRef/isReference last week at OGF36,
> with valuable input from Aaron by email.
> 
> Unfortunately, there still does not seem a clear consensus.
> 
> This means that I feel forced to move this issue to the experimental
> draft. If you disagree, please read the rest of this email and reply
> before the Oct 25 conference call.
> 
> Since nearly all participants agree that the discussed concepts are
> useful, I do suggest to continue to discussion. We do need this in the
> experimental document, not drop it altogether.
> 
> It seems that there are three overlapping use cases: authority
> (distinguishing between something defined by the sender, or defined by a
> third party), reference (pointing to the location -third party, or other
> place in the document-) and finally verification (making sure that a
> definition is complete, and uniquely defined).
> 
> Most proposal I've seen dealt with syntax, some with logic, but none
> really started with a requirement based on these use cases. That leads
> me to believe that this issue is not fully understood and belongs in the
> experimental document.
> 
> These topics have one thing in common: they all are part of the control
> plane of the NML protocol, rather than issues dealing with actually
> Topology description. For example, the authority use case ultimately
> deals with trust. Jeroen's proposal is to basically accept all messages
> as authoritative and combine them in a single object, regardless of
> origin of the message and how it is described (or at least deal with
> this sort of logic on the application layer). Aaron's proposal is more
> elaborate, and does allow the sender to make a distinction between a
> full definition and a object reference. This might allow syntax checks
> or change the confidentiality level that a NML recipient may have in a
> statement (compare "here a full description of a Port" to "I *think*
> this link ends up at this-and-that 3rd party Port, but I don't know the
> details of that port"). If I was recipient, I would place more
> confidentiality in the first message than the second statement, and if
> the conflict, I would drop the second statement in favour of the first.
> 
> I still feel that Aaron's proposal has a good potential. However, I'm
> still not 100% sure about the logic -- is it only about verification, or
> also authority? Despite the subject line in this email thread, it
> doesn't seem to be about reference (after all, an idRef means the id may
> either be defined elsewhere in the document, or it may be defined by a
> third party, but it doesn't tell me who that third party is or where in
> the document the definition can be found).
> 
> Hence, I'm going with the most simple (and IMHO less elegant) proposal
> by Jeroen which doesn't make any statement about any of the above, and
> just uses "id" all the time. No idRef, no isReference, no isDefinedBy.
> 
> One thing we still want to consider is to include idRef in the NML-base
> document, and say that NML compatible parsers SHOULD also accept the
> "idRef" in addition to the "id" parameter. A parser SHOULD treat them
> equally. This would at least allow us to later differentiate between id
> and idRef. This may help prevent backward incompatibility if we decide
> to add idRef later.
> 
> This issue has some strong opponents, so if you feel that I as co-chair
> made the wrong decision here, please let me know off-list of on-list.
> I'm always open to suggestions and improvement. And please, do not stop
> discussing this issue. We should pursue it; it is just that at the
> current state of discussion I see no other option to move it to
> experimental not to unduly delay publication of the base document.
> 
> Regards,
> Freek
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg

TIP2013, University of Hawaii Mānoa
January 13 - January 17, 2013, Honolulu, HI
http://events.internet2.edu/2013/tip/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20121017/156dad05/attachment.html>