Subject: FW: [Ecrit] Architecture comparisons

From: "Marc Linsner" <[email-masked]>
Date: Tue, 19 Jun 2007 11:10:30 -0400

Richard,

More questions/comments in-line.... 

> 
> You're correct that a general LoST lookup (with no assumptions about 
> the locality of the seeker) does rely on the network of FGs and tree 
> nodes to guide the query to the LoST server that's authoritative for 
> the seeker's location.
> 
> The assumption that's being made here is that since the access network 
> is a geographically local entity, it can just remember which LoST 
> servers are authoritative for its coverage area, so that its queries 
> don't have to start at the top of the mapping heirarchy.  It can just 
> take queries from seekers connected to its network (since this 
> connectivity implies that they're in the coverage area) and send them 
> directly to the local LoST server.

Without a FG, how is the authoritative LoST server found initially?

I would think we (ecrit) would want to discourage 'remembering' the
authoritative server for the same reasons one should not 'remember' DNS
mappings.

> 
> A VSP-operated resolver, on the other hand, would potentially have to 
> handle queries from subscribers all over the world.
> In other words, it would have to handle general LoST lookups, with no 
> assumptions about the locality of the seeker.  Thus, in general, VSPs 
> will have to rely on the mapping infrastructure to find the 
> appropriate LoST server to answer a given query from one of its 
> subscribers.  This can be optimized by caching (e.g., if most 
> subscribers are in one area), but in general, a VSP needs to do the 
> full LoST song and dance.
> 
> IOW: Geographic locality of an entity allows caching of authoritative 
> LoST servers.  Access networks (and their
> subscribers) are necessarily localized to a coverage area; VSPs 
> aren't, in general.

I'm still missing the tie between the access provider and the authoritative
LoST server.

-Marc-

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 19 Jun 2007 10:32:50 -0500

Hi Marc,

Regarding you last comment:

" I'm still missing the tie between the access provider and the
authoritative LoST server."

It's what Brian said - the ISP is "local" to the caller. Just as a
cellular network provider currently "knows" which PSAPs are pertinent to
their area of coverage (have to in order to provide the dedicated trunks
to the 911 tandem switches) so too can any Internet access network
provider offering service in a particular geographic region.

Just as they know the PSAP operators, they can know the identity of the
pertinent LoST server.

They are definitely in a qualitatively different situation compared to
the VSPs by virtue of the physics of providing network coverage and the
local knowledge that goes along with that.

e.g. I can certainly use a VoIP provider that has no business status in
Australia; I haven't found a way to do that with a DSL provider yet...

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 20 June 2007 1:11 AM
To: 'ECRIT'
Subject: FW: [Ecrit] Architecture comparisons

Richard,

> subscribers) are necessarily localized to a coverage area; VSPs 

I'm still missing the tie between the access provider and the
authoritative
LoST server.

-Marc-

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Richard Barnes <[email-masked]>
Date: Tue, 19 Jun 2007 12:14:00 -0400

> ~snip~

As Martin notes, it can be done by local configuration, just as networks 
today know about their local PSAPs.  This is, of course, not the optimal 
  case, but it works as a stop-gap until FGs are deployed.

The tie between the access provider and the authoritative LoST server is 
the same as the tie between the access provider and the selective router 
it uses to get to its PSAPs -- they're both concerned with the same 
geographical area.  So, as an optimization, an access provider might 
hard-wire LoST queries straight to the appropriate authoritative server, 
rather than going all the way from FGs down the tree.  I think you're 
right, though, that this kind of "caching" is a bad idea, since there's 
no standard way to know when the set of authoritative servers changes.

> authoritative server for the same reasons one should not 'remember' DNS

You're correct that it's not good to remember authoritative servers 
because there's no standard refresh mechanism.  However, it makes a lot 
of sense to cache mappings (as the DNS does).  A likely scenario is that 
an access network will have a local resolver that caches LoST mappings 
to cover its coverage area.  (It can either cache as subscriber requests 
come through or scan the area itself to gather them.)  This is OK: The 
mappings have marked expirations so that the resolver knows when to 
throw them out.

So, just like the DNS caches name-address mappings at various points, 
there will probably be caching in the mapping infrastructure -- it just 
makes sense, given the expected lifetime of mappings.  The mapping 
architecture allows for this; the expiry fields in LoST tell the server 
when to refresh.

--Richard

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 19 Jun 2007 11:25:59 -0500

I don't even know that this simile is very compelling...

LoST is a service, the URI for the service can be looked up in DNS and
those entries will be managed by whoever manages that LoST service. I
don't think I'm really caching the important information in this
scenario. If a FG comes into play at the local level then I still have
to have an FG URI; should I be concerned about the fact that I've
hardwired that?

Think about it; in the commonest type of national jurisdiction there'll
probably be one PSAP URI (which will be in DNS including redundant
destinations) and that jurisdiction is likely to have one LoST server to
serve up that one PSAP URI. So we have a system of using a known (?)
local FG to lookup up a local LoST server to look up the one local PSAP
URI. Isn't there a good deal of overkill viz levels of indirection going
on here?

Cheers,
Martin

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, 20 June 2007 2:14 AM
To: Marc Linsner
Cc: 'ECRIT'
Subject: Re: FW: [Ecrit] Architecture comparisons

authoritative

--Richard

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 19 Jun 2007 11:25:59 -0500

Cheers,
Martin

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, 20 June 2007 2:14 AM
To: Marc Linsner
Cc: 'ECRIT'
Subject: Re: FW: [Ecrit] Architecture comparisons

authoritative

--Richard

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 19 Jun 2007 12:26:06 -0400

Martin,
 
> " I'm still missing the tie between the access provider and 
> the authoritative LoST server."
> 
> It's what Brian said - the ISP is "local" to the caller. Just 
> as a cellular network provider currently "knows" which PSAPs 
> are pertinent to their area of coverage (have to in order to 
> provide the dedicated trunks to the 911 tandem switches) so 
> too can any Internet access network provider offering service 
> in a particular geographic region.
> 

I disagree that we can/should assume that ISPs are "local" to the caller.
Yes, some are, but some are not.  Many hot-spot/hotel networks are
aggregated/managed from afar with no local knowledge.  Should we propose
these ISPs change their business model in order to support LoST queries (due
to lack of a FG)?  The IETF LoST architecture includes support for "all"
access network providers and VSPs and should continue to do so.  The FG is a
key component to that architecture.

We have acknowledged that we will work on variations to the architecture to
support access providers that want/need to 'hide location' from the
end-host/VSP.  But I don't think we should sacrifice supporting
current/selective Internet provider architectures in doing so.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 19 Jun 2007 11:35:27 -0500

Tsk... we've discussed on numerous occasions that the access provider is
an amalgamation of the ISP and any intervening infrastructure provider.
The necessary assets for both location determination and corresponding
local knowledge exist within that mix.

I haven't heard of anyone delivering mass market Internet access via
subspace Ethernet yet, so there is always a physical presence associated
with the provision of the access.

You can go ahead and talk about satellite Internet access providers if
you like. I'll grant you the corner case - they'll probably need a FG...

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 20 June 2007 2:26 AM
To: Dawson, Martin; 'ECRIT'
Subject: RE: [Ecrit] Architecture comparisons

Martin,
 
> in a particular geographic region.

I disagree that we can/should assume that ISPs are "local" to the
caller.
Yes, some are, but some are not.  Many hot-spot/hotel networks are
aggregated/managed from afar with no local knowledge.  Should we propose
these ISPs change their business model in order to support LoST queries
(due
to lack of a FG)?  The IETF LoST architecture includes support for "all"
access network providers and VSPs and should continue to do so.  The FG
is a
key component to that architecture.

We have acknowledged that we will work on variations to the architecture
to
support access providers that want/need to 'hide location' from the
end-host/VSP.  But I don't think we should sacrifice supporting
current/selective Internet provider architectures in doing so.

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 19 Jun 2007 13:08:23 -0400

Richard, 

> 
> The tie between the access provider and the authoritative 
> LoST server is the same as the tie between the access 
> provider and the selective router it uses to get to its PSAPs 
> -- they're both concerned with the same geographical area.

And for non-telephony-offering access providers what is the tie?

My point is that for as many access providers that offer LoST services,
there will be just as many if not more that won't.  Furthermore, if the
access provider doesn't provide a LoST service because they don't care about
any telephony-like service (nor 'location-hiding' since that is what drove
this discussion), this leaves the end-host/VSP required to perform LoST
queries.  IMO, we, the IETF, cannot advocate an architecture that 'requires'
access providers to perform/provide LoST services, hence the need for a FG
such to support end-hosts/VSPs.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 19 Jun 2007 12:17:00 -0500

So who are we going to force to provide the FG?

In the mean time, since LoST already includes local discovery mechanisms
via DNS, how much has actually been forced on the ISP? All we've said is
that the LIS operator can discover and query the LoST server. Some
people have suggested that one possible implementation model is that
ISPs actually implement the LoST infrastructure - but I don't think
that's been stated as an imperative.

Answer the first question and I might agree that taking care of as much
as possible at the local level isn't necessarily the only safe starting
point.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 20 June 2007 3:08 AM
To: 'Richard Barnes'
Cc: 'ECRIT'
Subject: RE: FW: [Ecrit] Architecture comparisons

Richard, 

My point is that for as many access providers that offer LoST services,
there will be just as many if not more that won't.  Furthermore, if the
access provider doesn't provide a LoST service because they don't care
about
any telephony-like service (nor 'location-hiding' since that is what
drove
this discussion), this leaves the end-host/VSP required to perform LoST
queries.  IMO, we, the IETF, cannot advocate an architecture that
'requires'
access providers to perform/provide LoST services, hence the need for a
FG
such to support end-hosts/VSPs.

-Marc-

---

From: Richard Barnes <[email-masked]>
Date: Tue, 19 Jun 2007 14:04:49 -0400

Marc,

We're in violent agreement.  I was just suggesting that such 
caching/hard-wiring might reasonably be done as an optimization, or as a 
stop-gap until FGs are deployed.  I certainly agree that the approach of 
mapping-arch is the correct one.

(Incidentally, this doesn't have much to do with whether the access 
provider "offers telephony" -- any IP network offers it de facto as long 
as they allow SIP and RTP.  Ultimately, I expect that there will be 
regulation as to who exactly has to care about emergency services, 
including who has to run LoST services.)

--RB

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 19 Jun 2007 14:38:20 -0400

Martin,

> So who are we going to force to provide the FG?

The FG is a process of the LoST service which will be under the jurisdiction
of the PSAP/gov't or it's assignee.

> 
> In the mean time, since LoST already includes local discovery 
> mechanisms via DNS, 

FG and DNS LoST server discovery are orthogonal!

how much has actually been forced on the 
> ISP? All we've said is that the LIS operator can discover and 
> query the LoST server. Some people have suggested that one 
> possible implementation model is that ISPs actually implement 
> the LoST infrastructure - but I don't think that's been 
> stated as an imperative.

But you are attempting to discourage the FG, which is imperative if the ISP
doesn't want to participate in anything 'LoST'!

I don't have a problem if an ISP wants to: operate a LoST server and/or
query LoST OBO their subscribers.  What I have a problem with is
advocating/building an architecture that forces such.

I would expect most VSPs to either operate, or have a relationship with a
LoST resolver.

