Subject: [Ecrit] draft-ietf-ecrit-service-urn-01

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 5 Mar 2006 11:07:01 -0500

I have submitted an update to the service URN draft; you can find the  
HTML version at

http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service- 
urn-01.html

I believe it incorporates the comments received so far. Major changes  
include:

- registration of services

- description of service feature tag

- security considerations

- description of alternatives considered, as an appendix

- DDDS description

I now consider the document complete; there are no open issues  
listed. However, I'd like feedback on the DDDS description, as it  
makes certain choices. In particular, it assumes that various  
configuration protocols, such as DHCP and SIP configuration, will  
provide a domain name that provides a NAPTR record. The advantage of  
this approach is that a DHCP response doesn't have to include a long  
list of service mapping protocols, with preferences and other data,  
particularly if different services are hosted at different servers.

There would likely be a separate definition for an ENUM service for  
the mapping protocol, but that doesn't quite fit into the scope of  
this draft and warrants a separate document.

My suggestion would be to last-call the document after the IETF  
meeting, giving an opportunity for discussion at the ECRIT meeting.  
In order to better prepare for the meeting discussion, I'd appreciate  
if folks could read the document. It's short...

Henning

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

---

From: Shida Schubert <[email-masked]>
Date: Sun, 19 Mar 2006 14:26:46 -0800

Hi Henning;

 As I noted in another e-mail. If the service-urn in Accept-Contact 
header is
to be used as a marking for emergency call. I think some security 
consideration for
handling the call when the marking exists should be noted.

 Regards
  Shida Schubert

Henning Schulzrinne wrote:
> http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-urn-01.html 
>
>
> I now consider the document complete; there are no open issues listed. 
> However, I'd like feedback on the DDDS description, as it makes 
> certain choices. In particular, it assumes that various configuration 
> protocols, such as DHCP and SIP configuration, will provide a domain 
> name that provides a NAPTR record. The advantage of this approach is 
> that a DHCP response doesn't have to include a long list of service 
> mapping protocols, with preferences and other data, particularly if 
> different services are hosted at different servers.
>
> meeting, giving an opportunity for discussion at the ECRIT meeting. In 
> order to better prepare for the meeting discussion, I'd appreciate if 
> folks could read the document. It's short...
>
> Henning
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 19 Mar 2006 17:36:16 -0500

This is one of the two major open issues I plan to discuss on  
Tuesday. (The other is the DDDS approach.)

I suspect regardless of the marking, you'll always have the problem  
that a node that did not insert the marker, but wants to grant  
special privileges based on it, needs to either

(1) ascertain that the marked was inserted by a trusted party

OR

(2) that the request URL actually points to a PSAP.

The problem for (1) is somewhat similar to the P-Asserted-Id issue.  
It may well be that the outcome is similar, namely something akin to  
the SIP Identity header mechanism to allow a receiver to find out who  
signed for this.

For (2), the main role of the header is then to alert the recipient  
to perform the verification. This sounds onerous, but unless PSAP  
URLs suddenly turn into the local Walmart, the proxy can easily cache  
this "yes, sip:[email-masked] is a PSAP" information.

Storing credentials in DNS (see another SIP draft) is also a  
possibility, but only if there's a globally recognized "this is a  
PSAP" signature.

I'm using marker here generically, as I believe that the issues don't  
depend on whether this is a new header, a URL parameter or Accept- 
Contact.

Henning