[Nsi-wg] NSI Identifier format

[Henrik Thostrup Jensen]

Hi

On Tue, 21 Jan 2014, John MacAuley wrote:

> I got nervous when hans explained the parsing from the right.  It seems we are giving up on agreement of the
> format parsing from the left, but still forcing a specific format when parsing from the right.  I
> understanding what you are trying to do, but surely we can agree on a full format that can provide a
> consistently parsable URN?

Well, your suggestion assumes that it starts with urn:ogf:network:... That 
might be okay, but it is not assumption that is required for us as such.

> If the IETF can I can only assume we are smart enough to do it as well.

Not sure what you are referring to here.

> > I don't really see a need for all the other stuff. It it just rules without a good
> > reason for it. I mean, why even bother writing all the stuff down and making
> > the standards bigger without a real need?
> 
> My issue is incompleteness of specification.  You need two URN formats specified for this to work:
> 
> 1. The Network Id must be parsed from the NML Topology Id for you to determine the available networks.

Or have another mechanism to discover the networks/topologies.

> 2. The STP Id must be parsed into the Network Id and the Local Id.

Yep.

> Why would we specify the format of only two of the identifiers in the specification when we can easily specify
> them all?

Because we only need the two. I don't see a reason to standardise 
something we don't need to standardise.

> > What we did was to restrict the <stpId> such that there cannot be any ':' characters
> > in it, and then we split from the back.
> 
> Not an unreasonable restriction, but both the networkId and localId will need to be free of colons.

Ehh... AFAICT, only the local id needs to be free of colons.

> Your name
> is also only parsable given the context of the name, where as the proposal here provide naming context in the
> name its self.

Yes, but there is no need for that. I also assume that 
people/implementations are sane enough to use the right identifiers in the 
right place. Trying to provide explicit context for all identifiers 
doesn't prevent anything anyway.

> > NORDUnet, SURFnet, and GEANT have made up their mind and gone with the
> > split from the back here. It is NOT a permanent solution. But the suggestion here
> > doesn't really feel like it either.
> 
> Understood, but I would like a solution agreed and documented for standard, unless of course we believe there
> should be nothing documented in the standard and we are free to make it deployment specific.

Yes.

> > If we do this, could we use lowercase all the way please. We are not doing Java here :-).
> 
> It is CamelCase, but comment is understood.

I think what I intended to say is that case comparison with urns is a 
mess, due to the case-insensitivity of the initialy part and potential 
case sensisitivity in the latter part. Having all lowercase is just much 
less brittle.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet