[Nsi-wg] NURN proposal

Freek Dijkstra Freek.Dijkstra at surfsara.nl
Tue Oct 21 11:50:40 EDT 2014


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 at surfsara.nl | www.surfsara.nl |

Available on Mon | Tue | Wed | Thu |


More information about the nsi-wg mailing list