Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency cal ling and routing

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 27 Sep 2004 16:02:11 -0400

Henning,

Certainly, this charter was not intended to guarantee to any particular
outcome of the standards process, but rather to select a narrow scope of
work that is likely to be achievable. No doubt a choice of scope can make
all the difference in the selection of a solution. If you're especially
concerned about, say, the mention of IRIS in the text below, that can be
elided from the final version. The deliverables text there is still rough.
Specific suggestions would be helpful, obviously.

I appreciate that you feel a requirement has been missed in the charter; I
have a hard time looking at the deliverables you cite below, though, and
understanding in what respect they suggest a nationally-specific or
centralized design for this work (neither of which would be default
assumptions for IETF work). Can you suggest any specific language here that
will improve the starter text? Do you just want to see something in the
descriptive text of the charter to the effect that the design here needs to
be delegative and allow distribution of call routing data? If so, I'd have
no problem including something to that effect.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, September 27, 2004 5:49 AM
> To: Peterson, Jon
> Cc: [email-masked]; [email-masked]'
> Subject: Re: [Sipping-emergency] proposed charter, new wg on emergency
> calling and routing
> 
> 
> I'm glad to see some progress on this issue.
> 
> My concern is that the charter already specifies or biases 
> the solution. 
> I know Ted has a particular solution in mind, possibly 
> influenced by his 
> experience at his day job, but this is far from what most people who 
> have been actively working in this area have been discussing. 
> Thus, my 
> concerns are primarily with the paragraphs below:
> 
> 
> > Standards Track RFC describing a query protocol for 
> Emergency Service
> > Context
> > lookup  by physical location.  Update, insert, and 
> modification of the data
> > associated
> > with ERC's is out of scope for this work item.
> >     (IRIS might be a candidate protocol here--it is a query 
> only protocol
> > for registry data,
> >      which is one way to model the back end store mapping 
> location to ERC).
> > 
> > BCP describing the call routing strategies for ip911.
> >     (e.g.:  does an ERC have a sip: URI to talk to, or do 
> we need to last
> > mile via PSTN?)
> > 
> > BCP describing how to discover ERC capabilities.
> >     (can a deaf person IM this center or can we route 
> through a relay?)
> > 
> > Threats and security documentation
> >     (mainly pointers, but the pointers need to be gathered).
> 
> I believe that the description misses a core requirement, namely the 
> ability to administer the system in a fully decentralized manner that 
> reflects the current administrative boundaries and delebation of 
> responsibilities. It also must be international, i.e., it cannot just 
> work for the US (or pick any other country) or require a US entity to 
> manage the system.
> 
> It would have been nice to recognize that there has been work 
> going on 
> this area for several years, but maybe that's too much to ask.
> 
> Henning
> 

_______________________________________________
Sipping-emergency mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 27 Sep 2004 22:14:55 -0400

> Specific suggestions would be helpful, obviously.

One relatively simple division has three deliverables:

- A terminology and requirements informational document

- A 'how to identify an emergency call' BCP

- A 'how to route an emergency call based on location information' 
BCP/STD (depending on whether new protocol work is needed or one simply 
describes how to use something existing for this)

I find it somewhat strange, also, that the call routing protocol isn't 
mentioned. Should the WG concern itself with H.323, Skype, Asterisk and 
other protocols? (While I suspect some similarities across these, 
scoping might be helpful here. I'm again speaking from NENA experience 
here, particularly in the I2 discussions.)

> will improve the starter text? Do you just want to see something in the

My concern is primarily due to the directory notion. Once this is 
removed, the worry is diminished. I think writing this requirement as 
part of the charter would be quite helpful.

> no problem including something to that effect.

Indeed. Let's just say that there are people in certain companies (not 
generally active in the IETF) that have an interest in a 
centrally-controlled, pay-for-use one-big-national directory model since 
that corresponds nicely to their existing ALI business model. Those 
involved in the NENA discussion can fill in the details, but they are 
probably not relevant here.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 28 Sep 2004 18:51:45 -0500

At 10:14 PM 9/27/2004 -0400, Henning Schulzrinne wrote:
>Peterson, Jon wrote:
>>Henning,
>>The deliverables text there is still rough.

I agree this deliverable is necessary to ensure everyone with the different 
backgrounds involved do not continue to talk past each other - sometimes 
without knowing they are.

>- A 'how to identify an emergency call' BCP

"How to identify a session set-up request is to an emergency response 
center" (we need to think longer term than just voice) is a good task, 
although I don't know if it should be its own deliverable, or part of a 
larger effort.

>- A 'how to route an emergency call based on location information' BCP/STD 
>(depending on whether new protocol work is needed or one simply describes 
>how to use something existing for this)

This should be a deliverable, but could be combined with the item above to 
create an "identity and route and emergency session request" document.

As a general thought here - there are a lot of BCPs being proposed. BCPs 
are generally *not* obsoleted or modified with future experience; therefore 
I believe these efforts should lean down the STDs Track process if possible 
so that a behavior or a mechanism can be modified to account for future 
learned capabilities. I know this is an unusual request if there is not 
protocol modification done, but this is an unusual area of work.

>other protocols? \

SIP should be the base set-up protocol in the charter

>(While I suspect some similarities across these, scoping might be helpful 
>here. I'm again speaking from NENA experience here, particularly in the I2 
>discussions.)
>>Jon Peterson
>>NeuStar, Inc.
>

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented