Subject: [Ecrit] Update of draft-ietf-ecrit-mapping-arch

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 16 Dec 2006 17:16:29 -0500

I have submitted draft-ietf-ecrit-mapping-arch-01 to the I-D editor,  
with the following major changes:

- The document has been restructured to avoid duplication of material.

- Since LoST is now the accepted protocol implementing the  
architecture, I could be somewhat more specific in parts, hopefully  
making the document easier to follow.

- Where applicable, I've avoided text that restricts the architecture  
only to emergency calling, citing emergency calling as a running  
example.

Comments are appreciated.

An HTML version can be found at

http://www.cs.columbia.edu/sip/draft/lost-arch/draft-ietf-ecrit- 
mapping-arch-01.html

Henning

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

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 18 Dec 2006 17:06:49 +0100

> Comments are appreciated.

Here are some:

In the Definition section: 

|   parent:  A mapping server that covers the region of all of its
|      children.  A mapping server without a parent is a root resolver.

Shouldn't that be the root AMS?

There are two definitions for "resolver":

|   resolver:  A resolver is contacted by a seeker, consults a forest
|      mapping server and then resolves the query using an appropriate
|      tree.
|...
|   resolver:  Resolvers contact authoritative mapping servers to answer
|      queries by seekers, and may cache query results.

Regarding Forrest Guides:

We're running into a contradiction here, e.g.:

|   For scalability and reliability, there will need to be a
|   large number of forest guides, all providing the same information.  A
|   seeker can contact any forest guide and will then be directed to the
|   right tree or, rarely, set of trees.

vs. 

|   Trees can also restrict
|   their cooperation to parts of the information.  For example, if
|   country C does not recognize country T, C can propagate tree regions
|   for all but T.

Either the FGs offer all the same information or they don't. 

As I see the problem, we have basically two choices:

One choice is to  keep the forrest guides in sync with each other, with
an automated protocol between them. This is the first statement from
above plus these three sentences:

|   A tree node at the top of a tree can contact any forest
|   guide and inject new coverage region information into the system.
|   One would expect that each tree announces its coverage to more than
|   one forest guide.  Each forest guide peers with one or more other
|   guides and distributes new coverage region announcements to all other
|   guides.

In that case, this set of forrest guides act just as another layer in
the hierarchical resolution model. Thus we don't actually have a forrest,
but a single tree with the cluster of forrest guides as the root.

This, of course, reopens the pandora's box of who controls what to put
in there, which was the reason for the introduction of the forrest in
the first place.

Reading between the lines of the security section: Do you propose that
the forrest guides just sync a set of digitally signed tree referrals
amongst each other and then each FG decides based on local configuration
which ones he considers when answering questions? And who is going to
decide who can participate in this FG coverage exchange system?

The other option is to leave the question of forrest guide synchronization 
completely out of scope and thus don't even try to solve a political problem
with technical means.

I have this nagging feeling what we want to have our cake and eat it, too.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 18 Dec 2006 22:39:04 -0500

I'll change the subject line to reflect the more substantive issue  
you are raising.

I'm trying to walk a fine line in providing an architectural  
description that illustrates what's possible, without trying to nail  
down various practical "governance" approaches. In practice, I think  
a few options are possible:

- A real root, run by somebody. This is plausible for commercial  
directories for non-emergency services, possibly for a more limited  
geographic region. Effectively, a single FG or a single tree,  
depending on how you look at it.

- A "cooperative club": A group of organizations that propagate each  
other's announcements, but have some mechanism for admitting new  
members.

- A "semi-cooperative club": Everybody propagates most records, maybe  
with exceptions.

- Full peering: Each FG peers with all (say) countries it wants to  
work with. Thus, the "official" US FG would not talk to Iran and  
Cuba, say, except maybe through Switzerland.

In each case, records may be signed or, in a more tightly controlled  
environment, not.

There are probably more variations. I'm not sure I want to detail  
them all, since I'm reluctant to rule out "business models". Clearly,  
the text needs to be consistent, so I'll work on that.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Dec 2006 07:31:14 -0500

I think there is a problem with this approach.  This is ecrit, so the tree
that matters is the sos tree.  It needs to work, always, no matter where you
roam.  How do we do that?