BTW, I sense a misunderstanding.  UAs and/or VSP proxies don't/won't know
about FGs, only LoST servers do.  From a UA/Proxy view, the goal is for
*any* LoST server to resolve location to uri for everywhere.  There is
nothing in the architecture that I'm aware of that suggests a UA/Proxy go
'LoST server shopping'.  So, if my ISP (Joe's U-Haul and Pool Parlor) offers
a LoST service and my UA queries that server for a mapping from afar, it
will be expected the Joe's LoST server is fully engaged in the FG such that
my UA will receive correct data.
 
-Marc- 

> 
> Answer the first question and I might agree that taking care 
> of as much as possible at the local level isn't necessarily 
> the only safe starting point.
> 
> Cheers,
> Martin
> 
> LoST server 
> > is the same as the tie between the access provider and the 
> selective 
> > router it uses to get to its PSAPs
> My point is that for as many access providers that offer LoST 
> services, there will be just as many if not more that won't.  
> Furthermore, if the access provider doesn't provide a LoST 
> service because they don't care about any telephony-like 
> service (nor 'location-hiding' since that is what drove this 
> discussion), this leaves the end-host/VSP required to perform 
> LoST queries.  IMO, we, the IETF, cannot advocate an 
> architecture that 'requires'
> access providers to perform/provide LoST services, hence the 
> need for a FG such to support end-hosts/VSPs.
> 
> -Marc- 
> 
>  
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 19 Jun 2007 14:56:55 -0400

On Jun 19, 2007, at 1:17 PM, Dawson, Martin wrote:

> mechanisms
> via DNS, how much has actually been forced on the ISP?

It does?  Where did you find that?  I know there is a proposed DHCP  
discovery mechanism, but nothing along the lines as is found with the  
document that James/Martin wrote for LIS discovery.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 19 Jun 2007 18:38:41 -0500

Hi Andy,

The current LoST draft specifically puts finding the hostname of the
LoST server out of scope. Which means that the end-point has to know
this, including the domain before performing the U-NAPTR lookup to
obtain the full URI.

Yes, there are a number of ways that the End-Point can learn the
hostname of the LoST server. Realistically in many broadband deployments
this number is significantly restricted as DHCP, the only currently
defined way to learn the identity of the lost server, is not available.
This really only leaves hard-coding or DNS.

One basic DNS mechanism is defined in the LIS discovery draft you
mention below. 

To work in general though the End-Point needs to identify a domain of
some description or it won't work. If the End-Point uses the domain
configured into their device then they will discover the LoST server
associated with their home domain. If they are roaming, then there needs
to be a set of forest guides that can link their home LoST server to the
LoST server for the User's current area or they really are LoST.

Alternatively the End-Point can learn the identity of the domain
currently providing it access, and ask the DNS server for the local LoST
server.

I am sure that there are other methods too. The point I think Martin was
trying to make was that if option 3 is used, then the ISP don't have to
have LoST records in its DNS, and connecting forest guides don't have to
be in place for the service to work. I agree that ultimately we want
them there, but it is a fact of life that they won't be to start with,
and having an orderly alternative is better than a bunch of adhoc
solutions.

Cheers
James

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Wednesday, 20 June 2007 4:57 AM
> To: Dawson, Martin
> Cc: ECRIT
> Subject: Re: [Ecrit] Architecture comparisons
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 19 Jun 2007 20:22:05 -0400

> and having an orderly alternative is better than a bunch of adhoc

If an ISP thinks it is an onerous task to put some DNS records in  
their name servers that point to a LoST regional resolver, then they  
need not be in the ISP business.  I've been to enough NANOG and RIPE  
meetings to tell you that most ISPs in the modern world would find  
this to be a trivial task.  And doing DNS discovery for networks that  
don't use DHCP is a far shorter path than trying to half-heartedly  
tunnel LoST through an LCP.

LoST discovery is work that this group needs to conduct.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 19 Jun 2007 20:21:09 -0500

Hi Andy,

I would just like to point out that the description that I provided is
in addition to the ISP having to boundary map intersections for LoST
service boundaries on a per subscriber basis. I think that if you couple
those two efforts then providing enabled service URNs and URIs through
an LCP is much less work and provides a far higher degree of control
with regards to what location can and cannot be used for.

Cheers
James

> Sent: Wednesday, 20 June 2007 10:22 AM
> To: Winterbottom, James
> Cc: Dawson, Martin; ECRIT

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Jun 2007 21:21:51 -0400

Agree with everything in this post
> LoST discovery is work that this group needs to conduct.
Okay so:
The ISP supplies a DHCP entry and/or a DNS entry for the domain
The VSP could do it with config

It would be very nice to have some more universal mechanism.  
I have an idea, but I'd better run it by some experts before I get seriously
singed.

Brian

> Sent: Tuesday, June 19, 2007 8:22 PM
> To: Winterbottom, James

---

From: Andrew Newton <[email-masked]>
Date: Wed, 20 Jun 2007 08:40:23 -0400

> The ISP supplies a DHCP entry and/or a DNS entry for the domain

There's also rev. DNS and mDNS.

> The VSP could do it with config

And I don't think this needs to be specified any further.  The config  
mechanisms for ATAs and soft clients are various and many.

> I have an idea, but I'd better run it by some experts before I get  

I agree, a more universal mechanism is better.  It's annoying to re- 
invent this type of thing for every application.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Jun 2007 11:06:02 -0400

Well, my suggestion may not solve the general case.

Put an SRV for LoST in the root of the ccTLD (e.g. in .us)
For most countries, that's pretty much exactly what you want.  

For places like the U.S., configuration of the domain may be complex to
spread the load on multiple servers that may or may not be operated by the
same entity, but we can do that.  Of course we could also put one in .pa.us
for example.  It's pretty straightforward to get a country code, and even if
you are off, the FG thing ought to work.

I'd make a priority order of first ISP, then VSP then ccTLD.

Reverse DNS may be needed to get the domain of the ISP.  Was that what you
were thinking?

mDNS clearly should be an alternative.

Brian

> Sent: Wednesday, June 20, 2007 8:40 AM
> To: Brian Rosen
> Cc: 'Winterbottom, James'; 'Dawson, Martin'; 'ECRIT'

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Jun 2007 13:03:55 -0400

Brian:

Practically speaking, inserting things directly under .ccltd is  
probably difficult. I'm also not convinced that this is a problem we  
need to solve immediately, given that most systems will get  
configuration information from their VSP.

For the VSP model, we have two choices:

- leverage SIP configuration, now in SIPPING WG LC; it picks the SIP  
subscription address based on the AOR

- creating a look-up from the host part of the AOR, via NAPTR; this  
is essentially already in the draft. We only need to add one  
sentence: "A SIP user agent uses the host part of its SIP AOR." Done.

For the non-VSP model, there is the danger of re-creating the global  
ENUM problem, i.e., agreeing on a common root. I happen to think that  
the model used for finding DNS root servers, namely anycast, would be  
a better one. It provides a low-level redundancy that is highly  
robust and avoids having to start with a country code.

I'm not opposed to something like us.lost.org (just to make up  
something), but it would be nice to have something that can be done  
by a grassroots effort, rather than getting ICANN and/or the ITU  
involved. Determining who can speak for the public safety community  
in each country is non-trivial; the equivalent (determining the local  
authority in charge of E.164) made global ENUM such a pain. (I was on  
the IAB during that discussion, so I can attest to the pain and  
suffering. And it's still not working.)

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Jun 2007 14:09:07 -0400

I checked; there are already some SRVs in the ccTLDs:
dig _nicname._tcp.us srv

My local DNS expert (Ed Lewis) didn't bat an eyelash when I asked.

The point of this is that the ccTLDs already have the delegations, so we
don't have to get into another ENUM mess.  The problem devolves to having
the ccTLD operator decide that the entity wanting to load the SRV was the
right one.  I think that could work pretty well; they are, after all, local.

I would make this mechanism third: if your ISP AND your VSP don't get you to
a LoST server that can route, use the ccTLD entry where you are.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2007 1:04 PM
> To: Brian Rosen
> Cc: ECRIT

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Jun 2007 14:25:12 -0400

> I checked; there are already some SRVs in the ccTLDs:

This is a service operated directly by the ccTLD operator, so there  
is no issue with the NIC figuring out who represents PSAPs in the US,  
particularly if, say, two large commercial database operators both  
stand up and say "it's me!". Or, in the US, NENA and APCO.

> don't have to get into another ENUM mess.  The problem devolves to  

This was exactly the same problem for ENUM. It also relied  
(partially) on national ccTLDs, but they were not the same entities  
that managed the local E.164 space. The ccTLDs don't know anything  
about local PSAP politics.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Jun 2007 14:38:43 -0400

I wouldn't dare speak to anything other than the part I know about.

If APCO and NENA came to Neustar (the .us ccTLD operator) and both asked for
the SRV to point to them, we would ask both the DoC (who contracts with us
for .us domain operation) and the FCC what we should do.  We would get an
answer.

Brian

> Sent: Wednesday, June 20, 2007 2:25 PM
> To: Brian Rosen
> Cc: 'ECRIT'

---

From: Andrew Newton <[email-masked]>
Date: Wed, 20 Jun 2007 15:08:50 -0400

>> I checked; there are already some SRVs in the ccTLDs:

It would be a NAPTR record, btw.  I'm not sure what the hang-up is  
with SRV.

> about local PSAP politics.

I agree with Henning.  There might end up being only a smattering of  
countries that put in the correct NAPTR record.  However, as a third  
tier mechanism, I don't think it is harmful.

-andy