Subject: RE: [Ecrit] Proposed requirement: split responsibility

From: "Marc Linsner" <[email-masked]>
Date: Wed, 25 May 2005 15:53:30 -0400

No

-Marc- 

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]] 
> Sent: Wednesday, May 25, 2005 1:31 PM
> To: Marc Linsner
> Subject: Re: [Ecrit] Proposed requirement: split responsibility
> 
> Did you intentionally mean to exclude the ecrit list in your reply?
> 
> -andy
> 
> 
> On May 25, 2005, at 1:16 PM, Marc Linsner wrote:
> 
> > Andy,
> >
> > In-line are 'some' comments, reserving the right to think 
> about this 
> > for more than 30 seconds and come back at a later time.
> >
> > -Marc-
> >
> >>
> >> Not that I disagree with your conclusion, but I take away 
> different 
> >> meanings from what you have quoted.  Comments in-line:
> >>
> >> On May 24, 2005, at 1:20 PM, Marc Linsner wrote:
> >>> 'The group will show how the availability of location 
> data and call 
> >>> routing information at different steps in session setup
> >> would enable
> >>> communication between a user and a relevant emergency response 
> >>> center.'
> >>
> >> Going back through what has been said in the BoF and WG 
> sessions, I 
> >> thought this was speaking to the ability of making an 
> emergency call 
> >> before location information is available.  As in, determination of 
> >> which PSAP to contact should not have to wait on the 30 seconds it 
> >> takes to get a GPS lock.
> >
> > Let's look at the basics.  Unlike the PSTN or cellular, unless you 
> > have some hint as to where to terminate the call, one cannot even 
> > start the IP call routing process (same address, many destinations) 
> > prior to knowing location.
> > It's easy with the PSTN even if the ALI record process is not 
> > complete, you simply route to the default for that particular end 
> > office.  Likewise with cellular, you route based on the tower 
> > location.  If you guessed wrong, at least the PSAP that answers can 
> > transfer the call to their neighboring PSAP.
> > So, to accomplish what you describe, you must have some 
> information in 
> > order to begin the routing process.  But then, the PSAPs have a 
> > requirement to change the routing db dynamically at their 
> descretion.  
> > If you supply an 'early hint' as to how to route the call while 
> > waiting on your gps, you would have to:
> >
> > 1) Advise the client via ?? (dhcp?) to a hint for 'early routing'
> >
> > This would kind of defeat the PSAP requirement for db 
> change as they 
> > have to deal with all the dhcp servers that pass out 
> information for 
> > their jurisdiction?
> >
> > 2) Have the VoIP SP maintain a state machine as to your 'location'?
> >
> > Kind of flies in the face of location privacy???
> >
> > Do we need yet a third mechanism for 'get ya close' routing 
> based on 
> > source IP address????
> >
> >>
> >>> 'any solution presented must be useful regardless of
> >> jurisdiction, and
> >>> it must be possible to use without a single, central authority.'
> >>
> >> All I get out of this is that the system shouldn't require a 
> >> centralized database for any jurisdiction that wishes to 
> break up the 
> >> data into multiple mapping services.
> >
> > Going back to Tom's original scope question, is the 
> discovery of the 
> > mapping server an ECRIT problem, here are my thoughts.  
> ECRIT is going 
> > to describe how to use already defined mechanisms, or 
> create new ones, 
> > to solve the problem of emergency context routing.  If all we 
> > accomplish in ECRIT is to pick apart the problem and throw 
> things over 
> > the wall to other wgs, we haven't met our goal of providing a 
> > solution.  Even if locating a mapping service is a simply 
> as: take the 
> > country code you got via dhcp and stuff in a dns query 
> > www.us.sos.arpa, so be it.  But to state that xyz wg is 
> going to solve 
> > that, I don't believe is what the ADs had in mind when they 
> approved 
> > the charter.  Hence, finding the mapping service in order 
> to complete 
> > the emergency context routing process in within scope imo.  
> Hey, this 
> > may be a good use for DDDS......
> >
> > Afterall, I'm a little surprise the geopriv chair(s) took 
> all the crap 
> > ecrit threw at them.......you're just too easy!
> >
> >>
> >>> Matching location data with routing data without a central
> >> authority,
> >>> imo, implies our requirement to explain/define the process of 
> >>> discovery of the appropriate mapping server.
> >>
> >> Again, I'm not disagreeing with your conclusion (just a little 
> >> puzzled about how you arrived at it).  But this does bring up a 
> >> process
> >> question: does putting discovery in scope mean that we are 
> to write 
> >> requirements regarding the discovery mechanism in other protocols, 
> >> write requirements regarding the interaction between the discovery 
> >> mechanism and the mapping service, and/or simply write about the 
> >> discovery mechanism in the OBTW document (we really need a 
> name for 
> >> that)?  I see the last two items as being unproblematic from the 
> >> "plays well with others" standpoint.  However, the first 
> item touches 
> >> back on the issue of ECRIT going around and telling others 
> what to do 
> >> based on our requirements (which in some areas is about as 
> welcome as 
> >> a poke in the eye).
> >
> > I agree.  Given multiple choices with equal functionality, ECRIT 
> > should choose the path of least resistance.  If discovery 
> of location 
> > mapping service can use an already proven mechanism vs. 
> asking dns for 
> > a rearchitecture (as an example, not a proposed solution!), use the 
> > existing one.  If ECRIT finds that it can't meet the 
> requirements at 
> > all levels without rework, we'll start buying beers for other wg 
> > chairs and ADs.
> >
> > We may not be able to accomplish our task without involving 
> > others......
> >
> >>
> >> In the spirit of writing requirements regarding the interaction 
> >> between the discovery mechanism and the mapping service (number 2 
> >> from above), I propose the following: The mechanism for 
> discovery of 
> >> a mapping service MUST NOT impose upon the query interface of the 
> >> mapping service, and the two SHOULD be separable.
> >
> > I like that!
> >
> >>
> >> On May 25, 2005, at 8:38 AM, Henning Schulzrinne wrote:
> >>
> >>> I'm certainly not suggesting that there is a single hierarchy of 
> >>> PIDF-LO elements or that all levels of that hierarchy are
> >> populated in
> >>> all cases. I am suggesting that there is a general 
> hierarchy, with 
> >>> different tree depths in different countries, but that this
> >> is not a
> >>> simple hierarchy with a fixed referral mechanism.
> >>
> >> Perhaps I'm missing the point, but such genericism seems 
> to obviate 
> >> the imposition of this hierarchy.
> >>
> >>>  As Brian indicated, in some civic address cases, the next
> >> resolution
> >>> step may under some circumstances not be determinable by simply 
> >>> looking at the address. Again, let me repeat my example:
> >> Imagine the
> >>> city of Smalltown, NJ that is divided by a river, where
> >> parts of the
> >>> city are covered by mapping server A and other parts by
> >> mapping server
> >>> B. (Mapping server A and B may each contain references to
> >> any number
> >>> of ESZs or PSAPs.)
> >>>
> >>> For example, streets east of the river are covered by
> >> mapping server
> >>> A, streets west by mapping server B, but the precise
> >> division makes no
> >>> difference.
> >>>
> >>> Smalltown, NJ is part of Jefferson County. Jefferson County
> >> maintains
> >>> a mapping server that has an entry for Smalltown, NJ, but
> >> it needs to
> >>> send a query to either server A or server B (or both),
> >> since it does
> >>> not keep track of whether Oak Avenue is east or west of the
> >> river (or
> >>> whether Oak Avenue exists at all). The county mapping 
> server could 
> >>> provide two mapping server URLs to the querier, but that's
> >> just one of
> >>> several possible solutions. The protocol machinery has to
> >> support this
> >>> case unless we explicitly rule it out.
> >>
> >> If I'm reading this right, you are suggesting the 
> following scenario 
> >> may be necessary:
> >>    a) client queries mapping server A
> >>    b) mapping server A says "I don't know, go query both 
> server B and 
> >> server C because one of them MAY have the answer"
> >>    c) client queries both mapping server B and mapping server C
> >>
> >> If so, that's interesting.  I wouldn't say this needs to be ruled 
> >> out, but it certainly sounds less than ideal.
> >>
> >>> The equivalent problem is not likely to exist in geo
> >> coordinates. For
> >>> the geo mapping, the county server would simply have two
> >> polygons, one
> >>> covering the service area east of the river, the other the
> >> one west of
> >>> the river. As long as the river stays in place, this is 
> unlikely to 
> >>> change. In any event, once you support this functionality
> >> for civic,
> >>> the same mechanism is likely to work for geo coordinates.
> >>
> >> And I'm still asking myself why you need to care about imposing a 
> >> hierarchy to do this.  What in the referral mechanism is 
> dependent on 
> >> that?
> >>
> >> Perhaps the requirement would better be changed to: The mapping 
> >> protocol MUST NOT inhibit the ability of a mapping provider to 
> >> distribute mapping service across multiple, distinctly 
> named mapping 
> >> servers.
> >>
> >> -andy

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Andrew Newton <[email-masked]>
Date: Wed, 25 May 2005 17:53:09 -0400