We can't leave that part without a real plan that will work.  You have
repeatedly derided the ENUM approach, but, cumbersome though it is, it
works.  What will work which will allow any caller to determine the route to
the PSAP that serves where he is, no matter where he is?

That is not a business model.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, December 18, 2006 10:39 PM
> To: Otmar Lendl
> Cc: [email-masked]
> Subject: Re: [Ecrit] Forest guides
>

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 19 Dec 2006 13:53:56 +0100

> I'll change the subject line to reflect the more substantive issue  

Good.

> a few options are possible:

Your list of options makes a lot of sense. 

I'm a bit lost though, what the process will be to to establish one
of these options as the solution which will be deployed. My experience
in the ENUM world makes me a bit wary about mixing protocol issues
with world-wide political agreements. There are many pitfalls
and potential delays (dare I say "ITU"?) to consider when trying
to forge world-wide cooperation for this collaborative effort.

Based on this, I'd rule out 

> other's announcements, but have some mechanism for admitting new  

as a short-term solution.

> Cuba, say, except maybe through Switzerland.

These two options are more reasonable in the short term, though I'm not
sure that even such a loose cooperation between countries is easy and
fast to set up.

> In each case, records may be signed or, in a more tightly controlled  

That depends a lot on protocol details for overage announcements and
FG synchronization.

Perhaps we just need to specify a data-format which each
country/organization can use to publish it's coverage region with the
entrance point to its tree. Anybody then can aggregate this information
as they wish to configure their FG.

One of the open questions is whether we should even try to develop
a protocol for FG synchronization. That data is rather static anyway, so
I don't see the pressing need to encode all the politics of which
coverage announcements to honor into software.

As I see it, either go for an ENUM-like worldwide agreement, or leave
the question of FGs open to competing aggregation services.
(Similar to RSS aggregation or news.google.com)

/ol

---

From: Andrew Newton <[email-masked]>
Date: Tue, 19 Dec 2006 08:38:07 -0500

> coverage announcements to honor into software.

We've been through this in the working group, and it has been subject  
of much controversy.  I believe we now have a fair compromise,  
leaving out the server synchronization from the base spec but doing  
those things we know will make synchronization more viable.  Henning  
has a draft on synchronization of servers (which I don't believe  
would be any different for authoritative-to-authoritative than FG-to- 
FG).  While I reman skeptical that such a scheme would be better than  
back-end data store schemes already in existence for tightly coupled  
clusters, Henning's approach seems very reasonable for the many other  
situations, such as FG-to-FG.  If some FGs decide not to run the  
synchronization aspect, it should not preclude others from doing so.

> the question of FGs open to competing aggregation services.

Given the ability of the world to agree upon issues at the moment,  
I'm not holding my breathe for anything ENUM-like.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 Dec 2006 15:24:39 -0500

> to forge world-wide cooperation for this collaborative effort.

I agree. Unlike for ENUM, I hope we don't have to wait for a "big  
bang" that creates a nice, cooperative universe. Rather, I suspect a  
more likely scenario is bottom up, rather than top down. In other  
words, US states each build their own tree, as does Austria. First,  
some subset of US states cooperate, e.g., regionally. (This is not  
uncommon in other cases, and makes sense, given the "continental  
divide" and the uneven distribution of population in the US. As one  
recent example, take the propagation of EZPass, the electronic toll  
collection system. Started either in NY or NJ and is now slowly  
spreading west, north and south.)

On a peer-to-peer basis, Austria and the US then peer, adding in  
other interested countries. Maybe Canada gets added next, etc.

> as a short-term solution.

The latter seems actually pretty reasonable to me, except maybe to  
add that there may be several such "clubs" in the beginning, say a  
"European" club and a "North American" club.

> sure that even such a loose cooperation between countries is easy and

I'm hoping that some of the problems are a bit easier than for ENUM:  
There are clear jurisdictional responsibilities in each country and  
the ownership issues are easier, compared to E.164. As long as  
countries don't claim each other's territory, there don't seem to be  
insurmountable coordination problems.

> as they wish to configure their FG.

That format has been (implicitly) specific, namely <mapping>, where  
the <uri> is a LoST URL. (This element will appear in -03.)

As Andy pointed out, the lost-sync draft allows FGs to exchange  
these. Whether they'll use the tool, I don't know, but they  
definitely won't if it isn't available. I suspect that anything  
involving different organizations will require some kind of protocol  
mechanism, even if it's ftp.

> the question of FGs open to competing aggregation services.

As far as I can tell, the architecture precludes neither outcome, so  
I think we don't need to polish our crystal ball too much.

---

From: John Schnizlein <[email-masked]>
Date: Tue, 19 Dec 2006 15:46:52 -0500

I hope it can be accomplished without multiple separate systems and a 
phase of interoperability engineering as this history of EZPass 
suggests: http://en.wikipedia.org/wiki/EZPass

On Dec 19, 2006, at 3:24 PM, Henning Schulzrinne wrote:

> As one recent example, take the propagation of EZPass, the electronic 
> toll collection system. Started either in NY or NJ and is now slowly

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 Dec 2006 22:24:25 -0500

Brian,

I share your concern, but I believe that solving the policy problem  
is beyond the scope of ECRIT. Just like ENUM didn't try to deal with  
the ITU to set up (or not) e164.arpa, I don't think we can do working  
group documents that describe this. There is one commonality between  
this discussion and the ENUM effort: Since countries and even regions  
within a country are going to move at very different speeds on all-IP  
emergency calling, it seems unlikely that we'll have the same sense  
of urgency globally at the same time, so I think it's important to  
have an architecture that can evolve over time.

To answer your direct question: I think we have several possible  
plans that can work, where "work" means that all accessible FGs can  
be accessed. (Which doesn't mean that things will work in every  
country, simply because there may be no authoritative servers at  
all.) ISPs and VSPs will operate resolvers that point to FGs, either  
operated by them or some government authority.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Dec 2006 07:34:44 -0500

Henning

I don't see this as a policy issue.  I see it as a design issue.  What is
the design of the Forest Guides for the world's emergency call routing
database going to be?

When they worked out the design of ENUM, they planned for the ITU to do the
delegation.  They asked ITU if it was willing to do the delegation, and the
positive answer was known well before the documents were published.  They
created a design, and they were pretty sure it would be implemented, however
slowly and ungainly.

We need a plan, not a hand wave, and not a "could be this, could be that".
We need to state what our expectations are, and we need to do some checks to
make sure that at least a few key regions are willing to do it that way.  We
don't have to write rules for governments, but we have to describe something
that will work, something we can write code to.

Brian

> Sent: Tuesday, December 19, 2006 10:24 PM
> To: Brian Rosen
> Cc: 'Otmar Lendl'; [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Dec 2006 08:19:29 -0500

Brian,

I agree that we should check with a few regions, but unlike ENUM,  
where plausibly the IAB, and ITU could claim "ownership" (due to  
owning E.164 and the DNS root), there doesn't seem to be a natural  
point of initial contact. Who would be the authoritative contact in  
the US, just to pick a relatively simple example?

Henning

On Dec 20, 2006, at 7:34 AM, Brian Rosen wrote:

>>>>> |   guides and distributes new coverage region announcements to  
>>>>> all
>>>>> other
>>>>> |   guides.
>>>>>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Dec 2006 08:31:21 -0500

In the U.S., you ask NENA, and you, for completeness, ask the FCC.  The FCC
may not answer in a time frame that matters.  NENA would. 

But what are we asking?  If we have a plan, and we're validating that the
entities that have to implement some part of the plan are agreeable, then
the above is a good answer.  We don't (yet) have a plan.  We have "maybe
this, maybe that, maybe something else".

Brian

> Sent: Wednesday, December 20, 2006 8:19 AM
> To: Brian Rosen

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Dec 2006 08:44:43 -0500

I'm happy to provide a plan: FGs operated by states (or their  
contractors), with mutual peering.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Dec 2006 08:57:17 -0500

I'm sure we can get that to work, but what is the international plan?  How
does an enterprise VoIP system in the U.S. find routing for a roamer in
France?

Brian

> Sent: Wednesday, December 20, 2006 8:45 AM
> To: Brian Rosen

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Dec 2006 09:06:35 -0500

The answer, I think, depends on whether we believe we'll see national  
peering (NENA-appointed entity peering with their counterpart in  
France) or some global coordination body. I suspect that the former  
is more likely, but I don't know whether there is much international  
contact between these bodies. From what I know, most countries don't  
even have the equivalent of NENA, which arose at least partially due  
to the extremely distributed operation of the US 911 system. Any  
suggestions?

