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

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:hgs@cs.columbia.edu]
> Sent: Monday, September 27, 2004 5:49 AM
> To: Peterson, Jon
> Cc: sipping-emergency@ietf.org; 'mankin@psg.com'
> 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
Sipping-emergency@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-emergency