Subject: [Ecrit] ECRIT Working Group Session: Summary

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 22 Mar 2006 10:52:13 -0600

Hi all,

at the ECRIT WG meeting yesterday we discussed a few aspects and we 
would like to confirm them on the mailing list:

* Requirements
**************
   http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06.txt

Issues raised during WGLC will be added to the issue tracker, will be 
discussed and a new draft version will be resubmitted very soon.

Roger will discuss the align the usage of RFC 2119 language in the 
Security Threats draft and the Requirements draft.

* Security Threats
******************

http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats-03.txt

Tom will reflect comments regarding the security aspects of a proxy 
initiating the mapping protocol interaction. Text might need to go to 
the requirements document as well.

* A Uniform Resource Name for Services
**************************************

http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-01.txt

Based on long discussions during the meeting Henning will send a summary 
of the call identification with a suggested approach on resolving the 
issue. Discussions during the meeting already pointed to a preferred 
approach but more discussions might be needed.

Text about DDDS resolution will be removed from the draft and moved to 
the LoST document.

According to our charter milestones the document has to be finished soon.

* LoST
******
http://www.ietf-ecrit.org/cache/draft-hardie-ecrit-lost-00.txt

The participants showed interest to make LoST a working group item and 
to work on it aggressively.

* Mapping Architecture and Framework
************************************

http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-mapping-arch-00.txt

The working group expressed interest in working on such a document. 
Since this work is not captured by the current charter the chairs will 
compile a proposal for a modified charter.

* ECRIT Big Picture
*******************

There was interest in the past to write a document that explains the big 
picture. The chairs will form a design team to work on such a document.

* Phone BCP
***********

http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-00.txt

The working group expressed interest in working on such a document. 
Since this work is not captured by the current charter the chairs will 
compile a proposal for a modified charter.

*Analyzing ECRIT Mapping of a Location to an Emergency URI for Emergency 
Calling
************************************************************************

http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-events-00.txt

This document will be discussed further on the mailing list.

* Authority To Citizen Notification
***********************************

This presentation was purely informational for the working group.
Interested parties should contact the chairs and/or Steve Norreys.

* 3GPP Emergency Services and ECRIT work
****************************************

Discussions about 3GPP Emergency Service work revealed the need to 
establish a closer interaction between ECRIT and the respective 3GPP 
groups. The chairs will think about a possible way forward.

Please let us know if you have further comments.

Ciao
Hannes

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Mar 2006 15:13:52 -0500

> * A Uniform Resource Name for Services

As the WG may have noticed (or missed, in the flood of email...) is that 
I came up with a different solution to this problem. I hope it addresses 
the issues with doing re-mapping that were discussed in the meeting. To 
repeat briefly: We add a LoST operation that asks "is URL X a known PSAP 
URL?" The answer is "yes", "don't know" or "definitely not". Here, 
'known' means "would be returned by a mapping operation". Obviously, 
LoST can't know about PSAP URLs that exist only outside the LoST 
framework. All the usual caching applies, i.e., the answer contains an 
indication of how long this is valid.

> Text about DDDS resolution will be removed from the draft and moved to 

The more I think about this, the more I think this is a bad idea.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 22 Mar 2006 14:36:39 -0600

Hi Henning,

Henning Schulzrinne wrote:
>> Based on long discussions during the meeting Henning will send a 
>> summary of the call identification with a suggested approach on 
>> resolving the issue. Discussions during the meeting already pointed to 
>> a preferred approach but more discussions might be needed.
> 
> 
Thanks for starting this discussion quickly after the meeting.

> The more I think about this, the more I think this is a bad idea.

Hmmm. So, what could be the reason to put it into the Service URN draft?
Additionally, I wasn't quite sure whether we would go for NAPTR or the 
S-NAPTR approach. There was an argument for the simplicity of the 
S-NAPTR solution but there was also the argument by Jon for just getting 
NAPTR right.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Mar 2006 15:52:52 -0500

>>> Text about DDDS resolution will be removed from the draft and moved 
>>> to the LoST document.

The basic question is whether service URNs would always be resolved 
using LoST, across all current and future services. I hope this is the 
case, but it seems hard to predict. If a proxy, say, gets a service URN, 
they should be able to consult a directory to find out which mapping 
protocol(s) would be used to resolve the URN. It seems to be common 
practice to have a URN that has enough information to do the resolution. 
Indeed, the 3958 examples seem to head in that general direction, 
although they don't use URNs as examples.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 22 Mar 2006 15:59:02 -0500

FWIW, I share Henning's concern.  I don't want to tie urn:service to LoST.
For example, there could be services that do not depend on location as the
discriminator.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, March 22, 2006 3:53 PM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Ecrit] DDDS

Henning