I don't have a solid definition, but in my view, "isAlias" should define some sort of identity relation, which can be used for two different purposes:


* Joining two identifiers given out by different organisations if they -for whatever reason- can not agree on a common identifier. (I suspect a single
 resource may get more identifiers in these case: a boundary between two domains, or a Link that spans multiple domains)

* To add a level of indirection so that a more abstract identifier can be used externally while a more concrete identifier is used internally. E.g. 
the abstract "link-domainx-domainy" isAlias of the concrete "link-domainx-deviceAhc34-intf3.1-to-domainy-deviceBfg5-intf0.28"

I encourage arguments why these two things should use two different relations, but in absence of these arguments, I propose to use the "isAlias" 
relation to cover both purposes.

FYI, this presumes that we indeed want the concept of subtopologies. I created artf6551 to discuss that.

This item should discuss aliases, and should be updated with the 3 proposals, and with the discussion that followed.

NSI is proposing to use aliases in topologies and subtopologies. it seems to be an extension for NSI, can we think of 
other NML use-cases?

Jerry is volunteering to provide a proposal.

NSI is proposing to use aliases in topologies and subtopologies. it seems to be an extension for NSI, can we think of 
other NML use-cases?

unclear whether alias describes port adjacency, or identity relations of NML objects

Jerry is volunteering to provide a proposal.