Evangelos Chaniotakis wrote:
I agree, but I say: formalize that pop1 is the "abstracted" view and the rest are the "detailed" view. If we did that, a network information DB could hand out that single document and applications would select the view that's most appropriate for their demands and capabilities. In the snippet above, there is no way to tell if pop1 is a real node or a "virtual" node. (and, if you start labeling things, you end up doing something quite similar to views)
And as far as treating domains and networks as generic Nodes with interfaces poking out: No problem, and I don't see it conflicting with the domain / view / network model. They could (and probably should) all have the NetworkNode aspect.
So, if one is creating a specific view, why is it being limited to a view of a single administrative network? Couldn't I create a 'view' of the set of pinger measurement points where the set of nodes spanned across a large number of administrative domains? I think the view concept is really the same as the 'group' element that we discussed at OGF. It's basically a grouping of various network elements that have some relation. Defining what this relation is in a view seems to depend on the context. Say a user requests all the views that i've defined. How does it know which one to select? i.e. How do we assign meaning to this arbitrary grouping of elements. Once we've defined on how to assign meaning to these groupings, I think the difference between a group and a view goes away. I.e. how is "i know what group X means" different than "i know what view X means"? Cheers, Aaron