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