Peoples, I have taken another look over Jeroen's document "Network Service Interface Topology Representation" given the discussion we had today on the call. I must say that we are totally out of synch with the definition of an STP Identifier in Jeroen's document and what we have in the NSI CS (no specific fault on Jeroen). Specifically, if we look at section 2.2 and 2.3 the STP identifier is defined as follows: STP ID = urn:ogf:network:example.net:2013:A2?vlan=1781 urn:ogf:network: - describes that it is a network identifier. example.net:2013 - DNS name and a (at least) year to make a globally unique prefix creating the network identifier. A2?vlan=1781 - The local component identifying the STP in the context of the network identifier. The root STP ID "urn:ogf:network:example.net:2013:A2" would be an under specified STP referring to the bundle of STP enumerated by vlan. I believe, although not specifically stated, that "urn:ogf:network:example.net:2013:A2?vlan=1780-1790" would also allow me to under specify a range of vlan. This definition for an STP Identifier is in line with the Baton Rouge discussions. This is also how I build an internal STP identifier within my path finder implementation so I can refer to an STP using a single string. So there is a gap in definition between what we have defined as an STP identifier, and what is defined in the nsi-ext specification. We have taken multiple fields from NML objects and composed a complex STP Identifier: NSI CS STP Identifier = { networkId = NML Topology Identifier; localId = NML BidirectionalPort Identifier choice { label = NML Unidirectional Port Label; labelGroup = NML Unidirectional PortGroup LabelGroup; } } To compare the content of the two, here is an example of an STP from the Netherlight topology: <sourceStp> <networkId>urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed</networkId> <localId>urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1</localId> <label type="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1781</label> </sourceStp> versus something like this: urn:ogf:network:netherlight.net:2013:a-gole:testbed:port:uva:1?vlan=1781 where "urn:ogf:network:netherlight.net:2013:a-gole:testbed:" is the network portion, and "port:uva:1?vlan=1781" is the local portion. I must admit I am questioning the value of our complex STP definition. I understand the value of the being able to route on networkId, and the issue with URN opaqueness, but if we are constructing the URN following a specific set of rules, could we also not parse it similarly? John