Subject: RE: New I-D on using DNS to support Emergency Calls

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 19 Feb 2004 14:12:27 -0500

Sorry, I did not understand your goal well enough.

Then again, I don't think you can meet your goal with the DNS.
The computer which you are sending or receiving email or entering 
credit card information probably does not have an externally available 
DNS entry, and the "nearest" (in the Internet sense) one that does 
is not very close to you (in the postal address sense) in almost 
every case.  

Brian

> -----Original Message-----
> From: Al Costanzo [mailto:[email-masked]]
> Sent: Thursday, February 19, 2004 1:53 PM
> To: Rosen, Brian; [email-masked]
> Subject: Re: New I-D on using DNS to support Emergency Calls
> 
> 
> Brian,
> 
> Hmmm... In the case of 911 records my draft  may not help 
> then (if you feel
> you must put in your postal address and not the desired 911 location).
> 
> But this draft helps the other two points that it actually 
> was written for.
> To keep track of the physical address of the location of the 
> machine that
> the A record is associated with.
> 
> Or the location that the ISP would like to have it on record.
> 
> The dradt was written to help prevent credit card fraud by 
> having a fall
> back for non-mobile computers to help verify the address entered.
> 
> Please note that the draft I submitted support precision so 
> for example you
> could just enter the country or country & state, etc, for a 
> less precise
> location for Privacy concern.
> 
> Because this draft was written to help prevent SPAM as well 
> as help with
> credit card processing, it may be that it cannot help you 
> with your need.
> 
> Unfortuantely, Lat & Log co-ordinates do not help me with the 
> needs I am
> trying to address.
> 
> Best Regards,
> 
> Al
> ----- Original Message ----- 
> From: "Rosen, Brian" <[email-masked]>
> To: "'Al Costanzo'" <[email-masked]>; <[email-masked]>
> Sent: Thursday, February 19, 2004 1:43 PM
> Subject: RE: New I-D on using DNS to support Emergency Calls
> 
> 
> > Al
> >
> > A Zip+4 can cross a township boundary (mine does).  It can 
> cross an ERC
> > response boundary (also true here), and it can cross a 
> state boundary
> (rare,
> > but true).  Postal codes are for the post office, and they 
> don't reflect
> > anything other than convenience for the Post Office sorting 
> and delivery
> > people.  In many countries, they don't even have postal 
> codes.  As such,
> > I don't think they help anything but delivering snail mail.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Al Costanzo [mailto:[email-masked]]
> > > Sent: Thursday, February 19, 2004 1:37 PM
> > > To: Rosen, Brian; [email-masked]
> > > Subject: Re: New I-D on using DNS to support Emergency Calls
> > >
> > >
> > > Hi Brian,
> > >
> > > A complete Zip+4 points to your exact location.  There is 
> no rule what
> > > address you use in the field, and there is a cmment area as well.
> > >
> > > My opinion is ased on the fact that hardly anyone uses the
> > > LOC RR and I
> > > think it is because it requires a Log & Lad indication as 
> points of
> > > references.
> > >
> > > IMHO postal addresses solve this, but its only my opinion.
> > >
> > > Al
> > > ----- Original Message ----- 
> > > From: "Rosen, Brian" <[email-masked]>
> > > To: "'Al Costanzo'" <[email-masked]>; <[email-masked]>
> > > Sent: Thursday, February 19, 2004 1:24 PM
> > > Subject: RE: New I-D on using DNS to support Emergency Calls
> > >
> > >
> > > > As a practical matter, you rarely type your location 
> into a form to
> > > > determine
> > > > where you are.  Rather, various service providers, 
> enterprises and
> > > automated
> > > > mechanisms determine your location from a variety of
> > > information sources.
> > > > Therefore, the idea that the form of the entry has to
> > > exactly match a
> > > postal
> > > > address is not true.  Further, for emergency response, your
> > > postal address
> > > > is
> > > > often not your response address, for example when the post
> > > office that
> > > > serves
> > > > you is not the municipality where you are located.  In my
> > > own case, I live
> > > > in
> > > > Pine Township, Allegheny County, but my postal address is
> > > Mars, PA 16046.
> > > > Mars is a nearby town, in Butler County.  For emergency
> > > dispatch, it is
> > > > essential that the ERC serving Pine Township get the call,
> > > and that for
> > > > dispatch, that the address is a Pine township address 
> and not a Mars
> > > > address.
> > > >
> > > > Also, the delegation properties of the DNS exactly match
> > > what is required
> > > to
> > > > provide location to the precision of a room. Using the
> > > naming hierarchy to
> > > > permit delegation of an address to a building owner, and
> > > thence to a suite
> > > > owner, who enters room level data in his entry is
> > > particularly useful.
> > > >
> > > > And, the postal zone boundary does not align with the ERC
> > > boundaries, and
> > > > does not align with municipal boundaries, which further 
> complicates
> > > > populating the database.
> > > >
> > > > For these reasons, I believe my suggestion is a better one.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Al Costanzo [mailto:[email-masked]]
> > > > > Sent: Thursday, February 19, 2004 12:21 PM
> > > > > To: Rosen, Brian; [email-masked]
> > > > > Subject: Re: New I-D on using DNS to support Emergency Calls
> > > > >
> > > > >
> > > > > Dear Brian & everyone on the namedroppers list,
> > > > >
> > > > > When I tell you I total agree that this information needs to
> > > > > be in the DNS
> > > > > for a number or reasons:
> > > > >
> > > > > 1.911 as you mentioned
> > > > > 2.Credit Card Verification Processing
> > > > > 3.New Anti-Spam Legislation
> > > > >
> > > > > To add just two more.
> > > > >
> > > > > After reading your draft, I disagree on how the
> > > information is to be
> > > > > inserted into the RR.
> > > > >
> > > > > The address needs to be listed in the RR as it was a postal
> > > > > address. The
> > > > > reason for this is ease of use. Everyone know their own
> > > > > address but not mank
> > > > > know thier geographic location.
> > > > >
> > > > > I welcome you and everone to help me come up with a solution
> > > > > in this matter.
> > > > > A document I just revised is attached to this email. Not sure
> > > > > if the list
> > > > > server allows such things.
> > > > >
> > > > > I am not a proud or I need it done my way or I want the glory
> > > > > for the RFC
> > > > > kinda guy.
> > > > >
> > > > > I see a problem that needs to be addressed, I think the
> > > > > solution I presented
> > > > > is the best solution, but if anyone thinks this idea can be
> > > > > tweaked or you
> > > > > want to co-author the work and work on this solution with me,
> > > > > please feel
> > > > > free to let me know. I however do not want the RR to use Log
> > > > > and Lat as
> > > > > reference points.
> > > > >
> > > > > The draft has been submitted as: draft-costanzo-dns-gl-06.txt
> > > > >  but I am sure
> > > > > it is not listed in the I-D directory yet.
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message ----- 
> > > > > From: "Rosen, Brian" <[email-masked]>
> > > > > To: <[email-masked]>
> > > > > Sent: Thursday, February 19, 2004 10:55 AM
> > > > > Subject: New I-D on using DNS to support Emergency Calls
> > > > >
> > > > >
> > > > > > Please have a look at
> > > > > > 
> http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt
> > > > > >
> > > > > > Yeah, I know.  Flame away.  I think it's a pretty good idea
> > > > > anyway :)
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > --
> > > > > > to unsubscribe send a message to
> > > > > [email-masked] with
> > > > > > the word 'unsubscribe' in a single line as the message
> > > text body.
> > > > > > archive: <http://ops.ietf.org/lists/namedroppers/>
> > > > > >
> > > > >
> > > >
> > > > --
> > > > to unsubscribe send a message to
> > > [email-masked] with
> > > > the word 'unsubscribe' in a single line as the message 
> text body.
> > > > archive: <http://ops.ietf.org/lists/namedroppers/>
> > > >
> > >
> >
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 19 Feb 2004 15:22:02 -0500

