Draft-rosen-dns-sos-02 Brian Rosen. The basic idea 123.main.pittsburgh.allegheny.pa.us.sos.arpa...

6
draft-rosen-dns-sos-02 Brian Rosen

Transcript of Draft-rosen-dns-sos-02 Brian Rosen. The basic idea 123.main.pittsburgh.allegheny.pa.us.sos.arpa...

Page 1: Draft-rosen-dns-sos-02 Brian Rosen. The basic idea 123.main.pittsburgh.allegheny.pa.us.sos.arpa contains a NAPTR, sos+psap, of something like sip:newcom@psap.state.pa.usnewcom@psap.state.pa.us.

draft-rosen-dns-sos-02

Brian Rosen

Page 2: Draft-rosen-dns-sos-02 Brian Rosen. The basic idea 123.main.pittsburgh.allegheny.pa.us.sos.arpa contains a NAPTR, sos+psap, of something like sip:newcom@psap.state.pa.usnewcom@psap.state.pa.us.

The basic idea

123.main.pittsburgh.allegheny.pa.us.sos.arpa contains a NAPTR, sos+psap, of something like sip:[email protected]

As specified, it’s a straight DDDS application All A(n) levels of PIDF-LO must be present (use

“.null” if not used in a locale) A combination rule creates the street name and

house number fields including prefixes and postfixes Regular DNS delegation rules for components

Page 3: Draft-rosen-dns-sos-02 Brian Rosen. The basic idea 123.main.pittsburgh.allegheny.pa.us.sos.arpa contains a NAPTR, sos+psap, of something like sip:newcom@psap.state.pa.usnewcom@psap.state.pa.us.

NAPTRs in the heirarchy

PSAP URI Other responder URIs Pointer to polygon list Pointer to XML list of next level down names

(facilitates validation error processing) and polygon list creation

Pointer to additional information available about this location

Page 4: Draft-rosen-dns-sos-02 Brian Rosen. The basic idea 123.main.pittsburgh.allegheny.pa.us.sos.arpa contains a NAPTR, sos+psap, of something like sip:newcom@psap.state.pa.usnewcom@psap.state.pa.us.

Start up

Delegate sos.arpa to e.g. ITU Delegate cc.sos.arpa to e.g. NENA or a govt agency

– This is sufficient for many countries where there is only one PSAP Delegate state/province.cc.sos.arpa to some state/province

agency or just list them– This is sufficient for many countries where there are a small

number of PSAPs on regional boundaries Delegate county.state.cc.sos.arpa to the appropriate agencies

– This is sufficient for many areas where PSAPs match county boundaries

Delegate city.county.state.cc.sos.arpa to the appropriate agency– This is sufficient for many areas where some cities have their own

PSAP Fill in street data from existing SAG, where SAG exists

Page 5: Draft-rosen-dns-sos-02 Brian Rosen. The basic idea 123.main.pittsburgh.allegheny.pa.us.sos.arpa contains a NAPTR, sos+psap, of something like sip:newcom@psap.state.pa.usnewcom@psap.state.pa.us.

Some problems

International names– Use IDN

Names can get long– Use consistently applied abbreviations

Isn’t XML– Yeah, but it’s simple enough

Polygon search requires more work at resolver. – Not ideal, but workable.

Page 6: Draft-rosen-dns-sos-02 Brian Rosen. The basic idea 123.main.pittsburgh.allegheny.pa.us.sos.arpa contains a NAPTR, sos+psap, of something like sip:newcom@psap.state.pa.usnewcom@psap.state.pa.us.

Why do this?

We know, with a lot of certainty, that it will work when disasters occur

We know, with a lot of certainty, what the problems (deployment, scaling, startup, security) are

– This not to say that the answers are so obvious The delegation mechanism works for the realistic

cases– Simple things (one PSAP per country) is trivial– Complex things (all of three cities, plus several streets,

minus a few houses on one street) are possible