Hey Jason, Excellent discussion. I attached the original example again, with one small change: segmentBC is now part of domain "example.org" instead of "example.net". Remember, there are two distinct ways in the XML to "trace" the original path: - Using ports (if the sink of link A is port X, and the source of link B is also port X, you know that links A and B are connected in series) - Using explicit ordering (either order="1", order="2" or hop/nextHop). Could you confirm that you want to see BOTH approaches in NML? (I think there are use cases for both.) We're currently focussing on the second way. Let's continue that.
I would vote for Aaron's proposal that I listed out in one of the first mails (no longer in this tread for some reason) to use pointer elements instead of count/type elements. I believe that respects the original hop/path idea a little closer. If the existing tooling can deal with a concept that 'follows' a path, that's a strong argument to remain with it even if the syntax changes slightly.
Could you rewrite the attached example to use the hop/nextHop approach? I think we should write both down in detail, and if we're happy with both examples, we should ask the group to vote (I currently have no preference). Regarding the id/idRef distinction, I probably understand what you're saying in text, but I can't translate this to XML. Both statements below make sense, but they still seem to clash.
Typically 'id' is the definition of something, 'idRef' is used as a pointer to something previously defined. [...]
Let's take the example that domain example.org wants to say "urn:ogf:network:example.org:segmentBC is a segment of the end-to-end link urn:ogf:network:example.net:pathAC, but I don't know the names of other segments of this path". If I follow the above statement, I'm inclined to write: <nml:link id="urn:ogf:network:example.net:pathAC"> <nml:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:example.org:segmentBC"/> </nml:relation> </nml:link> <nml:link idRef="urn:ogf:network:example.org:segmentBC"> <!-- more properties of this link --> </nml:link>
Following these examples, I would claim that if some domain defines/owns an object, such as a link, they get to assign the 'id' field. If this is a GLIFesq definition I would assume this gives it a global scope.
For any other use that wishes to reference this original, there needs to be a clear semantic meaning that we are not trying to define (or re-define) the original. In the case of an end to end path that is using several links that belong to others (e.g. the control plane world), I am suggesting that if you intend to reference the individual components of the entire path, it is necessary to use idRefs instead of ids.
However, following the above text, example.org can only use the id attribute for it's own links, and should use idRef for the end-to-end link defined by example.net: <nml:link idRef="urn:ogf:network:example.net:pathAC"> <nml:relation type="serialcompound"> <nml:link id="urn:ogf:network:example.org:segmentBC"/> </nml:relation> </nml:link> (Obviously if example.net would announce the very same information, the id and idRef would flip in this example.) Which one did you mean? Regards, Freek (PS: I trimmed the cc with people who are already on the NML mailing list. I also increased the cc limit, this should stop the bounces.)