Thank you for your direct response to the issues raised by the draft
 
> - It mixes the information you need to find the number to the correct 
> ERC with information you need to send to the ERC. In Sweden for 
> example, the resolution is on city boundary basis, but even 
> if you pass 
> the call to one such ERC, the destination E.164 you use is in reality 
> only a hint to the "virtual ERC" which is covering Sweden where the 
> call is coming from. So, it seems in the US (and this draft) 
> you try to 
> solve a problem which for example we in Sweden have solved by forcing 
> the ERC's in the country to solve the problem among themselves?
You don't know that VoIP routing will be done the same way, but suppose
that it is.  The proposal allows the ERC entry to be in se.sos.arpa.
It could also be more complex.  For example, Stockholm could have
calls come directly to it (stockholm.se.sos.arpa, I don't know if you
have a "county" equivalent), with the rest of the country sending calls
to the ERC NAPTR at se.sos.arpa.

You still need to be able to dispatch to a room based on a lat/lon, 
where the lat/lon is known, and you need to be able to have a 
"standardized" naming convention for a civil address when that
is known, which is what the proposal provides.

> 
> - What information is passed to the ERC is, I claim, by far more 
> important than finding the right ERC. Yes, YMMV (see above).
Yes, my mileage varies quite a bit; finding the right ERC is the
first step, and has to be done well.  If I am in Stockholm,
but connecting to Marconi's VoIP system through a VPN tunnel,
then I really want the call to go to Stockholm's ERC and not
Pittsburgh's ERC.

