[Nsi-wg] Identifiers

[Jerry Sobieski]

THanks Jeroen!   I figured the DNS thing was for uniqueness.  What 
happened to using the funky web service convention for generating unique 
strings?  :-)

As for yearly timestamps - this seems completely out in left field.   
That should be the purvue of the current owner to decide their structure 
unless it is critical to the NML topology descriptions to know what year 
an object name was created.  I think this pollutes an otehrwise usable 
naming convention.    It could be *suggested* ...but it complicates 
things unnecessarilly and is out of scope for NML  (IMHO).   Besides 
there is no way to enforce it.

I would suggest NML should decide what the :network: hierarchy formally 
represents.  Not the specific names, but the hierarchical structure.   
This should dictate the format of the structure ... does the structure 
represent an annual hierarchy??   :-)

I still think the year component is extraneous and should be removed.

Thanks again!
Jerry



On 6/13/12 9:13 AM, Jeroen van der Ham wrote:
> Hi,
>
> Let me quickly answer your questions:
>
> On 13 Jun 2012, at 14:54, Jerry Sobieski wrote:
>
>> If the NSI two-tuple<networkid>:<localid>  STP name is preserved in the NML naming convention, then I think it is possible to use the NML convention with maybe some minor mods...
>>
>> However, I have some concerns about the NML convention in this respect:
>>
>> Q1.)  Is the proposed NML naming convention "urn:ogf:network:<DNSname>:<year>:<opaque part>" used for all topological objects?  Or is it *only* for naming STPs?
> This is meant for all topological objects.
>
>> Q1.b)  Is "urn:ogf:network:" now to be used solely for NML topology? or will that namesapce be available for naming other objects or subspaces related to other aspects of grid networking in general?
> It is not restricted to NML topologies, it is meant for all kinds of things you want to identify in networking objects. The NML group is just taking the initiative in registering this subnamespace.
>
>> Q2.) Is it *required* that the NML naming element that follows "network" be specifically a DNS domain name?   I.e. Why does NML require a DNS name?   In essence, the *DNS requirement* makes the the domain naming registry the authority that guarantees uniqueness for OGF URNs.  right?    Further, requiring DNS names makes it difficult for end users to name their own network(s) as not every STP resides where a DNS name is clear or appropriate or valid.
> Yes, this is defined in the syntactic structure required by this namespace. The definition of this structure is require when you register a urn (sub)namespace. It is the method that we defined as the way to guarantee uniqueness.
> We do not foresee problems with end-users who own a large enough network to use this, yet not having a DNS name.
>
>> Q2.b) Since NSI Networks are "service domains" rather than comprehensive hardware infrastructure, they may not map directly or uniquely to specific DNS domains.  For instance, there is nothing preventing a number of collaborating organizations from pooling their resources into a single NSI Network service domain.  How would the DNS mapping be applied in this scenario?
> That would be up to those organisations to figure out. They have been able to somehow align their policies, part of that will probably also be to figure out a DNS name for it.
> In practice you almost always see that such an organisation would have a DNS name of its own (e.g., GLIF, Geant).
>
>> Q3.)  What does the DNS name level represent in terms of NML?  I.e. why have it at all ?  What are the NML requirements for object names that requires DNS names in them (or the year value that follows the DNS element..)
>> Q4.) There is a<year>  following the DNS element in the NML convention.  Why?   In particular, what authority is responsible for naming topological objects under a "ogf:network:<DNS name>:" name space?  Is this truly necessary?  This feels rather  convoluted and questionable... - we certainly do not need it for the NSI naming...
> It is a very simple method for guaranteeing uniqueness, without requiring the creation of a new central registry. The year is in there because it is possible that DNS names change hands. This ensures that an organisation that acquires the DNS name does not end up with a polluted namespace. DNS changeover processes for these kinds of organisations take usually many months, or years even, so we did not think it was necessary to add further timestamp information.
>
> Jeroen.
>
>