[Nsi-wg] Addressing connections across requesters

Henrik Thostrup Jensen htj at nordu.net
Thu Aug 23 04:25:01 EDT 2012


On Wed, 22 Aug 2012, John MacAuley wrote:

> LOL - I argued endlessly about this and gave up.
>
> I would rather have the provider return the new connectionId

So, 3 for solution B :-).

> So how does the UUID not work?  You just need it to. E unique within the 
> provider NSA to solve your problem do you not?

If you let the client generate the connection id, you have two choices:

1. Scope the connection id within the identity of requester nsa

This guaranties that the connection id is not taken, assuming the client 
have not specified the connection id before (something might have gone 
wrong and it tried to reserve again). This is what we have today. 
Unfortunately referencing to connections created by other NSAs are rather 
tricky / messy.

2. Let the client use its specified connections id if it is not taken 
(solution A).

In theory, UUIDs should work here assuming everything uses 
them correctly. However as we have a protocol, I just see the UUID as a 
format, and not as a way of generating non-clashing identifiers. There are 
some slighly tricky problems concerning if it is allowed to reuse 
connection ids for re-reservation with this, but nothing major.


     Best regards, Henrik

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



More information about the nsi-wg mailing list