---

From: <[email-masked]>
Date: Wed, 20 Dec 2006 09:09:14 -0500

Hello Gentlemen,
 
This issue surfaced at a National Press Club event I attended this month.  In fact, the same question came from a man from Paris who visits here often. He wanted to know if the EU participated on the research in the US as there was nothing that he knew of underway in France (let alone other countries).
 
My question to you: Is there a member of the EU who participates on IETF? In any case, perhaps we can extend specific invitations to the Spring meeting?
 
Jenny

________________________________

From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wed 12/20/2006 9:06 AM
To: Brian Rosen
Cc: 'Otmar Lendl'; [email-masked]
Subject: Re: [Ecrit] Forest guides

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 20 Dec 2006 09:45:21 -0500

Jenny, et al,

Alain Van Gaever from the EU Commission presented at ESW06.  Alain is very
interested in including the EU in a global solution.

I agree that time should be spent on this issue at the spring ESW.

-Marc-

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, December 20, 2006 9:09 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Ecrit] Forest guides
> 
> Hello Gentlemen,
>  
> This issue surfaced at a National Press Club event I attended 
> this month.  In fact, the same question came from a man from 
> Paris who visits here often. He wanted to know if the EU 
> participated on the research in the US as there was nothing 
> that he knew of underway in France (let alone other countries).
>  
> My question to you: Is there a member of the EU who 
> participates on IETF? In any case, perhaps we can extend 
> specific invitations to the Spring meeting?
>  
> Jenny
> 
> The answer, I think, depends on whether we believe we'll see 
> national peering (NENA-appointed entity peering with their 
> counterpart in
> France) or some global coordination body. I suspect that the 
> former is more likely, but I don't know whether there is much 
> international contact between these bodies. From what I know, 
> most countries don't even have the equivalent of NENA, which 
> arose at least partially due to the extremely distributed 
> operation of the US 911 system. Any suggestions?
> 
> > I'm sure we can get that to work, but what is the 
> international plan?  
> > How does an enterprise VoIP system in the U.S. find routing for a 
> > roamer in France?
> >
> > Brian
> >
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Dec 2006 10:56:35 -0500

I agree a global coordination body would be difficult.  I'm sure we could
get the ITU to do it, but I'm also sure we won't like the result, and I'm
not in favor of that unless we have no other viable alternatives.

What I was thinking was that there was a partial mesh with referral.  There
are clearly areas of the world that would flatly refuse to cooperate with
one another, so a full mesh is never going to happen.  However, a partial
mesh would work.  If you allow referral, then we can get the "Switzerland
handles our diplomatic contacts with NeverNeverLand, because we don't have
diplomatic relations with them).

Brian

> Sent: Wednesday, December 20, 2006 9:07 AM
> To: Brian Rosen

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Dec 2006 11:01:43 -0500

Alain is the right guy, and he does follow this stuff fairly closely.  I did
give a presentation to the EU Expert Group on Emergency Calling last year so
they are mostly at least aware of what is happening.  We could probably ask
him to seek advice from the expert group if anyone saw problems with a
specific approach.  I'll let him directly answer the question of whether we
could get a more formal response to a specific "would you implement this"
kind of question.  

A couple of people from EU countries also participate here.  Steve Norreys
is probably the one we all know.  I'm pretty sure there are others who
monitor the list.  There are also several people from Asia who participate
here, and I hope we could get some response from them.

Brian

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, December 20, 2006 9:45 AM
> To: [email-masked]
> Cc: 'Alain Van Gaever'; [email-masked]

---

From: Andrew Newton <[email-masked]>
Date: Wed, 20 Dec 2006 20:00:30 -0500

> diplomatic relations with them).

Brian, considering your accusation against Henning for handing  
waving, I think you've just done exactly the same thing.  I don't  
know what it is you think the IETF is gonna do about this, but  
running around the world and asking governments to appoint LoST  
coordinators is likely something the IETF will never do.  As Henning  
pointed out, ENUM was designed to be E.164 layered on DNS, both of  
which had authorities appointed already.  And a lot of good it did,  
huh?  Today, there are far more ENUM activities in private trees than  
in the IETF-blessed, public ENUM.  If anything, it illustrates the  
point.  The IETF is good at technical solutions, not political  
solutions.

