Subject: [Ecrit] Several IDs recently submitted by me

From: "James M. Polk" <[email-masked]>
Date: Thu, 29 Jun 2006 15:19:10 -0500

ECRIT

I've recently submitted several new IDs as individual submissions involving 
the scope near or of this WG.

All proposed new DHCP Options involving emergency services are to be 
discussed on the ECRIT list now.  This was worked out by both sets of WG 
chairs.

http://www.ietf.org/internet-drafts/draft-polk-dhc-ecrit-lost-server-uri-00.txt
defines a new DHCP Option for requesting and returning a LoST Server URI to 
a client.  This indicates to a endsystem where to send its initial LoST 
query as the access provider (SP, SMB or Enterprise) sees it.

Sometimes a Voice Service Provider (think Vonage) may want or need (perhaps 
by law or just strong guidance) to provide which LoST server(s) an 
endsystem sends its initial LoST query to.  This is addressed in:
http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-server-uri-00.txt 
as part of an endsystem's SIP Registration transaction.

Some here are have a position that LoST should be the only means to learn 
an emergency dialstring.  As utopian an idea as I think this is, I do not 
believe this WG should be making implementation decisions for every 
infrastructure type or for every domain administration.  There may be real 
reasons for using an existing protocol, with a small extension, to solve 
this dialstring-to-the-phone issue.
http://www.ietf.org/internet-drafts/draft-polk-ecrit-dhc-emergency-dialstring-option-00.txt 
solves this using DHCP, and another ID:
http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency-dialstring-00.txt
solves this during SIP Registration.

This latter transaction could yield both an emergency dialstring and a LoST 
URI in the same SIP 200 OK response message, making the messaging extremely 
efficient, and controllable by the application layer Voice SP - again, 
which may be forced on them by local laws or guidance.  Since it is already 
highly advisable to use TLS during SIP Registration, confidentiality and 
integrity are covered without anything newly defined here.

Finally, there may be infrastructures that want DHCP to provide a PSAP/ESRP 
URI in DHCP.  These infrastuctures would/should be of a more contained type 
of infrastructure, like a smaller or single site enterprise network, and I 
have no issues with the Framework or phoneBCP stating this recommended 
limitation. But in such cases, I believe:
http://www.ietf.org/internet-drafts/draft-polk-dhc-ecrit-uri-psap-esrp-00.txt 
addresses this solution space.

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