Hi all and John :-)   -

I don't have an aversion to XML - I actually sorta like it due to its structured high level specifications.  And even namespaces are not so bad - if they are well considered.   But you must admit defining where XML ends and Web Service begin is a slippery slope  :-) 

The problem at hand is thus:  How do we identify service "endpoints" or STPs within the NSI context?

If we look at some high successful aspects of the internet we see:  Names that map to IP addresses, IP addresses that map globally to an interface, and interface addresses that can be moved locally to other hardware without changing references to those interfaces.    

The <network>:<endpoint> tuple is analogous to the global IP address with its <network>/<host> definition.  So we can call the NSI tuple a symbolic global addressing scheme.   I think this is an important feature for NSI. AS it turns out, this tuple is sufficient to route a request across the global NSI topology, but is independent of the physical topology.  It is the leaf NSA's job to know how to translate an NSI EPR to the local NRM.   Indeed, since the leaf NSA is just a PA frontend to the NRM, we can say that translating from NSI EPR to local NRM is the job of the NRM-PA. THis makes the translation to local topology a function of the NRM and out of scope for NSI.

We could allow a topological specification as well.   But this has the drawback that every application globally referencing that end point will need to know the topological location.  If that physical location changes for any reason, all applications need to be changed.  Just as IP address *can* be used for URLs, DNS names are used in order to abstract the desired endpoint from the physical location it occupies at the moment.    In addition, advertising endpoints by their topological specification allows internal topology to leak out globally.

I know Inder (and probably Tomohiro) have questions about how you select VLANs at a remote endpoint, but I view this as a pathfinding issue within each domain - not a global issue.  While this is related to topology and visibility, if we stay within the confines/context of the NSI-CS protcol I do not think we need to address this in the standard.  At least not immediately.

So whether we use a "urn:blah <domain>:<endpoint>" or just a raw tuple "//<domainname>/<endpointname>" is not a big issue with me.  As long as we support the tuple and agree on *one* convention that all NSAs must recognize. 


I have a couple other comments below...



On 3/12/11 8:42 PM, John MacAuley wrote:
On 2011-03-10, at 11:16 AM, Jerry Sobieski wrote:

> If someone thinks we need a URN specification for version 1.0, please pipe up and
> provide the reasoning - there may be such, I just am unaware of one in my mind at
> this moment.  (But please don't tell me its needed for web services-WS is not why we
> created NSI:-).  Adding a URN prefix qualifies the namespace - why does/should NSI
> need a qualified namespace for endpoint references?  If you think we do, or even if
> you think it is just a good idea, please explain how this reconciles with the NSI
> architecture - i.e. how the URN version maps the <network><endpoint> tuple, and
> how it improves the basic GID mentioned above?   Remember, we are only speaking
> to NSI endpoint references,...

Jerry,

It makes me giggle just imagining you in front of our computer having a seizure every time you think of web services. 
Well I'm glad I entertain you all:-)

I am truly sorry we have such differing opinions on this.  But I have not seen much compelling to change my opinion that Web Services is highly structured to very little practical effect.   A noble vision, but it got buried in a mountain of software and specifications.  Where is the  K&R and Hello World of web services? 

Just to make sure we are clear on definitions, URNs are not specifically associated with web services, and in fact, have little to do with web services.  Here is the introduction from RFC2141 that defines the URN:

  • Uniform Resource Names (URNs) are intended to serve as persistent location-independent, resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. Therefore, the URN syntax provides a means to encode character data in a form that can be sent in existing protocols, transcribed on most keyboards, etc.

By definition it is exactly what you have been asking for with physical location independent naming.  Whether you are using web services or some other binary protocol, a URN is just a syntax for identification and naming.  This mechanism has been chosen for use by the GLIF, perfSONAR, and the NML group.

Now, a URN also qualifies as an instance of a URI similar to how a URL is also an instance of a URI.  Perhaps this is why you may have confused it with  web services?
I think my concern is that the endpoints we are trying to reference are not values passed to application services - they are endpoints of conenctions.   Is it apropriate to force all users of NSI to adopt OGF naming conventions for their network endpoints?  It is one thing to say NSI uses these namepsaces internal to the protocol, its is another to say all users of NSI services must also use OGF name spaces to name their endpoints. If we specify any namesapce, it seems to me we are also excluding all others.   Is this necessary to identify endpoints suitably?- or just a habit we've gotten into?

Personally, I do not like to be wishy washy with types when defining protocols.  Stating that an endpoint mush be from a URN namespace, or more specifically, the OGF URN namespace, will give more clarity in the protocol definition, and bind the protocol definition to other OGF specifications. 
Speaking of clarity, how much "clarity" does it really need?  What is not clear?   We are talking about a two part tuple...  That carries no NSI relevant information in the names.   Why would more namespaces provide more "clarity"?   Namespaces just qualify the ...uh..namespace.   duh.  I think what you want is not just namespaces but XML schemas.  

Remember - these names are not places we are sending HTTP commands - these are dataplane end points.   Putting all that clarity on them sure seems to me to be unnecessary ...I don't see the confusion.
I would probably define a compound type as follows (I use XML schema since I know it well):

   <xsd:complexType name="StpType">
      <xsd:sequence>
         <xsd:element name="domain" type="xsd:anyURI" />
         <xsd:element name="endpoint" type="xsd:anyURI" />
      </xsd:sequence>
   </xsd:complexType>

However, I am not going to argue is people think it should be two strings instead of two URN.

John.

Thanks John and all of you for the thoughtful discussion.
Jerry