On 21-10-2014 17:32, John MacAuley wrote:
In the NSI extensions to NML we are specifying a relaxation of the opaque rule of GFD.202. We are not writing a new OGF URN specification to handle this. My feeling is this is okay for our solution since we are still a valid character subset of GFD.202, we just relax the GFD.202 specific opaque rule for the local part. People reading the NSI specification will get enough information to implement the solution and create the correct URNs.
I think Hans is referring to the problem what a NSI client should do if it encounters a perfectly valid NURN, which is not a valid NSI URN. E.g. right now, SURFnet has a STP called "urn:ogf:network:surfnet.nl:1990:port:surfnet6:production:5614". This is an isAlias of "urn:ogf:network:surfsara.nl:2013:port:surfnet-lp-eyr3-lsg", which is published by SURFsara. What is the correct behaviour of the SURFnet NSA if it receives this NURN "urn:ogf:network:surfsara.nl:2013:port:surfnet-lp-eyr3-lsg"? This broken backward compatibility can either be handled by writing a new URN spec, or by clearly defining the behaviour in these cases in one of the NSI specs. Freek -- Freek Dijkstra | Group Leader & Network Expert | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 | | Freek.Dijkstra@surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Wed | Thu |