> 
> - Doing a width-first *search* in DNS is to be honest a plain 
> bad idea. 
> The operation doesn't exist (part from zone transfers of 
> course), and I 
> would suggest going to a specific protocol which can do this.
Yes, I clearly understand the weakness here.  The text does
discuss this.  You need both mappings.  Either you use the zone
transfer idea, caching the result, or we really create both mappings
in the DNS.

Henning Schultzrinne has made a suggestion that we use a PTR
RR for each leaf below any point in the tree.  It makes the entries
bigger, but fixes the problem.

> 
> - When you define a new RR type for this, why not "just" tag 
> the URI to 
> the data just like the corners of the polygon which is defining the 
> area?
This is possible.  The weakness is that you can't depend on the URI
to be available when you make the call.  This forces every proxy that
routes emergency calls to off-line create a complete database by
visiting the requisite URIs.  The proposal envisions that you cache
the entries you need most of the time, but are able to use the DNS
for "odd" calls, like the roaming VPN user.

> 
> - The overall problem for ERC dispatch services is as far as I know 
> that the person/tool/whatever which issue the call don't know 
> where he 
> is. So, the "network" have to tell the ERC where the call is coming 
> from, and _that_ is the real problem to solve. If you know this, I am 
> sure the ERC can use whatever database needed to map to whatever 
> coordinates they use this tuesday.
Yes, we are working hard on the problem of determining your location,
and there are a number of drafts in progress on this subject in progress.
All of the drafts end up with ONE of civil or geo.  They don't end up
with the URI of the ERC serving the location, and as my draft points out,
you often need both forms.  Therefore, yes, we need to solve the
"where am I" problem, but we also need to solve the "what is the URI
of the ERC serving my location" and also the conversion between geo and
civil.  We also need a standardized enumeration of legal civils (the
Master Street Address Guide").  The proposal solves all three of these
problems.

> 
> - The database normally used for ERC coordination is extremely 
> sensitive information, at least in Sweden. It can for example map the 
> coordinate of E.164 numbers to geographical location, 
> _including_ E.164 
> which are protected, used by people with protected (changed) identity 
> etc. If this data get out on the street.... The database 
> access must be 
> extremely protected and only possible to access by very 
> special access 
> codes etc. Security implications are enormous. Yes, in Sweden a telco 
> is required over the SS7 network to _always_ pass the caller 
> id of the 
> calling party to the ERC's. That's a very special function in Sweden 
> and overrides whatever other rules there might be (like *NEVER*EVER* 
> passing the caller ID of people with protected identities to third 
> parties).
Yes, location information is sensitive.  Address information is not;
it is public information.  You cannot have an unlisted house.
The proposal does not make any connection between an E.164 and a
location, nor does it associate a name, or any other personal information
with a location.  

As the draft discusses, there is a concern over interior building
information, which is often not public, and proposes a solution for that.

> 
> Etc etc...
> 
> So, there is a lot of work to do in the area of 911/112 calls, and I 
> think very very few (if any) have to do with DNS.
Well, there is definitely a lot of work.  And there is already a lot
of effort.  However, it does no good to solve most of the problem,
one has to solve all of it, and these three problems do not currently
have any standardized solution.