Creating LoST and the outputs of ECRIT is the IETF's role in this.   
Selling it to the world is the role of NENA (and its counterparts in  
other countries).

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Dec 2006 20:44:39 -0500

> Today, there are far more ENUM activities in private trees than in  
> the IETF-blessed, public ENUM.  If anything, it illustrates the  

I think there's a lesson in the ENUM evolution: The ENUM folks had to  
do a fair amount of work to make a variety of non-centralized  
solutions work ("enterprise ENUM"). Given the ENUM experience, if not  
just plain common sense, I think we need to anticipate that we won't  
get to where we want in one neat step, so making sure that we can  
support a range of deployment options seems a sensible thing to me,  
even if it is hand-waving. I'd rather wave hands than polish my  
crystal ball.

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 21 Dec 2006 10:24:59 +0100

Folks,

>From my ENUM experience:
I think we first need a stable technical solution (done in IETF).
ENUM RFC3761 and the related RFCs are used by public User and
Infrastructure ENUM and also by all private trees.

It would be nice if this technical solution is also accepted by other
standard bodies (3GPP, ETSI TISPAN - and eventually ITU-T NGN)
I see them slowly moving in this direction.

Lets talk first about emergency services only:

Emergency services are nationally organized, so the trees will
be also national. The FG should coordinate between the trees.

Not all countries will move to IP PSAPs at the same time, but some
large countries (e.g the US) will do and will create facts.

Most of these countries have diplomatic relationships and there
will be no problems to point to each other.

Countries not doing this at the moment will follow later, because they
have no choice.

But this will only work if we have ONE stable global standard, and
this is the task if the IETF (together with the other large standard
bodies involved in VoIP.

Regards
Richard

> Sent: Thursday, December 21, 2006 2:45 AM
> To: Andrew Newton
> Cc: [email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 21 Dec 2006 09:02:50 -0500

Excuse me, but I thought I proposed a specific, workable answer.  I think we
probably CAN arrange a partial mesh.  It will never be a full mesh.  It will
be voluntary.

Since we can't get a partial mesh, we may need some referral operation where
an entity in the mesh undertakes to return a tree he is not authoritative
for, but merely acts as an agent.

I do think we want to have some more specifics.  I'm not sure if the
specifics can be an IETF document, but that would be my preference.  What I
hope for is that there is a normative document that describes exactly how
meshes and partial meshes work (in a protocol sense).  Then I think we can
draft a BCP that would guide creation of the mesh by countries.  The latter
document would be something we would solicit input from NENA, the EU Expert
Group on Emergency Access, the appropriate Asian agencies, etc.  If we got
positive responses from them, we may have a solution.  It's a BCP, not a
treaty.

Brian

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Wednesday, December 20, 2006 8:01 PM
> To: Brian Rosen
> Cc: Henning Schulzrinne; [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 21 Dec 2006 09:38:52 -0500

> for, but merely acts as an agent.

That's already possible with the existing spec. Any LoST server can  
always return a referral (another LoST URL) in a mapping response or  
a special redirection error response. Hopefully, the details will be  
clearer in LoST -03.

> positive responses from them, we may have a solution.  It's a BCP,  

The lost-sync document describes this, although it can probably use  
more detail in places. It allows any set of LoST servers to  
synchronize their data, be that FGs or authoritative servers. This  
can be either a full mesh or some partial peering mesh that floods  
mapping information by more than one step. Thus, I'd appreciate  
comments on the lost-sync document to make sure it has enough details  
to be usable.

I'm trying to minimize the number of mechanisms across the architecture.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 21 Dec 2006 09:55:49 -0500

> a special redirection error response. Hopefully, the details will be
That's pretty much what I was expecting, although it's hard to see how that
works for trees in the documentation as it exists today.  I'll wait for
Lost-03 and if I still get confused, maybe I'll suggest specifics.

> comments on the lost-sync document to make sure it has enough details
I had not realized that this was the intended mechanism.  Again probably not
thinking of this as applying to the forest.  I'll review the documents
again.
> I'm trying to minimize the number of mechanisms across the architecture.
Yeah, you've said that, and I understand it, but maybe we haven't gotten the
documents there yet.

Now that would be the protocol part.  A BCP on how you use it may still be
usefull.