Marc, comments in-line:

>>> transfer the call to their neighboring PSAP.

This assumption has vexed me from the start.  There seems to be a 
notion that IP networks are made up entirely of intangible elements.  
Is this true?  Are there no relationships between IP routes and copper 
or fiber?

>>> have to deal with all the dhcp servers that pass out

When you say 'dynamic' here, what is the frequency?  By the minute or 
by the month?

>>> may be a good use for DDDS......

Actually, the qualities you are seeking are for a federated DNS 
namespace... which require DNS registries... who are acting as central 
authorities... of which can be argued as being explicitly out of scope 
by the ECRIT charter text.  But we're not talking about solution space 
yet, are we?

>>> If ECRIT finds that it can't meet the
>> requirements at

Meet you in the bar!

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 25 May 2005 18:29:00 -0400

> This assumption has vexed me from the start.  There seems to 
> be a notion that IP networks are made up entirely of 
> intangible elements.  
> Is this true?  Are there no relationships between IP routes 
> and copper or fiber?

This is the assumption.  With VPNs, there is no relationship between
physical and IP location.

> When you say 'dynamic' here, what is the frequency?  By the 
> minute or by the month?

The common scenario is the responder that normal utilizes a bridge to reach
it's jurisdiction wants calls to route differently if the bridge were to
fail.  How often does this happen?  No very often, but it's not predicable
and needs to work on very short notice.

> Actually, the qualities you are seeking are for a federated 
> DNS namespace... which require DNS registries... who are 
> acting as central authorities... of which can be argued as 
> being explicitly out of scope by the ECRIT charter text.  But 
> we're not talking about solution space yet, are we?

I only mentioned DDDS as it's already been discussed.  I've not proposed any
solution.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 May 2005 20:06:28 -0400

> physical and IP location.

Also, while in non-VPN cases, there may be some connection to location, 
often, a whole enterprise has the same IP address range. As a local 
example, the Columbia conference/retreat center, Arden House, shares the 
same IP address range as the main campus in Manhattan, which happens to 
be about 54 miles south and in a different county.

Some geo-mapping software puts me in Jersey City, which is probably 
about 20 miles away.

Some cable systems probably span a county, while each town in New Jersey 
has its own PSAP (in addition to its own foreign policy and customs 
offices).