Subject: Re: [Ecrit] Comments on phonebcp-07

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Feb 2009 19:29:58 -0500 (EST)

Thank you for your comments.  Sorry this took so long.  I am temporarily
unable to create an actual "Reply all" to your email, so this is
cut/pasted from a non-IETF archive (the archives are screwed up, there is
no mail from Feb 2 to Feb 27).  The changes are now in -framework-08 and
-phonebcp-08

Enterprise = access network operator.  They must meet the AN requirements.
 I'll point that out.  Enterprises could run their own LoST server which
would deliver the right things (dial string, URI, ...).  I've added text
on both enterprise as access network provider and potential LoST and PSAP
provider in -framework, and mentioned enterprise as a possible access
network provider in -phonebcp

1. ED-6 vs ED-9 is the difference between discovery with a home country
code and provisioning of actual dial string.  We haven't described
discovery, so I'll have to delete ED-6

2. I'll Reword SP-8 to say that Service providers may provision endpoints
with home dial strings (see ED-9)

3. Changes in the list clarifies this, but ED-18 says do it, and ED-21
specifies protocol support to do it.  I added a reference to -21 in -18.

4. We discussed this on the interim conference call.  The resolution will
be to remove the requirement and have something non normative in
-framework.

5. I'll downgrade the sip-sips reference to Informational.  Could refer to
the 3.1 text.

6. Don't know how to define a requirement which assumes the presence of a
B2BUA.  I propose to leave as is

7. I'll fix the text for MUST and delete "normal"

8. An actual problem.  Calls out for a way to mark the Route as the
emergency route.  Two solutions were discussed.  One is to use the sos
parameter.  The other is to say that the Geolocation header must not have
a "used for routing" parameter unless the LoST routing was completed.  I
think I will recommend the second.

9. Rework to make it a SHOULD noting the issue.  Unauthenticaed devices
usually are allowed to make calls, but not always.  I'll add text.

10.  If the device is no longer registered, then the Contact can't be
valid.  I can insert text to this effect.  Don't know how to handle B2BUAs
that munge Contact headers.   I can at least call out the problem in
-framework.

11. Tried to make the requirement minimal (no Replaces, for example), but
I think you need referred by.  I'll think some more about that.  I'll add
text that says device implementers should consider the effect of emergency
call transfer on a stressed user; generally, the device should do the
transfer.

12. Don't understand the problem.  The situation described is AFTER a call
session is established, but before it is terminated.   LoST resolution is
complete.

13. a) If a call arrives while an emergency call is up, we don't want a
call waiting tone, alert or other prompt, we don't want the emergency call
put on hold and we don't want the incoming call to be answered.
b) Although some features can be applied to incoming calls, they are also
applicable to outgoing calls, which is what we want here; we don't want
the emergency call put on hold, put into a client-side conference, ...
c) I'll add a definition of "flash hold" to -framework.  Of  course "flash
hold" does involve a proxy,  where normal SIP hold does not.  You don't
want Hold (that is, disconnect the media to or from the PSAP).

14. Call waiting on an incoming call is the same as on an outgoing call:
you don't alert to another call, you don't offer hold and switch.  The
PSAP callback stays up.  Yes, 486 or voicemail is appropriate.  Indeed the
recognition of the callback is difficult, and I hope we will charter an
item.  I think the domain recognition is a reasonable first step, and I
recognize it won't always work.   When it doesn't, callback won't get the
feature suppression.  Not a good thing, but not fatal.

15. I may be misinterpreting your concern, but I think the B2BUA that maps
Contact doesn't alter the caller's domain as seen by the called party.  If
the call arrives directed TO the Contact or AoR given out in the original
emergency call, and it's FROM the same domain that answered the call, then
it should be treated as a call back.

16. I don't really care much what error message we use.  I can change it
to 404 if there are no objections.  ".test" is not registered.  We
probably should do that, but not in this document.  It's not really
required that we register it, as it's a subdomain of a registered domain. 
i need to get a document started to register a couple of things not
dissimilar to this, so I'll put it in that

17. The response certainly should be using TLS, but it might not work. 
I'll add text.

18.  I will delete the sentence referencing 4916.

Brian

------ original message contents -------
Some WGLC comments on this. Apologies for not raising them before, but I
have not participated in this WG until recently.

General comment:
It is not clear if and how this applies to enterprise networks.
Enterprise networks are mentioned in a couple requirements involving
intermediate range wireless connections, but that is all. Particular
requirements of enterprise networks, which might include their own
"PSAPs" in some situations, for example, and different dial strings in
some circumstances, do not seem to be addressed. So perhaps it should be
made clear that it does not address special requirements of enterprise
networks.

Detailed comments:

1. "ED-6/SP-5 Devices MUST be able to be configured with the home
country
   from which the home dial string(s) can be determined."
And later:
"ED-9 Endpoints SHOULD be able to have home dial strings provisioned
   by configuration."
I can't figure out exactly why we need two separate requirements here.

2. "SP-8 Service providers MAY provide home dial strings by
   configuration"
It is not clear to whom or to what home dial strings are provided, and
how this relates to requirements ED-6/SP-5 and ED-9.

3. "ED-18/INT-9 Endpoints SHOULD attempt to configure their own
location."
And later:
"ED-21/INT-12 Devices MUST support both the DHCP location options
   [RFC4776], [RFC3825] and HELD"
There appears to be some inconsistency here. If there are circumstances
in which a device does not need to attempt to configure its own location
(because it is only SHOULD strength), why are support for DHCP and HELD
mandated?

4. "ED-59 Best Current Practice for SIP user agents [RFC4504] including
   handling of audio, video and real-time text [RFC4103] SHOULD be
   applied."
Is it permissible for a Standards Track to make a SHOULD statement
involving an informational RFC? I believe not. Furthermore, RFC 4504
refers back to ECRIT work, which makes it rather circular.

5. "ED-60/SP-31 TLS MUST be specified when attempting to signal an
   emergency call with SIP per [I-D.ietf-sip-sips].  IPSEC [RFC3986] is
   an acceptable alternative."
I think we need to be more specific about what aspect of sip-sips we are
referring to. For example, are we talking about 3.1 "Models for using
TLS in SIP"? That section doesn't seem to include any normative
statements, so why is it a normative reference. The normative part of
sip-sips seems to relate to the SIPS URI scheme, which presumably we
don't want to use.

6. " A Contact header MUST be present which MUST be globally
        routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid
        for several minutes following the termination of the call to
        permit an immediate call-back to the specific device which
        placed the emergency call."
As a requirement for a user agent, I don't think this is necessary in
situations where there is a B2BUA that maps a local contact URI to a
globally routable contact URI.

7. "ED-58 Initial INVITES MUST provide an Offer [RFC3264]."
And later:
"A normal SDP offer SHOULD be included in the INVITE.  If voice
        is supported the offer MUST include the G.711 codec, see
        Section 14."
This seems contradictory (MUST and SHOULD). Also what is "normal"?

8. "A proxy that processes such a call looks for
   the presence of a SIP Route header field with a URI of a PSAP.
   Absence of such a Route header indicates the UAC was unable to invoke
   LoST and the proxy MUST perform the LoST mapping and insert a Route
   header field with the URI obtained."
How does the proxy determine whether a URI is indeed a PSAP URI? Does it
need to examine the Geolocation header field to see if the location has
been used for routing?

9. "Either a P-Asserted-Identity [RFC3325] or an Identity header
       [RFC4474], or both, MUST be included to identify the sender."
A proxy cannot do this unless it has authenticated the UA or unless it
violates the rules of RFC 3325 or RFC 4474. I think we need some
commentary on whether unauthenticated UAs are allowed to make emergency
calls, and if so, how to get around this problem of providing PAI or
Identity.

10. "SP-36 Call backs to the Contact: header URI recieved within 30
   minutes of an emergency call must reach the device regardless of call
   features or services that would normally cause the call to be routed
   to some other entity."
a) What if the device is no longer registered?
c) Also, what if there are downstream B2BUAs that map contact URIs? Will
they necessarily cache that mapping after the original call has
finished? If not, I don't see how a callback to the contact URI can
work.

11. "ED-67/SP-38 During the course of an emergency call, devices and
   proxies MUST support REFER transactions and the Referred-by: header
   [RFC3515]."
a)This is a very broad requirement. I can see the need for supporting
REFER with SIP/SIPS URI and with method=INVITE. Is there a requirement
beyond this?
b) A UA can support REFER by consulting its user whether to go ahead and
reference. The user may decline. Or UA policy might prevent certain
dereferences. Does anything need to be said about this?

12. "If in the interval, an incoming call is received from
   the domain of the PSAP, the device MUST drop the old call and alert
   for the (new) incoming call."
Can the device necessarily determine this? For example, if the device
just submitted a dial string, or submitted a service URN without
performing a LoST query, or if the call gets retargeted to a different
PSAP domain?

13. "ED-70/SP-39 User Agents and proxies MUST disable outgoing call
   features such as
   o  Call Waiting
   o  Call Transfer
   o  Three Way Call
   o  Flash hold
   o  Outbound Call Blocking"
a) I don't see how Call Waiting can be considered an outgoing call
feature. Some explanation is needed.
b) I don't see call transfer, three way call (presumably 3-way
conference) and hold as "outgoing call features" particularly - you can
use these "features" with incoming calls too.
c) "Flash hold" seems to be a north American term - use a more generic
term or describe what this means.
d) If "flash hold" means "hold", proxies have no influence over it.
Also, if hold means "stop sending and rendering media", a device can do
that simply by preventing the user turning down the microphone or
speaker volume. Is this what it means? Removing any control over volume
seems unwise.

14. " ED-72/SP-41 The User Agent and Proxies SHOULD disable the
following
   incoming call features on call backs from the PSAP:
   o  Call Waiting"
a) Disabling call waiting will generally result in rejecting an incoming
call with a 486, or forwarding, e.g., to voicemail. Is this really what
is required?
b) How does a UA or proxy determine that the callback is from a PSAP
(see earlier comment, and also next comment)?

15. "ED-73 Call backs SHOULD be determined by retaining the domain of
the
   PSAP which answers an outgoing emergency call and instantiating a
   timer which starts when the call is terminated.  If a call is
   received from the same domain and within the timer period, sent to
   the Contact: or AoR used in the emergency call, it should be assumed
   to be a call back.  The suggested timer period is 5 minutes."
Suppose there is a B2BUA on the path that maps contact URIs. Every call
the UA makes through that B2BUA will have a contact URI with the domain
of that B2BUA, so every call within the time period concerned would be
treated as coming from a PSAP.

16. "ED-81 INVITE requests to a service URN ending in ".test" indicates
a
   request for an automated test.  For example,
   "urn:service.sos.fire.test".  As in standard SIP, a 200 (OK) response
   indicates that the address was recognized and a 404 (Not found) that
   it was not.  A 486 (Busy Here) MUST be returned if the test service
   is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP
   does not support the test mechanism."
This seems to be the wrong semantics for 488, since in this case there
is nothing wrong with the session description. Wouldn't 404 be more
appropriate, since the .test URN is not recognised?
Also, where is ".test" registered?

17. "ED-82 In its response to the test, the PSAP MAY include a text body
   (text/plain) indicating the identity of the PSAP, the requested
   service, and the location reported with the call.  For the latter,
   the PSAP SHOULD return location-by-value even if the original
   location delivered with the test was by-reference."
Isn't there a security issue with this, particularly for the case where
SIPS has not been used? There is no discussion in Security
Considerations.

18. "The response MAY
   include the connected identity of the PSAP per [RFC4916]."
RFC 4916 makes no provision for responses.

John

Date: Wed, 04 Feb 2009 15:29:33 +0000
From: "Elwell, John" <[email-masked]>
To: [email-masked]
Content-class: urn:content-classes:message
Subject: [Ecrit] Comments on phonebcp-07

Some WGLC comments on this. Apologies for not raising them before, but I
have not participated in this WG until recently.

General comment:
It is not clear if and how this applies to enterprise networks.
Enterprise networks are mentioned in a couple requirements involving
intermediate range wireless connections, but that is all. Particular
requirements of enterprise networks, which might include their own
"PSAPs" in some situations, for example, and different dial strings in
some circumstances, do not seem to be addressed. So perhaps it should be
made clear that it does not address special requirements of enterprise
networks.

Detailed comments:

1. "ED-6/SP-5 Devices MUST be able to be configured with the home
country
   from which the home dial string(s) can be determined."
And later:
"ED-9 Endpoints SHOULD be able to have home dial strings provisioned
   by configuration."
I can't figure out exactly why we need two separate requirements here.

2. "SP-8 Service providers MAY provide home dial strings by
   configuration"
It is not clear to whom or to what home dial strings are provided, and
how this relates to requirements ED-6/SP-5 and ED-9.

3. "ED-18/INT-9 Endpoints SHOULD attempt to configure their own
location."
And later:
"ED-21/INT-12 Devices MUST support both the DHCP location options
   [RFC4776], [RFC3825] and HELD"
There appears to be some inconsistency here. If there are circumstances
in which a device does not need to attempt to configure its own location
(because it is only SHOULD strength), why are support for DHCP and HELD
mandated?

4. "ED-59 Best Current Practice for SIP user agents [RFC4504] including
   handling of audio, video and real-time text [RFC4103] SHOULD be
   applied."
Is it permissible for a Standards Track to make a SHOULD statement
involving an informational RFC? I believe not. Furthermore, RFC 4504
refers back to ECRIT work, which makes it rather circular.

5. "ED-60/SP-31 TLS MUST be specified when attempting to signal an
   emergency call with SIP per [I-D.ietf-sip-sips].  IPSEC [RFC3986] is
   an acceptable alternative."
I think we need to be more specific about what aspect of sip-sips we are
referring to. For example, are we talking about 3.1 "Models for using
TLS in SIP"? That section doesn't seem to include any normative
statements, so why is it a normative reference. The normative part of
sip-sips seems to relate to the SIPS URI scheme, which presumably we
don't want to use.

6. " A Contact header MUST be present which MUST be globally
        routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid
        for several minutes following the termination of the call to
        permit an immediate call-back to the specific device which
        placed the emergency call."
As a requirement for a user agent, I don't think this is necessary in
situations where there is a B2BUA that maps a local contact URI to a
globally routable contact URI.

7. "ED-58 Initial INVITES MUST provide an Offer [RFC3264]."
And later:
"A normal SDP offer SHOULD be included in the INVITE.  If voice
        is supported the offer MUST include the G.711 codec, see
        Section 14."
This seems contradictory (MUST and SHOULD). Also what is "normal"?

8. "A proxy that processes such a call looks for
   the presence of a SIP Route header field with a URI of a PSAP.
   Absence of such a Route header indicates the UAC was unable to invoke
   LoST and the proxy MUST perform the LoST mapping and insert a Route
   header field with the URI obtained."
How does the proxy determine whether a URI is indeed a PSAP URI? Does it
need to examine the Geolocation header field to see if the location has
been used for routing?

9. "Either a P-Asserted-Identity [RFC3325] or an Identity header
       [RFC4474], or both, MUST be included to identify the sender."
A proxy cannot do this unless it has authenticated the UA or unless it
violates the rules of RFC 3325 or RFC 4474. I think we need some
commentary on whether unauthenticated UAs are allowed to make emergency
calls, and if so, how to get around this problem of providing PAI or
Identity.

10. "SP-36 Call backs to the Contact: header URI recieved within 30
   minutes of an emergency call must reach the device regardless of call
   features or services that would normally cause the call to be routed
   to some other entity."
a) What if the device is no longer registered?
c) Also, what if there are downstream B2BUAs that map contact URIs? Will
they necessarily cache that mapping after the original call has
finished? If not, I don't see how a callback to the contact URI can
work.

11. "ED-67/SP-38 During the course of an emergency call, devices and
   proxies MUST support REFER transactions and the Referred-by: header
   [RFC3515]."
a)This is a very broad requirement. I can see the need for supporting
REFER with SIP/SIPS URI and with method=3DINVITE. Is there a requirement
beyond this?
b) A UA can support REFER by consulting its user whether to go ahead and
reference. The user may decline. Or UA policy might prevent certain
dereferences. Does anything need to be said about this?

12. "If in the interval, an incoming call is received from
   the domain of the PSAP, the device MUST drop the old call and alert
   for the (new) incoming call."
Can the device necessarily determine this? For example, if the device
just submitted a dial string, or submitted a service URN without
performing a LoST query, or if the call gets retargeted to a different
PSAP domain?

13. "ED-70/SP-39 User Agents and proxies MUST disable outgoing call
   features such as
   o  Call Waiting
   o  Call Transfer
   o  Three Way Call
   o  Flash hold
   o  Outbound Call Blocking"
a) I don't see how Call Waiting can be considered an outgoing call
feature. Some explanation is needed.
b) I don't see call transfer, three way call (presumably 3-way
conference) and hold as "outgoing call features" particularly - you can
use these "features" with incoming calls too.
c) "Flash hold" seems to be a north American term - use a more generic
term or describe what this means.
d) If "flash hold" means "hold", proxies have no influence over it.
Also, if hold means "stop sending and rendering media", a device can do
that simply by preventing the user turning down the microphone or
speaker volume. Is this what it means? Removing any control over volume
seems unwise.

14. " ED-72/SP-41 The User Agent and Proxies SHOULD disable the
following
   incoming call features on call backs from the PSAP:
   o  Call Waiting"
a) Disabling call waiting will generally result in rejecting an incoming
call with a 486, or forwarding, e.g., to voicemail. Is this really what
is required?
b) How does a UA or proxy determine that the callback is from a PSAP
(see earlier comment, and also next comment)?

15. "ED-73 Call backs SHOULD be determined by retaining the domain of
the
   PSAP which answers an outgoing emergency call and instantiating a
   timer which starts when the call is terminated.  If a call is
   received from the same domain and within the timer period, sent to
   the Contact: or AoR used in the emergency call, it should be assumed
   to be a call back.  The suggested timer period is 5 minutes."
Suppose there is a B2BUA on the path that maps contact URIs. Every call
the UA makes through that B2BUA will have a contact URI with the domain
of that B2BUA, so every call within the time period concerned would be
treated as coming from a PSAP.

16. "ED-81 INVITE requests to a service URN ending in ".test" indicates
a
   request for an automated test.  For example,
   "urn:service.sos.fire.test".  As in standard SIP, a 200 (OK) response
   indicates that the address was recognized and a 404 (Not found) that
   it was not.  A 486 (Busy Here) MUST be returned if the test service
   is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP
   does not support the test mechanism."
This seems to be the wrong semantics for 488, since in this case there
is nothing wrong with the session description. Wouldn't 404 be more
appropriate, since the .test URN is not recognised?
Also, where is ".test" registered?

17. "ED-82 In its response to the test, the PSAP MAY include a text body
   (text/plain) indicating the identity of the PSAP, the requested
   service, and the location reported with the call.  For the latter,
   the PSAP SHOULD return location-by-value even if the original
   location delivered with the test was by-reference."
Isn't there a security issue with this, particularly for the case where
SIPS has not been used? There is no discussion in Security
Considerations.

18. "The response MAY
   include the connected identity of the PSAP per [RFC4916]."
RFC 4916 makes no provision for responses.

John

From: "Hannes Tschofenig" <[email-masked]>
To: "'Richard Barnes'" <[email-masked]>, "'ECRIT'" <[email-masked]>, <[email-masked]>
Date: Wed, 4 Feb 2009 19:28:40 +0200
Subject: Re: [Ecrit] Review of draft-ietf-lost-sync-01

Hi Richard, 

Thanks for your detailed review of the document. I produced a new version
based on your feedback. Here is a snapshot: 
http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/draft-ietf-ecri
t-lost-sync-03.txt

Please look at it before I submit it to make sure that goes into the right
direction of addressing your comments. 

More comments below: 
 
>This draft proposes an XML syntax for transferring LoST 
>mappings between LoST nodes.

I prefer to say that it transfers mappings that are defined in LoST between
different nodes. I believe that the protocol can be used even without LoST. 

For example, you could use this protocol in the NENA i2.5 environment. 

  While this XML syntax seems to 
>have most of the necessary features for the proposed use 
>cases, the details of how the XML syntax is to be used to 
>effect the transfer are either ambiguous or completely 
>missing.  Specific comments below.
>--Richard
>
>
>Section 1. Introduction
>-- This may reflect a misunderstanding of the mapping 
>architecture on my part, but my impression was that the 
>architecture envisioned query patterns similar to the DNS, 
>either iterating or recursing through the tree.  This document 
>seems to propose that instead, authoritative servers and 
>branch nodes would push mapping up, presumably to FGs (this 
>behavior has no analogue in the DNS to my knowledge).  It 
>would be helpful if this document could clarify how these two 
>patterns interact.

When used in the LoST mapping architecture then this document is going to be
mainly used between FGs. Still, one could use this document also between
other nodes. LoST itself would allow you to dynamically obtain mappings
whereas this document essentially replicates cache entries. 

The DNS analogon would be a zone transfer. 

>
>Section 3. Distributing Mappings via <pushMappings> ...
>-- I think there's enough description here to basically 
>understand how this is supposed to work, but there's not a 
>clear, normative specification, not a single MUST in the whole 
>section!  It would be helpful to have clear "Sender 
>processing" and "Recipient processing" 
>instructions.

Worked on it 

>-- Likewise, there's no clear description of who sends which 
>messages to whom (except by example), and no description at 
>all of how these messages are carried.  If this is an 
>extension to LoST, please say so, or if it's another HTTP 
>usage, or bare TCP, etc.  The absence of these details 
>(particularly message flow patterns), it's a hard to 
>understand the sequence of events.

The transport is reused from LoST but it is certainly useful to say that. 

>-- The message pattern this seems to be following is a little 
>weird; it's "pub/sub", but without the "sub".  There should be 
>some comment on this, e.g., that there is an expectation that 
>these peering relationships are established out of band, and 
>thus no subscription or request is necessary.

That's true. There is no subscribe in the protocol. This is done in an
out-of-band fashion, if desired. 

  Alternatively, 
><getMappings> could possibly support an "asynchronous" flag.
>-- There's a stray " at the end of the fourth paragraph
>-- The URIs in the example <uri> fields are invalid
>
OK. 

>Section 4. Synchronizing Mapping Stores via <getMappings> ...
>-- Same first two comments as for Section 3.  There needs to 
>be a much clearer, normative description of how the peers 
>process and transmit messages.

Fixed. 

>-- Please change the <m> tag to something readable 
>(<mapping-descriptor>?)

Fixed. 

>-- The description here seems to conflate two types of query 
>parameters, "what I have" and "what I want".  If you separate 
>these two out, it could simplify the semantics: the "what I 
>have" section would have <mapping> elements that MUST have all 
>three identifier fields, while the "what I want" section would 
>have <mapping-descriptor> descriptions of mappings to be 
>returned (using subsets of identifier fields).

Done. See the revised version. 

>-- Why can't a <getMappings> element have a lastUpdated attribute? 
>Either it should have everything or nothing.  (IMO, the 
>optimization isn't worth the extra complexity of merging 
>attributes from <getMappings> and <m>)

Please look at the revised version and let me know if there is some
functionality we should get rid off

>-- Is there a reason no content-based queries are allowed?  
>For example, I could imagine that it would be useful to be 
>able to query for all service boundaries that intersect a 
>given region, or to constrain a query by service URN.

This is a new requirement I have not seen before in the context of LoST
Sync. 

Currently, the document is about exchanging information between two peers. 

>Section 5. Security Considerations
>-- The document delegates security to LoST without ever having 
>said that the XML defined here is carried by LoST. 

It is not carried by LoST but rather it references the <mapping> element
structure defined in LoST. 

> In order 
>for this stuff to be meaningful, there has to be a transport 
>protocol defined.

Done. 

Ciao
Hannes

Date: Wed, 04 Feb 2009 11:53:53 -0600
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>, "ext Hannes Tschofenig" <[email-masked]>, "ECRIT" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda

At 06:07 AM 2/3/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>Recently Roger and Richard provided their document reviews. We discuss
>their reviews.
>Henning or Hannes will be the discussion lead.
>
>* draft-ietf-ecrit-local-emergency-rph-namespace

Hannes

I believe you should disqualify yourself as lead of this discussion 
given that you are the _lone_ voice not supporting this ID, but 
rather - IMO - you need to concentrate your full attention to the 
discussion itself.

James

Date: Wed, 04 Feb 2009 11:58:35 -0600
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>, "ext Hannes Tschofenig" <[email-masked]>, "ECRIT" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Subject: [Ecrit] Fwd: Re: ECRIT Virtual Interim Meeting: Agenda (my mistake)

I appear to have been hasty in my previous message - and not clearly 
viewed the order of who was leading which discussion - i.e., I viewed 
the name(s) above the ID to be the ones leading the discussion when I 
should have viewed the names below to be leading the discussion. I 
apologize Hannes, you have this correct and I read it wrong.

>Date: Wed, 04 Feb 2009 11:53:53 -0600
>To: "Tschofenig, Hannes (NSN - FI/Espoo)" 
><[email-masked]>, "ext Hannes Tschofenig" 
><[email-masked]>, "ECRIT" <[email-masked]>
>From: "James M. Polk" <[email-masked]>
>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda
>
>At 06:07 AM 2/3/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>Recently Roger and Richard provided their document reviews. We discuss
>>their reviews.
>>Henning or Hannes will be the discussion lead.
>>
>>* draft-ietf-ecrit-local-emergency-rph-namespace
>
>Hannes
>
>I believe you should disqualify yourself as lead of this discussion 
>given that you are the _lone_ voice not supporting this ID, but 
>rather - IMO - you need to concentrate your full attention to the 
>discussion itself.
>
>James

Date: Wed, 04 Feb 2009 11:59:34 -0600
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>, "ext Hannes Tschofenig" <[email-masked]>, "ECRIT" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (timing?)

Hannes

This would be considered a full agenda for a f2f meeting. How long do 
you expect this call to last?

James

At 06:07 AM 2/3/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>This is the agenda proposal for the meeting:
>
>* draft-ietf-ecrit-phonebcp and draft-ietf-ecrit-framework
>
>Only if there are substantial comments received during WGLC that require
>a discussion.
>Brian will do the job.
>
>* draft-ietf-ecrit-lost-sync
>
>Recently Roger and Richard provided their document reviews. We discuss
>their reviews.
>Henning or Hannes will be the discussion lead.
>
>* draft-ietf-ecrit-local-emergency-rph-namespace
>
>This document received a lot of feedback. We should start our discussion
>with the where the marking should happen along the e2e chain. James is
>going to lead this discussion.
>
>* draft-barnes-ecrit-rough-loc
>
>Richard will lead us through this document and tell us what the
>necessary steps are to complete it.
>
>* draft-patel-ecrit-sos-parameter
>
>Milan will tell us what the open issues with this document are.
>
>* draft-rosen-ecrit-premature-disconnect-rqmts
>
>Brian will inform us about the recent draft update and we will chat
>whether this version can be picked up as a WG item.
>
>* RFC5031bis and draft-forte-ecrit-lost-extensions
>
>Henning or Andrea will brief us about the plans to update the Service
>URN RFC and how to then deal with the extensions that have been proposed
>to the group.
>
>* draft-wolf-ecrit-lost-servicelistboundary
>
>Karl Heinz wanted to give a presentation about this draft at the last
>IETF meeting but we ran out of time. Let's try it again.
>
>* draft-schulzrinne-ecrit-unauthenticated-access
>
>Finally, we should chat about how we should proceed with the
>unauthenticated emergency calls document.
>
>Ciao
>Hannes
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

From: "Hannes Tschofenig" <[email-masked]>
To: "'James M. Polk'" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Wed, 4 Feb 2009 22:37:07 +0200
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my  mistake)

> James wrote: 
>> you are the _lone_ voice not supporting this ID, 

Listening to the audio recording of past meetings I have to say that I was
not the only persons raising concerns about the document. 
That was probably the reason why you agreed to limit the scope of the
document (which you didn't later do) to get folks to agree to make it a WG
item.

Btw, I not disagreeing with the document as such. I just want to the scope
to change. The usage of RPH within the emergency services network is fine
for me. I may get convinced to start the RPH marking from the the VSP
towards the PSAP. I feel uneasy about the end host doing the marking. I
don't see advantages -- only disadvantages. 

Ciao
Hannes

Date: Wed, 04 Feb 2009 15:41:40 -0500
From: Marc Linsner <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, James Polk <[email-masked]>, "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>, "'ECRIT'" <[email-masked]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my  mistake)

Hannes,

I'm curious. Are you against the RPH in general, or just this namespace?

-Marc-

On 2/4/09 3:37 PM, "Hannes Tschofenig" <[email-masked]> wrote:

>> James wrote: 
>>> you are the _lone_ voice not supporting this ID,
> 
> Listening to the audio recording of past meetings I have to say that I was
> not the only persons raising concerns about the document.
> That was probably the reason why you agreed to limit the scope of the
> document (which you didn't later do) to get folks to agree to make it a WG
> item.
> 
> Btw, I not disagreeing with the document as such. I just want to the scope
> to change. The usage of RPH within the emergency services network is fine
> for me. I may get convinced to start the RPH marking from the the VSP
> towards the PSAP. I feel uneasy about the end host doing the marking. I
> don't see advantages -- only disadvantages.
> 
> Ciao
> Hannes
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

From: "Hannes Tschofenig" <[email-masked]>
To: "'James M. Polk'" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Wed, 4 Feb 2009 22:54:06 +0200
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (timing?)

Hi James, 

I was thinking of 2 hours, see
http://www.ietf.org/mail-archive/web/ecrit/current/msg05849.html
 
Based on the experience from working group meetings I believe that most
items can be covered fairly quickly. 
In case we can come up with some action items during the meeting to move our
documents along then our mission is accomplished. 

Ciao
Hannes

>-----Original Message-----
>From: James M. Polk [mailto:[email-masked]] 
>Sent: 04 February, 2009 20:00
>To: Tschofenig, Hannes (NSN - FI/Espoo); ext Hannes Tschofenig; ECRIT
>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (timing?)
>
>Hannes
>
>This would be considered a full agenda for a f2f meeting. How 
>long do you expect this call to last?
>
>James
>
>At 06:07 AM 2/3/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>This is the agenda proposal for the meeting:
>>
>>* draft-ietf-ecrit-phonebcp and draft-ietf-ecrit-framework
>>
>>Only if there are substantial comments received during WGLC that 
>>require a discussion.
>>Brian will do the job.
>>
>>* draft-ietf-ecrit-lost-sync
>>
>>Recently Roger and Richard provided their document reviews. 
>We discuss 
>>their reviews.
>>Henning or Hannes will be the discussion lead.
>>
>>* draft-ietf-ecrit-local-emergency-rph-namespace
>>
>>This document received a lot of feedback. We should start our 
>>discussion with the where the marking should happen along the e2e 
>>chain. James is going to lead this discussion.
>>
>>* draft-barnes-ecrit-rough-loc
>>
>>Richard will lead us through this document and tell us what the 
>>necessary steps are to complete it.
>>
>>* draft-patel-ecrit-sos-parameter
>>
>>Milan will tell us what the open issues with this document are.
>>
>>* draft-rosen-ecrit-premature-disconnect-rqmts
>>
>>Brian will inform us about the recent draft update and we will chat 
>>whether this version can be picked up as a WG item.
>>
>>* RFC5031bis and draft-forte-ecrit-lost-extensions
>>
>>Henning or Andrea will brief us about the plans to update the Service 
>>URN RFC and how to then deal with the extensions that have been 
>>proposed to the group.
>>
>>* draft-wolf-ecrit-lost-servicelistboundary
>>
>>Karl Heinz wanted to give a presentation about this draft at the last 
>>IETF meeting but we ran out of time. Let's try it again.
>>
>>* draft-schulzrinne-ecrit-unauthenticated-access
>>
>>Finally, we should chat about how we should proceed with the 
>>unauthenticated emergency calls document.
>>
>>Ciao
>>Hannes
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/ecrit
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'Marc Linsner'" <[email-masked]>, "'James Polk'" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Wed, 4 Feb 2009 22:56:46 +0200
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my  mistake)

I only don't want to let the end host todo the marking.   

>-----Original Message-----
>From: Marc Linsner [mailto:[email-masked]] 
>Sent: 04 February, 2009 22:42
>To: Hannes Tschofenig; James Polk; Tschofenig, Hannes (NSN - 
>FI/Espoo); 'ECRIT'
>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake)
>
>Hannes,
>
>I'm curious. Are you against the RPH in general, or just this 
>namespace?
>
>-Marc-
>
>
>On 2/4/09 3:37 PM, "Hannes Tschofenig" 
><[email-masked]> wrote:
>
>>> James wrote: 
>>>> you are the _lone_ voice not supporting this ID,
>> 
>> Listening to the audio recording of past meetings I have to 
>say that I 
>> was not the only persons raising concerns about the document.
>> That was probably the reason why you agreed to limit the 
>scope of the 
>> document (which you didn't later do) to get folks to agree 
>to make it 
>> a WG item.
>> 
>> Btw, I not disagreeing with the document as such. I just want to the 
>> scope to change. The usage of RPH within the emergency services 
>> network is fine for me. I may get convinced to start the RPH marking 
>> from the the VSP towards the PSAP. I feel uneasy about the end host 
>> doing the marking. I don't see advantages -- only disadvantages.
>> 
>> Ciao
>> Hannes
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'ECRIT'" <[email-masked]>
Date: Wed, 4 Feb 2009 23:01:18 +0200
Subject: [Ecrit] ECRIT Virtual Interim Meeting: Conference Bridge

Marc kindly offered his Webex conference bridge for the meeting. 
I have copied the info to the ECRIT Wiki: 
http://trac.tools.ietf.org/wg/ecrit/trac/wiki

Ciao
Hannes

Date: Wed, 04 Feb 2009 15:01:00 -0600
To: "Hannes Tschofenig" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "'ECRIT'" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)

At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> > James wrote:
> >> you are the _lone_ voice not supporting this ID,
>
>Listening to the audio recording of past meetings I have to say that I was
>not the only persons raising concerns about the document.
>That was probably the reason why you agreed to limit the scope of the
>document (which you didn't later do) to get folks to agree to make it a WG
>item.

re-listen to the audio please

Ted's concerns were consistent with most (all?) other concerns -- 
which were based on the premise of whether or not the UAC should be 
trusted to initiate the marking on the INVITE.  The most recent 
version has backed off this to a "can" -- meaning not prohibited 
(i.e., no 2119 text).  I also backed off the text in the SP domain 
part to "can", such that there is no 2119 text mandating or even 
recommending its usage there. I also do not prohibit its use, based 
on local policy.  Keith has come forward with the specific request 
that non-ESInet networks be allowed to mark and pay attention to this 
priority indication -- with IMS as the specific example he wishes to 
have this valid for.

Where there is no disagreement, save for your recent pushback - is in 
the ESInet, which is where Brian has requested it's definition in the 
IETF on behalf of NENA.  He's the i3 WG chair within NENA, and if he 
asks for it, are you going to say you know better than he?

>Btw, I not disagreeing with the document as such. I just want to the scope
>to change. The usage of RPH within the emergency services network is fine
>for me. I may get convinced to start the RPH marking from the the VSP
>towards the PSAP. I feel uneasy about the end host doing the marking.

please read what I wrote above, and then re-read the most recent 
version of the ID. I don't have endpoints that SHOULD or MUST mark 
anything wrt RPH.  I also don't want to prohibit it, because there 
might be cases (that I don't know of) of valid uses under certain 
circumstances.  Figure 1 is very clear that there are 3 networking 
parts to consider

#1 - from the endpoint
#2 - within the VSP
#3 - within the ESInet

the most recent ID version has "can" for #s 1 and 2, and 2119 
language offering those supporting this specification will have RPH 
adherence within #3 (the ESInet).

What other scope changes do you want, because I haven't heard them.

I only heard you claim in email during the last IETF and in the ECRIT 
session that RPH should not be used for priority marking 
requests.  This is something Keith (SIP WG chair) voiced his 
opposition to your views regarding creating a second means for SIP to 
priority mark request "when SIP already has one interoperable way to 
accomplish this... it's call the RP header mechanism".

>I don't see advantages -- only disadvantages.
>
>Ciao
>Hannes

From: "Hannes Tschofenig" <[email-masked]>
To: "'ECRIT'" <[email-masked]>
Date: Wed, 4 Feb 2009 23:49:41 +0200
Subject: [Ecrit] draft-ietf-ecrit-mapping-arch: DISCUSS by Cullen

Cullen recently issued a DISCUSS against draft-ietf-ecrit-mapping-arch, see 
https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-mapping-arch/comment
/90923/
"
[IESG Evaluation DISCUSS] 
When this document was written, LOST only did points for  geo locations  so
the text    For the former, the LoST server performs a point-    in-polygon
operation to find the polygon that contains the query    point.  (More
complicated geometric matching algorithms may be added    in the future.)

Since then LOST was changed to support a wider range of shape. You
need to update this and explain what happens when the location shape
overlaps
two regions. My suggestion would be to say to return both in the overlap
case
or say it is server defined what happens. But one way or another, it seems
like this needs to be addressed. Jon and I would both very much like to have
this addressed Real Soon Now so I would greatly appreciate if this could
land
in the priory pile. I imagine we are only talking about a few sentence that
need to be written.
"

Cullen is right that this issue has to be addressed. 
The current text in the draft has to be changed from
"
   Coverage regions are described by sets of polygons enclosing
   contiguous geographic areas or by descriptors enumerating groups of
   civic locations.  For the former, the LoST server performs a point-
   in-polygon operation to find the polygon that contains the query
   point.  (More complicated geometric matching algorithms may be added
   in the future.)
"

To:
"
   Coverage regions are described by sets of LoST-compatible shapes
   enclosing contiguous geographic areas or by descriptors enumerating
   groups of civic locations.  For the former, the LoST server performs
   the same matching operation as described in Section 12.2 of the LoST
   specification [RFC5222].
"

Ciao
Hannes

From: "Brian Rosen" <[email-masked]>
To: "'James M. Polk'" <[email-masked]>, "'Hannes Tschofenig'" <[email-masked]>, "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" <[email-masked]>,  "'ECRIT'" <[email-masked]>
Date: Wed, 4 Feb 2009 17:03:28 -0500
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)

Hannes

This matches my understanding precisely.  We wish to permit endpoints to
mark. We do not require it, and don't necessarily expect it in many (even
most) cases.  We don't wish to see the document prohibit it.  We all seem to
agree it has value within the Emergency Services IP Networks.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of James M. Polk
> Sent: Wednesday, February 04, 2009 4:01 PM
> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake)
> 
> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> > > James wrote:
> > >> you are the _lone_ voice not supporting this ID,
> >
> >Listening to the audio recording of past meetings I have to say that I
> was
> >not the only persons raising concerns about the document.
> >That was probably the reason why you agreed to limit the scope of the
> >document (which you didn't later do) to get folks to agree to make it
> a WG
> >item.
> 
> re-listen to the audio please
> 
> Ted's concerns were consistent with most (all?) other concerns --
> which were based on the premise of whether or not the UAC should be
> trusted to initiate the marking on the INVITE.  The most recent
> version has backed off this to a "can" -- meaning not prohibited
> (i.e., no 2119 text).  I also backed off the text in the SP domain
> part to "can", such that there is no 2119 text mandating or even
> recommending its usage there. I also do not prohibit its use, based
> on local policy.  Keith has come forward with the specific request
> that non-ESInet networks be allowed to mark and pay attention to this
> priority indication -- with IMS as the specific example he wishes to
> have this valid for.
> 
> Where there is no disagreement, save for your recent pushback - is in
> the ESInet, which is where Brian has requested it's definition in the
> IETF on behalf of NENA.  He's the i3 WG chair within NENA, and if he
> asks for it, are you going to say you know better than he?
> 
> 
> >Btw, I not disagreeing with the document as such. I just want to the
> scope
> >to change. The usage of RPH within the emergency services network is
> fine
> >for me. I may get convinced to start the RPH marking from the the VSP
> >towards the PSAP. I feel uneasy about the end host doing the marking.
> 
> please read what I wrote above, and then re-read the most recent
> version of the ID. I don't have endpoints that SHOULD or MUST mark
> anything wrt RPH.  I also don't want to prohibit it, because there
> might be cases (that I don't know of) of valid uses under certain
> circumstances.  Figure 1 is very clear that there are 3 networking
> parts to consider
> 
> #1 - from the endpoint
> #2 - within the VSP
> #3 - within the ESInet
> 
> the most recent ID version has "can" for #s 1 and 2, and 2119
> language offering those supporting this specification will have RPH
> adherence within #3 (the ESInet).
> 
> What other scope changes do you want, because I haven't heard them.
> 
> I only heard you claim in email during the last IETF and in the ECRIT
> session that RPH should not be used for priority marking
> requests.  This is something Keith (SIP WG chair) voiced his
> opposition to your views regarding creating a second means for SIP to
> priority mark request "when SIP already has one interoperable way to
> accomplish this... it's call the RP header mechanism".
> 
> >I don't see advantages -- only disadvantages.
> >
> >Ciao
> >Hannes
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

From: "Hannes Tschofenig" <[email-masked]>
To: "'Brian Rosen'" <[email-masked]>, "'James M. Polk'" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Thu, 5 Feb 2009 00:09:16 +0200
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)

I don't even see the value in permitting the endpoint todo the RPH marking. 
In addition to the security concerns there is also the problem that there
are more options to implement without an additional value.  

>-----Original Message-----
>From: Brian Rosen [mailto:[email-masked]] 
>Sent: 05 February, 2009 00:03
>To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, Hannes 
>(NSN - FI/Espoo)'; 'ECRIT'
>Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake)
>
>Hannes
>
>This matches my understanding precisely.  We wish to permit 
>endpoints to mark. We do not require it, and don't necessarily 
>expect it in many (even
>most) cases.  We don't wish to see the document prohibit it.  
>We all seem to agree it has value within the Emergency 
>Services IP Networks.
>
>Brian
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>> Of James M. Polk
>> Sent: Wednesday, February 04, 2009 4:01 PM
>> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my 
>> mistake)
>> 
>> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
>> > > James wrote:
>> > >> you are the _lone_ voice not supporting this ID,
>> >
>> >Listening to the audio recording of past meetings I have to 
>say that 
>> >I
>> was
>> >not the only persons raising concerns about the document.
>> >That was probably the reason why you agreed to limit the 
>scope of the 
>> >document (which you didn't later do) to get folks to agree 
>to make it
>> a WG
>> >item.
>> 
>> re-listen to the audio please
>> 
>> Ted's concerns were consistent with most (all?) other concerns -- 
>> which were based on the premise of whether or not the UAC should be 
>> trusted to initiate the marking on the INVITE.  The most recent 
>> version has backed off this to a "can" -- meaning not prohibited 
>> (i.e., no 2119 text).  I also backed off the text in the SP domain 
>> part to "can", such that there is no 2119 text mandating or even 
>> recommending its usage there. I also do not prohibit its 
>use, based on 
>> local policy.  Keith has come forward with the specific request that 
>> non-ESInet networks be allowed to mark and pay attention to this 
>> priority indication -- with IMS as the specific example he wishes to 
>> have this valid for.
>> 
>> Where there is no disagreement, save for your recent 
>pushback - is in 
>> the ESInet, which is where Brian has requested it's 
>definition in the 
>> IETF on behalf of NENA.  He's the i3 WG chair within NENA, and if he 
>> asks for it, are you going to say you know better than he?
>> 
>> 
>> >Btw, I not disagreeing with the document as such. I just want to the
>> scope
>> >to change. The usage of RPH within the emergency services network is
>> fine
>> >for me. I may get convinced to start the RPH marking from 
>the the VSP 
>> >towards the PSAP. I feel uneasy about the end host doing 
>the marking.
>> 
>> please read what I wrote above, and then re-read the most recent 
>> version of the ID. I don't have endpoints that SHOULD or MUST mark 
>> anything wrt RPH.  I also don't want to prohibit it, because there 
>> might be cases (that I don't know of) of valid uses under certain 
>> circumstances.  Figure 1 is very clear that there are 3 networking 
>> parts to consider
>> 
>> #1 - from the endpoint
>> #2 - within the VSP
>> #3 - within the ESInet
>> 
>> the most recent ID version has "can" for #s 1 and 2, and 
>2119 language 
>> offering those supporting this specification will have RPH adherence 
>> within #3 (the ESInet).
>> 
>> What other scope changes do you want, because I haven't heard them.
>> 
>> I only heard you claim in email during the last IETF and in 
>the ECRIT 
>> session that RPH should not be used for priority marking requests.  
>> This is something Keith (SIP WG chair) voiced his opposition to your 
>> views regarding creating a second means for SIP to priority mark 
>> request "when SIP already has one interoperable way to accomplish 
>> this... it's call the RP header mechanism".
>> 
>> >I don't see advantages -- only disadvantages.
>> >
>> >Ciao
>> >Hannes
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>

Date: Wed, 04 Feb 2009 17:10:04 -0500
From: Marc Linsner <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, James Polk <[email-masked]>, "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>, "'ECRIT'" <[email-masked]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my  mistake)

Hannes,

What if there is no proxy?

-Marc-

On 2/4/09 3:56 PM, "Hannes Tschofenig" <[email-masked]> wrote:

> I only don't want to let the end host todo the marking.
> 
>> -----Original Message-----
>> From: Marc Linsner [mailto:[email-masked]]
>> Sent: 04 February, 2009 22:42
>> To: Hannes Tschofenig; James Polk; Tschofenig, Hannes (NSN -
>> FI/Espoo); 'ECRIT'
>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake)
>> 
>> Hannes,
>> 
>> I'm curious. Are you against the RPH in general, or just this
>> namespace?
>> 
>> -Marc-
>> 
>> 
>> On 2/4/09 3:37 PM, "Hannes Tschofenig"
>> <[email-masked]> wrote:
>> 
>>>> James wrote: 
>>>>> you are the _lone_ voice not supporting this ID,
>>> 
>>> Listening to the audio recording of past meetings I have to
>> say that I 
>>> was not the only persons raising concerns about the document.
>>> That was probably the reason why you agreed to limit the
>> scope of the 
>>> document (which you didn't later do) to get folks to agree
>> to make it 
>>> a WG item.
>>> 
>>> Btw, I not disagreeing with the document as such. I just want to the
>>> scope to change. The usage of RPH within the emergency services
>>> network is fine for me. I may get convinced to start the RPH marking
>>> from the the VSP towards the PSAP. I feel uneasy about the end host
>>> doing the marking. I don't see advantages -- only disadvantages.
>>> 
>>> Ciao
>>> Hannes
>>> 
>>> _______________________________________________
>>> Ecrit mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
>> 
> 

From: "Brian Rosen" <[email-masked]>
To: "'Hannes Tschofenig'" <[email-masked]>, "'James M. Polk'" <[email-masked]>, "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" <[email-masked]>,  "'ECRIT'" <[email-masked]>
Date: Wed, 4 Feb 2009 17:18:51 -0500
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)

The value is that in some networks where priority for emergency calls is
appropriate, and appropriate policing of marking is implemented, emergency
calls will receive resource priority.

Not all networks would need policing.  Some will.  Policing could be to
Route header/R-URI content, but other criteria are possible.

Not all networks will need resource priority for emergency calls.  Fine,
ignore this marking/namespace.

Brian
> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, February 04, 2009 5:09 PM
> To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN -
> FI/Espoo); 'ECRIT'
> Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake)
> 
> I don't even see the value in permitting the endpoint todo the RPH
> marking.
> In addition to the security concerns there is also the problem that
> there
> are more options to implement without an additional value.
> 
> >-----Original Message-----
> >From: Brian Rosen [mailto:[email-masked]]
> >Sent: 05 February, 2009 00:03
> >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, Hannes
> >(NSN - FI/Espoo)'; 'ECRIT'
> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> mistake)
> >
> >Hannes
> >
> >This matches my understanding precisely.  We wish to permit
> >endpoints to mark. We do not require it, and don't necessarily
> >expect it in many (even
> >most) cases.  We don't wish to see the document prohibit it.
> >We all seem to agree it has value within the Emergency
> >Services IP Networks.
> >
> >Brian
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]]
> >On Behalf
> >> Of James M. Polk
> >> Sent: Wednesday, February 04, 2009 4:01 PM
> >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> mistake)
> >>
> >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> >> > > James wrote:
> >> > >> you are the _lone_ voice not supporting this ID,
> >> >
> >> >Listening to the audio recording of past meetings I have to
> >say that
> >> >I
> >> was
> >> >not the only persons raising concerns about the document.
> >> >That was probably the reason why you agreed to limit the
> >scope of the
> >> >document (which you didn't later do) to get folks to agree
> >to make it
> >> a WG
> >> >item.
> >>
> >> re-listen to the audio please
> >>
> >> Ted's concerns were consistent with most (all?) other concerns --
> >> which were based on the premise of whether or not the UAC should be
> >> trusted to initiate the marking on the INVITE.  The most recent
> >> version has backed off this to a "can" -- meaning not prohibited
> >> (i.e., no 2119 text).  I also backed off the text in the SP domain
> >> part to "can", such that there is no 2119 text mandating or even
> >> recommending its usage there. I also do not prohibit its
> >use, based on
> >> local policy.  Keith has come forward with the specific request that
> >> non-ESInet networks be allowed to mark and pay attention to this
> >> priority indication -- with IMS as the specific example he wishes to
> >> have this valid for.
> >>
> >> Where there is no disagreement, save for your recent
> >pushback - is in
> >> the ESInet, which is where Brian has requested it's
> >definition in the
> >> IETF on behalf of NENA.  He's the i3 WG chair within NENA, and if he
> >> asks for it, are you going to say you know better than he?
> >>
> >>
> >> >Btw, I not disagreeing with the document as such. I just want to
> the
> >> scope
> >> >to change. The usage of RPH within the emergency services network
> is
> >> fine
> >> >for me. I may get convinced to start the RPH marking from
> >the the VSP
> >> >towards the PSAP. I feel uneasy about the end host doing
> >the marking.
> >>
> >> please read what I wrote above, and then re-read the most recent
> >> version of the ID. I don't have endpoints that SHOULD or MUST mark
> >> anything wrt RPH.  I also don't want to prohibit it, because there
> >> might be cases (that I don't know of) of valid uses under certain
> >> circumstances.  Figure 1 is very clear that there are 3 networking
> >> parts to consider
> >>
> >> #1 - from the endpoint
> >> #2 - within the VSP
> >> #3 - within the ESInet
> >>
> >> the most recent ID version has "can" for #s 1 and 2, and
> >2119 language
> >> offering those supporting this specification will have RPH adherence
> >> within #3 (the ESInet).
> >>
> >> What other scope changes do you want, because I haven't heard them.
> >>
> >> I only heard you claim in email during the last IETF and in
> >the ECRIT
> >> session that RPH should not be used for priority marking requests.
> >> This is something Keith (SIP WG chair) voiced his opposition to your
> >> views regarding creating a second means for SIP to priority mark
> >> request "when SIP already has one interoperable way to accomplish
> >> this... it's call the RP header mechanism".
> >>
> >> >I don't see advantages -- only disadvantages.
> >> >
> >> >Ciao
> >> >Hannes
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >

To: "Hannes Tschofenig" <[email-masked]>
From: Janet P Gunn <[email-masked]>
Date: Wed, 4 Feb 2009 17:37:17 -0500
Cc: [email-masked], "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)

This is a multipart message in MIME format.
--=_alternative 007C40DC85257553_=
Content-Type: text/plain; charset="US-ASCII"

If you do not permit the endpoint to mark with RPH, then it is very 
difficult to give the INVITE any kind of priority on the first "hop".

In each case, this needs to be balanced against the (quite significant) 
issues with letting the endpoint mark with RPH.  But it SHOULD NOT be 
prohibited.

Janet

[email-masked] wrote on 02/04/2009 05:09:16 PM:

> I don't even see the value in permitting the endpoint todo the RPH 
marking. 
> In addition to the security concerns there is also the problem that 
there
> are more options to implement without an additional value. 
> 
> >-----Original Message-----
> >From: Brian Rosen [mailto:[email-masked]] 
> >Sent: 05 February, 2009 00:03
> >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, Hannes 
> >(NSN - FI/Espoo)'; 'ECRIT'
> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake)
> >
> >Hannes
> >
> >This matches my understanding precisely.  We wish to permit 
> >endpoints to mark. We do not require it, and don't necessarily 
> >expect it in many (even
> >most) cases.  We don't wish to see the document prohibit it. 
> >We all seem to agree it has value within the Emergency 
> >Services IP Networks.
> >
> >Brian
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] 
> >On Behalf 
> >> Of James M. Polk
> >> Sent: Wednesday, February 04, 2009 4:01 PM
> >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my 
> >> mistake)
> >> 
> >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> >> > > James wrote:
> >> > >> you are the _lone_ voice not supporting this ID,
> >> >
> >> >Listening to the audio recording of past meetings I have to 
> >say that 
> >> >I
> >> was
> >> >not the only persons raising concerns about the document.
> >> >That was probably the reason why you agreed to limit the 
> >scope of the 
> >> >document (which you didn't later do) to get folks to agree 
> >to make it
> >> a WG
> >> >item.
> >> 
> >> re-listen to the audio please
> >> 
> >> Ted's concerns were consistent with most (all?) other concerns -- 
> >> which were based on the premise of whether or not the UAC should be 
> >> trusted to initiate the marking on the INVITE.  The most recent 
> >> version has backed off this to a "can" -- meaning not prohibited 
> >> (i.e., no 2119 text).  I also backed off the text in the SP domain 
> >> part to "can", such that there is no 2119 text mandating or even 
> >> recommending its usage there. I also do not prohibit its 
> >use, based on 
> >> local policy.  Keith has come forward with the specific request that 
> >> non-ESInet networks be allowed to mark and pay attention to this 
> >> priority indication -- with IMS as the specific example he wishes to 
> >> have this valid for.
> >> 
> >> Where there is no disagreement, save for your recent 
> >pushback - is in 
> >> the ESInet, which is where Brian has requested it's 
> >definition in the 
> >> IETF on behalf of NENA.  He's the i3 WG chair within NENA, and if he 
> >> asks for it, are you going to say you know better than he?
> >> 
> >> 
> >> >Btw, I not disagreeing with the document as such. I just want to the
> >> scope
> >> >to change. The usage of RPH within the emergency services network is
> >> fine
> >> >for me. I may get convinced to start the RPH marking from 
> >the the VSP 
> >> >towards the PSAP. I feel uneasy about the end host doing 
> >the marking.
> >> 
> >> please read what I wrote above, and then re-read the most recent 
> >> version of the ID. I don't have endpoints that SHOULD or MUST mark 
> >> anything wrt RPH.  I also don't want to prohibit it, because there 
> >> might be cases (that I don't know of) of valid uses under certain 
> >> circumstances.  Figure 1 is very clear that there are 3 networking 
> >> parts to consider
> >> 
> >> #1 - from the endpoint
> >> #2 - within the VSP
> >> #3 - within the ESInet
> >> 
> >> the most recent ID version has "can" for #s 1 and 2, and 
> >2119 language 
> >> offering those supporting this specification will have RPH adherence 
> >> within #3 (the ESInet).
> >> 
> >> What other scope changes do you want, because I haven't heard them.
> >> 
> >> I only heard you claim in email during the last IETF and in 
> >the ECRIT 
> >> session that RPH should not be used for priority marking requests. 
> >> This is something Keith (SIP WG chair) voiced his opposition to your 
> >> views regarding creating a second means for SIP to priority mark 
> >> request "when SIP already has one interoperable way to accomplish 
> >> this... it's call the RP header mechanism".
> >> 
> >> >I don't see advantages -- only disadvantages.
> >> >
> >> >Ciao
> >> >Hannes
> >> 
> >> _______________________________________________
> >> Ecrit mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

--=_alternative 007C40DC85257553_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif"><br>
If you do not permit the endpoint to mark with RPH, then it is very difficult
to give the INVITE any kind of priority on the first &quot;hop&quot;.</font>
<br>
<br><font size=2 face="sans-serif">In each case, this needs to be balanced
against the (quite significant) issues with letting the endpoint mark with
RPH. &nbsp;But it SHOULD NOT be prohibited.</font>
<br>
<br><font size=2 face="sans-serif">Janet</font>
<br>
<br><font size=2><tt>[email-masked] wrote on 02/04/2009 05:09:16
PM:<br>
<br>
&gt; I don't even see the value in permitting the endpoint todo the RPH
marking. <br>
&gt; In addition to the security concerns there is also the problem that
there<br>
&gt; are more options to implement without an additional value. &nbsp;<br>
&gt; <br>
&gt; &gt;-----Original Message-----<br>
&gt; &gt;From: Brian Rosen [mailto:[email-masked]] <br>
&gt; &gt;Sent: 05 February, 2009 00:03<br>
&gt; &gt;To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, Hannes
<br>
&gt; &gt;(NSN - FI/Espoo)'; 'ECRIT'<br>
&gt; &gt;Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
mistake)<br>
&gt; &gt;<br>
&gt; &gt;Hannes<br>
&gt; &gt;<br>
&gt; &gt;This matches my understanding precisely. &nbsp;We wish to permit
<br>
&gt; &gt;endpoints to mark. We do not require it, and don't necessarily
<br>
&gt; &gt;expect it in many (even<br>
&gt; &gt;most) cases. &nbsp;We don't wish to see the document prohibit
it. &nbsp;<br>
&gt; &gt;We all seem to agree it has value within the Emergency <br>
&gt; &gt;Services IP Networks.<br>
&gt; &gt;<br>
&gt; &gt;Brian<br>
&gt; &gt;<br>
&gt; &gt;&gt; -----Original Message-----<br>
&gt; &gt;&gt; From: [email-masked] [mailto:[email-masked]]
<br>
&gt; &gt;On Behalf <br>
&gt; &gt;&gt; Of James M. Polk<br>
&gt; &gt;&gt; Sent: Wednesday, February 04, 2009 4:01 PM<br>
&gt; &gt;&gt; To: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo);
'ECRIT'<br>
&gt; &gt;&gt; Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda
(my <br>
&gt; &gt;&gt; mistake)<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:<br>
&gt; &gt;&gt; &gt; &gt; James wrote:<br>
&gt; &gt;&gt; &gt; &gt;&gt; you are the _lone_ voice not supporting this
ID,<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt;Listening to the audio recording of past meetings I have
to <br>
&gt; &gt;say that <br>
&gt; &gt;&gt; &gt;I<br>
&gt; &gt;&gt; was<br>
&gt; &gt;&gt; &gt;not the only persons raising concerns about the document.<br>
&gt; &gt;&gt; &gt;That was probably the reason why you agreed to limit
the <br>
&gt; &gt;scope of the <br>
&gt; &gt;&gt; &gt;document (which you didn't later do) to get folks to
agree <br>
&gt; &gt;to make it<br>
&gt; &gt;&gt; a WG<br>
&gt; &gt;&gt; &gt;item.<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; re-listen to the audio please<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; Ted's concerns were consistent with most (all?) other concerns
-- <br>
&gt; &gt;&gt; which were based on the premise of whether or not the UAC
should be <br>
&gt; &gt;&gt; trusted to initiate the marking on the INVITE. &nbsp;The
most recent <br>
&gt; &gt;&gt; version has backed off this to a &quot;can&quot; -- meaning
not prohibited <br>
&gt; &gt;&gt; (i.e., no 2119 text). &nbsp;I also backed off the text in
the SP domain <br>
&gt; &gt;&gt; part to &quot;can&quot;, such that there is no 2119 text
mandating or even <br>
&gt; &gt;&gt; recommending its usage there. I also do not prohibit its
<br>
&gt; &gt;use, based on <br>
&gt; &gt;&gt; local policy. &nbsp;Keith has come forward with the specific
request that <br>
&gt; &gt;&gt; non-ESInet networks be allowed to mark and pay attention
to this <br>
&gt; &gt;&gt; priority indication -- with IMS as the specific example he
wishes to <br>
&gt; &gt;&gt; have this valid for.<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; Where there is no disagreement, save for your recent <br>
&gt; &gt;pushback - is in <br>
&gt; &gt;&gt; the ESInet, which is where Brian has requested it's <br>
&gt; &gt;definition in the <br>
&gt; &gt;&gt; IETF on behalf of NENA. &nbsp;He's the i3 WG chair within
NENA, and if he <br>
&gt; &gt;&gt; asks for it, are you going to say you know better than he?<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; &gt;Btw, I not disagreeing with the document as such. I just
want to the<br>
&gt; &gt;&gt; scope<br>
&gt; &gt;&gt; &gt;to change. The usage of RPH within the emergency services
network is<br>
&gt; &gt;&gt; fine<br>
&gt; &gt;&gt; &gt;for me. I may get convinced to start the RPH marking
from <br>
&gt; &gt;the the VSP <br>
&gt; &gt;&gt; &gt;towards the PSAP. I feel uneasy about the end host doing
<br>
&gt; &gt;the marking.<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; please read what I wrote above, and then re-read the most
recent <br>
&gt; &gt;&gt; version of the ID. I don't have endpoints that SHOULD or
MUST mark <br>
&gt; &gt;&gt; anything wrt RPH. &nbsp;I also don't want to prohibit it,
because there <br>
&gt; &gt;&gt; might be cases (that I don't know of) of valid uses under
certain <br>
&gt; &gt;&gt; circumstances. &nbsp;Figure 1 is very clear that there are
3 networking <br>
&gt; &gt;&gt; parts to consider<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; #1 - from the endpoint<br>
&gt; &gt;&gt; #2 - within the VSP<br>
&gt; &gt;&gt; #3 - within the ESInet<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; the most recent ID version has &quot;can&quot; for #s 1 and
2, and <br>
&gt; &gt;2119 language <br>
&gt; &gt;&gt; offering those supporting this specification will have RPH
adherence <br>
&gt; &gt;&gt; within #3 (the ESInet).<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; What other scope changes do you want, because I haven't heard
them.<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; I only heard you claim in email during the last IETF and
in <br>
&gt; &gt;the ECRIT <br>
&gt; &gt;&gt; session that RPH should not be used for priority marking
requests. &nbsp;<br>
&gt; &gt;&gt; This is something Keith (SIP WG chair) voiced his opposition
to your <br>
&gt; &gt;&gt; views regarding creating a second means for SIP to priority
mark <br>
&gt; &gt;&gt; request &quot;when SIP already has one interoperable way
to accomplish <br>
&gt; &gt;&gt; this... it's call the RP header mechanism&quot;.<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; &gt;I don't see advantages -- only disadvantages.<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt;Ciao<br>
&gt; &gt;&gt; &gt;Hannes<br>
&gt; &gt;&gt; <br>
&gt; &gt;&gt; _______________________________________________<br>
&gt; &gt;&gt; Ecrit mailing list<br>
&gt; &gt;&gt; [email-masked]<br>
&gt; &gt;&gt; https://www.ietf.org/mailman/listinfo/ecrit<br>
&gt; &gt;<br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; Ecrit mailing list<br>
&gt; [email-masked]<br>
&gt; https://www.ietf.org/mailman/listinfo/ecrit<br>
</tt></font>
--=_alternative 007C40DC85257553_=--

From: "Edge, Stephen" <[email-masked]>
To: "'ECRIT'" <[email-masked]>
Date: Wed, 4 Feb 2009 23:49:30 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: [Ecrit] Comments on Framework Draft

All
=A0
draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative descri=
ption of how terminals and networks should support emergency calls made ove=
r IP capable facilities to IP capable PSAPs. It appears intended to cover a=
ll types of access network - including fixed line, WiFi and cellular (e.g. =
examples involving each can be found throughout the draft).
=A0
When we evaluated this with respect to support of wireless cellular access =
and WiFi access associated with a cellular operator (e.g. WLAN or Femto cel=
ls integrated into a cellular network), we found that certain portions of t=
he draft exhibited one or more of the following characteristics:
=A0
=A0=A0=A0 (A) Inconsistent with already standardized wireless solutions
=A0
=A0=A0=A0 (B) Inconsistent with essential wireless requirements and convent=
ions
=A0
=A0=A0=A0 (C) Already part of wireless standards or potentially part of fut=
ure standards
=A0
(A) refers to all portions of the draft framework that differ from the requ=
irements and procedures currently standardized for wireless emergency acces=
s by 3GPP, 3GPP2 and OMA. This is a plain difference of solution and could =
be resolved through support of both solutions by terminals (with each solut=
ion being used according to the type of access network and VSP) or could be=
 resolved by supporting only one solution and accessing only the types of n=
etwork supporting that solution. To acknowledge this category, the framewor=
k document could reference the applicable wireless standards and point out =
that these are valid alternatives for wireless cellular based access.
=A0
(B) refers to portions of the draft that would be unsuitable for wireless n=
etworks even if no alternative solution existed together with other portion=
s missing from the draft that would be needed to fully support wireless net=
works. Examples of the former include: (a) emphasis on endpoint derivation =
of location, performance of Lost query and receipt of local dial strings; (=
b) restriction of LCPs to protocols that require terminal initiation (not a=
llowing for network initiation as far as we can tell) and that include two =
LCPs (DHCP and LLDP) that are not applicable to (not defined for) cellular =
access; and (c) the requirement that a terminal or at least a LIS will upda=
te the PSAP whenever location changes. (a) is impractical due to network an=
d terminal loading consequences and failure to support non-IP capable PSAPs=
; (b) makes location verification and updated location provision to PSAPs d=
ifficult or impossible; while (c) is also incompatible with support of exis=
ting non-IP capable PSAPs besides increasing terminal load and possibly int=
erfering with optimum maintenance of the RF connection (e.g. if a terminal =
has to tune away from the serving base station or WLAN periodically to make=
 location measurements). Examples of the latter include (d) absence of supp=
ort for access to non-IP capable PSAPs as already mentioned (e.g. to suppor=
t E911 phase 2 in the US); (e) no support for handover from the IP to the c=
ircuit domain when a terminal loses (e.g. moves out of) RF coverage in the =
IP domain; and (f) no allowance for limited access modes wherein a terminal=
 may access a network only to place an emergency call with ensuing restrict=
ions on (for example) location acquisition, PSAP callback and caller verifi=
cation and identification to the PSAP. To resolve this category either sign=
ificant changes to the framework document could be made or a disclaimer/app=
licability statement could be added stating that support of cellular wirele=
ss networks and their associated WLAN and Femto access points is not covere=
d.
=A0
Category (C) comprises concepts and capabilities in the draft that are eith=
er already part of the standardized solution for wireless networks or that =
might be added at a later time. Examples of the former include LoST, SIP lo=
cation conveyance, general use of SIP, location for routing versus for disp=
atch, cellular positioning methods. Examples of the latter include use of l=
ocation references and dereferencing and possible interworking between the =
current wireless network solutions (in 3GPP, 3GPP2 and OMA) and the solutio=
n described in this draft. The presence of this category could be acknowled=
ged by following the disclaimer for (B) with a statement that certain porti=
ons of the solution are expected to be incorporated into wireless networks =
now and/or in the future.
=A0
We hope that these comments will be seen to be a useful addition to this re=
view in the sense of enabling a more precise scoping for the framework docu=
ment and we are willing to assist in providing wording for any disclaimer/a=
pplicability statement that the Ecrit working group may now deem fit to inc=
lude.
=A0
Kind Regards
=A0
Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm 3GPP=
2 TSG-X and TSG-C participant)

PS  this being sent on 2/4/09 at 11:50pm PST

From: "Edge, Stephen" <[email-masked]>
To: "'ECRIT'" <[email-masked]>
Date: Thu, 5 Feb 2009 00:11:19 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: [Ecrit] Comments on BCP Draft

All

draft-ietf-ecrit-phonebcp-07 is a more precise description and set of requi=
rements concerning how terminals and networks should support emergency call=
s made over IP capable facilities to IP capable PSAPs. As for the framework=
 draft, it appears intended to cover all types of access network - includin=
g fixed line, WiFi and cellular (implicit or explicit references to which c=
an be found throughout the draft).

When we evaluated this with respect to support of wireless cellular access =
and WiFi access associated with a cellular operator (e.g. WLAN or Femto cel=
ls integrated into a cellular network), we found that many requirements exh=
ibited one or more of the following characteristics:

    (A) Inconsistent with already standardized wireless solutions

    (B) Inconsistent with essential wireless requirements and conventions

    (C) Already part of wireless standards or potentially part of future st=
andards

(A) refers to all requirements (and portions of requirements) that differ f=
rom the requirements and procedures currently standardized for wireless eme=
rgency access by 3GPP, 3GPP2 and OMA. This is a plain difference of solutio=
n and could be resolved through support of both solutions by terminals (wit=
h each solution being used according to the type of access network and VSP)=
 or could be resolved by supporting only one solution and accessing only th=
e types of network supporting that solution. To acknowledge this category, =
the BCP document could reference the applicable wireless standards and poin=
t out that these are valid alternatives for wireless cellular based access.

(B) refers to requirements (and portions of requirements) that would be uns=
uitable for wireless networks even if no alternative solution existed toget=
her with other requirements missing from the BCP that would be needed to fu=
lly support wireless networks. To resolve this category either significant =
changes to the current draft could be made or a disclaimer/applicability st=
atement could be added stating that support of cellular wireless networks a=
nd their associated WLAN and Femto access points is not covered.

(C) comprises requirements that are either already part of the standardized=
 solution for wireless networks or that might be included at a later time. =
In fact there are a large number of requirements and portions of requiremen=
ts in this category (far more than listed below) that demonstrate a signifi=
cant overlap between the BCP and current wireless standards. The presence o=
f this category could be acknowledged by following the disclaimer for (B) w=
ith a statement that certain portions of the solution are expected to be in=
corporated into wireless networks now and/or in the future.

A partial list of the requirements corresponding to each category above is =
as follows. Note that inclusion in (B) automatically implies inclusion in (=
A).

	(A)	ED-5, ED-7, ED-12, AN-7/INT-6, AN-11, ED-18, ED-20, ED-22, ED-24, ED-2=
5, ED-28, ED-36, ED-37, ED-43, ED-48, ED-49, ED-50, ED-51, SP-25, ED-52, SP=
-34 (portions only),=20

	(B)	ED-15, AN-9, ED-21, AN-12, ED-31, ED-35, ED-38, SP-18, SP-19, ED-53, E=
D-54, ED-55, ED-56, ED-66/SP-35, SP-36

	(C)	ED-42/SP-21, SP-26 (and many others)

We hope that these comments will be seen to be a useful addition to this re=
view in the sense of enabling a more precise scoping for the BCP document a=
nd we are willing to assist in establishing wording for any disclaimer/appl=
icability statement that the Ecrit working group may deem fit to include.

Kind Regards

Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm 3GPP=
2 TSG-X and TSG-C participant)

PS  this is being sent on 2/5/09 at 00:10am PST (since an Outlook crash at =
the precise instant the Send button was hit 15 minutes ago prevented compli=
ance with the 2/4/09 deadline)

From: "Hannes Tschofenig" <[email-masked]>
To: "'Edge, Stephen'" <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Thu, 5 Feb 2009 11:18:27 +0200
Subject: Re: [Ecrit] Comments on Framework Draft

Hi Stephen,=20

Thanks for your review. A few minor comments.=20

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]=20
>On Behalf Of Edge, Stephen
>Sent: 05 February, 2009 09:50
>To: 'ECRIT'
>Subject: [Ecrit] Comments on Framework Draft
>
>All
>=A0
>draft-ietf-ecrit-framework-07 is (as we see it) a mostly=20
>informative description of how terminals and networks should=20
>support emergency calls made over IP capable facilities to IP=20
>capable PSAPs. It appears intended to cover all types of=20
>access network - including fixed line, WiFi and cellular (e.g.=20
>examples involving each can be found throughout the draft).

Correct. The framework document is the informative description where=20
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.txt
provides the normative part.=20

We thought that this would make it easy for the reader to follow the =
entire
story best.=20

>=A0
>When we evaluated this with respect to support of wireless=20
>cellular access and WiFi access associated with a cellular=20
>operator (e.g. WLAN or Femto cells integrated into a cellular=20
>network), we found that certain portions of the draft=20
>exhibited one or more of the following characteristics:
>=A0
>=A0=A0=A0 (A) Inconsistent with already standardized wireless solutions
>=A0
>=A0=A0=A0 (B) Inconsistent with essential wireless requirements and=20
>conventions
>=A0
>=A0=A0=A0 (C) Already part of wireless standards or potentially part=20
>of future standards
>=A0
>(A) refers to all portions of the draft framework that differ=20
>from the requirements and procedures currently standardized=20
>for wireless emergency access by 3GPP, 3GPP2 and OMA. This is=20
>a plain difference of solution and could be resolved through=20
>support of both solutions by terminals (with each solution=20
>being used according to the type of access network and VSP) or=20
>could be resolved by supporting only one solution and=20
>accessing only the types of network supporting that solution.=20
>To acknowledge this category, the framework document could=20
>reference the applicable wireless standards and point out that=20
>these are valid alternatives for wireless cellular based access.

You know that we have tried hard over the past few years to harmonize =
the
work done by different SDOs, including 3GPP. You were involved in some =
of
these activities.=20

For some reason, various companies did not like such an alignment and =
hence
we are left with the situation that IMS emergency calling and emergency
calling for everything else works differently.=20

This is unfortunate. Your company was always a big fan of developing a
harmonized solution, right?=20

I doubt that the situation is improved by summarizing other =
standardization
efforts in this document nor by describing the content of this document =
in
3GPP, 3GPP2 or OMA documents.=20

>(B) refers to portions of the draft that would be unsuitable=20
>for wireless networks even if no alternative solution existed=20
>together with other portions missing from the draft that would=20
>be needed to fully support wireless networks.

Please note that we make a differentiation between wireless and =
cellular. I
guess you refer to cellular.=20

 Examples of the=20
>former include: (a) emphasis on endpoint derivation of=20
>location, performance of Lost query and receipt of local dial=20
>strings;

Please note that we are talking about location for 2 different purposes
here:=20
* Location for routing=20
* Location for dispatch

It is true that the document puts a focus on the end point obtaining
location (at least for routing). There is, however, a story in there for =
the
case where the end point does not have access to location at all.=20

Having access to local dial strings at the end point is a very useful =
thing,
if you think about it.=20

Regarding LoST: Please note that LoST can also be executed by the VoIP
provider when routing is required.=20

>(b) restriction of LCPs to protocols that require=20
>terminal initiation (not allowing for network initiation as=20
>far as we can tell) and that include two LCPs (DHCP and LLDP)=20
>that are not applicable to (not defined for) cellular access;=20

These two LCPs are only required for devices that can also be used in a
fixed / wireless (but not cellular) environment. In environments where =
the
end host is expected to only ever use a cellular system these two LCPs =
need
not to be implemented.=20

Network initiation has never found huge excitement within the members of =
the
GEOPRIV group. I don't see this is a limitation, to be honest.=20

>and (c) the requirement that a terminal or at least a LIS will=20
>update the PSAP whenever location changes.

I guess the items below refer to the dynamic location change.

 (a) is impractical=20
>due to network and terminal loading consequences

I guess you see it as more dramatic than it is. The LIS and the PSAP can
control the rate of information disclosure, see
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-03.txt=
.=20

Specifying at what rate the terminal would send up-to-date information =
is
policy and implementation dependent. =20

 and failure=20
>to support non-IP capable PSAPs;

The IETF ECRIT solution is an IP-based solution and hence the Internet =
ends
where the last IP node is located.=20
For interworking with non-IP capable PSAPs please take a look at the =
NENA
i2/i2.5 work, which is the most advanced of its kind.=20

 (b) makes location=20
>verification and updated location provision to PSAPs difficult=20
>or impossible;

Could you elaborate a bit? Not sure I understood the "verification" and =
the
"updated location provisioning" part.=20

 while (c) is also incompatible with support of=20
>existing non-IP capable PSAPs besides increasing terminal load=20
>and possibly interfering with optimum maintenance of the RF=20
>connection (e.g. if a terminal has to tune away from the=20
>serving base station or WLAN periodically to make location=20
>measurements).

I guess you are hunting an academic problem. The document does not say =
that
you provide a continues stream of location information. We are more
concerned about getting rough location as fast as possible to make the
emergency call routing to happen to the right PSAP and then provide
up-to-date location available to the PSAP for dispatch, when available.=20

Sure, there are corner cases when the emergency caller happens to be in =
a
fast car driving down the highway and location is constantly changing.=20

 Examples of the latter include (d) absence of=20
>support for access to non-IP capable PSAPs as already=20
>mentioned (e.g. to support E911 phase 2 in the US);=20

This is excluded by our charter and, as I said, possible with the =
solution
NENA has worked out with i2 and i2.5.=20

Please also note that today fixed (and wireless -- but not cellular)
operators are looking for VoIP emergency solutions as they are somewhat
ahead with VoIP deployment compared to cellular operators.

Hence, this will give PSAP operators more time to migrate to an IP-based
environment and these things are happening as we speak. Sure, this all =
needs
time but the cost savings for an IP-based solution (as it was reported =
to
use at the emergency services workshops) seems to speak in favor of IP.=20

(e) no=20
>support for handover from the IP to the circuit domain when a=20
>terminal loses (e.g. moves out of) RF coverage in the IP=20
>domain;=20

Correct. Our charter does not allow us to work on VCC.=20

and (f) no allowance for limited access modes wherein=20
>a terminal may access a network only to place an emergency=20
>call with ensuing restrictions on (for example) location=20
>acquisition, PSAP callback and caller verification and=20
>identification to the PSAP. To resolve this category either=20
>significant changes to the framework document could be made or=20
>a disclaimer/applicability statement could be added stating=20
>that support of cellular wireless networks and their=20
>associated WLAN and Femto access points is not covered.

This issue in under consideration in the ECRIT working group, see
http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-0=
4.t
xt.=20
The reason for us to separate this aspect from the main document is =
simply
it's complexity and the uncertainty from a regulatory point of view.=20
When you look at the document you will quickly realize that =
"unauthenticated
emergency calls" in an IP-based context mean much more than they do =
today.=20

We have also discussed this topic at the emergency services workshops =
and
the different views about this topic are interesting to observe but =
leave a
lot of fuzziness behind.=20

>=A0
>Category (C) comprises concepts and capabilities in the draft=20
>that are either already part of the standardized solution for=20
>wireless networks or that might be added at a later time.=20
>Examples of the former include LoST, SIP location conveyance,=20
>general use of SIP, location for routing versus for dispatch,=20
>cellular positioning methods. Examples of the latter include=20
>use of location references and dereferencing and possible=20
>interworking between the current wireless network solutions=20
>(in 3GPP, 3GPP2 and OMA) and the solution described in this=20
>draft. The presence of this category could be acknowledged by=20
>following the disclaimer for (B) with a statement that certain=20
>portions of the solution are expected to be incorporated into=20
>wireless networks now and/or in the future.

I am not sure I got your point. It is true that we have produced a =
couple of
specifications and, in case of SIP Location Conveyance, the =
standardization
effort is not yet completed.=20

>=A0
>We hope that these comments will be seen to be a useful=20
>addition to this review in the sense of enabling a more=20
>precise scoping for the framework document and we are willing=20
>to assist in providing wording for any=20
>disclaimer/applicability statement that the Ecrit working=20
>group may now deem fit to include.

Thanks for your help.=20

>=A0
>Kind Regards
>=A0

Thanks for your detailed review and for trying to help us ensuring that =
the
document does not raise wrong expectations.=20

Ciao
Hannes

>Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs=20
>(Qualcomm 3GPP2 TSG-X and TSG-C participant)
>
>PS  this being sent on 2/4/09 at 11:50pm PST
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Brian Rosen <[email-masked]>, "'Hannes Tschofenig'" <[email-masked]>, "'James M. Polk'" <[email-masked]>, "'Tschofenig, Hannes (NSN - FI/Espoo)'" <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Thu, 5 Feb 2009 13:55:09 +0100
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)

Which is exactly what RFC 4412 specifies for all namespaces.

regards

Keith=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> On Behalf Of Brian Rosen
> Sent: Wednesday, February 04, 2009 10:19 PM
> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, Hannes=20
> (NSN - FI/Espoo)'; 'ECRIT'
> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda=20
> (my mistake)
>=20
> The value is that in some networks where priority for=20
> emergency calls is appropriate, and appropriate policing of=20
> marking is implemented, emergency calls will receive resource=20
> priority.
>=20
> Not all networks would need policing.  Some will.  Policing=20
> could be to Route header/R-URI content, but other criteria=20
> are possible.
>=20
> Not all networks will need resource priority for emergency=20
> calls.  Fine, ignore this marking/namespace.
>=20
> Brian
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:[email-masked]]
> > Sent: Wednesday, February 04, 2009 5:09 PM
> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN -=20
> > FI/Espoo); 'ECRIT'
> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my=20
> > mistake)
> >=20
> > I don't even see the value in permitting the endpoint todo the RPH=20
> > marking.
> > In addition to the security concerns there is also the problem that=20
> > there are more options to implement without an additional value.
> >=20
> > >-----Original Message-----
> > >From: Brian Rosen [mailto:[email-masked]]
> > >Sent: 05 February, 2009 00:03
> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,=20
> Hannes (NSN -=20
> > >FI/Espoo)'; 'ECRIT'
> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> > mistake)
> > >
> > >Hannes
> > >
> > >This matches my understanding precisely.  We wish to=20
> permit endpoints=20
> > >to mark. We do not require it, and don't necessarily expect it in=20
> > >many (even
> > >most) cases.  We don't wish to see the document prohibit it.
> > >We all seem to agree it has value within the Emergency Services IP=20
> > >Networks.
> > >
> > >Brian
> > >
> > >> -----Original Message-----
> > >> From: [email-masked] [mailto:[email-masked]]
> > >On Behalf
> > >> Of James M. Polk
> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -=20
> FI/Espoo); 'ECRIT'
> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> > >> mistake)
> > >>
> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> > >> > > James wrote:
> > >> > >> you are the _lone_ voice not supporting this ID,
> > >> >
> > >> >Listening to the audio recording of past meetings I have to
> > >say that
> > >> >I
> > >> was
> > >> >not the only persons raising concerns about the document.
> > >> >That was probably the reason why you agreed to limit the
> > >scope of the
> > >> >document (which you didn't later do) to get folks to agree
> > >to make it
> > >> a WG
> > >> >item.
> > >>
> > >> re-listen to the audio please
> > >>
> > >> Ted's concerns were consistent with most (all?) other=20
> concerns --=20
> > >> which were based on the premise of whether or not the=20
> UAC should be=20
> > >> trusted to initiate the marking on the INVITE.  The most recent=20
> > >> version has backed off this to a "can" -- meaning not prohibited=20
> > >> (i.e., no 2119 text).  I also backed off the text in the=20
> SP domain=20
> > >> part to "can", such that there is no 2119 text mandating or even=20
> > >> recommending its usage there. I also do not prohibit its
> > >use, based on
> > >> local policy.  Keith has come forward with the specific request=20
> > >> that non-ESInet networks be allowed to mark and pay attention to=20
> > >> this priority indication -- with IMS as the specific example he=20
> > >> wishes to have this valid for.
> > >>
> > >> Where there is no disagreement, save for your recent
> > >pushback - is in
> > >> the ESInet, which is where Brian has requested it's
> > >definition in the
> > >> IETF on behalf of NENA.  He's the i3 WG chair within=20
> NENA, and if=20
> > >> he asks for it, are you going to say you know better than he?
> > >>
> > >>
> > >> >Btw, I not disagreeing with the document as such. I just want to
> > the
> > >> scope
> > >> >to change. The usage of RPH within the emergency=20
> services network
> > is
> > >> fine
> > >> >for me. I may get convinced to start the RPH marking from
> > >the the VSP
> > >> >towards the PSAP. I feel uneasy about the end host doing
> > >the marking.
> > >>
> > >> please read what I wrote above, and then re-read the most recent=20
> > >> version of the ID. I don't have endpoints that SHOULD or=20
> MUST mark=20
> > >> anything wrt RPH.  I also don't want to prohibit it,=20
> because there=20
> > >> might be cases (that I don't know of) of valid uses=20
> under certain=20
> > >> circumstances.  Figure 1 is very clear that there are 3=20
> networking=20
> > >> parts to consider
> > >>
> > >> #1 - from the endpoint
> > >> #2 - within the VSP
> > >> #3 - within the ESInet
> > >>
> > >> the most recent ID version has "can" for #s 1 and 2, and
> > >2119 language
> > >> offering those supporting this specification will have RPH=20
> > >> adherence within #3 (the ESInet).
> > >>
> > >> What other scope changes do you want, because I haven't=20
> heard them.
> > >>
> > >> I only heard you claim in email during the last IETF and in
> > >the ECRIT
> > >> session that RPH should not be used for priority marking=20
> requests.
> > >> This is something Keith (SIP WG chair) voiced his opposition to=20
> > >> your views regarding creating a second means for SIP to priority=20
> > >> mark request "when SIP already has one interoperable way to=20
> > >> accomplish this... it's call the RP header mechanism".
> > >>
> > >> >I don't see advantages -- only disadvantages.
> > >> >
> > >> >Ciao
> > >> >Hannes
> > >>
> > >> _______________________________________________
> > >> Ecrit mailing list
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/ecrit
> > >
>=20
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
> =

From: "Hannes Tschofenig" <[email-masked]>
To: "'DRAGE, Keith \(Keith\)'" <[email-masked]>, "'Brian Rosen'" <[email-masked]>, "'James M. Polk'" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Thu, 5 Feb 2009 21:05:47 +0200
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)

Keith, please understand that the usage of RFC 4412 for GETS and for the
type of emergency call we discuss here is different. Just looking at the
header and the name of the namespace is a bit artificial. I hope you
understand that. 

>-----Original Message-----
>From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
>Sent: 05 February, 2009 14:55
>To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 
>'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
>Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake)
>
>Which is exactly what RFC 4412 specifies for all namespaces.
>
>regards
>
>Keith 
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>> Of Brian Rosen
>> Sent: Wednesday, February 04, 2009 10:19 PM
>> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, Hannes (NSN - 
>> FI/Espoo)'; 'ECRIT'
>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my 
>> mistake)
>> 
>> The value is that in some networks where priority for 
>emergency calls 
>> is appropriate, and appropriate policing of marking is implemented, 
>> emergency calls will receive resource priority.
>> 
>> Not all networks would need policing.  Some will.  Policing could be 
>> to Route header/R-URI content, but other criteria are possible.
>> 
>> Not all networks will need resource priority for emergency calls.  
>> Fine, ignore this marking/namespace.
>> 
>> Brian
>> > -----Original Message-----
>> > From: Hannes Tschofenig [mailto:[email-masked]]
>> > Sent: Wednesday, February 04, 2009 5:09 PM
>> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN - 
>> > FI/Espoo); 'ECRIT'
>> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
>> > mistake)
>> > 
>> > I don't even see the value in permitting the endpoint todo the RPH 
>> > marking.
>> > In addition to the security concerns there is also the 
>problem that 
>> > there are more options to implement without an additional value.
>> > 
>> > >-----Original Message-----
>> > >From: Brian Rosen [mailto:[email-masked]]
>> > >Sent: 05 February, 2009 00:03
>> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,
>> Hannes (NSN -
>> > >FI/Espoo)'; 'ECRIT'
>> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
>> > mistake)
>> > >
>> > >Hannes
>> > >
>> > >This matches my understanding precisely.  We wish to
>> permit endpoints
>> > >to mark. We do not require it, and don't necessarily expect it in 
>> > >many (even
>> > >most) cases.  We don't wish to see the document prohibit it.
>> > >We all seem to agree it has value within the Emergency 
>Services IP 
>> > >Networks.
>> > >
>> > >Brian
>> > >
>> > >> -----Original Message-----
>> > >> From: [email-masked] [mailto:[email-masked]]
>> > >On Behalf
>> > >> Of James M. Polk
>> > >> Sent: Wednesday, February 04, 2009 4:01 PM
>> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
>> FI/Espoo); 'ECRIT'
>> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
>> > >> mistake)
>> > >>
>> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
>> > >> > > James wrote:
>> > >> > >> you are the _lone_ voice not supporting this ID,
>> > >> >
>> > >> >Listening to the audio recording of past meetings I have to
>> > >say that
>> > >> >I
>> > >> was
>> > >> >not the only persons raising concerns about the document.
>> > >> >That was probably the reason why you agreed to limit the
>> > >scope of the
>> > >> >document (which you didn't later do) to get folks to agree
>> > >to make it
>> > >> a WG
>> > >> >item.
>> > >>
>> > >> re-listen to the audio please
>> > >>
>> > >> Ted's concerns were consistent with most (all?) other
>> concerns --
>> > >> which were based on the premise of whether or not the
>> UAC should be
>> > >> trusted to initiate the marking on the INVITE.  The most recent 
>> > >> version has backed off this to a "can" -- meaning not 
>prohibited 
>> > >> (i.e., no 2119 text).  I also backed off the text in the
>> SP domain
>> > >> part to "can", such that there is no 2119 text 
>mandating or even 
>> > >> recommending its usage there. I also do not prohibit its
>> > >use, based on
>> > >> local policy.  Keith has come forward with the specific request 
>> > >> that non-ESInet networks be allowed to mark and pay 
>attention to 
>> > >> this priority indication -- with IMS as the specific example he 
>> > >> wishes to have this valid for.
>> > >>
>> > >> Where there is no disagreement, save for your recent
>> > >pushback - is in
>> > >> the ESInet, which is where Brian has requested it's
>> > >definition in the
>> > >> IETF on behalf of NENA.  He's the i3 WG chair within
>> NENA, and if
>> > >> he asks for it, are you going to say you know better than he?
>> > >>
>> > >>
>> > >> >Btw, I not disagreeing with the document as such. I 
>just want to
>> > the
>> > >> scope
>> > >> >to change. The usage of RPH within the emergency
>> services network
>> > is
>> > >> fine
>> > >> >for me. I may get convinced to start the RPH marking from
>> > >the the VSP
>> > >> >towards the PSAP. I feel uneasy about the end host doing
>> > >the marking.
>> > >>
>> > >> please read what I wrote above, and then re-read the 
>most recent 
>> > >> version of the ID. I don't have endpoints that SHOULD or
>> MUST mark
>> > >> anything wrt RPH.  I also don't want to prohibit it,
>> because there
>> > >> might be cases (that I don't know of) of valid uses
>> under certain
>> > >> circumstances.  Figure 1 is very clear that there are 3
>> networking
>> > >> parts to consider
>> > >>
>> > >> #1 - from the endpoint
>> > >> #2 - within the VSP
>> > >> #3 - within the ESInet
>> > >>
>> > >> the most recent ID version has "can" for #s 1 and 2, and
>> > >2119 language
>> > >> offering those supporting this specification will have RPH 
>> > >> adherence within #3 (the ESInet).
>> > >>
>> > >> What other scope changes do you want, because I haven't
>> heard them.
>> > >>
>> > >> I only heard you claim in email during the last IETF and in
>> > >the ECRIT
>> > >> session that RPH should not be used for priority marking
>> requests.
>> > >> This is something Keith (SIP WG chair) voiced his opposition to 
>> > >> your views regarding creating a second means for SIP to 
>priority 
>> > >> mark request "when SIP already has one interoperable way to 
>> > >> accomplish this... it's call the RP header mechanism".
>> > >>
>> > >> >I don't see advantages -- only disadvantages.
>> > >> >
>> > >> >Ciao
>> > >> >Hannes
>> > >>
>> > >> _______________________________________________
>> > >> Ecrit mailing list
>> > >> [email-masked]
>> > >> https://www.ietf.org/mailman/listinfo/ecrit
>> > >
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
>

Date: Thu, 05 Feb 2009 17:35:39 -0600
To: "Hannes Tschofenig" <[email-masked]>, "'DRAGE, Keith \(Keith\)'" <[email-masked]>, "'Brian Rosen'" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "'ECRIT'" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Subject: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)

Hannes - I believe it is you who do not understand RFC 4412 -- and 
many of us are trying to get that through to you, but you don't seem 
to want to listen/read.

RFC 4412 is *for* priority marking SIP requests,

One use is GETS.

One use is MLPP.

These examples are in RFC 4412 because there were specific namespaces 
being created for the IANA section of that document.

Reading the whole document, you will see that RPH can be specified 
for other uses than GETS or MLPP specifically.

I knew when I wrote RFC 4412 that one day we would specify a 
namespace for ECRIT (the "esnet" namespace now) -- but I also knew it 
was premature for RFC 4412 to incorporate that namespace, that a 
future doc to RFC 4412 would have to be written to do this. Brian and 
I talked about this at the original NENA meeting that created the IP 
WGs there (in August of 03).  We both agreed we should wait until it 
was appropriate to the work in the IETF to submit this document that is now
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-00.txt

Yet, you seem to want to use some additional mechanism to indicate 
priority of a call in SIP.  That means you want to introduce a second 
way to accomplish this in SIP.  Why do you want to promote a separate 
way to do something SIP has already defined? That will cause 
interoperability issues and we both know that.

You've said to me (and others) that you believe RPH is just another 
way to accomplish what sos or a URI can indicate - and you're 
wrong.  Your way would be _the_second_way_to_do_it, because SIP 
already considers RPH to be *the*way* to priority mark SIP requests.

If you don't believe me (no comment), then why do you not believe the 
SIP WG chair (who knows more about SIP than both of us) - who, on 
this thread, has again said to you "RFC 4412 (RPH) is the SIP 
mechanism to priority mark SIP requests"?

Further, I believe it is inappropriate to prohibit endpoints from 
being able to set the esnet namespace.  I absolutely believe it will 
not be needed most of the time, but I believe if someone does find a 
valid use for endpoints to mark priority in SIP, this ID - once it 
has become an RFC -- will have to be obsoleted with a new RFC saying 
the exact opposite.

(color me confused ... over and over again)

James

At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>Keith, please understand that the usage of RFC 4412 for GETS and for the
>type of emergency call we discuss here is different. Just looking at the
>header and the name of the namespace is a bit artificial. I hope you
>understand that.
>
> >-----Original Message-----
> >From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> >Sent: 05 February, 2009 14:55
> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk';
> >'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake)
> >
> >Which is exactly what RFC 4412 specifies for all namespaces.
> >
> >regards
> >
> >Keith
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]]
> >On Behalf
> >> Of Brian Rosen
> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, Hannes (NSN -
> >> FI/Espoo)'; 'ECRIT'
> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> mistake)
> >>
> >> The value is that in some networks where priority for
> >emergency calls
> >> is appropriate, and appropriate policing of marking is implemented,
> >> emergency calls will receive resource priority.
> >>
> >> Not all networks would need policing.  Some will.  Policing could be
> >> to Route header/R-URI content, but other criteria are possible.
> >>
> >> Not all networks will need resource priority for emergency calls.
> >> Fine, ignore this marking/namespace.
> >>
> >> Brian
> >> > -----Original Message-----
> >> > From: Hannes Tschofenig [mailto:[email-masked]]
> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN -
> >> > FI/Espoo); 'ECRIT'
> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> > mistake)
> >> >
> >> > I don't even see the value in permitting the endpoint todo the RPH
> >> > marking.
> >> > In addition to the security concerns there is also the
> >problem that
> >> > there are more options to implement without an additional value.
> >> >
> >> > >-----Original Message-----
> >> > >From: Brian Rosen [mailto:[email-masked]]
> >> > >Sent: 05 February, 2009 00:03
> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,
> >> Hannes (NSN -
> >> > >FI/Espoo)'; 'ECRIT'
> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> > mistake)
> >> > >
> >> > >Hannes
> >> > >
> >> > >This matches my understanding precisely.  We wish to
> >> permit endpoints
> >> > >to mark. We do not require it, and don't necessarily expect it in
> >> > >many (even
> >> > >most) cases.  We don't wish to see the document prohibit it.
> >> > >We all seem to agree it has value within the Emergency
> >Services IP
> >> > >Networks.
> >> > >
> >> > >Brian
> >> > >
> >> > >> -----Original Message-----
> >> > >> From: [email-masked] [mailto:[email-masked]]
> >> > >On Behalf
> >> > >> Of James M. Polk
> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
> >> FI/Espoo); 'ECRIT'
> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> > >> mistake)
> >> > >>
> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> >> > >> > > James wrote:
> >> > >> > >> you are the _lone_ voice not supporting this ID,
> >> > >> >
> >> > >> >Listening to the audio recording of past meetings I have to
> >> > >say that
> >> > >> >I
> >> > >> was
> >> > >> >not the only persons raising concerns about the document.
> >> > >> >That was probably the reason why you agreed to limit the
> >> > >scope of the
> >> > >> >document (which you didn't later do) to get folks to agree
> >> > >to make it
> >> > >> a WG
> >> > >> >item.
> >> > >>
> >> > >> re-listen to the audio please
> >> > >>
> >> > >> Ted's concerns were consistent with most (all?) other
> >> concerns --
> >> > >> which were based on the premise of whether or not the
> >> UAC should be
> >> > >> trusted to initiate the marking on the INVITE.  The most recent
> >> > >> version has backed off this to a "can" -- meaning not
> >prohibited
> >> > >> (i.e., no 2119 text).  I also backed off the text in the
> >> SP domain
> >> > >> part to "can", such that there is no 2119 text
> >mandating or even
> >> > >> recommending its usage there. I also do not prohibit its
> >> > >use, based on
> >> > >> local policy.  Keith has come forward with the specific request
> >> > >> that non-ESInet networks be allowed to mark and pay
> >attention to
> >> > >> this priority indication -- with IMS as the specific example he
> >> > >> wishes to have this valid for.
> >> > >>
> >> > >> Where there is no disagreement, save for your recent
> >> > >pushback - is in
> >> > >> the ESInet, which is where Brian has requested it's
> >> > >definition in the
> >> > >> IETF on behalf of NENA.  He's the i3 WG chair within
> >> NENA, and if
> >> > >> he asks for it, are you going to say you know better than he?
> >> > >>
> >> > >>
> >> > >> >Btw, I not disagreeing with the document as such. I
> >just want to
> >> > the
> >> > >> scope
> >> > >> >to change. The usage of RPH within the emergency
> >> services network
> >> > is
> >> > >> fine
> >> > >> >for me. I may get convinced to start the RPH marking from
> >> > >the the VSP
> >> > >> >towards the PSAP. I feel uneasy about the end host doing
> >> > >the marking.
> >> > >>
> >> > >> please read what I wrote above, and then re-read the
> >most recent
> >> > >> version of the ID. I don't have endpoints that SHOULD or
> >> MUST mark
> >> > >> anything wrt RPH.  I also don't want to prohibit it,
> >> because there
> >> > >> might be cases (that I don't know of) of valid uses
> >> under certain
> >> > >> circumstances.  Figure 1 is very clear that there are 3
> >> networking
> >> > >> parts to consider
> >> > >>
> >> > >> #1 - from the endpoint
> >> > >> #2 - within the VSP
> >> > >> #3 - within the ESInet
> >> > >>
> >> > >> the most recent ID version has "can" for #s 1 and 2, and
> >> > >2119 language
> >> > >> offering those supporting this specification will have RPH
> >> > >> adherence within #3 (the ESInet).
> >> > >>
> >> > >> What other scope changes do you want, because I haven't
> >> heard them.
> >> > >>
> >> > >> I only heard you claim in email during the last IETF and in
> >> > >the ECRIT
> >> > >> session that RPH should not be used for priority marking
> >> requests.
> >> > >> This is something Keith (SIP WG chair) voiced his opposition to
> >> > >> your views regarding creating a second means for SIP to
> >priority
> >> > >> mark request "when SIP already has one interoperable way to
> >> > >> accomplish this... it's call the RP header mechanism".
> >> > >>
> >> > >> >I don't see advantages -- only disadvantages.
> >> > >> >
> >> > >> >Ciao
> >> > >> >Hannes
> >> > >>
> >> > >> _______________________________________________
> >> > >> Ecrit mailing list
> >> > >> [email-masked]
> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> > >
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "'Brian Rosen'" <[email-masked]>, "'James M. Polk'" <[email-masked]>, "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Fri, 6 Feb 2009 02:51:33 +0100
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)

RFC 4412 is not specific to a single namespace. The general principles eluc=
idated by Brian apply to all the namespaces, and give a framework for their=
 use.

I believe I understand RFC 4412, but my interpretation is certainly at vari=
ance to yours. I am just glad I seem to have a common interpretation with a=
 number of other people.

Keith=20

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]=20
> Sent: Thursday, February 05, 2009 7:06 PM
> To: DRAGE, Keith (Keith); 'Brian Rosen'; 'James M. Polk';=20
> Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
> Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda=20
> (my mistake)
>=20
> Keith, please understand that the usage of RFC 4412 for GETS=20
> and for the type of emergency call we discuss here is=20
> different. Just looking at the header and the name of the=20
> namespace is a bit artificial. I hope you understand that.=20
>=20
> >-----Original Message-----
> >From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> >Sent: 05 February, 2009 14:55
> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,=20
> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda=20
> (my mistake)
> >
> >Which is exactly what RFC 4412 specifies for all namespaces.
> >
> >regards
> >
> >Keith
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]]
> >On Behalf
> >> Of Brian Rosen
> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,=20
> Hannes (NSN -=20
> >> FI/Espoo)'; 'ECRIT'
> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> mistake)
> >>=20
> >> The value is that in some networks where priority for
> >emergency calls
> >> is appropriate, and appropriate policing of marking is=20
> implemented,=20
> >> emergency calls will receive resource priority.
> >>=20
> >> Not all networks would need policing.  Some will. =20
> Policing could be=20
> >> to Route header/R-URI content, but other criteria are possible.
> >>=20
> >> Not all networks will need resource priority for emergency calls. =20
> >> Fine, ignore this marking/namespace.
> >>=20
> >> Brian
> >> > -----Original Message-----
> >> > From: Hannes Tschofenig [mailto:[email-masked]]
> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN -=20
> >> > FI/Espoo); 'ECRIT'
> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> > mistake)
> >> >=20
> >> > I don't even see the value in permitting the endpoint=20
> todo the RPH=20
> >> > marking.
> >> > In addition to the security concerns there is also the
> >problem that
> >> > there are more options to implement without an additional value.
> >> >=20
> >> > >-----Original Message-----
> >> > >From: Brian Rosen [mailto:[email-masked]]
> >> > >Sent: 05 February, 2009 00:03
> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,
> >> Hannes (NSN -
> >> > >FI/Espoo)'; 'ECRIT'
> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> > mistake)
> >> > >
> >> > >Hannes
> >> > >
> >> > >This matches my understanding precisely.  We wish to
> >> permit endpoints
> >> > >to mark. We do not require it, and don't necessarily=20
> expect it in=20
> >> > >many (even
> >> > >most) cases.  We don't wish to see the document prohibit it.
> >> > >We all seem to agree it has value within the Emergency
> >Services IP
> >> > >Networks.
> >> > >
> >> > >Brian
> >> > >
> >> > >> -----Original Message-----
> >> > >> From: [email-masked] [mailto:[email-masked]]
> >> > >On Behalf
> >> > >> Of James M. Polk
> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
> >> FI/Espoo); 'ECRIT'
> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> > >> mistake)
> >> > >>
> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> >> > >> > > James wrote:
> >> > >> > >> you are the _lone_ voice not supporting this ID,
> >> > >> >
> >> > >> >Listening to the audio recording of past meetings I have to
> >> > >say that
> >> > >> >I
> >> > >> was
> >> > >> >not the only persons raising concerns about the document.
> >> > >> >That was probably the reason why you agreed to limit the
> >> > >scope of the
> >> > >> >document (which you didn't later do) to get folks to agree
> >> > >to make it
> >> > >> a WG
> >> > >> >item.
> >> > >>
> >> > >> re-listen to the audio please
> >> > >>
> >> > >> Ted's concerns were consistent with most (all?) other
> >> concerns --
> >> > >> which were based on the premise of whether or not the
> >> UAC should be
> >> > >> trusted to initiate the marking on the INVITE.  The=20
> most recent=20
> >> > >> version has backed off this to a "can" -- meaning not
> >prohibited
> >> > >> (i.e., no 2119 text).  I also backed off the text in the
> >> SP domain
> >> > >> part to "can", such that there is no 2119 text
> >mandating or even
> >> > >> recommending its usage there. I also do not prohibit its
> >> > >use, based on
> >> > >> local policy.  Keith has come forward with the=20
> specific request=20
> >> > >> that non-ESInet networks be allowed to mark and pay
> >attention to
> >> > >> this priority indication -- with IMS as the specific=20
> example he=20
> >> > >> wishes to have this valid for.
> >> > >>
> >> > >> Where there is no disagreement, save for your recent
> >> > >pushback - is in
> >> > >> the ESInet, which is where Brian has requested it's
> >> > >definition in the
> >> > >> IETF on behalf of NENA.  He's the i3 WG chair within
> >> NENA, and if
> >> > >> he asks for it, are you going to say you know better than he?
> >> > >>
> >> > >>
> >> > >> >Btw, I not disagreeing with the document as such. I
> >just want to
> >> > the
> >> > >> scope
> >> > >> >to change. The usage of RPH within the emergency
> >> services network
> >> > is
> >> > >> fine
> >> > >> >for me. I may get convinced to start the RPH marking from
> >> > >the the VSP
> >> > >> >towards the PSAP. I feel uneasy about the end host doing
> >> > >the marking.
> >> > >>
> >> > >> please read what I wrote above, and then re-read the
> >most recent
> >> > >> version of the ID. I don't have endpoints that SHOULD or
> >> MUST mark
> >> > >> anything wrt RPH.  I also don't want to prohibit it,
> >> because there
> >> > >> might be cases (that I don't know of) of valid uses
> >> under certain
> >> > >> circumstances.  Figure 1 is very clear that there are 3
> >> networking
> >> > >> parts to consider
> >> > >>
> >> > >> #1 - from the endpoint
> >> > >> #2 - within the VSP
> >> > >> #3 - within the ESInet
> >> > >>
> >> > >> the most recent ID version has "can" for #s 1 and 2, and
> >> > >2119 language
> >> > >> offering those supporting this specification will have RPH=20
> >> > >> adherence within #3 (the ESInet).
> >> > >>
> >> > >> What other scope changes do you want, because I haven't
> >> heard them.
> >> > >>
> >> > >> I only heard you claim in email during the last IETF and in
> >> > >the ECRIT
> >> > >> session that RPH should not be used for priority marking
> >> requests.
> >> > >> This is something Keith (SIP WG chair) voiced his=20
> opposition to=20
> >> > >> your views regarding creating a second means for SIP to
> >priority
> >> > >> mark request "when SIP already has one interoperable way to=20
> >> > >> accomplish this... it's call the RP header mechanism".
> >> > >>
> >> > >> >I don't see advantages -- only disadvantages.
> >> > >> >
> >> > >> >Ciao
> >> > >> >Hannes
> >> > >>
> >> > >> _______________________________________________
> >> > >> Ecrit mailing list
> >> > >> [email-masked]
> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> > >
> >>=20
> >> _______________________________________________
> >> Ecrit mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>=20
> >
>=20
> =

From: "Hannes Tschofenig" <[email-masked]>
To: "'James M. Polk'" <[email-masked]>, "'DRAGE, Keith \(Keith\)'" <[email-masked]>, "'Brian Rosen'" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Fri, 6 Feb 2009 11:21:51 +0200
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)

Hi James, 

I have read RFC 4412 and also the GETS/MLPP IETF documents. What I would
like to point out is that there is more than just a header and values within
the header that have to be considered in order to make a judgement of what
is appropriate and what isn't. There is an architectural question and
whether the environment we are using the stuff is indeed providing the
properties you need for the solution to be appropriate. 

Let me describe in more detail what I meant (and please correct me if I am
wrong). 

Getting priority for SIP requests when using a GETS alike scenario means
that the entity that issues the request is specially authorized since
otherwise you introduce a nice denial of service attack. This authorization
is tied to the entity that makes the request. For example, the person is
working for the government and has special rights. James Bond as a (not so)
secret agent might have these rights. 

The emergency services case (citizen-to-authority) is a bit different as
there aren't really special rights with respect to authorization tied to
individuals. Instead, the fact that something is an emergency is purely a
judgement of the human that dials a special number. To deal with fraud, we
discussed in the group on what we can actually do to ensure that end users
do not bypass security procedures (such as authorization checks, charging
and so on). Part of this investigation was the publication of
http://www.ietf.org/rfc/rfc5069.txt that also describes this issue. 

So, imagine the implementation of a SIP proxy (and we implemented that
stuff) that receives a call that contains a Service URN. The code branches
into a special mode where everything is done so that the call receives
appropriate treatment and does not get dropped on the floor. The way how the
Service URN is placed in the message ensures that the call cannot go to my
friend (instead of the PSAP) unless the end host ran LoST already. In the
latter case, we discussed this also on the list for a while and Richard even
wrote a draft about it in the context of the location hiding topic, we said
that the proxy would have to run LoST if he cares about a potential
fraudulent usage. 

So, what do we need todo in order to provide secure RFC 4412 functionality
in our context? 

Do you think that the current text in
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-nam
espace-00.txt reflects any of the above-described issues: 
"
   The Security considerations that apply to RFC 4412 [RFC4412] apply 
   here.  This document introduces no new security issues relative to 
   RFC 4412.
"

>From various discussions in GEOPRIV I recall that you are super-sensitive
regarding security and privacy. For some reasons you don't seem to have the
same concerns here. I would like to understand your reasoning.

Please also do me another favor: Don't always say that I don't understand
the subject. Even if that would be the case it isn't particular fair given
that different folks had to educate you on other topics in the past as well.
Additionally, if you listen to the audio recordings then you will notice
that Henning, Ted, and Jon do not seem to understand the issue either as
they have raised similar issues during the F2F meetings. 

Ciao
Hannes

>Hannes - I believe it is you who do not understand RFC 4412 -- 
>and many of us are trying to get that through to you, but you 
>don't seem to want to listen/read.
>
>RFC 4412 is *for* priority marking SIP requests,
>
>One use is GETS.
>
>One use is MLPP.
>
>These examples are in RFC 4412 because there were specific 
>namespaces being created for the IANA section of that document.
>
>Reading the whole document, you will see that RPH can be 
>specified for other uses than GETS or MLPP specifically.
>
>I knew when I wrote RFC 4412 that one day we would specify a 
>namespace for ECRIT (the "esnet" namespace now) -- but I also 
>knew it was premature for RFC 4412 to incorporate that 
>namespace, that a future doc to RFC 4412 would have to be 
>written to do this. Brian and I talked about this at the 
>original NENA meeting that created the IP WGs there (in August 
>of 03).  We both agreed we should wait until it was 
>appropriate to the work in the IETF to submit this document 
>that is now 
>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>gency-rph-namespace-00.txt
>
>Yet, you seem to want to use some additional mechanism to 
>indicate priority of a call in SIP.  That means you want to 
>introduce a second way to accomplish this in SIP.  Why do you 
>want to promote a separate way to do something SIP has already 
>defined? That will cause interoperability issues and we both know that.
>
>You've said to me (and others) that you believe RPH is just 
>another way to accomplish what sos or a URI can indicate - and 
>you're wrong.  Your way would be _the_second_way_to_do_it, 
>because SIP already considers RPH to be *the*way* to priority 
>mark SIP requests.
>
>If you don't believe me (no comment), then why do you not 
>believe the SIP WG chair (who knows more about SIP than both 
>of us) - who, on this thread, has again said to you "RFC 4412 
>(RPH) is the SIP mechanism to priority mark SIP requests"?
>
>Further, I believe it is inappropriate to prohibit endpoints 
>from being able to set the esnet namespace.  I absolutely 
>believe it will not be needed most of the time, but I believe 
>if someone does find a valid use for endpoints to mark 
>priority in SIP, this ID - once it has become an RFC -- will 
>have to be obsoleted with a new RFC saying the exact opposite.
>
>(color me confused ... over and over again)
>
>James
>
>At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>>Keith, please understand that the usage of RFC 4412 for GETS and for 
>>the type of emergency call we discuss here is different. Just looking 
>>at the header and the name of the namespace is a bit 
>artificial. I hope 
>>you understand that.
>>
>> >-----Original Message-----
>> >From: DRAGE, Keith (Keith) [mailto:[email-masked]]
>> >Sent: 05 February, 2009 14:55
>> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, 
>> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
>> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my 
>> >mistake)
>> >
>> >Which is exactly what RFC 4412 specifies for all namespaces.
>> >
>> >regards
>> >
>> >Keith
>> >
>> >> -----Original Message-----
>> >> From: [email-masked] [mailto:[email-masked]]
>> >On Behalf
>> >> Of Brian Rosen
>> >> Sent: Wednesday, February 04, 2009 10:19 PM
>> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, 
>Hannes (NSN 
>> >> - FI/Espoo)'; 'ECRIT'
>> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
>> >> mistake)
>> >>
>> >> The value is that in some networks where priority for
>> >emergency calls
>> >> is appropriate, and appropriate policing of marking is 
>implemented, 
>> >> emergency calls will receive resource priority.
>> >>
>> >> Not all networks would need policing.  Some will.  Policing could 
>> >> be to Route header/R-URI content, but other criteria are possible.
>> >>
>> >> Not all networks will need resource priority for emergency calls.
>> >> Fine, ignore this marking/namespace.
>> >>
>> >> Brian
>> >> > -----Original Message-----
>> >> > From: Hannes Tschofenig [mailto:[email-masked]]
>> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN - 
>> >> > FI/Espoo); 'ECRIT'
>> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
>> >> > mistake)
>> >> >
>> >> > I don't even see the value in permitting the endpoint todo the 
>> >> > RPH marking.
>> >> > In addition to the security concerns there is also the
>> >problem that
>> >> > there are more options to implement without an additional value.
>> >> >
>> >> > >-----Original Message-----
>> >> > >From: Brian Rosen [mailto:[email-masked]]
>> >> > >Sent: 05 February, 2009 00:03
>> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,
>> >> Hannes (NSN -
>> >> > >FI/Espoo)'; 'ECRIT'
>> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
>> >> > mistake)
>> >> > >
>> >> > >Hannes
>> >> > >
>> >> > >This matches my understanding precisely.  We wish to
>> >> permit endpoints
>> >> > >to mark. We do not require it, and don't necessarily expect it 
>> >> > >in many (even
>> >> > >most) cases.  We don't wish to see the document prohibit it.
>> >> > >We all seem to agree it has value within the Emergency
>> >Services IP
>> >> > >Networks.
>> >> > >
>> >> > >Brian
>> >> > >
>> >> > >> -----Original Message-----
>> >> > >> From: [email-masked] [mailto:[email-masked]]
>> >> > >On Behalf
>> >> > >> Of James M. Polk
>> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
>> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
>> >> FI/Espoo); 'ECRIT'
>> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: 
>Agenda (my
>> >> > >> mistake)
>> >> > >>
>> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
>> >> > >> > > James wrote:
>> >> > >> > >> you are the _lone_ voice not supporting this ID,
>> >> > >> >
>> >> > >> >Listening to the audio recording of past meetings I have to
>> >> > >say that
>> >> > >> >I
>> >> > >> was
>> >> > >> >not the only persons raising concerns about the document.
>> >> > >> >That was probably the reason why you agreed to limit the
>> >> > >scope of the
>> >> > >> >document (which you didn't later do) to get folks to agree
>> >> > >to make it
>> >> > >> a WG
>> >> > >> >item.
>> >> > >>
>> >> > >> re-listen to the audio please
>> >> > >>
>> >> > >> Ted's concerns were consistent with most (all?) other
>> >> concerns --
>> >> > >> which were based on the premise of whether or not the
>> >> UAC should be
>> >> > >> trusted to initiate the marking on the INVITE.  The most 
>> >> > >> recent version has backed off this to a "can" -- meaning not
>> >prohibited
>> >> > >> (i.e., no 2119 text).  I also backed off the text in the
>> >> SP domain
>> >> > >> part to "can", such that there is no 2119 text
>> >mandating or even
>> >> > >> recommending its usage there. I also do not prohibit its
>> >> > >use, based on
>> >> > >> local policy.  Keith has come forward with the specific 
>> >> > >> request that non-ESInet networks be allowed to mark and pay
>> >attention to
>> >> > >> this priority indication -- with IMS as the specific example 
>> >> > >> he wishes to have this valid for.
>> >> > >>
>> >> > >> Where there is no disagreement, save for your recent
>> >> > >pushback - is in
>> >> > >> the ESInet, which is where Brian has requested it's
>> >> > >definition in the
>> >> > >> IETF on behalf of NENA.  He's the i3 WG chair within
>> >> NENA, and if
>> >> > >> he asks for it, are you going to say you know better than he?
>> >> > >>
>> >> > >>
>> >> > >> >Btw, I not disagreeing with the document as such. I
>> >just want to
>> >> > the
>> >> > >> scope
>> >> > >> >to change. The usage of RPH within the emergency
>> >> services network
>> >> > is
>> >> > >> fine
>> >> > >> >for me. I may get convinced to start the RPH marking from
>> >> > >the the VSP
>> >> > >> >towards the PSAP. I feel uneasy about the end host doing
>> >> > >the marking.
>> >> > >>
>> >> > >> please read what I wrote above, and then re-read the
>> >most recent
>> >> > >> version of the ID. I don't have endpoints that SHOULD or
>> >> MUST mark
>> >> > >> anything wrt RPH.  I also don't want to prohibit it,
>> >> because there
>> >> > >> might be cases (that I don't know of) of valid uses
>> >> under certain
>> >> > >> circumstances.  Figure 1 is very clear that there are 3
>> >> networking
>> >> > >> parts to consider
>> >> > >>
>> >> > >> #1 - from the endpoint
>> >> > >> #2 - within the VSP
>> >> > >> #3 - within the ESInet
>> >> > >>
>> >> > >> the most recent ID version has "can" for #s 1 and 2, and
>> >> > >2119 language
>> >> > >> offering those supporting this specification will have RPH 
>> >> > >> adherence within #3 (the ESInet).
>> >> > >>
>> >> > >> What other scope changes do you want, because I haven't
>> >> heard them.
>> >> > >>
>> >> > >> I only heard you claim in email during the last IETF and in
>> >> > >the ECRIT
>> >> > >> session that RPH should not be used for priority marking
>> >> requests.
>> >> > >> This is something Keith (SIP WG chair) voiced his opposition 
>> >> > >> to your views regarding creating a second means for SIP to
>> >priority
>> >> > >> mark request "when SIP already has one interoperable way to 
>> >> > >> accomplish this... it's call the RP header mechanism".
>> >> > >>
>> >> > >> >I don't see advantages -- only disadvantages.
>> >> > >> >
>> >> > >> >Ciao
>> >> > >> >Hannes
>> >> > >>
>> >> > >> _______________________________________________
>> >> > >> Ecrit mailing list
>> >> > >> [email-masked]
>> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> > >
>> >>
>> >> _______________________________________________
>> >> Ecrit mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >>
>> >
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'DRAGE, Keith \(Keith\)'" <[email-masked]>, "'Brian Rosen'" <[email-masked]>, "'James M. Polk'" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Fri, 6 Feb 2009 11:23:38 +0200
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)

I am also glad that some folks share the security concerns I have. 

>-----Original Message-----
>From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
>Sent: 06 February, 2009 03:52
>To: Hannes Tschofenig; 'Brian Rosen'; 'James M. Polk'; 
>Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
>Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake)
>
>RFC 4412 is not specific to a single namespace. The general 
>principles elucidated by Brian apply to all the namespaces, 
>and give a framework for their use.
>
>I believe I understand RFC 4412, but my interpretation is 
>certainly at variance to yours. I am just glad I seem to have 
>a common interpretation with a number of other people.
>
>Keith 
>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[email-masked]]
>> Sent: Thursday, February 05, 2009 7:06 PM
>> To: DRAGE, Keith (Keith); 'Brian Rosen'; 'James M. Polk'; 
>Tschofenig, 
>> Hannes (NSN - FI/Espoo); 'ECRIT'
>> Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my 
>> mistake)
>> 
>> Keith, please understand that the usage of RFC 4412 for GETS and for 
>> the type of emergency call we discuss here is different. 
>Just looking 
>> at the header and the name of the namespace is a bit artificial. I 
>> hope you understand that.
>> 
>> >-----Original Message-----
>> >From: DRAGE, Keith (Keith) [mailto:[email-masked]]
>> >Sent: 05 February, 2009 14:55
>> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, 
>> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
>> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda
>> (my mistake)
>> >
>> >Which is exactly what RFC 4412 specifies for all namespaces.
>> >
>> >regards
>> >
>> >Keith
>> >
>> >> -----Original Message-----
>> >> From: [email-masked] [mailto:[email-masked]]
>> >On Behalf
>> >> Of Brian Rosen
>> >> Sent: Wednesday, February 04, 2009 10:19 PM
>> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
>> Hannes (NSN -
>> >> FI/Espoo)'; 'ECRIT'
>> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
>> >> mistake)
>> >> 
>> >> The value is that in some networks where priority for
>> >emergency calls
>> >> is appropriate, and appropriate policing of marking is
>> implemented,
>> >> emergency calls will receive resource priority.
>> >> 
>> >> Not all networks would need policing.  Some will.  
>> Policing could be
>> >> to Route header/R-URI content, but other criteria are possible.
>> >> 
>> >> Not all networks will need resource priority for 
>emergency calls.  
>> >> Fine, ignore this marking/namespace.
>> >> 
>> >> Brian
>> >> > -----Original Message-----
>> >> > From: Hannes Tschofenig [mailto:[email-masked]]
>> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN - 
>> >> > FI/Espoo); 'ECRIT'
>> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
>> >> > mistake)
>> >> > 
>> >> > I don't even see the value in permitting the endpoint
>> todo the RPH
>> >> > marking.
>> >> > In addition to the security concerns there is also the
>> >problem that
>> >> > there are more options to implement without an additional value.
>> >> > 
>> >> > >-----Original Message-----
>> >> > >From: Brian Rosen [mailto:[email-masked]]
>> >> > >Sent: 05 February, 2009 00:03
>> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,
>> >> Hannes (NSN -
>> >> > >FI/Espoo)'; 'ECRIT'
>> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
>> >> > mistake)
>> >> > >
>> >> > >Hannes
>> >> > >
>> >> > >This matches my understanding precisely.  We wish to
>> >> permit endpoints
>> >> > >to mark. We do not require it, and don't necessarily
>> expect it in
>> >> > >many (even
>> >> > >most) cases.  We don't wish to see the document prohibit it.
>> >> > >We all seem to agree it has value within the Emergency
>> >Services IP
>> >> > >Networks.
>> >> > >
>> >> > >Brian
>> >> > >
>> >> > >> -----Original Message-----
>> >> > >> From: [email-masked] [mailto:[email-masked]]
>> >> > >On Behalf
>> >> > >> Of James M. Polk
>> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
>> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
>> >> FI/Espoo); 'ECRIT'
>> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: 
>Agenda (my
>> >> > >> mistake)
>> >> > >>
>> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
>> >> > >> > > James wrote:
>> >> > >> > >> you are the _lone_ voice not supporting this ID,
>> >> > >> >
>> >> > >> >Listening to the audio recording of past meetings I have to
>> >> > >say that
>> >> > >> >I
>> >> > >> was
>> >> > >> >not the only persons raising concerns about the document.
>> >> > >> >That was probably the reason why you agreed to limit the
>> >> > >scope of the
>> >> > >> >document (which you didn't later do) to get folks to agree
>> >> > >to make it
>> >> > >> a WG
>> >> > >> >item.
>> >> > >>
>> >> > >> re-listen to the audio please
>> >> > >>
>> >> > >> Ted's concerns were consistent with most (all?) other
>> >> concerns --
>> >> > >> which were based on the premise of whether or not the
>> >> UAC should be
>> >> > >> trusted to initiate the marking on the INVITE.  The
>> most recent
>> >> > >> version has backed off this to a "can" -- meaning not
>> >prohibited
>> >> > >> (i.e., no 2119 text).  I also backed off the text in the
>> >> SP domain
>> >> > >> part to "can", such that there is no 2119 text
>> >mandating or even
>> >> > >> recommending its usage there. I also do not prohibit its
>> >> > >use, based on
>> >> > >> local policy.  Keith has come forward with the
>> specific request
>> >> > >> that non-ESInet networks be allowed to mark and pay
>> >attention to
>> >> > >> this priority indication -- with IMS as the specific
>> example he
>> >> > >> wishes to have this valid for.
>> >> > >>
>> >> > >> Where there is no disagreement, save for your recent
>> >> > >pushback - is in
>> >> > >> the ESInet, which is where Brian has requested it's
>> >> > >definition in the
>> >> > >> IETF on behalf of NENA.  He's the i3 WG chair within
>> >> NENA, and if
>> >> > >> he asks for it, are you going to say you know better than he?
>> >> > >>
>> >> > >>
>> >> > >> >Btw, I not disagreeing with the document as such. I
>> >just want to
>> >> > the
>> >> > >> scope
>> >> > >> >to change. The usage of RPH within the emergency
>> >> services network
>> >> > is
>> >> > >> fine
>> >> > >> >for me. I may get convinced to start the RPH marking from
>> >> > >the the VSP
>> >> > >> >towards the PSAP. I feel uneasy about the end host doing
>> >> > >the marking.
>> >> > >>
>> >> > >> please read what I wrote above, and then re-read the
>> >most recent
>> >> > >> version of the ID. I don't have endpoints that SHOULD or
>> >> MUST mark
>> >> > >> anything wrt RPH.  I also don't want to prohibit it,
>> >> because there
>> >> > >> might be cases (that I don't know of) of valid uses
>> >> under certain
>> >> > >> circumstances.  Figure 1 is very clear that there are 3
>> >> networking
>> >> > >> parts to consider
>> >> > >>
>> >> > >> #1 - from the endpoint
>> >> > >> #2 - within the VSP
>> >> > >> #3 - within the ESInet
>> >> > >>
>> >> > >> the most recent ID version has "can" for #s 1 and 2, and
>> >> > >2119 language
>> >> > >> offering those supporting this specification will have RPH 
>> >> > >> adherence within #3 (the ESInet).
>> >> > >>
>> >> > >> What other scope changes do you want, because I haven't
>> >> heard them.
>> >> > >>
>> >> > >> I only heard you claim in email during the last IETF and in
>> >> > >the ECRIT
>> >> > >> session that RPH should not be used for priority marking
>> >> requests.
>> >> > >> This is something Keith (SIP WG chair) voiced his
>> opposition to
>> >> > >> your views regarding creating a second means for SIP to
>> >priority
>> >> > >> mark request "when SIP already has one interoperable way to 
>> >> > >> accomplish this... it's call the RP header mechanism".
>> >> > >>
>> >> > >> >I don't see advantages -- only disadvantages.
>> >> > >> >
>> >> > >> >Ciao
>> >> > >> >Hannes
>> >> > >>
>> >> > >> _______________________________________________
>> >> > >> Ecrit mailing list
>> >> > >> [email-masked]
>> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> > >
>> >> 
>> >> _______________________________________________
>> >> Ecrit mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> 
>> >
>> 
>> 
>

To: "Hannes Tschofenig" <[email-masked]>
From: Janet P Gunn <[email-masked]>
Date: Fri, 6 Feb 2009 07:11:11 -0500
Cc: 'ECRIT' <[email-masked]>, [email-masked], "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)

This is a multipart message in MIME format.
--=_alternative 0042EC5F85257555_=
Content-Type: text/plain; charset="US-ASCII"

But there is nothing IN RFC4412 that specifically addresses how to prevent 
any particular namespace being used for DoS.  Anyone/any UA can ATTEMPT to 
invoke priority treatment by attaching RPH.  For all of the 4412 
namespaces, as with the new proposed namespace, the mechanisms for 
preventing DoS are not specified in the document that defines the 
namespace. They are/will be specified elsewhere.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.

[email-masked] wrote on 02/06/2009 04:21:51 AM:

> Hi James, 
> 
> I have read RFC 4412 and also the GETS/MLPP IETF documents. What I would
> like to point out is that there is more than just a header and values 
within
> the header that have to be considered in order to make a judgement of 
what
> is appropriate and what isn't. There is an architectural question and
> whether the environment we are using the stuff is indeed providing the
> properties you need for the solution to be appropriate. 
> 
> Let me describe in more detail what I meant (and please correct me if I 
am
> wrong). 
> 
> Getting priority for SIP requests when using a GETS alike scenario means
> that the entity that issues the request is specially authorized since
> otherwise you introduce a nice denial of service attack. This 
authorization
> is tied to the entity that makes the request. For example, the person is
> working for the government and has special rights. James Bond as a (not 
so)
> secret agent might have these rights. 
> 
> The emergency services case (citizen-to-authority) is a bit different as
> there aren't really special rights with respect to authorization tied to
> individuals. Instead, the fact that something is an emergency is purely 
a
> judgement of the human that dials a special number. To deal with fraud, 
we
> discussed in the group on what we can actually do to ensure that end 
users
> do not bypass security procedures (such as authorization checks, 
charging
> and so on). Part of this investigation was the publication of
> http://www.ietf.org/rfc/rfc5069.txt that also describes this issue. 
> 
> So, imagine the implementation of a SIP proxy (and we implemented that
> stuff) that receives a call that contains a Service URN. The code 
branches
> into a special mode where everything is done so that the call receives
> appropriate treatment and does not get dropped on the floor. The way how 
the
> Service URN is placed in the message ensures that the call cannot go to 
my
> friend (instead of the PSAP) unless the end host ran LoST already. In 
the
> latter case, we discussed this also on the list for a while and Richard 
even
> wrote a draft about it in the context of the location hiding topic, we 
said
> that the proxy would have to run LoST if he cares about a potential
> fraudulent usage. 
> 
> So, what do we need todo in order to provide secure RFC 4412 
functionality
> in our context? 
> 
> Do you think that the current text in
> 
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-nam
> espace-00.txt reflects any of the above-described issues: 
> "
>    The Security considerations that apply to RFC 4412 [RFC4412] apply 
>    here.  This document introduces no new security issues relative to 
>    RFC 4412.
> "
> 
> From various discussions in GEOPRIV I recall that you are 
super-sensitive
> regarding security and privacy. For some reasons you don't seem to have 
the
> same concerns here. I would like to understand your reasoning.
> 
> Please also do me another favor: Don't always say that I don't 
understand
> the subject. Even if that would be the case it isn't particular fair 
given
> that different folks had to educate you on other topics in the past as 
well.
> Additionally, if you listen to the audio recordings then you will notice
> that Henning, Ted, and Jon do not seem to understand the issue either as
> they have raised similar issues during the F2F meetings. 
> 
> Ciao
> Hannes
> 
> 
> >Hannes - I believe it is you who do not understand RFC 4412 -- 
> >and many of us are trying to get that through to you, but you 
> >don't seem to want to listen/read.
> >
> >RFC 4412 is *for* priority marking SIP requests,
> >
> >One use is GETS.
> >
> >One use is MLPP.
> >
> >These examples are in RFC 4412 because there were specific 
> >namespaces being created for the IANA section of that document.
> >
> >Reading the whole document, you will see that RPH can be 
> >specified for other uses than GETS or MLPP specifically.
> >
> >I knew when I wrote RFC 4412 that one day we would specify a 
> >namespace for ECRIT (the "esnet" namespace now) -- but I also 
> >knew it was premature for RFC 4412 to incorporate that 
> >namespace, that a future doc to RFC 4412 would have to be 
> >written to do this. Brian and I talked about this at the 
> >original NENA meeting that created the IP WGs there (in August 
> >of 03).  We both agreed we should wait until it was 
> >appropriate to the work in the IETF to submit this document 
> >that is now 
> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >gency-rph-namespace-00.txt
> >
> >Yet, you seem to want to use some additional mechanism to 
> >indicate priority of a call in SIP.  That means you want to 
> >introduce a second way to accomplish this in SIP.  Why do you 
> >want to promote a separate way to do something SIP has already 
> >defined? That will cause interoperability issues and we both know that.
> >
> >You've said to me (and others) that you believe RPH is just 
> >another way to accomplish what sos or a URI can indicate - and 
> >you're wrong.  Your way would be _the_second_way_to_do_it, 
> >because SIP already considers RPH to be *the*way* to priority 
> >mark SIP requests.
> >
> >If you don't believe me (no comment), then why do you not 
> >believe the SIP WG chair (who knows more about SIP than both 
> >of us) - who, on this thread, has again said to you "RFC 4412 
> >(RPH) is the SIP mechanism to priority mark SIP requests"?
> >
> >Further, I believe it is inappropriate to prohibit endpoints 
> >from being able to set the esnet namespace.  I absolutely 
> >believe it will not be needed most of the time, but I believe 
> >if someone does find a valid use for endpoints to mark 
> >priority in SIP, this ID - once it has become an RFC -- will 
> >have to be obsoleted with a new RFC saying the exact opposite.
> >
> >(color me confused ... over and over again)
> >
> >James
> >
> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >>Keith, please understand that the usage of RFC 4412 for GETS and for 
> >>the type of emergency call we discuss here is different. Just looking 
> >>at the header and the name of the namespace is a bit 
> >artificial. I hope 
> >>you understand that.
> >>
> >> >-----Original Message-----
> >> >From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> >> >Sent: 05 February, 2009 14:55
> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, 
> >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my 
> >> >mistake)
> >> >
> >> >Which is exactly what RFC 4412 specifies for all namespaces.
> >> >
> >> >regards
> >> >
> >> >Keith
> >> >
> >> >> -----Original Message-----
> >> >> From: [email-masked] [mailto:[email-masked]]
> >> >On Behalf
> >> >> Of Brian Rosen
> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, 
> >Hannes (NSN 
> >> >> - FI/Espoo)'; 'ECRIT'
> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >> mistake)
> >> >>
> >> >> The value is that in some networks where priority for
> >> >emergency calls
> >> >> is appropriate, and appropriate policing of marking is 
> >implemented, 
> >> >> emergency calls will receive resource priority.
> >> >>
> >> >> Not all networks would need policing.  Some will.  Policing could 
> >> >> be to Route header/R-URI content, but other criteria are possible.
> >> >>
> >> >> Not all networks will need resource priority for emergency calls.
> >> >> Fine, ignore this marking/namespace.
> >> >>
> >> >> Brian
> >> >> > -----Original Message-----
> >> >> > From: Hannes Tschofenig [mailto:[email-masked]]
> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN - 
> >> >> > FI/Espoo); 'ECRIT'
> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >> > mistake)
> >> >> >
> >> >> > I don't even see the value in permitting the endpoint todo the 
> >> >> > RPH marking.
> >> >> > In addition to the security concerns there is also the
> >> >problem that
> >> >> > there are more options to implement without an additional value.
> >> >> >
> >> >> > >-----Original Message-----
> >> >> > >From: Brian Rosen [mailto:[email-masked]]
> >> >> > >Sent: 05 February, 2009 00:03
> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,
> >> >> Hannes (NSN -
> >> >> > >FI/Espoo)'; 'ECRIT'
> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >> > mistake)
> >> >> > >
> >> >> > >Hannes
> >> >> > >
> >> >> > >This matches my understanding precisely.  We wish to
> >> >> permit endpoints
> >> >> > >to mark. We do not require it, and don't necessarily expect it 
> >> >> > >in many (even
> >> >> > >most) cases.  We don't wish to see the document prohibit it.
> >> >> > >We all seem to agree it has value within the Emergency
> >> >Services IP
> >> >> > >Networks.
> >> >> > >
> >> >> > >Brian
> >> >> > >
> >> >> > >> -----Original Message-----
> >> >> > >> From: [email-masked] [mailto:[email-masked]]
> >> >> > >On Behalf
> >> >> > >> Of James M. Polk
> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
> >> >> FI/Espoo); 'ECRIT'
> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: 
> >Agenda (my
> >> >> > >> mistake)
> >> >> > >>
> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> >> >> > >> > > James wrote:
> >> >> > >> > >> you are the _lone_ voice not supporting this ID,
> >> >> > >> >
> >> >> > >> >Listening to the audio recording of past meetings I have to
> >> >> > >say that
> >> >> > >> >I
> >> >> > >> was
> >> >> > >> >not the only persons raising concerns about the document.
> >> >> > >> >That was probably the reason why you agreed to limit the
> >> >> > >scope of the
> >> >> > >> >document (which you didn't later do) to get folks to agree
> >> >> > >to make it
> >> >> > >> a WG
> >> >> > >> >item.
> >> >> > >>
> >> >> > >> re-listen to the audio please
> >> >> > >>
> >> >> > >> Ted's concerns were consistent with most (all?) other
> >> >> concerns --
> >> >> > >> which were based on the premise of whether or not the
> >> >> UAC should be
> >> >> > >> trusted to initiate the marking on the INVITE.  The most 
> >> >> > >> recent version has backed off this to a "can" -- meaning not
> >> >prohibited
> >> >> > >> (i.e., no 2119 text).  I also backed off the text in the
> >> >> SP domain
> >> >> > >> part to "can", such that there is no 2119 text
> >> >mandating or even
> >> >> > >> recommending its usage there. I also do not prohibit its
> >> >> > >use, based on
> >> >> > >> local policy.  Keith has come forward with the specific 
> >> >> > >> request that non-ESInet networks be allowed to mark and pay
> >> >attention to
> >> >> > >> this priority indication -- with IMS as the specific example 
> >> >> > >> he wishes to have this valid for.
> >> >> > >>
> >> >> > >> Where there is no disagreement, save for your recent
> >> >> > >pushback - is in
> >> >> > >> the ESInet, which is where Brian has requested it's
> >> >> > >definition in the
> >> >> > >> IETF on behalf of NENA.  He's the i3 WG chair within
> >> >> NENA, and if
> >> >> > >> he asks for it, are you going to say you know better than he?
> >> >> > >>
> >> >> > >>
> >> >> > >> >Btw, I not disagreeing with the document as such. I
> >> >just want to
> >> >> > the
> >> >> > >> scope
> >> >> > >> >to change. The usage of RPH within the emergency
> >> >> services network
> >> >> > is
> >> >> > >> fine
> >> >> > >> >for me. I may get convinced to start the RPH marking from
> >> >> > >the the VSP
> >> >> > >> >towards the PSAP. I feel uneasy about the end host doing
> >> >> > >the marking.
> >> >> > >>
> >> >> > >> please read what I wrote above, and then re-read the
> >> >most recent
> >> >> > >> version of the ID. I don't have endpoints that SHOULD or
> >> >> MUST mark
> >> >> > >> anything wrt RPH.  I also don't want to prohibit it,
> >> >> because there
> >> >> > >> might be cases (that I don't know of) of valid uses
> >> >> under certain
> >> >> > >> circumstances.  Figure 1 is very clear that there are 3
> >> >> networking
> >> >> > >> parts to consider
> >> >> > >>
> >> >> > >> #1 - from the endpoint
> >> >> > >> #2 - within the VSP
> >> >> > >> #3 - within the ESInet
> >> >> > >>
> >> >> > >> the most recent ID version has "can" for #s 1 and 2, and
> >> >> > >2119 language
> >> >> > >> offering those supporting this specification will have RPH 
> >> >> > >> adherence within #3 (the ESInet).
> >> >> > >>
> >> >> > >> What other scope changes do you want, because I haven't
> >> >> heard them.
> >> >> > >>
> >> >> > >> I only heard you claim in email during the last IETF and in
> >> >> > >the ECRIT
> >> >> > >> session that RPH should not be used for priority marking
> >> >> requests.
> >> >> > >> This is something Keith (SIP WG chair) voiced his opposition 
> >> >> > >> to your views regarding creating a second means for SIP to
> >> >priority
> >> >> > >> mark request "when SIP already has one interoperable way to 
> >> >> > >> accomplish this... it's call the RP header mechanism".
> >> >> > >>
> >> >> > >> >I don't see advantages -- only disadvantages.
> >> >> > >> >
> >> >> > >> >Ciao
> >> >> > >> >Hannes
> >> >> > >>
> >> >> > >> _______________________________________________
> >> >> > >> Ecrit mailing list
> >> >> > >> [email-masked]
> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> > >
> >> >>
> >> >> _______________________________________________
> >> >> Ecrit mailing list
> >> >> [email-masked]
> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>
> >> >
> >
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

--=_alternative 0042EC5F85257555_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">But there is nothing IN RFC4412 that
specifically addresses how to prevent any particular namespace being used
for DoS. &nbsp;Anyone/any UA can ATTEMPT to invoke priority treatment by
attaching RPH. &nbsp;For all of the 4412 namespaces, as with the new proposed
namespace, the mechanisms for preventing DoS are not specified in the document
that defines the namespace. They are/will be specified elsewhere.</font>
<br>
<br><font size=2 face="sans-serif">Janet<br>
<br>
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. <br>
NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.</font>
<br>
<br><font size=2><tt>[email-masked] wrote on 02/06/2009 04:21:51
AM:<br>
<br>
&gt; Hi James, <br>
&gt; <br>
&gt; I have read RFC 4412 and also the GETS/MLPP IETF documents. What I
would<br>
&gt; like to point out is that there is more than just a header and values
within<br>
&gt; the header that have to be considered in order to make a judgement
of what<br>
&gt; is appropriate and what isn't. There is an architectural question
and<br>
&gt; whether the environment we are using the stuff is indeed providing
the<br>
&gt; properties you need for the solution to be appropriate. <br>
&gt; <br>
&gt; Let me describe in more detail what I meant (and please correct me
if I am<br>
&gt; wrong). <br>
&gt; <br>
&gt; Getting priority for SIP requests when using a GETS alike scenario
means<br>
&gt; that the entity that issues the request is specially authorized since<br>
&gt; otherwise you introduce a nice denial of service attack. This authorization<br>
&gt; is tied to the entity that makes the request. For example, the person
is<br>
&gt; working for the government and has special rights. James Bond as a
(not so)<br>
&gt; secret agent might have these rights. <br>
&gt; <br>
&gt; The emergency services case (citizen-to-authority) is a bit different
as<br>
&gt; there aren't really special rights with respect to authorization tied
to<br>
&gt; individuals. Instead, the fact that something is an emergency is purely
a<br>
&gt; judgement of the human that dials a special number. To deal with fraud,
we<br>
&gt; discussed in the group on what we can actually do to ensure that end
users<br>
&gt; do not bypass security procedures (such as authorization checks, charging<br>
&gt; and so on). Part of this investigation was the publication of<br>
&gt; http://www.ietf.org/rfc/rfc5069.txt that also describes this issue.
<br>
&gt; <br>
&gt; So, imagine the implementation of a SIP proxy (and we implemented
that<br>
&gt; stuff) that receives a call that contains a Service URN. The code
branches<br>
&gt; into a special mode where everything is done so that the call receives<br>
&gt; appropriate treatment and does not get dropped on the floor. The way
how the<br>
&gt; Service URN is placed in the message ensures that the call cannot
go to my<br>
&gt; friend (instead of the PSAP) unless the end host ran LoST already.
In the<br>
&gt; latter case, we discussed this also on the list for a while and Richard
even<br>
&gt; wrote a draft about it in the context of the location hiding topic,
we said<br>
&gt; that the proxy would have to run LoST if he cares about a potential<br>
&gt; fraudulent usage. <br>
&gt; <br>
&gt; So, what do we need todo in order to provide secure RFC 4412 functionality<br>
&gt; in our context? <br>
&gt; <br>
&gt; Do you think that the current text in<br>
&gt; http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-nam<br>
&gt; espace-00.txt reflects any of the above-described issues: <br>
&gt; &quot;<br>
&gt; &nbsp; &nbsp;The Security considerations that apply to RFC 4412 [RFC4412]
apply <br>
&gt; &nbsp; &nbsp;here. &nbsp;This document introduces no new security
issues relative to <br>
&gt; &nbsp; &nbsp;RFC 4412.<br>
&gt; &quot;<br>
&gt; <br>
&gt; From various discussions in GEOPRIV I recall that you are super-sensitive<br>
&gt; regarding security and privacy. For some reasons you don't seem to
have the<br>
&gt; same concerns here. I would like to understand your reasoning.<br>
&gt; <br>
&gt; Please also do me another favor: Don't always say that I don't understand<br>
&gt; the subject. Even if that would be the case it isn't particular fair
given<br>
&gt; that different folks had to educate you on other topics in the past
as well.<br>
&gt; Additionally, if you listen to the audio recordings then you will
notice<br>
&gt; that Henning, Ted, and Jon do not seem to understand the issue either
as<br>
&gt; they have raised similar issues during the F2F meetings. <br>
&gt; <br>
&gt; Ciao<br>
&gt; Hannes<br>
&gt; <br>
&gt; <br>
&gt; &gt;Hannes - I believe it is you who do not understand RFC 4412 --
<br>
&gt; &gt;and many of us are trying to get that through to you, but you
<br>
&gt; &gt;don't seem to want to listen/read.<br>
&gt; &gt;<br>
&gt; &gt;RFC 4412 is *for* priority marking SIP requests,<br>
&gt; &gt;<br>
&gt; &gt;One use is GETS.<br>
&gt; &gt;<br>
&gt; &gt;One use is MLPP.<br>
&gt; &gt;<br>
&gt; &gt;These examples are in RFC 4412 because there were specific <br>
&gt; &gt;namespaces being created for the IANA section of that document.<br>
&gt; &gt;<br>
&gt; &gt;Reading the whole document, you will see that RPH can be <br>
&gt; &gt;specified for other uses than GETS or MLPP specifically.<br>
&gt; &gt;<br>
&gt; &gt;I knew when I wrote RFC 4412 that one day we would specify a <br>
&gt; &gt;namespace for ECRIT (the &quot;esnet&quot; namespace now) -- but
I also <br>
&gt; &gt;knew it was premature for RFC 4412 to incorporate that <br>
&gt; &gt;namespace, that a future doc to RFC 4412 would have to be <br>
&gt; &gt;written to do this. Brian and I talked about this at the <br>
&gt; &gt;original NENA meeting that created the IP WGs there (in August
<br>
&gt; &gt;of 03). &nbsp;We both agreed we should wait until it was <br>
&gt; &gt;appropriate to the work in the IETF to submit this document <br>
&gt; &gt;that is now <br>
&gt; &gt;http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer<br>
&gt; &gt;gency-rph-namespace-00.txt<br>
&gt; &gt;<br>
&gt; &gt;Yet, you seem to want to use some additional mechanism to <br>
&gt; &gt;indicate priority of a call in SIP. &nbsp;That means you want
to <br>
&gt; &gt;introduce a second way to accomplish this in SIP. &nbsp;Why do
you <br>
&gt; &gt;want to promote a separate way to do something SIP has already
<br>
&gt; &gt;defined? That will cause interoperability issues and we both know
that.<br>
&gt; &gt;<br>
&gt; &gt;You've said to me (and others) that you believe RPH is just <br>
&gt; &gt;another way to accomplish what sos or a URI can indicate - and
<br>
&gt; &gt;you're wrong. &nbsp;Your way would be _the_second_way_to_do_it,
<br>
&gt; &gt;because SIP already considers RPH to be *the*way* to priority
<br>
&gt; &gt;mark SIP requests.<br>
&gt; &gt;<br>
&gt; &gt;If you don't believe me (no comment), then why do you not <br>
&gt; &gt;believe the SIP WG chair (who knows more about SIP than both <br>
&gt; &gt;of us) - who, on this thread, has again said to you &quot;RFC
4412 <br>
&gt; &gt;(RPH) is the SIP mechanism to priority mark SIP requests&quot;?<br>
&gt; &gt;<br>
&gt; &gt;Further, I believe it is inappropriate to prohibit endpoints <br>
&gt; &gt;from being able to set the esnet namespace. &nbsp;I absolutely
<br>
&gt; &gt;believe it will not be needed most of the time, but I believe
<br>
&gt; &gt;if someone does find a valid use for endpoints to mark <br>
&gt; &gt;priority in SIP, this ID - once it has become an RFC -- will <br>
&gt; &gt;have to be obsoleted with a new RFC saying the exact opposite.<br>
&gt; &gt;<br>
&gt; &gt;(color me confused ... over and over again)<br>
&gt; &gt;<br>
&gt; &gt;James<br>
&gt; &gt;<br>
&gt; &gt;At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:<br>
&gt; &gt;&gt;Keith, please understand that the usage of RFC 4412 for GETS
and for <br>
&gt; &gt;&gt;the type of emergency call we discuss here is different. Just
looking <br>
&gt; &gt;&gt;at the header and the name of the namespace is a bit <br>
&gt; &gt;artificial. I hope <br>
&gt; &gt;&gt;you understand that.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;-----Original Message-----<br>
&gt; &gt;&gt; &gt;From: DRAGE, Keith (Keith) [mailto:[email-masked]]<br>
&gt; &gt;&gt; &gt;Sent: 05 February, 2009 14:55<br>
&gt; &gt;&gt; &gt;To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk';
'Tschofenig, <br>
&gt; &gt;&gt; &gt;Hannes (NSN - FI/Espoo)'; 'ECRIT'<br>
&gt; &gt;&gt; &gt;Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda
(my <br>
&gt; &gt;&gt; &gt;mistake)<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt;Which is exactly what RFC 4412 specifies for all namespaces.<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt;regards<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt;Keith<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt;&gt; -----Original Message-----<br>
&gt; &gt;&gt; &gt;&gt; From: [email-masked] [mailto:[email-masked]]<br>
&gt; &gt;&gt; &gt;On Behalf<br>
&gt; &gt;&gt; &gt;&gt; Of Brian Rosen<br>
&gt; &gt;&gt; &gt;&gt; Sent: Wednesday, February 04, 2009 10:19 PM<br>
&gt; &gt;&gt; &gt;&gt; To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
<br>
&gt; &gt;Hannes (NSN <br>
&gt; &gt;&gt; &gt;&gt; - FI/Espoo)'; 'ECRIT'<br>
&gt; &gt;&gt; &gt;&gt; Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
Agenda (my<br>
&gt; &gt;&gt; &gt;&gt; mistake)<br>
&gt; &gt;&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; The value is that in some networks where priority
for<br>
&gt; &gt;&gt; &gt;emergency calls<br>
&gt; &gt;&gt; &gt;&gt; is appropriate, and appropriate policing of marking
is <br>
&gt; &gt;implemented, <br>
&gt; &gt;&gt; &gt;&gt; emergency calls will receive resource priority.<br>
&gt; &gt;&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; Not all networks would need policing. &nbsp;Some
will. &nbsp;Policing could <br>
&gt; &gt;&gt; &gt;&gt; be to Route header/R-URI content, but other criteria
are possible.<br>
&gt; &gt;&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; Not all networks will need resource priority for
emergency calls.<br>
&gt; &gt;&gt; &gt;&gt; Fine, ignore this marking/namespace.<br>
&gt; &gt;&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; Brian<br>
&gt; &gt;&gt; &gt;&gt; &gt; -----Original Message-----<br>
&gt; &gt;&gt; &gt;&gt; &gt; From: Hannes Tschofenig [mailto:[email-masked]]<br>
&gt; &gt;&gt; &gt;&gt; &gt; Sent: Wednesday, February 04, 2009 5:09 PM<br>
&gt; &gt;&gt; &gt;&gt; &gt; To: 'Brian Rosen'; 'James M. Polk'; Tschofenig,
Hannes (NSN - <br>
&gt; &gt;&gt; &gt;&gt; &gt; FI/Espoo); 'ECRIT'<br>
&gt; &gt;&gt; &gt;&gt; &gt; Subject: RE: [Ecrit] ECRIT Virtual Interim
Meeting: Agenda (my<br>
&gt; &gt;&gt; &gt;&gt; &gt; mistake)<br>
&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; I don't even see the value in permitting the
endpoint todo the <br>
&gt; &gt;&gt; &gt;&gt; &gt; RPH marking.<br>
&gt; &gt;&gt; &gt;&gt; &gt; In addition to the security concerns there
is also the<br>
&gt; &gt;&gt; &gt;problem that<br>
&gt; &gt;&gt; &gt;&gt; &gt; there are more options to implement without
an additional value.<br>
&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;-----Original Message-----<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;From: Brian Rosen [mailto:[email-masked]]<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;Sent: 05 February, 2009 00:03<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;To: 'James M. Polk'; 'Hannes Tschofenig';
'Tschofenig,<br>
&gt; &gt;&gt; &gt;&gt; Hannes (NSN -<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;FI/Espoo)'; 'ECRIT'<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;Subject: RE: [Ecrit] ECRIT Virtual Interim
Meeting: Agenda (my<br>
&gt; &gt;&gt; &gt;&gt; &gt; mistake)<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;Hannes<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;This matches my understanding precisely.
&nbsp;We wish to<br>
&gt; &gt;&gt; &gt;&gt; permit endpoints<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;to mark. We do not require it, and don't
necessarily expect it <br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;in many (even<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;most) cases. &nbsp;We don't wish to see
the document prohibit it.<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;We all seem to agree it has value within
the Emergency<br>
&gt; &gt;&gt; &gt;Services IP<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;Networks.<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;Brian<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; -----Original Message-----<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; From: [email-masked] [mailto:[email-masked]]<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;On Behalf<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; Of James M. Polk<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; Sent: Wednesday, February 04, 2009
4:01 PM<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; To: Hannes Tschofenig; Tschofenig,
Hannes (NSN -<br>
&gt; &gt;&gt; &gt;&gt; FI/Espoo); 'ECRIT'<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; Subject: Re: [Ecrit] ECRIT Virtual
Interim Meeting: <br>
&gt; &gt;Agenda (my<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; mistake)<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; At 02:37 PM 2/4/2009, Hannes Tschofenig
wrote:<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt; &gt; James wrote:<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt; &gt;&gt; you are the _lone_ voice
not supporting this ID,<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;Listening to the audio recording
of past meetings I have to<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;say that<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;I<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; was<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;not the only persons raising concerns
about the document.<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;That was probably the reason why
you agreed to limit the<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;scope of the<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;document (which you didn't later
do) to get folks to agree<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;to make it<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; a WG<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;item.<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; re-listen to the audio please<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; Ted's concerns were consistent with
most (all?) other<br>
&gt; &gt;&gt; &gt;&gt; concerns --<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; which were based on the premise of
whether or not the<br>
&gt; &gt;&gt; &gt;&gt; UAC should be<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; trusted to initiate the marking on
the INVITE. &nbsp;The most <br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; recent version has backed off this
to a &quot;can&quot; -- meaning not<br>
&gt; &gt;&gt; &gt;prohibited<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; (i.e., no 2119 text). &nbsp;I also
backed off the text in the<br>
&gt; &gt;&gt; &gt;&gt; SP domain<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; part to &quot;can&quot;, such that
there is no 2119 text<br>
&gt; &gt;&gt; &gt;mandating or even<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; recommending its usage there. I also
do not prohibit its<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;use, based on<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; local policy. &nbsp;Keith has come
forward with the specific <br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; request that non-ESInet networks be
allowed to mark and pay<br>
&gt; &gt;&gt; &gt;attention to<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; this priority indication -- with IMS
as the specific example <br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; he wishes to have this valid for.<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; Where there is no disagreement, save
for your recent<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;pushback - is in<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; the ESInet, which is where Brian has
requested it's<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;definition in the<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; IETF on behalf of NENA. &nbsp;He's
the i3 WG chair within<br>
&gt; &gt;&gt; &gt;&gt; NENA, and if<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; he asks for it, are you going to say
you know better than he?<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;Btw, I not disagreeing with the
document as such. I<br>
&gt; &gt;&gt; &gt;just want to<br>
&gt; &gt;&gt; &gt;&gt; &gt; the<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; scope<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;to change. The usage of RPH within
the emergency<br>
&gt; &gt;&gt; &gt;&gt; services network<br>
&gt; &gt;&gt; &gt;&gt; &gt; is<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; fine<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;for me. I may get convinced to
start the RPH marking from<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;the the VSP<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;towards the PSAP. I feel uneasy
about the end host doing<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;the marking.<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; please read what I wrote above, and
then re-read the<br>
&gt; &gt;&gt; &gt;most recent<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; version of the ID. I don't have endpoints
that SHOULD or<br>
&gt; &gt;&gt; &gt;&gt; MUST mark<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; anything wrt RPH. &nbsp;I also don't
want to prohibit it,<br>
&gt; &gt;&gt; &gt;&gt; because there<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; might be cases (that I don't know
of) of valid uses<br>
&gt; &gt;&gt; &gt;&gt; under certain<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; circumstances. &nbsp;Figure 1 is very
clear that there are 3<br>
&gt; &gt;&gt; &gt;&gt; networking<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; parts to consider<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; #1 - from the endpoint<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; #2 - within the VSP<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; #3 - within the ESInet<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; the most recent ID version has &quot;can&quot;
for #s 1 and 2, and<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;2119 language<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; offering those supporting this specification
will have RPH <br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; adherence within #3 (the ESInet).<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; What other scope changes do you want,
because I haven't<br>
&gt; &gt;&gt; &gt;&gt; heard them.<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; I only heard you claim in email during
the last IETF and in<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;the ECRIT<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; session that RPH should not be used
for priority marking<br>
&gt; &gt;&gt; &gt;&gt; requests.<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; This is something Keith (SIP WG chair)
voiced his opposition <br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; to your views regarding creating a
second means for SIP to<br>
&gt; &gt;&gt; &gt;priority<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; mark request &quot;when SIP already
has one interoperable way to <br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; accomplish this... it's call the RP
header mechanism&quot;.<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;I don't see advantages -- only
disadvantages.<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;Ciao<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; &gt;Hannes<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; _______________________________________________<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; Ecrit mailing list<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; [email-masked]<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;&gt; https://www.ietf.org/mailman/listinfo/ecrit<br>
&gt; &gt;&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;&gt; _______________________________________________<br>
&gt; &gt;&gt; &gt;&gt; Ecrit mailing list<br>
&gt; &gt;&gt; &gt;&gt; [email-masked]<br>
&gt; &gt;&gt; &gt;&gt; https://www.ietf.org/mailman/listinfo/ecrit<br>
&gt; &gt;&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;<br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; Ecrit mailing list<br>
&gt; [email-masked]<br>
&gt; https://www.ietf.org/mailman/listinfo/ecrit<br>
</tt></font>
--=_alternative 0042EC5F85257555_=--

From: "Hannes Tschofenig" <[email-masked]>
To: "'Janet P Gunn'" <[email-masked]>
Date: Fri, 6 Feb 2009 15:07:15 +0200
Cc: 'ECRIT' <[email-masked]>, [email-masked], "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)

Who would define something that could prevent DoS problems? 

________________________________

	From: Janet P Gunn [mailto:[email-masked]] 
	Sent: 06 February, 2009 14:11
	To: Hannes Tschofenig
	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
[email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); 'James M. Polk'
	Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)

	But there is nothing IN RFC4412 that specifically addresses how to
prevent any particular namespace being used for DoS.  Anyone/any UA can
ATTEMPT to invoke priority treatment by attaching RPH.  For all of the 4412
namespaces, as with the new proposed namespace, the mechanisms for
preventing DoS are not specified in the document that defines the namespace.
They are/will be specified elsewhere. 
	
	Janet
	
	This is a PRIVATE message. If you are not the intended recipient,
please delete without copying and kindly advise us by e-mail of the mistake
in delivery. 
	NOTE: Regardless of content, this e-mail shall not operate to bind
CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose. 
	
	[email-masked] wrote on 02/06/2009 04:21:51 AM:
	
	> Hi James, 
	> 
	> I have read RFC 4412 and also the GETS/MLPP IETF documents. What I
would
	> like to point out is that there is more than just a header and
values within
	> the header that have to be considered in order to make a judgement
of what
	> is appropriate and what isn't. There is an architectural question
and
	> whether the environment we are using the stuff is indeed providing
the
	> properties you need for the solution to be appropriate. 
	> 
	> Let me describe in more detail what I meant (and please correct me
if I am
	> wrong). 
	> 
	> Getting priority for SIP requests when using a GETS alike scenario
means
	> that the entity that issues the request is specially authorized
since
	> otherwise you introduce a nice denial of service attack. This
authorization
	> is tied to the entity that makes the request. For example, the
person is
	> working for the government and has special rights. James Bond as a
(not so)
	> secret agent might have these rights. 
	> 
	> The emergency services case (citizen-to-authority) is a bit
different as
	> there aren't really special rights with respect to authorization
tied to
	> individuals. Instead, the fact that something is an emergency is
purely a
	> judgement of the human that dials a special number. To deal with
fraud, we
	> discussed in the group on what we can actually do to ensure that
end users
	> do not bypass security procedures (such as authorization checks,
charging
	> and so on). Part of this investigation was the publication of
	> http://www.ietf.org/rfc/rfc5069.txt that also describes this
issue. 
	> 
	> So, imagine the implementation of a SIP proxy (and we implemented
that
	> stuff) that receives a call that contains a Service URN. The code
branches
	> into a special mode where everything is done so that the call
receives
	> appropriate treatment and does not get dropped on the floor. The
way how the
	> Service URN is placed in the message ensures that the call cannot
go to my
	> friend (instead of the PSAP) unless the end host ran LoST already.
In the
	> latter case, we discussed this also on the list for a while and
Richard even
	> wrote a draft about it in the context of the location hiding
topic, we said
	> that the proxy would have to run LoST if he cares about a
potential
	> fraudulent usage. 
	> 
	> So, what do we need todo in order to provide secure RFC 4412
functionality
	> in our context? 
	> 
	> Do you think that the current text in
	>
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-nam
	> espace-00.txt reflects any of the above-described issues: 
	> "
	>    The Security considerations that apply to RFC 4412 [RFC4412]
apply 
	>    here.  This document introduces no new security issues relative
to 
	>    RFC 4412.
	> "
	> 
	> From various discussions in GEOPRIV I recall that you are
super-sensitive
	> regarding security and privacy. For some reasons you don't seem to
have the
	> same concerns here. I would like to understand your reasoning.
	> 
	> Please also do me another favor: Don't always say that I don't
understand
	> the subject. Even if that would be the case it isn't particular
fair given
	> that different folks had to educate you on other topics in the
past as well.
	> Additionally, if you listen to the audio recordings then you will
notice
	> that Henning, Ted, and Jon do not seem to understand the issue
either as
	> they have raised similar issues during the F2F meetings. 
	> 
	> Ciao
	> Hannes
	> 
	> 
	> >Hannes - I believe it is you who do not understand RFC 4412 -- 
	> >and many of us are trying to get that through to you, but you 
	> >don't seem to want to listen/read.
	> >
	> >RFC 4412 is *for* priority marking SIP requests,
	> >
	> >One use is GETS.
	> >
	> >One use is MLPP.
	> >
	> >These examples are in RFC 4412 because there were specific 
	> >namespaces being created for the IANA section of that document.
	> >
	> >Reading the whole document, you will see that RPH can be 
	> >specified for other uses than GETS or MLPP specifically.
	> >
	> >I knew when I wrote RFC 4412 that one day we would specify a 
	> >namespace for ECRIT (the "esnet" namespace now) -- but I also 
	> >knew it was premature for RFC 4412 to incorporate that 
	> >namespace, that a future doc to RFC 4412 would have to be 
	> >written to do this. Brian and I talked about this at the 
	> >original NENA meeting that created the IP WGs there (in August 
	> >of 03).  We both agreed we should wait until it was 
	> >appropriate to the work in the IETF to submit this document 
	> >that is now 
	> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
	> >gency-rph-namespace-00.txt
	> >
	> >Yet, you seem to want to use some additional mechanism to 
	> >indicate priority of a call in SIP.  That means you want to 
	> >introduce a second way to accomplish this in SIP.  Why do you 
	> >want to promote a separate way to do something SIP has already 
	> >defined? That will cause interoperability issues and we both know
that.
	> >
	> >You've said to me (and others) that you believe RPH is just 
	> >another way to accomplish what sos or a URI can indicate - and 
	> >you're wrong.  Your way would be _the_second_way_to_do_it, 
	> >because SIP already considers RPH to be *the*way* to priority 
	> >mark SIP requests.
	> >
	> >If you don't believe me (no comment), then why do you not 
	> >believe the SIP WG chair (who knows more about SIP than both 
	> >of us) - who, on this thread, has again said to you "RFC 4412 
	> >(RPH) is the SIP mechanism to priority mark SIP requests"?
	> >
	> >Further, I believe it is inappropriate to prohibit endpoints 
	> >from being able to set the esnet namespace.  I absolutely 
	> >believe it will not be needed most of the time, but I believe 
	> >if someone does find a valid use for endpoints to mark 
	> >priority in SIP, this ID - once it has become an RFC -- will 
	> >have to be obsoleted with a new RFC saying the exact opposite.
	> >
	> >(color me confused ... over and over again)
	> >
	> >James
	> >
	> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
	> >>Keith, please understand that the usage of RFC 4412 for GETS and
for 
	> >>the type of emergency call we discuss here is different. Just
looking 
	> >>at the header and the name of the namespace is a bit 
	> >artificial. I hope 
	> >>you understand that.
	> >>
	> >> >-----Original Message-----
	> >> >From: DRAGE, Keith (Keith) [mailto:[email-masked]]
	> >> >Sent: 05 February, 2009 14:55
	> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk';
'Tschofenig, 
	> >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
	> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my

	> >> >mistake)
	> >> >
	> >> >Which is exactly what RFC 4412 specifies for all namespaces.
	> >> >
	> >> >regards
	> >> >
	> >> >Keith
	> >> >
	> >> >> -----Original Message-----
	> >> >> From: [email-masked] [mailto:[email-masked]]
	> >> >On Behalf
	> >> >> Of Brian Rosen
	> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
	> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, 
	> >Hannes (NSN 
	> >> >> - FI/Espoo)'; 'ECRIT'
	> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda
(my
	> >> >> mistake)
	> >> >>
	> >> >> The value is that in some networks where priority for
	> >> >emergency calls
	> >> >> is appropriate, and appropriate policing of marking is 
	> >implemented, 
	> >> >> emergency calls will receive resource priority.
	> >> >>
	> >> >> Not all networks would need policing.  Some will.  Policing
could 
	> >> >> be to Route header/R-URI content, but other criteria are
possible.
	> >> >>
	> >> >> Not all networks will need resource priority for emergency
calls.
	> >> >> Fine, ignore this marking/namespace.
	> >> >>
	> >> >> Brian
	> >> >> > -----Original Message-----
	> >> >> > From: Hannes Tschofenig [mailto:[email-masked]]
	> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
	> >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes
(NSN - 
	> >> >> > FI/Espoo); 'ECRIT'
	> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda
(my
	> >> >> > mistake)
	> >> >> >
	> >> >> > I don't even see the value in permitting the endpoint todo
the 
	> >> >> > RPH marking.
	> >> >> > In addition to the security concerns there is also the
	> >> >problem that
	> >> >> > there are more options to implement without an additional
value.
	> >> >> >
	> >> >> > >-----Original Message-----
	> >> >> > >From: Brian Rosen [mailto:[email-masked]]
	> >> >> > >Sent: 05 February, 2009 00:03
	> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,
	> >> >> Hannes (NSN -
	> >> >> > >FI/Espoo)'; 'ECRIT'
	> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting:
Agenda (my
	> >> >> > mistake)
	> >> >> > >
	> >> >> > >Hannes
	> >> >> > >
	> >> >> > >This matches my understanding precisely.  We wish to
	> >> >> permit endpoints
	> >> >> > >to mark. We do not require it, and don't necessarily
expect it 
	> >> >> > >in many (even
	> >> >> > >most) cases.  We don't wish to see the document prohibit
it.
	> >> >> > >We all seem to agree it has value within the Emergency
	> >> >Services IP
	> >> >> > >Networks.
	> >> >> > >
	> >> >> > >Brian
	> >> >> > >
	> >> >> > >> -----Original Message-----
	> >> >> > >> From: [email-masked]
[mailto:[email-masked]]
	> >> >> > >On Behalf
	> >> >> > >> Of James M. Polk
	> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
	> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
	> >> >> FI/Espoo); 'ECRIT'
	> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: 
	> >Agenda (my
	> >> >> > >> mistake)
	> >> >> > >>
	> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
	> >> >> > >> > > James wrote:
	> >> >> > >> > >> you are the _lone_ voice not supporting this ID,
	> >> >> > >> >
	> >> >> > >> >Listening to the audio recording of past meetings I
have to
	> >> >> > >say that
	> >> >> > >> >I
	> >> >> > >> was
	> >> >> > >> >not the only persons raising concerns about the
document.
	> >> >> > >> >That was probably the reason why you agreed to limit
the
	> >> >> > >scope of the
	> >> >> > >> >document (which you didn't later do) to get folks to
agree
	> >> >> > >to make it
	> >> >> > >> a WG
	> >> >> > >> >item.
	> >> >> > >>
	> >> >> > >> re-listen to the audio please
	> >> >> > >>
	> >> >> > >> Ted's concerns were consistent with most (all?) other
	> >> >> concerns --
	> >> >> > >> which were based on the premise of whether or not the
	> >> >> UAC should be
	> >> >> > >> trusted to initiate the marking on the INVITE.  The
most 
	> >> >> > >> recent version has backed off this to a "can" --
meaning not
	> >> >prohibited
	> >> >> > >> (i.e., no 2119 text).  I also backed off the text in
the
	> >> >> SP domain
	> >> >> > >> part to "can", such that there is no 2119 text
	> >> >mandating or even
	> >> >> > >> recommending its usage there. I also do not prohibit
its
	> >> >> > >use, based on
	> >> >> > >> local policy.  Keith has come forward with the specific

	> >> >> > >> request that non-ESInet networks be allowed to mark and
pay
	> >> >attention to
	> >> >> > >> this priority indication -- with IMS as the specific
example 
	> >> >> > >> he wishes to have this valid for.
	> >> >> > >>
	> >> >> > >> Where there is no disagreement, save for your recent
	> >> >> > >pushback - is in
	> >> >> > >> the ESInet, which is where Brian has requested it's
	> >> >> > >definition in the
	> >> >> > >> IETF on behalf of NENA.  He's the i3 WG chair within
	> >> >> NENA, and if
	> >> >> > >> he asks for it, are you going to say you know better
than he?
	> >> >> > >>
	> >> >> > >>
	> >> >> > >> >Btw, I not disagreeing with the document as such. I
	> >> >just want to
	> >> >> > the
	> >> >> > >> scope
	> >> >> > >> >to change. The usage of RPH within the emergency
	> >> >> services network
	> >> >> > is
	> >> >> > >> fine
	> >> >> > >> >for me. I may get convinced to start the RPH marking
from
	> >> >> > >the the VSP
	> >> >> > >> >towards the PSAP. I feel uneasy about the end host
doing
	> >> >> > >the marking.
	> >> >> > >>
	> >> >> > >> please read what I wrote above, and then re-read the
	> >> >most recent
	> >> >> > >> version of the ID. I don't have endpoints that SHOULD
or
	> >> >> MUST mark
	> >> >> > >> anything wrt RPH.  I also don't want to prohibit it,
	> >> >> because there
	> >> >> > >> might be cases (that I don't know of) of valid uses
	> >> >> under certain
	> >> >> > >> circumstances.  Figure 1 is very clear that there are 3
	> >> >> networking
	> >> >> > >> parts to consider
	> >> >> > >>
	> >> >> > >> #1 - from the endpoint
	> >> >> > >> #2 - within the VSP
	> >> >> > >> #3 - within the ESInet
	> >> >> > >>
	> >> >> > >> the most recent ID version has "can" for #s 1 and 2,
and
	> >> >> > >2119 language
	> >> >> > >> offering those supporting this specification will have
RPH 
	> >> >> > >> adherence within #3 (the ESInet).
	> >> >> > >>
	> >> >> > >> What other scope changes do you want, because I haven't
	> >> >> heard them.
	> >> >> > >>
	> >> >> > >> I only heard you claim in email during the last IETF
and in
	> >> >> > >the ECRIT
	> >> >> > >> session that RPH should not be used for priority
marking
	> >> >> requests.
	> >> >> > >> This is something Keith (SIP WG chair) voiced his
opposition 
	> >> >> > >> to your views regarding creating a second means for SIP
to
	> >> >priority
	> >> >> > >> mark request "when SIP already has one interoperable
way to 
	> >> >> > >> accomplish this... it's call the RP header mechanism".
	> >> >> > >>
	> >> >> > >> >I don't see advantages -- only disadvantages.
	> >> >> > >> >
	> >> >> > >> >Ciao
	> >> >> > >> >Hannes
	> >> >> > >>
	> >> >> > >> _______________________________________________
	> >> >> > >> Ecrit mailing list
	> >> >> > >> [email-masked]
	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
	> >> >> > >
	> >> >>
	> >> >> _______________________________________________
	> >> >> Ecrit mailing list
	> >> >> [email-masked]
	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
	> >> >>
	> >> >
	> >
	> 
	> _______________________________________________
	> Ecrit mailing list
	> [email-masked]
	> https://www.ietf.org/mailman/listinfo/ecrit

From: "Hannes Tschofenig" <[email-masked]>
To: "'Hannes Tschofenig'" <[email-masked]>, "'Janet P Gunn'" <[email-masked]>
Date: Fri, 6 Feb 2009 15:41:06 +0200
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, 'ECRIT' <[email-masked]>, [email-masked]
Subject: [Ecrit] RPH

Over lunch I was also thinking how an outbound proxy would implement some of
the emergency procedures. Here are some thoughts:

---------------------------------------------------

// Process incoming message 
Parse(msg); 

// SIP INVITE without Service URN
// legacy devices
If (recognize-dialstring(msg)==TRUE) {
  // we got an emergency call going on 
  emergency=TRUE; 
  if (dialstring(msg) == 911) serviceURN=urn:service:sos;
} else if (recognize-serviceURN(msg)==TRUE) { 
  // oh. A updated device that has a service URN attached to the call
  serviceURN=retrieve_ServiceURN(msg);
  emergency=TRUE; 
} else {
  // standard SIP message
  // regular processing
  process(msg);
  emergency=FALSE;
}

If (emergency == TRUE) {
   // make sure that the emergency call does not get dropped on the floor
   // skip authorization failures 
   // give the call a special treatment 
   lots-of-code-here();

   // trigger all the QoS signaling you have in the network to make James
happy
   trigger-qos(); 

   // query location
   location=retrieve-location();

   // determine next hop
   next-hop=lost(location, serviceURN)

   // attach RPH marking to outgoing msg to make James and Keith happy
   msg=add(msg, RPH);

   send(msg, next-hop);
} 

If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
   // all the emergency related processing done already upfront
   // hence I log something. 
   log(RPH_WAS_PRESENT_JUHU);
} else if ((rph-present(msg) == TRUE) && (emergency == FALSE)) {
  // this is not an emergency call 
  // this is something like GETS
  result=special-authorization-procedure(user);
 
  if (result == AUTHORIZED) {
    // do some priority & preemption thing here. 
    // trigger all the QoS you have 
    lots-of-code-here();
  } else {
    log("NOT AUTHORIZED; don't DoS my network");
  } 
} else {
  // don't need todo any RPH processing
  // this includes the case where the call was an emergency call but the RPH

  // marking was not there. 
  nothing();
}

---------------------------------------------------

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Hannes Tschofenig
>Sent: 06 February, 2009 15:07
>To: 'Janet P Gunn'
>Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN - FI/Espoo)
>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
>
>Who would define something that could prevent DoS problems? 
>
>________________________________
>
>	From: Janet P Gunn [mailto:[email-masked]] 
>	Sent: 06 February, 2009 14:11
>	To: Hannes Tschofenig
>	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; 
>[email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); 
>'James M. Polk'
>	Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
>	
>	
>
>	But there is nothing IN RFC4412 that specifically 
>addresses how to prevent any particular namespace being used 
>for DoS.  Anyone/any UA can ATTEMPT to invoke priority 
>treatment by attaching RPH.  For all of the 4412 namespaces, 
>as with the new proposed namespace, the mechanisms for 
>preventing DoS are not specified in the document that defines 
>the namespace.
>They are/will be specified elsewhere. 
>	
>	Janet
>	
>	This is a PRIVATE message. If you are not the intended 
>recipient, please delete without copying and kindly advise us 
>by e-mail of the mistake in delivery. 
>	NOTE: Regardless of content, this e-mail shall not 
>operate to bind CSC to any order or other contract unless 
>pursuant to explicit written agreement or government 
>initiative expressly permitting the use of e-mail for such purpose. 
>	
>	[email-masked] wrote on 02/06/2009 04:21:51 AM:
>	
>	> Hi James, 
>	> 
>	> I have read RFC 4412 and also the GETS/MLPP IETF 
>documents. What I would
>	> like to point out is that there is more than just a 
>header and values within
>	> the header that have to be considered in order to 
>make a judgement of what
>	> is appropriate and what isn't. There is an 
>architectural question and
>	> whether the environment we are using the stuff is 
>indeed providing the
>	> properties you need for the solution to be appropriate. 
>	> 
>	> Let me describe in more detail what I meant (and 
>please correct me if I am
>	> wrong). 
>	> 
>	> Getting priority for SIP requests when using a GETS 
>alike scenario means
>	> that the entity that issues the request is specially 
>authorized since
>	> otherwise you introduce a nice denial of service 
>attack. This authorization
>	> is tied to the entity that makes the request. For 
>example, the person is
>	> working for the government and has special rights. 
>James Bond as a (not so)
>	> secret agent might have these rights. 
>	> 
>	> The emergency services case (citizen-to-authority) is 
>a bit different as
>	> there aren't really special rights with respect to 
>authorization tied to
>	> individuals. Instead, the fact that something is an 
>emergency is purely a
>	> judgement of the human that dials a special number. 
>To deal with fraud, we
>	> discussed in the group on what we can actually do to 
>ensure that end users
>	> do not bypass security procedures (such as 
>authorization checks, charging
>	> and so on). Part of this investigation was the publication of
>	> http://www.ietf.org/rfc/rfc5069.txt that also 
>describes this issue. 
>	> 
>	> So, imagine the implementation of a SIP proxy (and we 
>implemented that
>	> stuff) that receives a call that contains a Service 
>URN. The code branches
>	> into a special mode where everything is done so that 
>the call receives
>	> appropriate treatment and does not get dropped on the 
>floor. The way how the
>	> Service URN is placed in the message ensures that the 
>call cannot go to my
>	> friend (instead of the PSAP) unless the end host ran 
>LoST already.
>In the
>	> latter case, we discussed this also on the list for a 
>while and Richard even
>	> wrote a draft about it in the context of the location 
>hiding topic, we said
>	> that the proxy would have to run LoST if he cares 
>about a potential
>	> fraudulent usage. 
>	> 
>	> So, what do we need todo in order to provide secure 
>RFC 4412 functionality
>	> in our context? 
>	> 
>	> Do you think that the current text in
>	>
>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>gency-rph-nam
>	> espace-00.txt reflects any of the above-described issues: 
>	> "
>	>    The Security considerations that apply to RFC 4412 
>[RFC4412]
>apply 
>	>    here.  This document introduces no new security 
>issues relative
>to 
>	>    RFC 4412.
>	> "
>	> 
>	> From various discussions in GEOPRIV I recall that you 
>are super-sensitive
>	> regarding security and privacy. For some reasons you 
>don't seem to have the
>	> same concerns here. I would like to understand your reasoning.
>	> 
>	> Please also do me another favor: Don't always say 
>that I don't understand
>	> the subject. Even if that would be the case it isn't 
>particular fair given
>	> that different folks had to educate you on other 
>topics in the past as well.
>	> Additionally, if you listen to the audio recordings 
>then you will notice
>	> that Henning, Ted, and Jon do not seem to understand 
>the issue either as
>	> they have raised similar issues during the F2F meetings. 
>	> 
>	> Ciao
>	> Hannes
>	> 
>	> 
>	> >Hannes - I believe it is you who do not understand 
>RFC 4412 -- 
>	> >and many of us are trying to get that through to 
>you, but you 
>	> >don't seem to want to listen/read.
>	> >
>	> >RFC 4412 is *for* priority marking SIP requests,
>	> >
>	> >One use is GETS.
>	> >
>	> >One use is MLPP.
>	> >
>	> >These examples are in RFC 4412 because there were specific 
>	> >namespaces being created for the IANA section of 
>that document.
>	> >
>	> >Reading the whole document, you will see that RPH can be 
>	> >specified for other uses than GETS or MLPP specifically.
>	> >
>	> >I knew when I wrote RFC 4412 that one day we would specify a 
>	> >namespace for ECRIT (the "esnet" namespace now) -- 
>but I also 
>	> >knew it was premature for RFC 4412 to incorporate that 
>	> >namespace, that a future doc to RFC 4412 would have to be 
>	> >written to do this. Brian and I talked about this at the 
>	> >original NENA meeting that created the IP WGs there 
>(in August 
>	> >of 03).  We both agreed we should wait until it was 
>	> >appropriate to the work in the IETF to submit this document 
>	> >that is now 
>	> 
>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>	> >gency-rph-namespace-00.txt
>	> >
>	> >Yet, you seem to want to use some additional mechanism to 
>	> >indicate priority of a call in SIP.  That means you want to 
>	> >introduce a second way to accomplish this in SIP.  
>Why do you 
>	> >want to promote a separate way to do something SIP 
>has already 
>	> >defined? That will cause interoperability issues and 
>we both know that.
>	> >
>	> >You've said to me (and others) that you believe RPH is just 
>	> >another way to accomplish what sos or a URI can 
>indicate - and 
>	> >you're wrong.  Your way would be _the_second_way_to_do_it, 
>	> >because SIP already considers RPH to be *the*way* to 
>priority 
>	> >mark SIP requests.
>	> >
>	> >If you don't believe me (no comment), then why do you not 
>	> >believe the SIP WG chair (who knows more about SIP than both 
>	> >of us) - who, on this thread, has again said to you 
>"RFC 4412 
>	> >(RPH) is the SIP mechanism to priority mark SIP requests"?
>	> >
>	> >Further, I believe it is inappropriate to prohibit endpoints 
>	> >from being able to set the esnet namespace.  I absolutely 
>	> >believe it will not be needed most of the time, but 
>I believe 
>	> >if someone does find a valid use for endpoints to mark 
>	> >priority in SIP, this ID - once it has become an RFC -- will 
>	> >have to be obsoleted with a new RFC saying the exact 
>opposite.
>	> >
>	> >(color me confused ... over and over again)
>	> >
>	> >James
>	> >
>	> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>	> >>Keith, please understand that the usage of RFC 4412 
>for GETS and for 
>	> >>the type of emergency call we discuss here is 
>different. Just looking 
>	> >>at the header and the name of the namespace is a bit 
>	> >artificial. I hope 
>	> >>you understand that.
>	> >>
>	> >> >-----Original Message-----
>	> >> >From: DRAGE, Keith (Keith) 
>[mailto:[email-masked]]
>	> >> >Sent: 05 February, 2009 14:55
>	> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. 
>Polk'; 'Tschofenig, 
>	> >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
>	> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim 
>Meeting: Agenda (my
>
>	> >> >mistake)
>	> >> >
>	> >> >Which is exactly what RFC 4412 specifies for all 
>namespaces.
>	> >> >
>	> >> >regards
>	> >> >
>	> >> >Keith
>	> >> >
>	> >> >> -----Original Message-----
>	> >> >> From: [email-masked] 
>[mailto:[email-masked]]
>	> >> >On Behalf
>	> >> >> Of Brian Rosen
>	> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
>	> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, 
>	> >Hannes (NSN 
>	> >> >> - FI/Espoo)'; 'ECRIT'
>	> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim 
>Meeting: Agenda (my
>	> >> >> mistake)
>	> >> >>
>	> >> >> The value is that in some networks where priority for
>	> >> >emergency calls
>	> >> >> is appropriate, and appropriate policing of marking is 
>	> >implemented, 
>	> >> >> emergency calls will receive resource priority.
>	> >> >>
>	> >> >> Not all networks would need policing.  Some 
>will.  Policing could 
>	> >> >> be to Route header/R-URI content, but other 
>criteria are possible.
>	> >> >>
>	> >> >> Not all networks will need resource priority 
>for emergency calls.
>	> >> >> Fine, ignore this marking/namespace.
>	> >> >>
>	> >> >> Brian
>	> >> >> > -----Original Message-----
>	> >> >> > From: Hannes Tschofenig 
>[mailto:[email-masked]]
>	> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>	> >> >> > To: 'Brian Rosen'; 'James M. Polk'; 
>Tschofenig, Hannes (NSN - 
>	> >> >> > FI/Espoo); 'ECRIT'
>	> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim 
>Meeting: Agenda (my
>	> >> >> > mistake)
>	> >> >> >
>	> >> >> > I don't even see the value in permitting the 
>endpoint todo the 
>	> >> >> > RPH marking.
>	> >> >> > In addition to the security concerns there is also the
>	> >> >problem that
>	> >> >> > there are more options to implement without 
>an additional value.
>	> >> >> >
>	> >> >> > >-----Original Message-----
>	> >> >> > >From: Brian Rosen [mailto:[email-masked]]
>	> >> >> > >Sent: 05 February, 2009 00:03
>	> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 
>'Tschofenig,
>	> >> >> Hannes (NSN -
>	> >> >> > >FI/Espoo)'; 'ECRIT'
>	> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting:
>Agenda (my
>	> >> >> > mistake)
>	> >> >> > >
>	> >> >> > >Hannes
>	> >> >> > >
>	> >> >> > >This matches my understanding precisely.  We wish to
>	> >> >> permit endpoints
>	> >> >> > >to mark. We do not require it, and don't 
>necessarily expect it 
>	> >> >> > >in many (even
>	> >> >> > >most) cases.  We don't wish to see the 
>document prohibit it.
>	> >> >> > >We all seem to agree it has value within the 
>Emergency
>	> >> >Services IP
>	> >> >> > >Networks.
>	> >> >> > >
>	> >> >> > >Brian
>	> >> >> > >
>	> >> >> > >> -----Original Message-----
>	> >> >> > >> From: [email-masked] 
>[mailto:[email-masked]]
>	> >> >> > >On Behalf
>	> >> >> > >> Of James M. Polk
>	> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
>	> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
>	> >> >> FI/Espoo); 'ECRIT'
>	> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim 
>Meeting: 
>	> >Agenda (my
>	> >> >> > >> mistake)
>	> >> >> > >>
>	> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
>	> >> >> > >> > > James wrote:
>	> >> >> > >> > >> you are the _lone_ voice not 
>supporting this ID,
>	> >> >> > >> >
>	> >> >> > >> >Listening to the audio recording of past 
>meetings I have to
>	> >> >> > >say that
>	> >> >> > >> >I
>	> >> >> > >> was
>	> >> >> > >> >not the only persons raising concerns 
>about the document.
>	> >> >> > >> >That was probably the reason why you 
>agreed to limit the
>	> >> >> > >scope of the
>	> >> >> > >> >document (which you didn't later do) to 
>get folks to agree
>	> >> >> > >to make it
>	> >> >> > >> a WG
>	> >> >> > >> >item.
>	> >> >> > >>
>	> >> >> > >> re-listen to the audio please
>	> >> >> > >>
>	> >> >> > >> Ted's concerns were consistent with most 
>(all?) other
>	> >> >> concerns --
>	> >> >> > >> which were based on the premise of whether 
>or not the
>	> >> >> UAC should be
>	> >> >> > >> trusted to initiate the marking on the 
>INVITE.  The most 
>	> >> >> > >> recent version has backed off this to a 
>"can" -- meaning not
>	> >> >prohibited
>	> >> >> > >> (i.e., no 2119 text).  I also backed off 
>the text in the
>	> >> >> SP domain
>	> >> >> > >> part to "can", such that there is no 2119 text
>	> >> >mandating or even
>	> >> >> > >> recommending its usage there. I also do 
>not prohibit its
>	> >> >> > >use, based on
>	> >> >> > >> local policy.  Keith has come forward with 
>the specific
>
>	> >> >> > >> request that non-ESInet networks be 
>allowed to mark and pay
>	> >> >attention to
>	> >> >> > >> this priority indication -- with IMS as 
>the specific example 
>	> >> >> > >> he wishes to have this valid for.
>	> >> >> > >>
>	> >> >> > >> Where there is no disagreement, save for 
>your recent
>	> >> >> > >pushback - is in
>	> >> >> > >> the ESInet, which is where Brian has requested it's
>	> >> >> > >definition in the
>	> >> >> > >> IETF on behalf of NENA.  He's the i3 WG 
>chair within
>	> >> >> NENA, and if
>	> >> >> > >> he asks for it, are you going to say you 
>know better than he?
>	> >> >> > >>
>	> >> >> > >>
>	> >> >> > >> >Btw, I not disagreeing with the document 
>as such. I
>	> >> >just want to
>	> >> >> > the
>	> >> >> > >> scope
>	> >> >> > >> >to change. The usage of RPH within the emergency
>	> >> >> services network
>	> >> >> > is
>	> >> >> > >> fine
>	> >> >> > >> >for me. I may get convinced to start the 
>RPH marking from
>	> >> >> > >the the VSP
>	> >> >> > >> >towards the PSAP. I feel uneasy about the 
>end host doing
>	> >> >> > >the marking.
>	> >> >> > >>
>	> >> >> > >> please read what I wrote above, and then 
>re-read the
>	> >> >most recent
>	> >> >> > >> version of the ID. I don't have endpoints 
>that SHOULD or
>	> >> >> MUST mark
>	> >> >> > >> anything wrt RPH.  I also don't want to 
>prohibit it,
>	> >> >> because there
>	> >> >> > >> might be cases (that I don't know of) of valid uses
>	> >> >> under certain
>	> >> >> > >> circumstances.  Figure 1 is very clear 
>that there are 3
>	> >> >> networking
>	> >> >> > >> parts to consider
>	> >> >> > >>
>	> >> >> > >> #1 - from the endpoint
>	> >> >> > >> #2 - within the VSP
>	> >> >> > >> #3 - within the ESInet
>	> >> >> > >>
>	> >> >> > >> the most recent ID version has "can" for 
>#s 1 and 2, and
>	> >> >> > >2119 language
>	> >> >> > >> offering those supporting this 
>specification will have RPH 
>	> >> >> > >> adherence within #3 (the ESInet).
>	> >> >> > >>
>	> >> >> > >> What other scope changes do you want, 
>because I haven't
>	> >> >> heard them.
>	> >> >> > >>
>	> >> >> > >> I only heard you claim in email during the 
>last IETF and in
>	> >> >> > >the ECRIT
>	> >> >> > >> session that RPH should not be used for 
>priority marking
>	> >> >> requests.
>	> >> >> > >> This is something Keith (SIP WG chair) 
>voiced his opposition 
>	> >> >> > >> to your views regarding creating a second 
>means for SIP to
>	> >> >priority
>	> >> >> > >> mark request "when SIP already has one 
>interoperable way to 
>	> >> >> > >> accomplish this... it's call the RP header 
>mechanism".
>	> >> >> > >>
>	> >> >> > >> >I don't see advantages -- only disadvantages.
>	> >> >> > >> >
>	> >> >> > >> >Ciao
>	> >> >> > >> >Hannes
>	> >> >> > >>
>	> >> >> > >> _______________________________________________
>	> >> >> > >> Ecrit mailing list
>	> >> >> > >> [email-masked]
>	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>	> >> >> > >
>	> >> >>
>	> >> >> _______________________________________________
>	> >> >> Ecrit mailing list
>	> >> >> [email-masked]
>	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>	> >> >>
>	> >> >
>	> >
>	> 
>	> _______________________________________________
>	> Ecrit mailing list
>	> [email-masked]
>	> https://www.ietf.org/mailman/listinfo/ecrit
>	
>
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>

From: "Brian Rosen" <[email-masked]>
To: "'Hannes Tschofenig'" <[email-masked]>, "'Janet P Gunn'" <[email-masked]>
Date: Fri, 6 Feb 2009 09:58:47 -0500
Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" <[email-masked]>, 'ECRIT' <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] RPH

Hannes

You need to talk to people who really implement this kind of thing.  You are
way off.

When you implement a resource priority system, the point of doing that is to
look though the queue of work and pick out the ones with priority, handling
them first.  You don't do all the parsing, you don't do a lot of decision
tree.  

Typically:
Check for DoS things, like too big messages, etc
Do a quick scan for the RPH message header
If found:
Parse the message
Determine validity
Determine priority
Queue on the correct work queue

The first two actions have to be very fast.  Anyone who builds a SIP thingie
will tell you that parsing is one of the big cycle consumers: if you have to
parse every message BEFORE you determine priority, you can't give much
resource priority.  Once you get the whole message parsed, you might as well
finish working on it, because you've done so much of the work. OTHOH,
finding the end-of-message delimiter and doing a quick string search for RPH
is fast.  If you are doing priority, you need to keep all the priority
processing pretty uniform, and pretty simple, or you tend to spend too much
time futzing around figuring out what to do.  You put all the priority
related stuff together, and use as much common code as possible.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Tschofenig
> Sent: Friday, February 06, 2009 8:41 AM
> To: 'Hannes Tschofenig'; 'Janet P Gunn'
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-
> [email-masked]
> Subject: [Ecrit] RPH
> 
> Over lunch I was also thinking how an outbound proxy would implement
> some of
> the emergency procedures. Here are some thoughts:
> 
> ---------------------------------------------------
> 
> // Process incoming message
> Parse(msg);
> 
> // SIP INVITE without Service URN
> // legacy devices
> If (recognize-dialstring(msg)==TRUE) {
>   // we got an emergency call going on
>   emergency=TRUE;
>   if (dialstring(msg) == 911) serviceURN=urn:service:sos;
> } else if (recognize-serviceURN(msg)==TRUE) {
>   // oh. A updated device that has a service URN attached to the call
>   serviceURN=retrieve_ServiceURN(msg);
>   emergency=TRUE;
> } else {
>   // standard SIP message
>   // regular processing
>   process(msg);
>   emergency=FALSE;
> }
> 
> If (emergency == TRUE) {
>    // make sure that the emergency call does not get dropped on the
> floor
>    // skip authorization failures
>    // give the call a special treatment
>    lots-of-code-here();
> 
>    // trigger all the QoS signaling you have in the network to make
> James
> happy
>    trigger-qos();
> 
>    // query location
>    location=retrieve-location();
> 
>    // determine next hop
>    next-hop=lost(location, serviceURN)
> 
>    // attach RPH marking to outgoing msg to make James and Keith happy
>    msg=add(msg, RPH);
> 
>    send(msg, next-hop);
> }
> 
> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
>    // all the emergency related processing done already upfront
>    // hence I log something.
>    log(RPH_WAS_PRESENT_JUHU);
> } else if ((rph-present(msg) == TRUE) && (emergency == FALSE)) {
>   // this is not an emergency call
>   // this is something like GETS
>   result=special-authorization-procedure(user);
> 
>   if (result == AUTHORIZED) {
>     // do some priority & preemption thing here.
>     // trigger all the QoS you have
>     lots-of-code-here();
>   } else {
>     log("NOT AUTHORIZED; don't DoS my network");
>   }
> } else {
>   // don't need todo any RPH processing
>   // this includes the case where the call was an emergency call but
> the RPH
> 
>   // marking was not there.
>   nothing();
> }
> 
> ---------------------------------------------------
> 
> 
> Ciao
> Hannes
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]
> >On Behalf Of Hannes Tschofenig
> >Sent: 06 February, 2009 15:07
> >To: 'Janet P Gunn'
> >Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
> FI/Espoo)
> >Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
> >
> >Who would define something that could prevent DoS problems?
> >
> >________________________________
> >
> >	From: Janet P Gunn [mailto:[email-masked]]
> >	Sent: 06 February, 2009 14:11
> >	To: Hannes Tschofenig
> >	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >[email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
> >'James M. Polk'
> >	Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
> >
> >
> >
> >	But there is nothing IN RFC4412 that specifically
> >addresses how to prevent any particular namespace being used
> >for DoS.  Anyone/any UA can ATTEMPT to invoke priority
> >treatment by attaching RPH.  For all of the 4412 namespaces,
> >as with the new proposed namespace, the mechanisms for
> >preventing DoS are not specified in the document that defines
> >the namespace.
> >They are/will be specified elsewhere.
> >
> >	Janet
> >
> >	This is a PRIVATE message. If you are not the intended
> >recipient, please delete without copying and kindly advise us
> >by e-mail of the mistake in delivery.
> >	NOTE: Regardless of content, this e-mail shall not
> >operate to bind CSC to any order or other contract unless
> >pursuant to explicit written agreement or government
> >initiative expressly permitting the use of e-mail for such purpose.
> >
> >	[email-masked] wrote on 02/06/2009 04:21:51 AM:
> >
> >	> Hi James,
> >	>
> >	> I have read RFC 4412 and also the GETS/MLPP IETF
> >documents. What I would
> >	> like to point out is that there is more than just a
> >header and values within
> >	> the header that have to be considered in order to
> >make a judgement of what
> >	> is appropriate and what isn't. There is an
> >architectural question and
> >	> whether the environment we are using the stuff is
> >indeed providing the
> >	> properties you need for the solution to be appropriate.
> >	>
> >	> Let me describe in more detail what I meant (and
> >please correct me if I am
> >	> wrong).
> >	>
> >	> Getting priority for SIP requests when using a GETS
> >alike scenario means
> >	> that the entity that issues the request is specially
> >authorized since
> >	> otherwise you introduce a nice denial of service
> >attack. This authorization
> >	> is tied to the entity that makes the request. For
> >example, the person is
> >	> working for the government and has special rights.
> >James Bond as a (not so)
> >	> secret agent might have these rights.
> >	>
> >	> The emergency services case (citizen-to-authority) is
> >a bit different as
> >	> there aren't really special rights with respect to
> >authorization tied to
> >	> individuals. Instead, the fact that something is an
> >emergency is purely a
> >	> judgement of the human that dials a special number.
> >To deal with fraud, we
> >	> discussed in the group on what we can actually do to
> >ensure that end users
> >	> do not bypass security procedures (such as
> >authorization checks, charging
> >	> and so on). Part of this investigation was the publication of
> >	> http://www.ietf.org/rfc/rfc5069.txt that also
> >describes this issue.
> >	>
> >	> So, imagine the implementation of a SIP proxy (and we
> >implemented that
> >	> stuff) that receives a call that contains a Service
> >URN. The code branches
> >	> into a special mode where everything is done so that
> >the call receives
> >	> appropriate treatment and does not get dropped on the
> >floor. The way how the
> >	> Service URN is placed in the message ensures that the
> >call cannot go to my
> >	> friend (instead of the PSAP) unless the end host ran
> >LoST already.
> >In the
> >	> latter case, we discussed this also on the list for a
> >while and Richard even
> >	> wrote a draft about it in the context of the location
> >hiding topic, we said
> >	> that the proxy would have to run LoST if he cares
> >about a potential
> >	> fraudulent usage.
> >	>
> >	> So, what do we need todo in order to provide secure
> >RFC 4412 functionality
> >	> in our context?
> >	>
> >	> Do you think that the current text in
> >	>
> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >gency-rph-nam
> >	> espace-00.txt reflects any of the above-described issues:
> >	> "
> >	>    The Security considerations that apply to RFC 4412
> >[RFC4412]
> >apply
> >	>    here.  This document introduces no new security
> >issues relative
> >to
> >	>    RFC 4412.
> >	> "
> >	>
> >	> From various discussions in GEOPRIV I recall that you
> >are super-sensitive
> >	> regarding security and privacy. For some reasons you
> >don't seem to have the
> >	> same concerns here. I would like to understand your reasoning.
> >	>
> >	> Please also do me another favor: Don't always say
> >that I don't understand
> >	> the subject. Even if that would be the case it isn't
> >particular fair given
> >	> that different folks had to educate you on other
> >topics in the past as well.
> >	> Additionally, if you listen to the audio recordings
> >then you will notice
> >	> that Henning, Ted, and Jon do not seem to understand
> >the issue either as
> >	> they have raised similar issues during the F2F meetings.
> >	>
> >	> Ciao
> >	> Hannes
> >	>
> >	>
> >	> >Hannes - I believe it is you who do not understand
> >RFC 4412 --
> >	> >and many of us are trying to get that through to
> >you, but you
> >	> >don't seem to want to listen/read.
> >	> >
> >	> >RFC 4412 is *for* priority marking SIP requests,
> >	> >
> >	> >One use is GETS.
> >	> >
> >	> >One use is MLPP.
> >	> >
> >	> >These examples are in RFC 4412 because there were specific
> >	> >namespaces being created for the IANA section of
> >that document.
> >	> >
> >	> >Reading the whole document, you will see that RPH can be
> >	> >specified for other uses than GETS or MLPP specifically.
> >	> >
> >	> >I knew when I wrote RFC 4412 that one day we would specify a
> >	> >namespace for ECRIT (the "esnet" namespace now) --
> >but I also
> >	> >knew it was premature for RFC 4412 to incorporate that
> >	> >namespace, that a future doc to RFC 4412 would have to be
> >	> >written to do this. Brian and I talked about this at the
> >	> >original NENA meeting that created the IP WGs there
> >(in August
> >	> >of 03).  We both agreed we should wait until it was
> >	> >appropriate to the work in the IETF to submit this document
> >	> >that is now
> >	>
> >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >	> >gency-rph-namespace-00.txt
> >	> >
> >	> >Yet, you seem to want to use some additional mechanism to
> >	> >indicate priority of a call in SIP.  That means you want to
> >	> >introduce a second way to accomplish this in SIP.
> >Why do you
> >	> >want to promote a separate way to do something SIP
> >has already
> >	> >defined? That will cause interoperability issues and
> >we both know that.
> >	> >
> >	> >You've said to me (and others) that you believe RPH is just
> >	> >another way to accomplish what sos or a URI can
> >indicate - and
> >	> >you're wrong.  Your way would be _the_second_way_to_do_it,
> >	> >because SIP already considers RPH to be *the*way* to
> >priority
> >	> >mark SIP requests.
> >	> >
> >	> >If you don't believe me (no comment), then why do you not
> >	> >believe the SIP WG chair (who knows more about SIP than both
> >	> >of us) - who, on this thread, has again said to you
> >"RFC 4412
> >	> >(RPH) is the SIP mechanism to priority mark SIP requests"?
> >	> >
> >	> >Further, I believe it is inappropriate to prohibit endpoints
> >	> >from being able to set the esnet namespace.  I absolutely
> >	> >believe it will not be needed most of the time, but
> >I believe
> >	> >if someone does find a valid use for endpoints to mark
> >	> >priority in SIP, this ID - once it has become an RFC -- will
> >	> >have to be obsoleted with a new RFC saying the exact
> >opposite.
> >	> >
> >	> >(color me confused ... over and over again)
> >	> >
> >	> >James
> >	> >
> >	> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >	> >>Keith, please understand that the usage of RFC 4412
> >for GETS and for
> >	> >>the type of emergency call we discuss here is
> >different. Just looking
> >	> >>at the header and the name of the namespace is a bit
> >	> >artificial. I hope
> >	> >>you understand that.
> >	> >>
> >	> >> >-----Original Message-----
> >	> >> >From: DRAGE, Keith (Keith)
> >[mailto:[email-masked]]
> >	> >> >Sent: 05 February, 2009 14:55
> >	> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
> >Polk'; 'Tschofenig,
> >	> >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >	> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
> >Meeting: Agenda (my
> >
> >	> >> >mistake)
> >	> >> >
> >	> >> >Which is exactly what RFC 4412 specifies for all
> >namespaces.
> >	> >> >
> >	> >> >regards
> >	> >> >
> >	> >> >Keith
> >	> >> >
> >	> >> >> -----Original Message-----
> >	> >> >> From: [email-masked]
> >[mailto:[email-masked]]
> >	> >> >On Behalf
> >	> >> >> Of Brian Rosen
> >	> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >	> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
> >	> >Hannes (NSN
> >	> >> >> - FI/Espoo)'; 'ECRIT'
> >	> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >Meeting: Agenda (my
> >	> >> >> mistake)
> >	> >> >>
> >	> >> >> The value is that in some networks where priority for
> >	> >> >emergency calls
> >	> >> >> is appropriate, and appropriate policing of marking is
> >	> >implemented,
> >	> >> >> emergency calls will receive resource priority.
> >	> >> >>
> >	> >> >> Not all networks would need policing.  Some
> >will.  Policing could
> >	> >> >> be to Route header/R-URI content, but other
> >criteria are possible.
> >	> >> >>
> >	> >> >> Not all networks will need resource priority
> >for emergency calls.
> >	> >> >> Fine, ignore this marking/namespace.
> >	> >> >>
> >	> >> >> Brian
> >	> >> >> > -----Original Message-----
> >	> >> >> > From: Hannes Tschofenig
> >[mailto:[email-masked]]
> >	> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >	> >> >> > To: 'Brian Rosen'; 'James M. Polk';
> >Tschofenig, Hannes (NSN -
> >	> >> >> > FI/Espoo); 'ECRIT'
> >	> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
> >Meeting: Agenda (my
> >	> >> >> > mistake)
> >	> >> >> >
> >	> >> >> > I don't even see the value in permitting the
> >endpoint todo the
> >	> >> >> > RPH marking.
> >	> >> >> > In addition to the security concerns there is also the
> >	> >> >problem that
> >	> >> >> > there are more options to implement without
> >an additional value.
> >	> >> >> >
> >	> >> >> > >-----Original Message-----
> >	> >> >> > >From: Brian Rosen [mailto:[email-masked]]
> >	> >> >> > >Sent: 05 February, 2009 00:03
> >	> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
> >'Tschofenig,
> >	> >> >> Hannes (NSN -
> >	> >> >> > >FI/Espoo)'; 'ECRIT'
> >	> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting:
> >Agenda (my
> >	> >> >> > mistake)
> >	> >> >> > >
> >	> >> >> > >Hannes
> >	> >> >> > >
> >	> >> >> > >This matches my understanding precisely.  We wish to
> >	> >> >> permit endpoints
> >	> >> >> > >to mark. We do not require it, and don't
> >necessarily expect it
> >	> >> >> > >in many (even
> >	> >> >> > >most) cases.  We don't wish to see the
> >document prohibit it.
> >	> >> >> > >We all seem to agree it has value within the
> >Emergency
> >	> >> >Services IP
> >	> >> >> > >Networks.
> >	> >> >> > >
> >	> >> >> > >Brian
> >	> >> >> > >
> >	> >> >> > >> -----Original Message-----
> >	> >> >> > >> From: [email-masked]
> >[mailto:[email-masked]]
> >	> >> >> > >On Behalf
> >	> >> >> > >> Of James M. Polk
> >	> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> >	> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
> >	> >> >> FI/Espoo); 'ECRIT'
> >	> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >Meeting:
> >	> >Agenda (my
> >	> >> >> > >> mistake)
> >	> >> >> > >>
> >	> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> >	> >> >> > >> > > James wrote:
> >	> >> >> > >> > >> you are the _lone_ voice not
> >supporting this ID,
> >	> >> >> > >> >
> >	> >> >> > >> >Listening to the audio recording of past
> >meetings I have to
> >	> >> >> > >say that
> >	> >> >> > >> >I
> >	> >> >> > >> was
> >	> >> >> > >> >not the only persons raising concerns
> >about the document.
> >	> >> >> > >> >That was probably the reason why you
> >agreed to limit the
> >	> >> >> > >scope of the
> >	> >> >> > >> >document (which you didn't later do) to
> >get folks to agree
> >	> >> >> > >to make it
> >	> >> >> > >> a WG
> >	> >> >> > >> >item.
> >	> >> >> > >>
> >	> >> >> > >> re-listen to the audio please
> >	> >> >> > >>
> >	> >> >> > >> Ted's concerns were consistent with most
> >(all?) other
> >	> >> >> concerns --
> >	> >> >> > >> which were based on the premise of whether
> >or not the
> >	> >> >> UAC should be
> >	> >> >> > >> trusted to initiate the marking on the
> >INVITE.  The most
> >	> >> >> > >> recent version has backed off this to a
> >"can" -- meaning not
> >	> >> >prohibited
> >	> >> >> > >> (i.e., no 2119 text).  I also backed off
> >the text in the
> >	> >> >> SP domain
> >	> >> >> > >> part to "can", such that there is no 2119 text
> >	> >> >mandating or even
> >	> >> >> > >> recommending its usage there. I also do
> >not prohibit its
> >	> >> >> > >use, based on
> >	> >> >> > >> local policy.  Keith has come forward with
> >the specific
> >
> >	> >> >> > >> request that non-ESInet networks be
> >allowed to mark and pay
> >	> >> >attention to
> >	> >> >> > >> this priority indication -- with IMS as
> >the specific example
> >	> >> >> > >> he wishes to have this valid for.
> >	> >> >> > >>
> >	> >> >> > >> Where there is no disagreement, save for
> >your recent
> >	> >> >> > >pushback - is in
> >	> >> >> > >> the ESInet, which is where Brian has requested it's
> >	> >> >> > >definition in the
> >	> >> >> > >> IETF on behalf of NENA.  He's the i3 WG
> >chair within
> >	> >> >> NENA, and if
> >	> >> >> > >> he asks for it, are you going to say you
> >know better than he?
> >	> >> >> > >>
> >	> >> >> > >>
> >	> >> >> > >> >Btw, I not disagreeing with the document
> >as such. I
> >	> >> >just want to
> >	> >> >> > the
> >	> >> >> > >> scope
> >	> >> >> > >> >to change. The usage of RPH within the emergency
> >	> >> >> services network
> >	> >> >> > is
> >	> >> >> > >> fine
> >	> >> >> > >> >for me. I may get convinced to start the
> >RPH marking from
> >	> >> >> > >the the VSP
> >	> >> >> > >> >towards the PSAP. I feel uneasy about the
> >end host doing
> >	> >> >> > >the marking.
> >	> >> >> > >>
> >	> >> >> > >> please read what I wrote above, and then
> >re-read the
> >	> >> >most recent
> >	> >> >> > >> version of the ID. I don't have endpoints
> >that SHOULD or
> >	> >> >> MUST mark
> >	> >> >> > >> anything wrt RPH.  I also don't want to
> >prohibit it,
> >	> >> >> because there
> >	> >> >> > >> might be cases (that I don't know of) of valid uses
> >	> >> >> under certain
> >	> >> >> > >> circumstances.  Figure 1 is very clear
> >that there are 3
> >	> >> >> networking
> >	> >> >> > >> parts to consider
> >	> >> >> > >>
> >	> >> >> > >> #1 - from the endpoint
> >	> >> >> > >> #2 - within the VSP
> >	> >> >> > >> #3 - within the ESInet
> >	> >> >> > >>
> >	> >> >> > >> the most recent ID version has "can" for
> >#s 1 and 2, and
> >	> >> >> > >2119 language
> >	> >> >> > >> offering those supporting this
> >specification will have RPH
> >	> >> >> > >> adherence within #3 (the ESInet).
> >	> >> >> > >>
> >	> >> >> > >> What other scope changes do you want,
> >because I haven't
> >	> >> >> heard them.
> >	> >> >> > >>
> >	> >> >> > >> I only heard you claim in email during the
> >last IETF and in
> >	> >> >> > >the ECRIT
> >	> >> >> > >> session that RPH should not be used for
> >priority marking
> >	> >> >> requests.
> >	> >> >> > >> This is something Keith (SIP WG chair)
> >voiced his opposition
> >	> >> >> > >> to your views regarding creating a second
> >means for SIP to
> >	> >> >priority
> >	> >> >> > >> mark request "when SIP already has one
> >interoperable way to
> >	> >> >> > >> accomplish this... it's call the RP header
> >mechanism".
> >	> >> >> > >>
> >	> >> >> > >> >I don't see advantages -- only disadvantages.
> >	> >> >> > >> >
> >	> >> >> > >> >Ciao
> >	> >> >> > >> >Hannes
> >	> >> >> > >>
> >	> >> >> > >> _______________________________________________
> >	> >> >> > >> Ecrit mailing list
> >	> >> >> > >> [email-masked]
> >	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >	> >> >> > >
> >	> >> >>
> >	> >> >> _______________________________________________
> >	> >> >> Ecrit mailing list
> >	> >> >> [email-masked]
> >	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >	> >> >>
> >	> >> >
> >	> >
> >	>
> >	> _______________________________________________
> >	> Ecrit mailing list
> >	> [email-masked]
> >	> https://www.ietf.org/mailman/listinfo/ecrit
> >
> >
> >
> >_______________________________________________
> >Ecrit mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/ecrit
> >
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

From: "Hannes Tschofenig" <[email-masked]>
To: "'Brian Rosen'" <[email-masked]>, "'Janet P Gunn'" <[email-masked]>
Date: Fri, 6 Feb 2009 17:20:47 +0200
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] RPH

Don't get hung up on the details. There are ways to optimize it. That was
not the point of the code example. 

The problem that my pseudo code should have shown you is that you 
* don't gain anything with RPH marking for the emergency call case from the
SIP UA towards the outbound proxy since the functionality is already provide
otherwise. How often does the proxy need to get told that this is an
emergency call todo whatever emergency call handling procedures are
necessary?  
* you only introduce fraud problems (if you are not careful and you
understand the security stuff well enough) 

If you can point me to people who implement the RPH emergency call case
please do so. I would love to talk to them. 

Ciao
Hannes

PS: You need to parse incoming messages to some extend so that you know what
it contains :-)
Only looking for the emergency RPH header (and not for the Service URN/dial
string) would exactly be the DoS/fraud attack I am worried about. 
That's the thing Henning was worried about (go and listen to the past
meeting minutes). 

>Hannes
>
>You need to talk to people who really implement this kind of 
>thing.  You are way off.
>
>When you implement a resource priority system, the point of 
>doing that is to look though the queue of work and pick out 
>the ones with priority, handling them first.  You don't do all 
>the parsing, you don't do a lot of decision tree.  
>
>Typically:
>Check for DoS things, like too big messages, etc Do a quick 
>scan for the RPH message header If found:
>Parse the message
>Determine validity
>Determine priority
>Queue on the correct work queue
>
>The first two actions have to be very fast.  Anyone who builds 
>a SIP thingie will tell you that parsing is one of the big 
>cycle consumers: if you have to parse every message BEFORE you 
>determine priority, you can't give much resource priority.  
>Once you get the whole message parsed, you might as well 
>finish working on it, because you've done so much of the work. 
>OTHOH, finding the end-of-message delimiter and doing a quick 
>string search for RPH is fast.  If you are doing priority, you 
>need to keep all the priority processing pretty uniform, and 
>pretty simple, or you tend to spend too much time futzing 
>around figuring out what to do.  You put all the priority 
>related stuff together, and use as much common code as possible.
>
>Brian
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>> Of Hannes Tschofenig
>> Sent: Friday, February 06, 2009 8:41 AM
>> To: 'Hannes Tschofenig'; 'Janet P Gunn'
>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- 
>> [email-masked]
>> Subject: [Ecrit] RPH
>> 
>> Over lunch I was also thinking how an outbound proxy would implement 
>> some of the emergency procedures. Here are some thoughts:
>> 
>> ---------------------------------------------------
>> 
>> // Process incoming message
>> Parse(msg);
>> 
>> // SIP INVITE without Service URN
>> // legacy devices
>> If (recognize-dialstring(msg)==TRUE) {
>>   // we got an emergency call going on
>>   emergency=TRUE;
>>   if (dialstring(msg) == 911) serviceURN=urn:service:sos; } else if 
>> (recognize-serviceURN(msg)==TRUE) {
>>   // oh. A updated device that has a service URN attached to the call
>>   serviceURN=retrieve_ServiceURN(msg);
>>   emergency=TRUE;
>> } else {
>>   // standard SIP message
>>   // regular processing
>>   process(msg);
>>   emergency=FALSE;
>> }
>> 
>> If (emergency == TRUE) {
>>    // make sure that the emergency call does not get dropped on the 
>> floor
>>    // skip authorization failures
>>    // give the call a special treatment
>>    lots-of-code-here();
>> 
>>    // trigger all the QoS signaling you have in the network to make 
>> James happy
>>    trigger-qos();
>> 
>>    // query location
>>    location=retrieve-location();
>> 
>>    // determine next hop
>>    next-hop=lost(location, serviceURN)
>> 
>>    // attach RPH marking to outgoing msg to make James and 
>Keith happy
>>    msg=add(msg, RPH);
>> 
>>    send(msg, next-hop);
>> }
>> 
>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
>>    // all the emergency related processing done already upfront
>>    // hence I log something.
>>    log(RPH_WAS_PRESENT_JUHU);
>> } else if ((rph-present(msg) == TRUE) && (emergency == FALSE)) {
>>   // this is not an emergency call
>>   // this is something like GETS
>>   result=special-authorization-procedure(user);
>> 
>>   if (result == AUTHORIZED) {
>>     // do some priority & preemption thing here.
>>     // trigger all the QoS you have
>>     lots-of-code-here();
>>   } else {
>>     log("NOT AUTHORIZED; don't DoS my network");
>>   }
>> } else {
>>   // don't need todo any RPH processing
>>   // this includes the case where the call was an emergency call but 
>> the RPH
>> 
>>   // marking was not there.
>>   nothing();
>> }
>> 
>> ---------------------------------------------------
>> 
>> 
>> Ciao
>> Hannes
>> 
>> >-----Original Message-----
>> >From: [email-masked] [mailto:[email-masked]] On 
>> >Behalf Of Hannes Tschofenig
>> >Sent: 06 February, 2009 15:07
>> >To: 'Janet P Gunn'
>> >Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
>> FI/Espoo)
>> >Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
>> >
>> >Who would define something that could prevent DoS problems?
>> >
>> >________________________________
>> >
>> >	From: Janet P Gunn [mailto:[email-masked]]
>> >	Sent: 06 February, 2009 14:11
>> >	To: Hannes Tschofenig
>> >	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; 
>> >[email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); 'James 
>> >M. Polk'
>> >	Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
>> >
>> >
>> >
>> >	But there is nothing IN RFC4412 that specifically 
>addresses how to 
>> >prevent any particular namespace being used for DoS.  Anyone/any UA 
>> >can ATTEMPT to invoke priority treatment by attaching RPH.  For all 
>> >of the 4412 namespaces, as with the new proposed namespace, the 
>> >mechanisms for preventing DoS are not specified in the 
>document that 
>> >defines the namespace.
>> >They are/will be specified elsewhere.
>> >
>> >	Janet
>> >
>> >	This is a PRIVATE message. If you are not the intended 
>recipient, 
>> >please delete without copying and kindly advise us by e-mail of the 
>> >mistake in delivery.
>> >	NOTE: Regardless of content, this e-mail shall not 
>operate to bind 
>> >CSC to any order or other contract unless pursuant to explicit 
>> >written agreement or government initiative expressly permitting the 
>> >use of e-mail for such purpose.
>> >
>> >	[email-masked] wrote on 02/06/2009 04:21:51 AM:
>> >
>> >	> Hi James,
>> >	>
>> >	> I have read RFC 4412 and also the GETS/MLPP IETF 
>documents. What I 
>> >would
>> >	> like to point out is that there is more than just a 
>header and 
>> >values within
>> >	> the header that have to be considered in order to 
>make a judgement 
>> >of what
>> >	> is appropriate and what isn't. There is an 
>architectural question 
>> >and
>> >	> whether the environment we are using the stuff is 
>indeed providing 
>> >the
>> >	> properties you need for the solution to be appropriate.
>> >	>
>> >	> Let me describe in more detail what I meant (and 
>please correct me 
>> >if I am
>> >	> wrong).
>> >	>
>> >	> Getting priority for SIP requests when using a GETS 
>alike scenario 
>> >means
>> >	> that the entity that issues the request is specially 
>authorized 
>> >since
>> >	> otherwise you introduce a nice denial of service attack. This 
>> >authorization
>> >	> is tied to the entity that makes the request. For 
>example, the 
>> >person is
>> >	> working for the government and has special rights.
>> >James Bond as a (not so)
>> >	> secret agent might have these rights.
>> >	>
>> >	> The emergency services case (citizen-to-authority) is a bit 
>> >different as
>> >	> there aren't really special rights with respect to 
>authorization 
>> >tied to
>> >	> individuals. Instead, the fact that something is an 
>emergency is 
>> >purely a
>> >	> judgement of the human that dials a special number.
>> >To deal with fraud, we
>> >	> discussed in the group on what we can actually do to 
>ensure that 
>> >end users
>> >	> do not bypass security procedures (such as 
>authorization checks, 
>> >charging
>> >	> and so on). Part of this investigation was the publication of
>> >	> http://www.ietf.org/rfc/rfc5069.txt that also describes this 
>> >issue.
>> >	>
>> >	> So, imagine the implementation of a SIP proxy (and we 
>implemented 
>> >that
>> >	> stuff) that receives a call that contains a Service 
>URN. The code 
>> >branches
>> >	> into a special mode where everything is done so that the call 
>> >receives
>> >	> appropriate treatment and does not get dropped on the 
>floor. The 
>> >way how the
>> >	> Service URN is placed in the message ensures that the 
>call cannot 
>> >go to my
>> >	> friend (instead of the PSAP) unless the end host ran 
>LoST already.
>> >In the
>> >	> latter case, we discussed this also on the list for a 
>while and 
>> >Richard even
>> >	> wrote a draft about it in the context of the location hiding 
>> >topic, we said
>> >	> that the proxy would have to run LoST if he cares about a 
>> >potential
>> >	> fraudulent usage.
>> >	>
>> >	> So, what do we need todo in order to provide secure RFC 4412 
>> >functionality
>> >	> in our context?
>> >	>
>> >	> Do you think that the current text in
>> >	>
>> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>> >gency-rph-nam
>> >	> espace-00.txt reflects any of the above-described issues:
>> >	> "
>> >	>    The Security considerations that apply to RFC 4412
>> >[RFC4412]
>> >apply
>> >	>    here.  This document introduces no new security
>> >issues relative
>> >to
>> >	>    RFC 4412.
>> >	> "
>> >	>
>> >	> From various discussions in GEOPRIV I recall that you are 
>> >super-sensitive
>> >	> regarding security and privacy. For some reasons you 
>don't seem to 
>> >have the
>> >	> same concerns here. I would like to understand your reasoning.
>> >	>
>> >	> Please also do me another favor: Don't always say 
>that I don't 
>> >understand
>> >	> the subject. Even if that would be the case it isn't 
>particular 
>> >fair given
>> >	> that different folks had to educate you on other 
>topics in the 
>> >past as well.
>> >	> Additionally, if you listen to the audio recordings 
>then you will 
>> >notice
>> >	> that Henning, Ted, and Jon do not seem to understand 
>the issue 
>> >either as
>> >	> they have raised similar issues during the F2F meetings.
>> >	>
>> >	> Ciao
>> >	> Hannes
>> >	>
>> >	>
>> >	> >Hannes - I believe it is you who do not understand 
>RFC 4412 --
>> >	> >and many of us are trying to get that through to you, but you
>> >	> >don't seem to want to listen/read.
>> >	> >
>> >	> >RFC 4412 is *for* priority marking SIP requests,
>> >	> >
>> >	> >One use is GETS.
>> >	> >
>> >	> >One use is MLPP.
>> >	> >
>> >	> >These examples are in RFC 4412 because there were specific
>> >	> >namespaces being created for the IANA section of 
>that document.
>> >	> >
>> >	> >Reading the whole document, you will see that RPH can be
>> >	> >specified for other uses than GETS or MLPP specifically.
>> >	> >
>> >	> >I knew when I wrote RFC 4412 that one day we would specify a
>> >	> >namespace for ECRIT (the "esnet" namespace now) -- but I also
>> >	> >knew it was premature for RFC 4412 to incorporate that
>> >	> >namespace, that a future doc to RFC 4412 would have to be
>> >	> >written to do this. Brian and I talked about this at the
>> >	> >original NENA meeting that created the IP WGs there 
>(in August
>> >	> >of 03).  We both agreed we should wait until it was
>> >	> >appropriate to the work in the IETF to submit this document
>> >	> >that is now
>> >	>
>> >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>> >	> >gency-rph-namespace-00.txt
>> >	> >
>> >	> >Yet, you seem to want to use some additional mechanism to
>> >	> >indicate priority of a call in SIP.  That means you want to
>> >	> >introduce a second way to accomplish this in SIP.
>> >Why do you
>> >	> >want to promote a separate way to do something SIP 
>has already
>> >	> >defined? That will cause interoperability issues and 
>we both know 
>> >that.
>> >	> >
>> >	> >You've said to me (and others) that you believe RPH is just
>> >	> >another way to accomplish what sos or a URI can 
>indicate - and
>> >	> >you're wrong.  Your way would be _the_second_way_to_do_it,
>> >	> >because SIP already considers RPH to be *the*way* to priority
>> >	> >mark SIP requests.
>> >	> >
>> >	> >If you don't believe me (no comment), then why do you not
>> >	> >believe the SIP WG chair (who knows more about SIP than both
>> >	> >of us) - who, on this thread, has again said to you "RFC 4412
>> >	> >(RPH) is the SIP mechanism to priority mark SIP requests"?
>> >	> >
>> >	> >Further, I believe it is inappropriate to prohibit endpoints
>> >	> >from being able to set the esnet namespace.  I absolutely
>> >	> >believe it will not be needed most of the time, but I believe
>> >	> >if someone does find a valid use for endpoints to mark
>> >	> >priority in SIP, this ID - once it has become an RFC -- will
>> >	> >have to be obsoleted with a new RFC saying the exact 
>opposite.
>> >	> >
>> >	> >(color me confused ... over and over again)
>> >	> >
>> >	> >James
>> >	> >
>> >	> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>> >	> >>Keith, please understand that the usage of RFC 4412 
>for GETS and 
>> >for
>> >	> >>the type of emergency call we discuss here is 
>different. Just 
>> >looking
>> >	> >>at the header and the name of the namespace is a bit
>> >	> >artificial. I hope
>> >	> >>you understand that.
>> >	> >>
>> >	> >> >-----Original Message-----
>> >	> >> >From: DRAGE, Keith (Keith)
>> >[mailto:[email-masked]]
>> >	> >> >Sent: 05 February, 2009 14:55
>> >	> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
>> >Polk'; 'Tschofenig,
>> >	> >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
>> >	> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
>> >Meeting: Agenda (my
>> >
>> >	> >> >mistake)
>> >	> >> >
>> >	> >> >Which is exactly what RFC 4412 specifies for all 
>namespaces.
>> >	> >> >
>> >	> >> >regards
>> >	> >> >
>> >	> >> >Keith
>> >	> >> >
>> >	> >> >> -----Original Message-----
>> >	> >> >> From: [email-masked] 
>[mailto:[email-masked]]
>> >	> >> >On Behalf
>> >	> >> >> Of Brian Rosen
>> >	> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
>> >	> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
>> >	> >Hannes (NSN
>> >	> >> >> - FI/Espoo)'; 'ECRIT'
>> >	> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>> >Meeting: Agenda (my
>> >	> >> >> mistake)
>> >	> >> >>
>> >	> >> >> The value is that in some networks where priority for
>> >	> >> >emergency calls
>> >	> >> >> is appropriate, and appropriate policing of marking is
>> >	> >implemented,
>> >	> >> >> emergency calls will receive resource priority.
>> >	> >> >>
>> >	> >> >> Not all networks would need policing.  Some 
>will.  Policing 
>> >could
>> >	> >> >> be to Route header/R-URI content, but other 
>criteria are 
>> >possible.
>> >	> >> >>
>> >	> >> >> Not all networks will need resource priority 
>for emergency 
>> >calls.
>> >	> >> >> Fine, ignore this marking/namespace.
>> >	> >> >>
>> >	> >> >> Brian
>> >	> >> >> > -----Original Message-----
>> >	> >> >> > From: Hannes Tschofenig
>> >[mailto:[email-masked]]
>> >	> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>> >	> >> >> > To: 'Brian Rosen'; 'James M. Polk'; 
>Tschofenig, Hannes 
>> >(NSN -
>> >	> >> >> > FI/Espoo); 'ECRIT'
>> >	> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
>> >Meeting: Agenda (my
>> >	> >> >> > mistake)
>> >	> >> >> >
>> >	> >> >> > I don't even see the value in permitting the 
>endpoint todo 
>> >the
>> >	> >> >> > RPH marking.
>> >	> >> >> > In addition to the security concerns there is also the
>> >	> >> >problem that
>> >	> >> >> > there are more options to implement without 
>an additional 
>> >value.
>> >	> >> >> >
>> >	> >> >> > >-----Original Message-----
>> >	> >> >> > >From: Brian Rosen [mailto:[email-masked]]
>> >	> >> >> > >Sent: 05 February, 2009 00:03
>> >	> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 
>'Tschofenig,
>> >	> >> >> Hannes (NSN -
>> >	> >> >> > >FI/Espoo)'; 'ECRIT'
>> >	> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting:
>> >Agenda (my
>> >	> >> >> > mistake)
>> >	> >> >> > >
>> >	> >> >> > >Hannes
>> >	> >> >> > >
>> >	> >> >> > >This matches my understanding precisely.  We wish to
>> >	> >> >> permit endpoints
>> >	> >> >> > >to mark. We do not require it, and don't necessarily 
>> >expect it
>> >	> >> >> > >in many (even
>> >	> >> >> > >most) cases.  We don't wish to see the 
>document prohibit 
>> >it.
>> >	> >> >> > >We all seem to agree it has value within the 
>Emergency
>> >	> >> >Services IP
>> >	> >> >> > >Networks.
>> >	> >> >> > >
>> >	> >> >> > >Brian
>> >	> >> >> > >
>> >	> >> >> > >> -----Original Message-----
>> >	> >> >> > >> From: [email-masked] 
>> >[mailto:[email-masked]]
>> >	> >> >> > >On Behalf
>> >	> >> >> > >> Of James M. Polk
>> >	> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
>> >	> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
>> >	> >> >> FI/Espoo); 'ECRIT'
>> >	> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>> >Meeting:
>> >	> >Agenda (my
>> >	> >> >> > >> mistake)
>> >	> >> >> > >>
>> >	> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
>> >	> >> >> > >> > > James wrote:
>> >	> >> >> > >> > >> you are the _lone_ voice not 
>supporting this ID,
>> >	> >> >> > >> >
>> >	> >> >> > >> >Listening to the audio recording of past 
>meetings I 
>> >have to
>> >	> >> >> > >say that
>> >	> >> >> > >> >I
>> >	> >> >> > >> was
>> >	> >> >> > >> >not the only persons raising concerns about the 
>> >document.
>> >	> >> >> > >> >That was probably the reason why you 
>agreed to limit 
>> >the
>> >	> >> >> > >scope of the
>> >	> >> >> > >> >document (which you didn't later do) to 
>get folks to 
>> >agree
>> >	> >> >> > >to make it
>> >	> >> >> > >> a WG
>> >	> >> >> > >> >item.
>> >	> >> >> > >>
>> >	> >> >> > >> re-listen to the audio please
>> >	> >> >> > >>
>> >	> >> >> > >> Ted's concerns were consistent with most
>> >(all?) other
>> >	> >> >> concerns --
>> >	> >> >> > >> which were based on the premise of whether 
>or not the
>> >	> >> >> UAC should be
>> >	> >> >> > >> trusted to initiate the marking on the 
>INVITE.  The 
>> >most
>> >	> >> >> > >> recent version has backed off this to a "can" -- 
>> >meaning not
>> >	> >> >prohibited
>> >	> >> >> > >> (i.e., no 2119 text).  I also backed off 
>the text in 
>> >the
>> >	> >> >> SP domain
>> >	> >> >> > >> part to "can", such that there is no 2119 text
>> >	> >> >mandating or even
>> >	> >> >> > >> recommending its usage there. I also do 
>not prohibit 
>> >its
>> >	> >> >> > >use, based on
>> >	> >> >> > >> local policy.  Keith has come forward with 
>the specific
>> >
>> >	> >> >> > >> request that non-ESInet networks be 
>allowed to mark and 
>> >pay
>> >	> >> >attention to
>> >	> >> >> > >> this priority indication -- with IMS as 
>the specific 
>> >example
>> >	> >> >> > >> he wishes to have this valid for.
>> >	> >> >> > >>
>> >	> >> >> > >> Where there is no disagreement, save for 
>your recent
>> >	> >> >> > >pushback - is in
>> >	> >> >> > >> the ESInet, which is where Brian has requested it's
>> >	> >> >> > >definition in the
>> >	> >> >> > >> IETF on behalf of NENA.  He's the i3 WG 
>chair within
>> >	> >> >> NENA, and if
>> >	> >> >> > >> he asks for it, are you going to say you 
>know better 
>> >than he?
>> >	> >> >> > >>
>> >	> >> >> > >>
>> >	> >> >> > >> >Btw, I not disagreeing with the document 
>as such. I
>> >	> >> >just want to
>> >	> >> >> > the
>> >	> >> >> > >> scope
>> >	> >> >> > >> >to change. The usage of RPH within the emergency
>> >	> >> >> services network
>> >	> >> >> > is
>> >	> >> >> > >> fine
>> >	> >> >> > >> >for me. I may get convinced to start the 
>RPH marking 
>> >from
>> >	> >> >> > >the the VSP
>> >	> >> >> > >> >towards the PSAP. I feel uneasy about the 
>end host 
>> >doing
>> >	> >> >> > >the marking.
>> >	> >> >> > >>
>> >	> >> >> > >> please read what I wrote above, and then 
>re-read the
>> >	> >> >most recent
>> >	> >> >> > >> version of the ID. I don't have endpoints 
>that SHOULD 
>> >or
>> >	> >> >> MUST mark
>> >	> >> >> > >> anything wrt RPH.  I also don't want to 
>prohibit it,
>> >	> >> >> because there
>> >	> >> >> > >> might be cases (that I don't know of) of valid uses
>> >	> >> >> under certain
>> >	> >> >> > >> circumstances.  Figure 1 is very clear 
>that there are 3
>> >	> >> >> networking
>> >	> >> >> > >> parts to consider
>> >	> >> >> > >>
>> >	> >> >> > >> #1 - from the endpoint
>> >	> >> >> > >> #2 - within the VSP
>> >	> >> >> > >> #3 - within the ESInet
>> >	> >> >> > >>
>> >	> >> >> > >> the most recent ID version has "can" for 
>#s 1 and 2, 
>> >and
>> >	> >> >> > >2119 language
>> >	> >> >> > >> offering those supporting this 
>specification will have 
>> >RPH
>> >	> >> >> > >> adherence within #3 (the ESInet).
>> >	> >> >> > >>
>> >	> >> >> > >> What other scope changes do you want, 
>because I haven't
>> >	> >> >> heard them.
>> >	> >> >> > >>
>> >	> >> >> > >> I only heard you claim in email during the 
>last IETF 
>> >and in
>> >	> >> >> > >the ECRIT
>> >	> >> >> > >> session that RPH should not be used for priority 
>> >marking
>> >	> >> >> requests.
>> >	> >> >> > >> This is something Keith (SIP WG chair) voiced his 
>> >opposition
>> >	> >> >> > >> to your views regarding creating a second 
>means for SIP 
>> >to
>> >	> >> >priority
>> >	> >> >> > >> mark request "when SIP already has one 
>interoperable 
>> >way to
>> >	> >> >> > >> accomplish this... it's call the RP header 
>mechanism".
>> >	> >> >> > >>
>> >	> >> >> > >> >I don't see advantages -- only disadvantages.
>> >	> >> >> > >> >
>> >	> >> >> > >> >Ciao
>> >	> >> >> > >> >Hannes
>> >	> >> >> > >>
>> >	> >> >> > >> _______________________________________________
>> >	> >> >> > >> Ecrit mailing list
>> >	> >> >> > >> [email-masked]
>> >	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>> >	> >> >> > >
>> >	> >> >>
>> >	> >> >> _______________________________________________
>> >	> >> >> Ecrit mailing list
>> >	> >> >> [email-masked]
>> >	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >	> >> >>
>> >	> >> >
>> >	> >
>> >	>
>> >	> _______________________________________________
>> >	> Ecrit mailing list
>> >	> [email-masked]
>> >	> https://www.ietf.org/mailman/listinfo/ecrit
>> >
>> >
>> >
>> >_______________________________________________
>> >Ecrit mailing list
>> >[email-masked]
>> >https://www.ietf.org/mailman/listinfo/ecrit
>> >
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>

From: Henning Schulzrinne <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 6 Feb 2009 10:33:28 -0500
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

To chime in here:

I don't think it's productive to simply state that 4412 doesn't worry  
about authorization, so we shouldn't either (simplifying a bit).  
Authorization was discussed repeatedly, and the general assumption was  
that there were two conditions: Either the user invoking resource- 
priority was well known and had a set of permissions that could be  
checked in real time or there are ways to deal with abuse after the  
fact in ways that deter abuse (the court-martial kind of thing in a  
military context).

The RFC 4412 security consideration (11.2) call this out in pretty  
strong language:

  Prioritized access to network and end-system resources imposes
    particularly stringent requirements on authentication and
    authorization mechanisms, since access to prioritized resources may
    impact overall system stability and performance and not just result
    in theft of, say, a single phone call.
Thus, the question is whether we have such strong authentication in  
emergency calling. In some cases, such as residential fixed line  
deployments where ISP = VSP, we're probably pretty close, in others,  
such as prepaid cell phones or hot spots or VSP-only providers, we  
aren't.

The other point that I think Hannes is making is that the information  
is either redundant or dangerous. If a processing element recognizes  
the call as being an emergency call, it can apply whatever treatment  
it deems appropriate and doesn't need additional information. If it  
doesn't or can't, using just the RPH can be rather dangerous unless  
that element can be reasonably certain that there is strong  
authentication and recourse.

I don't buy the argument that somehow finding the RPH is faster than  
just looking for the identifier. Thus, given that the information is  
either redundant or dangerous, I fail to see the advantage.

Henning

On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:

> Don't get hung up on the details. There are ways to optimize it.  
> That was
> not the point of the code example.
>
> The problem that my pseudo code should have shown you is that you
> * don't gain anything with RPH marking for the emergency call case  
> from the
> SIP UA towards the outbound proxy since the functionality is already  
> provide
> otherwise. How often does the proxy need to get told that this is an
> emergency call todo whatever emergency call handling procedures are
> necessary?
> * you only introduce fraud problems (if you are not careful and you
> understand the security stuff well enough)
>
> If you can point me to people who implement the RPH emergency call  
> case
> please do so. I would love to talk to them.
>
> Ciao
> Hannes
>
> PS: You need to parse incoming messages to some extend so that you  
> know what
> it contains :-)
> Only looking for the emergency RPH header (and not for the Service  
> URN/dial
> string) would exactly be the DoS/fraud attack I am worried about.
> That's the thing Henning was worried about (go and listen to the past
> meeting minutes).
>
>
>> Hannes
>>
>> You need to talk to people who really implement this kind of
>> thing.  You are way off.
>>
>> When you implement a resource priority system, the point of
>> doing that is to look though the queue of work and pick out
>> the ones with priority, handling them first.  You don't do all
>> the parsing, you don't do a lot of decision tree.
>>
>> Typically:
>> Check for DoS things, like too big messages, etc Do a quick
>> scan for the RPH message header If found:
>> Parse the message
>> Determine validity
>> Determine priority
>> Queue on the correct work queue
>>
>> The first two actions have to be very fast.  Anyone who builds
>> a SIP thingie will tell you that parsing is one of the big
>> cycle consumers: if you have to parse every message BEFORE you
>> determine priority, you can't give much resource priority.
>> Once you get the whole message parsed, you might as well
>> finish working on it, because you've done so much of the work.
>> OTHOH, finding the end-of-message delimiter and doing a quick
>> string search for RPH is fast.  If you are doing priority, you
>> need to keep all the priority processing pretty uniform, and
>> pretty simple, or you tend to spend too much time futzing
>> around figuring out what to do.  You put all the priority
>> related stuff together, and use as much common code as possible.
>>
>> Brian
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf
>>> Of Hannes Tschofenig
>>> Sent: Friday, February 06, 2009 8:41 AM
>>> To: 'Hannes Tschofenig'; 'Janet P Gunn'
>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-
>>> [email-masked]
>>> Subject: [Ecrit] RPH
>>>
>>> Over lunch I was also thinking how an outbound proxy would implement
>>> some of the emergency procedures. Here are some thoughts:
>>>
>>> ---------------------------------------------------
>>>
>>> // Process incoming message
>>> Parse(msg);
>>>
>>> // SIP INVITE without Service URN
>>> // legacy devices
>>> If (recognize-dialstring(msg)==TRUE) {
>>>  // we got an emergency call going on
>>>  emergency=TRUE;
>>>  if (dialstring(msg) == 911) serviceURN=urn:service:sos; } else if
>>> (recognize-serviceURN(msg)==TRUE) {
>>>  // oh. A updated device that has a service URN attached to the call
>>>  serviceURN=retrieve_ServiceURN(msg);
>>>  emergency=TRUE;
>>> } else {
>>>  // standard SIP message
>>>  // regular processing
>>>  process(msg);
>>>  emergency=FALSE;
>>> }
>>>
>>> If (emergency == TRUE) {
>>>   // make sure that the emergency call does not get dropped on the
>>> floor
>>>   // skip authorization failures
>>>   // give the call a special treatment
>>>   lots-of-code-here();
>>>
>>>   // trigger all the QoS signaling you have in the network to make
>>> James happy
>>>   trigger-qos();
>>>
>>>   // query location
>>>   location=retrieve-location();
>>>
>>>   // determine next hop
>>>   next-hop=lost(location, serviceURN)
>>>
>>>   // attach RPH marking to outgoing msg to make James and
>> Keith happy
>>>   msg=add(msg, RPH);
>>>
>>>   send(msg, next-hop);
>>> }
>>>
>>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
>>>   // all the emergency related processing done already upfront
>>>   // hence I log something.
>>>   log(RPH_WAS_PRESENT_JUHU);
>>> } else if ((rph-present(msg) == TRUE) && (emergency == FALSE)) {
>>>  // this is not an emergency call
>>>  // this is something like GETS
>>>  result=special-authorization-procedure(user);
>>>
>>>  if (result == AUTHORIZED) {
>>>    // do some priority & preemption thing here.
>>>    // trigger all the QoS you have
>>>    lots-of-code-here();
>>>  } else {
>>>    log("NOT AUTHORIZED; don't DoS my network");
>>>  }
>>> } else {
>>>  // don't need todo any RPH processing
>>>  // this includes the case where the call was an emergency call but
>>> the RPH
>>>
>>>  // marking was not there.
>>>  nothing();
>>> }
>>>
>>> ---------------------------------------------------
>>>
>>>
>>> Ciao
>>> Hannes
>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of Hannes Tschofenig
>>>> Sent: 06 February, 2009 15:07
>>>> To: 'Janet P Gunn'
>>>> Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
>>> FI/Espoo)
>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
>>>>
>>>> Who would define something that could prevent DoS problems?
>>>>
>>>> ________________________________
>>>>
>>>> 	From: Janet P Gunn [mailto:[email-masked]]
>>>> 	Sent: 06 February, 2009 14:11
>>>> 	To: Hannes Tschofenig
>>>> 	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
>>>> [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo); 'James
>>>> M. Polk'
>>>> 	Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
>>>>
>>>>
>>>>
>>>> 	But there is nothing IN RFC4412 that specifically
>> addresses how to
>>>> prevent any particular namespace being used for DoS.  Anyone/any UA
>>>> can ATTEMPT to invoke priority treatment by attaching RPH.  For all
>>>> of the 4412 namespaces, as with the new proposed namespace, the
>>>> mechanisms for preventing DoS are not specified in the
>> document that
>>>> defines the namespace.
>>>> They are/will be specified elsewhere.
>>>>
>>>> 	Janet
>>>>
>>>> 	This is a PRIVATE message. If you are not the intended
>> recipient,
>>>> please delete without copying and kindly advise us by e-mail of the
>>>> mistake in delivery.
>>>> 	NOTE: Regardless of content, this e-mail shall not
>> operate to bind
>>>> CSC to any order or other contract unless pursuant to explicit
>>>> written agreement or government initiative expressly permitting the
>>>> use of e-mail for such purpose.
>>>>
>>>> 	[email-masked] wrote on 02/06/2009 04:21:51 AM:
>>>>
>>>> 	> Hi James,
>>>> 	>
>>>> 	> I have read RFC 4412 and also the GETS/MLPP IETF
>> documents. What I
>>>> would
>>>> 	> like to point out is that there is more than just a
>> header and
>>>> values within
>>>> 	> the header that have to be considered in order to
>> make a judgement
>>>> of what
>>>> 	> is appropriate and what isn't. There is an
>> architectural question
>>>> and
>>>> 	> whether the environment we are using the stuff is
>> indeed providing
>>>> the
>>>> 	> properties you need for the solution to be appropriate.
>>>> 	>
>>>> 	> Let me describe in more detail what I meant (and
>> please correct me
>>>> if I am
>>>> 	> wrong).
>>>> 	>
>>>> 	> Getting priority for SIP requests when using a GETS
>> alike scenario
>>>> means
>>>> 	> that the entity that issues the request is specially
>> authorized
>>>> since
>>>> 	> otherwise you introduce a nice denial of service attack. This
>>>> authorization
>>>> 	> is tied to the entity that makes the request. For
>> example, the
>>>> person is
>>>> 	> working for the government and has special rights.
>>>> James Bond as a (not so)
>>>> 	> secret agent might have these rights.
>>>> 	>
>>>> 	> The emergency services case (citizen-to-authority) is a bit
>>>> different as
>>>> 	> there aren't really special rights with respect to
>> authorization
>>>> tied to
>>>> 	> individuals. Instead, the fact that something is an
>> emergency is
>>>> purely a
>>>> 	> judgement of the human that dials a special number.
>>>> To deal with fraud, we
>>>> 	> discussed in the group on what we can actually do to
>> ensure that
>>>> end users
>>>> 	> do not bypass security procedures (such as
>> authorization checks,
>>>> charging
>>>> 	> and so on). Part of this investigation was the publication of
>>>> 	> http://www.ietf.org/rfc/rfc5069.txt that also describes this
>>>> issue.
>>>> 	>
>>>> 	> So, imagine the implementation of a SIP proxy (and we
>> implemented
>>>> that
>>>> 	> stuff) that receives a call that contains a Service
>> URN. The code
>>>> branches
>>>> 	> into a special mode where everything is done so that the call
>>>> receives
>>>> 	> appropriate treatment and does not get dropped on the
>> floor. The
>>>> way how the
>>>> 	> Service URN is placed in the message ensures that the
>> call cannot
>>>> go to my
>>>> 	> friend (instead of the PSAP) unless the end host ran
>> LoST already.
>>>> In the
>>>> 	> latter case, we discussed this also on the list for a
>> while and
>>>> Richard even
>>>> 	> wrote a draft about it in the context of the location hiding
>>>> topic, we said
>>>> 	> that the proxy would have to run LoST if he cares about a
>>>> potential
>>>> 	> fraudulent usage.
>>>> 	>
>>>> 	> So, what do we need todo in order to provide secure RFC 4412
>>>> functionality
>>>> 	> in our context?
>>>> 	>
>>>> 	> Do you think that the current text in
>>>> 	>
>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>>>> gency-rph-nam
>>>> 	> espace-00.txt reflects any of the above-described issues:
>>>> 	> "
>>>> 	>    The Security considerations that apply to RFC 4412
>>>> [RFC4412]
>>>> apply
>>>> 	>    here.  This document introduces no new security
>>>> issues relative
>>>> to
>>>> 	>    RFC 4412.
>>>> 	> "
>>>> 	>
>>>> 	> From various discussions in GEOPRIV I recall that you are
>>>> super-sensitive
>>>> 	> regarding security and privacy. For some reasons you
>> don't seem to
>>>> have the
>>>> 	> same concerns here. I would like to understand your reasoning.
>>>> 	>
>>>> 	> Please also do me another favor: Don't always say
>> that I don't
>>>> understand
>>>> 	> the subject. Even if that would be the case it isn't
>> particular
>>>> fair given
>>>> 	> that different folks had to educate you on other
>> topics in the
>>>> past as well.
>>>> 	> Additionally, if you listen to the audio recordings
>> then you will
>>>> notice
>>>> 	> that Henning, Ted, and Jon do not seem to understand
>> the issue
>>>> either as
>>>> 	> they have raised similar issues during the F2F meetings.
>>>> 	>
>>>> 	> Ciao
>>>> 	> Hannes
>>>> 	>
>>>> 	>
>>>> 	> >Hannes - I believe it is you who do not understand
>> RFC 4412 --
>>>> 	> >and many of us are trying to get that through to you, but you
>>>> 	> >don't seem to want to listen/read.
>>>> 	> >
>>>> 	> >RFC 4412 is *for* priority marking SIP requests,
>>>> 	> >
>>>> 	> >One use is GETS.
>>>> 	> >
>>>> 	> >One use is MLPP.
>>>> 	> >
>>>> 	> >These examples are in RFC 4412 because there were specific
>>>> 	> >namespaces being created for the IANA section of
>> that document.
>>>> 	> >
>>>> 	> >Reading the whole document, you will see that RPH can be
>>>> 	> >specified for other uses than GETS or MLPP specifically.
>>>> 	> >
>>>> 	> >I knew when I wrote RFC 4412 that one day we would specify a
>>>> 	> >namespace for ECRIT (the "esnet" namespace now) -- but I also
>>>> 	> >knew it was premature for RFC 4412 to incorporate that
>>>> 	> >namespace, that a future doc to RFC 4412 would have to be
>>>> 	> >written to do this. Brian and I talked about this at the
>>>> 	> >original NENA meeting that created the IP WGs there
>> (in August
>>>> 	> >of 03).  We both agreed we should wait until it was
>>>> 	> >appropriate to the work in the IETF to submit this document
>>>> 	> >that is now
>>>> 	>
>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>>>> 	> >gency-rph-namespace-00.txt
>>>> 	> >
>>>> 	> >Yet, you seem to want to use some additional mechanism to
>>>> 	> >indicate priority of a call in SIP.  That means you want to
>>>> 	> >introduce a second way to accomplish this in SIP.
>>>> Why do you
>>>> 	> >want to promote a separate way to do something SIP
>> has already
>>>> 	> >defined? That will cause interoperability issues and
>> we both know
>>>> that.
>>>> 	> >
>>>> 	> >You've said to me (and others) that you believe RPH is just
>>>> 	> >another way to accomplish what sos or a URI can
>> indicate - and
>>>> 	> >you're wrong.  Your way would be _the_second_way_to_do_it,
>>>> 	> >because SIP already considers RPH to be *the*way* to priority
>>>> 	> >mark SIP requests.
>>>> 	> >
>>>> 	> >If you don't believe me (no comment), then why do you not
>>>> 	> >believe the SIP WG chair (who knows more about SIP than both
>>>> 	> >of us) - who, on this thread, has again said to you "RFC 4412
>>>> 	> >(RPH) is the SIP mechanism to priority mark SIP requests"?
>>>> 	> >
>>>> 	> >Further, I believe it is inappropriate to prohibit endpoints
>>>> 	> >from being able to set the esnet namespace.  I absolutely
>>>> 	> >believe it will not be needed most of the time, but I believe
>>>> 	> >if someone does find a valid use for endpoints to mark
>>>> 	> >priority in SIP, this ID - once it has become an RFC -- will
>>>> 	> >have to be obsoleted with a new RFC saying the exact
>> opposite.
>>>> 	> >
>>>> 	> >(color me confused ... over and over again)
>>>> 	> >
>>>> 	> >James
>>>> 	> >
>>>> 	> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>>>> 	> >>Keith, please understand that the usage of RFC 4412
>> for GETS and
>>>> for
>>>> 	> >>the type of emergency call we discuss here is
>> different. Just
>>>> looking
>>>> 	> >>at the header and the name of the namespace is a bit
>>>> 	> >artificial. I hope
>>>> 	> >>you understand that.
>>>> 	> >>
>>>> 	> >> >-----Original Message-----
>>>> 	> >> >From: DRAGE, Keith (Keith)
>>>> [mailto:[email-masked]]
>>>> 	> >> >Sent: 05 February, 2009 14:55
>>>> 	> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
>>>> Polk'; 'Tschofenig,
>>>> 	> >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
>>>> 	> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
>>>> Meeting: Agenda (my
>>>>
>>>> 	> >> >mistake)
>>>> 	> >> >
>>>> 	> >> >Which is exactly what RFC 4412 specifies for all
>> namespaces.
>>>> 	> >> >
>>>> 	> >> >regards
>>>> 	> >> >
>>>> 	> >> >Keith
>>>> 	> >> >
>>>> 	> >> >> -----Original Message-----
>>>> 	> >> >> From: [email-masked]
>> [mailto:[email-masked]]
>>>> 	> >> >On Behalf
>>>> 	> >> >> Of Brian Rosen
>>>> 	> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
>>>> 	> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
>>>> 	> >Hannes (NSN
>>>> 	> >> >> - FI/Espoo)'; 'ECRIT'
>>>> 	> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>>>> Meeting: Agenda (my
>>>> 	> >> >> mistake)
>>>> 	> >> >>
>>>> 	> >> >> The value is that in some networks where priority for
>>>> 	> >> >emergency calls
>>>> 	> >> >> is appropriate, and appropriate policing of marking is
>>>> 	> >implemented,
>>>> 	> >> >> emergency calls will receive resource priority.
>>>> 	> >> >>
>>>> 	> >> >> Not all networks would need policing.  Some
>> will.  Policing
>>>> could
>>>> 	> >> >> be to Route header/R-URI content, but other
>> criteria are
>>>> possible.
>>>> 	> >> >>
>>>> 	> >> >> Not all networks will need resource priority
>> for emergency
>>>> calls.
>>>> 	> >> >> Fine, ignore this marking/namespace.
>>>> 	> >> >>
>>>> 	> >> >> Brian
>>>> 	> >> >> > -----Original Message-----
>>>> 	> >> >> > From: Hannes Tschofenig
>>>> [mailto:[email-masked]]
>>>> 	> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>>>> 	> >> >> > To: 'Brian Rosen'; 'James M. Polk';
>> Tschofenig, Hannes
>>>> (NSN -
>>>> 	> >> >> > FI/Espoo); 'ECRIT'
>>>> 	> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
>>>> Meeting: Agenda (my
>>>> 	> >> >> > mistake)
>>>> 	> >> >> >
>>>> 	> >> >> > I don't even see the value in permitting the
>> endpoint todo
>>>> the
>>>> 	> >> >> > RPH marking.
>>>> 	> >> >> > In addition to the security concerns there is also the
>>>> 	> >> >problem that
>>>> 	> >> >> > there are more options to implement without
>> an additional
>>>> value.
>>>> 	> >> >> >
>>>> 	> >> >> > >-----Original Message-----
>>>> 	> >> >> > >From: Brian Rosen [mailto:[email-masked]]
>>>> 	> >> >> > >Sent: 05 February, 2009 00:03
>>>> 	> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
>> 'Tschofenig,
>>>> 	> >> >> Hannes (NSN -
>>>> 	> >> >> > >FI/Espoo)'; 'ECRIT'
>>>> 	> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting:
>>>> Agenda (my
>>>> 	> >> >> > mistake)
>>>> 	> >> >> > >
>>>> 	> >> >> > >Hannes
>>>> 	> >> >> > >
>>>> 	> >> >> > >This matches my understanding precisely.  We wish to
>>>> 	> >> >> permit endpoints
>>>> 	> >> >> > >to mark. We do not require it, and don't necessarily
>>>> expect it
>>>> 	> >> >> > >in many (even
>>>> 	> >> >> > >most) cases.  We don't wish to see the
>> document prohibit
>>>> it.
>>>> 	> >> >> > >We all seem to agree it has value within the
>> Emergency
>>>> 	> >> >Services IP
>>>> 	> >> >> > >Networks.
>>>> 	> >> >> > >
>>>> 	> >> >> > >Brian
>>>> 	> >> >> > >
>>>> 	> >> >> > >> -----Original Message-----
>>>> 	> >> >> > >> From: [email-masked]
>>>> [mailto:[email-masked]]
>>>> 	> >> >> > >On Behalf
>>>> 	> >> >> > >> Of James M. Polk
>>>> 	> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
>>>> 	> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
>>>> 	> >> >> FI/Espoo); 'ECRIT'
>>>> 	> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>>>> Meeting:
>>>> 	> >Agenda (my
>>>> 	> >> >> > >> mistake)
>>>> 	> >> >> > >>
>>>> 	> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
>>>> 	> >> >> > >> > > James wrote:
>>>> 	> >> >> > >> > >> you are the _lone_ voice not
>> supporting this ID,
>>>> 	> >> >> > >> >
>>>> 	> >> >> > >> >Listening to the audio recording of past
>> meetings I
>>>> have to
>>>> 	> >> >> > >say that
>>>> 	> >> >> > >> >I
>>>> 	> >> >> > >> was
>>>> 	> >> >> > >> >not the only persons raising concerns about the
>>>> document.
>>>> 	> >> >> > >> >That was probably the reason why you
>> agreed to limit
>>>> the
>>>> 	> >> >> > >scope of the
>>>> 	> >> >> > >> >document (which you didn't later do) to
>> get folks to
>>>> agree
>>>> 	> >> >> > >to make it
>>>> 	> >> >> > >> a WG
>>>> 	> >> >> > >> >item.
>>>> 	> >> >> > >>
>>>> 	> >> >> > >> re-listen to the audio please
>>>> 	> >> >> > >>
>>>> 	> >> >> > >> Ted's concerns were consistent with most
>>>> (all?) other
>>>> 	> >> >> concerns --
>>>> 	> >> >> > >> which were based on the premise of whether
>> or not the
>>>> 	> >> >> UAC should be
>>>> 	> >> >> > >> trusted to initiate the marking on the
>> INVITE.  The
>>>> most
>>>> 	> >> >> > >> recent version has backed off this to a "can" --
>>>> meaning not
>>>> 	> >> >prohibited
>>>> 	> >> >> > >> (i.e., no 2119 text).  I also backed off
>> the text in
>>>> the
>>>> 	> >> >> SP domain
>>>> 	> >> >> > >> part to "can", such that there is no 2119 text
>>>> 	> >> >mandating or even
>>>> 	> >> >> > >> recommending its usage there. I also do
>> not prohibit
>>>> its
>>>> 	> >> >> > >use, based on
>>>> 	> >> >> > >> local policy.  Keith has come forward with
>> the specific
>>>>
>>>> 	> >> >> > >> request that non-ESInet networks be
>> allowed to mark and
>>>> pay
>>>> 	> >> >attention to
>>>> 	> >> >> > >> this priority indication -- with IMS as
>> the specific
>>>> example
>>>> 	> >> >> > >> he wishes to have this valid for.
>>>> 	> >> >> > >>
>>>> 	> >> >> > >> Where there is no disagreement, save for
>> your recent
>>>> 	> >> >> > >pushback - is in
>>>> 	> >> >> > >> the ESInet, which is where Brian has requested it's
>>>> 	> >> >> > >definition in the
>>>> 	> >> >> > >> IETF on behalf of NENA.  He's the i3 WG
>> chair within
>>>> 	> >> >> NENA, and if
>>>> 	> >> >> > >> he asks for it, are you going to say you
>> know better
>>>> than he?
>>>> 	> >> >> > >>
>>>> 	> >> >> > >>
>>>> 	> >> >> > >> >Btw, I not disagreeing with the document
>> as such. I
>>>> 	> >> >just want to
>>>> 	> >> >> > the
>>>> 	> >> >> > >> scope
>>>> 	> >> >> > >> >to change. The usage of RPH within the emergency
>>>> 	> >> >> services network
>>>> 	> >> >> > is
>>>> 	> >> >> > >> fine
>>>> 	> >> >> > >> >for me. I may get convinced to start the
>> RPH marking
>>>> from
>>>> 	> >> >> > >the the VSP
>>>> 	> >> >> > >> >towards the PSAP. I feel uneasy about the
>> end host
>>>> doing
>>>> 	> >> >> > >the marking.
>>>> 	> >> >> > >>
>>>> 	> >> >> > >> please read what I wrote above, and then
>> re-read the
>>>> 	> >> >most recent
>>>> 	> >> >> > >> version of the ID. I don't have endpoints
>> that SHOULD
>>>> or
>>>> 	> >> >> MUST mark
>>>> 	> >> >> > >> anything wrt RPH.  I also don't want to
>> prohibit it,
>>>> 	> >> >> because there
>>>> 	> >> >> > >> might be cases (that I don't know of) of valid uses
>>>> 	> >> >> under certain
>>>> 	> >> >> > >> circumstances.  Figure 1 is very clear
>> that there are 3
>>>> 	> >> >> networking
>>>> 	> >> >> > >> parts to consider
>>>> 	> >> >> > >>
>>>> 	> >> >> > >> #1 - from the endpoint
>>>> 	> >> >> > >> #2 - within the VSP
>>>> 	> >> >> > >> #3 - within the ESInet
>>>> 	> >> >> > >>
>>>> 	> >> >> > >> the most recent ID version has "can" for
>> #s 1 and 2,
>>>> and
>>>> 	> >> >> > >2119 language
>>>> 	> >> >> > >> offering those supporting this
>> specification will have
>>>> RPH
>>>> 	> >> >> > >> adherence within #3 (the ESInet).
>>>> 	> >> >> > >>
>>>> 	> >> >> > >> What other scope changes do you want,
>> because I haven't
>>>> 	> >> >> heard them.
>>>> 	> >> >> > >>
>>>> 	> >> >> > >> I only heard you claim in email during the
>> last IETF
>>>> and in
>>>> 	> >> >> > >the ECRIT
>>>> 	> >> >> > >> session that RPH should not be used for priority
>>>> marking
>>>> 	> >> >> requests.
>>>> 	> >> >> > >> This is something Keith (SIP WG chair) voiced his
>>>> opposition
>>>> 	> >> >> > >> to your views regarding creating a second
>> means for SIP
>>>> to
>>>> 	> >> >priority
>>>> 	> >> >> > >> mark request "when SIP already has one
>> interoperable
>>>> way to
>>>> 	> >> >> > >> accomplish this... it's call the RP header
>> mechanism".
>>>> 	> >> >> > >>
>>>> 	> >> >> > >> >I don't see advantages -- only disadvantages.
>>>> 	> >> >> > >> >
>>>> 	> >> >> > >> >Ciao
>>>> 	> >> >> > >> >Hannes
>>>> 	> >> >> > >>
>>>> 	> >> >> > >> _______________________________________________
>>>> 	> >> >> > >> Ecrit mailing list
>>>> 	> >> >> > >> [email-masked]
>>>> 	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>>>> 	> >> >> > >
>>>> 	> >> >>
>>>> 	> >> >> _______________________________________________
>>>> 	> >> >> Ecrit mailing list
>>>> 	> >> >> [email-masked]
>>>> 	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>>>> 	> >> >>
>>>> 	> >> >
>>>> 	> >
>>>> 	>
>>>> 	> _______________________________________________
>>>> 	> Ecrit mailing list
>>>> 	> [email-masked]
>>>> 	> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>
>>> _______________________________________________
>>> Ecrit mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

From: "Brian Rosen" <[email-masked]>
To: "'Henning Schulzrinne'" <[email-masked]>, "'Hannes Tschofenig'" <[email-masked]>
Date: Fri, 6 Feb 2009 10:49:19 -0500
Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" <[email-masked]>, 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] RPH

I agree that not all networks will permit (or pay attention to) a priority
request from an end device.

No one has asked for that.

The namespace request has several uses, one of which is within an emergency
services IP network, one of which is between elements within a public
network controlled by the operator, and one of which is an endpoint request
for resource priority.

Those of us requesting this work proceed are happy if the endpoint part is
simply left as possible (MAY), and, speaking for myself, having the draft
discuss the security implications of endpoint marking is reasonable.

Having discussed this issue with an implementation team who worked on MLPP
systems, I am confident I know what I'm talking about, but YMMV.  The fact
that you could, if you wanted to, give resource priority to a call you
decided, however you decided, was an emergency call is an implementation
decision, and not subject to standardization.  

RPH is the IETF standard way for one entity to request resource priority of
another entity in a SIP system.  We're asking for a namespace to use that
within the domain of emergency calls.  That is, I think, a VERY reasonable
request.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, February 06, 2009 10:33 AM
> To: Hannes Tschofenig
> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
> Subject: Re: [Ecrit] RPH
> 
> To chime in here:
> 
> I don't think it's productive to simply state that 4412 doesn't worry
> about authorization, so we shouldn't either (simplifying a bit).
> Authorization was discussed repeatedly, and the general assumption was
> that there were two conditions: Either the user invoking resource-
> priority was well known and had a set of permissions that could be
> checked in real time or there are ways to deal with abuse after the
> fact in ways that deter abuse (the court-martial kind of thing in a
> military context).
> 
> The RFC 4412 security consideration (11.2) call this out in pretty
> strong language:
> 
>   Prioritized access to network and end-system resources imposes
>     particularly stringent requirements on authentication and
>     authorization mechanisms, since access to prioritized resources may
>     impact overall system stability and performance and not just result
>     in theft of, say, a single phone call.
> Thus, the question is whether we have such strong authentication in
> emergency calling. In some cases, such as residential fixed line
> deployments where ISP = VSP, we're probably pretty close, in others,
> such as prepaid cell phones or hot spots or VSP-only providers, we
> aren't.
> 
> The other point that I think Hannes is making is that the information
> is either redundant or dangerous. If a processing element recognizes
> the call as being an emergency call, it can apply whatever treatment
> it deems appropriate and doesn't need additional information. If it
> doesn't or can't, using just the RPH can be rather dangerous unless
> that element can be reasonably certain that there is strong
> authentication and recourse.
> 
> I don't buy the argument that somehow finding the RPH is faster than
> just looking for the identifier. Thus, given that the information is
> either redundant or dangerous, I fail to see the advantage.
> 
> Henning
> 
> 
> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
> 
> > Don't get hung up on the details. There are ways to optimize it.
> > That was
> > not the point of the code example.
> >
> > The problem that my pseudo code should have shown you is that you
> > * don't gain anything with RPH marking for the emergency call case
> > from the
> > SIP UA towards the outbound proxy since the functionality is already
> > provide
> > otherwise. How often does the proxy need to get told that this is an
> > emergency call todo whatever emergency call handling procedures are
> > necessary?
> > * you only introduce fraud problems (if you are not careful and you
> > understand the security stuff well enough)
> >
> > If you can point me to people who implement the RPH emergency call
> > case
> > please do so. I would love to talk to them.
> >
> > Ciao
> > Hannes
> >
> > PS: You need to parse incoming messages to some extend so that you
> > know what
> > it contains :-)
> > Only looking for the emergency RPH header (and not for the Service
> > URN/dial
> > string) would exactly be the DoS/fraud attack I am worried about.
> > That's the thing Henning was worried about (go and listen to the past
> > meeting minutes).
> >
> >
> >> Hannes
> >>
> >> You need to talk to people who really implement this kind of
> >> thing.  You are way off.
> >>
> >> When you implement a resource priority system, the point of
> >> doing that is to look though the queue of work and pick out
> >> the ones with priority, handling them first.  You don't do all
> >> the parsing, you don't do a lot of decision tree.
> >>
> >> Typically:
> >> Check for DoS things, like too big messages, etc Do a quick
> >> scan for the RPH message header If found:
> >> Parse the message
> >> Determine validity
> >> Determine priority
> >> Queue on the correct work queue
> >>
> >> The first two actions have to be very fast.  Anyone who builds
> >> a SIP thingie will tell you that parsing is one of the big
> >> cycle consumers: if you have to parse every message BEFORE you
> >> determine priority, you can't give much resource priority.
> >> Once you get the whole message parsed, you might as well
> >> finish working on it, because you've done so much of the work.
> >> OTHOH, finding the end-of-message delimiter and doing a quick
> >> string search for RPH is fast.  If you are doing priority, you
> >> need to keep all the priority processing pretty uniform, and
> >> pretty simple, or you tend to spend too much time futzing
> >> around figuring out what to do.  You put all the priority
> >> related stuff together, and use as much common code as possible.
> >>
> >> Brian
> >>
> >>> -----Original Message-----
> >>> From: [email-masked] [mailto:[email-masked]]
> >> On Behalf
> >>> Of Hannes Tschofenig
> >>> Sent: Friday, February 06, 2009 8:41 AM
> >>> To: 'Hannes Tschofenig'; 'Janet P Gunn'
> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-
> >>> [email-masked]
> >>> Subject: [Ecrit] RPH
> >>>
> >>> Over lunch I was also thinking how an outbound proxy would
> implement
> >>> some of the emergency procedures. Here are some thoughts:
> >>>
> >>> ---------------------------------------------------
> >>>
> >>> // Process incoming message
> >>> Parse(msg);
> >>>
> >>> // SIP INVITE without Service URN
> >>> // legacy devices
> >>> If (recognize-dialstring(msg)==TRUE) {
> >>>  // we got an emergency call going on
> >>>  emergency=TRUE;
> >>>  if (dialstring(msg) == 911) serviceURN=urn:service:sos; } else if
> >>> (recognize-serviceURN(msg)==TRUE) {
> >>>  // oh. A updated device that has a service URN attached to the
> call
> >>>  serviceURN=retrieve_ServiceURN(msg);
> >>>  emergency=TRUE;
> >>> } else {
> >>>  // standard SIP message
> >>>  // regular processing
> >>>  process(msg);
> >>>  emergency=FALSE;
> >>> }
> >>>
> >>> If (emergency == TRUE) {
> >>>   // make sure that the emergency call does not get dropped on the
> >>> floor
> >>>   // skip authorization failures
> >>>   // give the call a special treatment
> >>>   lots-of-code-here();
> >>>
> >>>   // trigger all the QoS signaling you have in the network to make
> >>> James happy
> >>>   trigger-qos();
> >>>
> >>>   // query location
> >>>   location=retrieve-location();
> >>>
> >>>   // determine next hop
> >>>   next-hop=lost(location, serviceURN)
> >>>
> >>>   // attach RPH marking to outgoing msg to make James and
> >> Keith happy
> >>>   msg=add(msg, RPH);
> >>>
> >>>   send(msg, next-hop);
> >>> }
> >>>
> >>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
> >>>   // all the emergency related processing done already upfront
> >>>   // hence I log something.
> >>>   log(RPH_WAS_PRESENT_JUHU);
> >>> } else if ((rph-present(msg) == TRUE) && (emergency == FALSE)) {
> >>>  // this is not an emergency call
> >>>  // this is something like GETS
> >>>  result=special-authorization-procedure(user);
> >>>
> >>>  if (result == AUTHORIZED) {
> >>>    // do some priority & preemption thing here.
> >>>    // trigger all the QoS you have
> >>>    lots-of-code-here();
> >>>  } else {
> >>>    log("NOT AUTHORIZED; don't DoS my network");
> >>>  }
> >>> } else {
> >>>  // don't need todo any RPH processing
> >>>  // this includes the case where the call was an emergency call but
> >>> the RPH
> >>>
> >>>  // marking was not there.
> >>>  nothing();
> >>> }
> >>>
> >>> ---------------------------------------------------
> >>>
> >>>
> >>> Ciao
> >>> Hannes
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>>> Behalf Of Hannes Tschofenig
> >>>> Sent: 06 February, 2009 15:07
> >>>> To: 'Janet P Gunn'
> >>>> Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
> >>> FI/Espoo)
> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
> >>>>
> >>>> Who would define something that could prevent DoS problems?
> >>>>
> >>>> ________________________________
> >>>>
> >>>> 	From: Janet P Gunn [mailto:[email-masked]]
> >>>> 	Sent: 06 February, 2009 14:11
> >>>> 	To: Hannes Tschofenig
> >>>> 	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >>>> [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
> 'James
> >>>> M. Polk'
> >>>> 	Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
> >>>>
> >>>>
> >>>>
> >>>> 	But there is nothing IN RFC4412 that specifically
> >> addresses how to
> >>>> prevent any particular namespace being used for DoS.  Anyone/any
> UA
> >>>> can ATTEMPT to invoke priority treatment by attaching RPH.  For
> all
> >>>> of the 4412 namespaces, as with the new proposed namespace, the
> >>>> mechanisms for preventing DoS are not specified in the
> >> document that
> >>>> defines the namespace.
> >>>> They are/will be specified elsewhere.
> >>>>
> >>>> 	Janet
> >>>>
> >>>> 	This is a PRIVATE message. If you are not the intended
> >> recipient,
> >>>> please delete without copying and kindly advise us by e-mail of
> the
> >>>> mistake in delivery.
> >>>> 	NOTE: Regardless of content, this e-mail shall not
> >> operate to bind
> >>>> CSC to any order or other contract unless pursuant to explicit
> >>>> written agreement or government initiative expressly permitting
> the
> >>>> use of e-mail for such purpose.
> >>>>
> >>>> 	[email-masked] wrote on 02/06/2009 04:21:51 AM:
> >>>>
> >>>> 	> Hi James,
> >>>> 	>
> >>>> 	> I have read RFC 4412 and also the GETS/MLPP IETF
> >> documents. What I
> >>>> would
> >>>> 	> like to point out is that there is more than just a
> >> header and
> >>>> values within
> >>>> 	> the header that have to be considered in order to
> >> make a judgement
> >>>> of what
> >>>> 	> is appropriate and what isn't. There is an
> >> architectural question
> >>>> and
> >>>> 	> whether the environment we are using the stuff is
> >> indeed providing
> >>>> the
> >>>> 	> properties you need for the solution to be appropriate.
> >>>> 	>
> >>>> 	> Let me describe in more detail what I meant (and
> >> please correct me
> >>>> if I am
> >>>> 	> wrong).
> >>>> 	>
> >>>> 	> Getting priority for SIP requests when using a GETS
> >> alike scenario
> >>>> means
> >>>> 	> that the entity that issues the request is specially
> >> authorized
> >>>> since
> >>>> 	> otherwise you introduce a nice denial of service attack. This
> >>>> authorization
> >>>> 	> is tied to the entity that makes the request. For
> >> example, the
> >>>> person is
> >>>> 	> working for the government and has special rights.
> >>>> James Bond as a (not so)
> >>>> 	> secret agent might have these rights.
> >>>> 	>
> >>>> 	> The emergency services case (citizen-to-authority) is a bit
> >>>> different as
> >>>> 	> there aren't really special rights with respect to
> >> authorization
> >>>> tied to
> >>>> 	> individuals. Instead, the fact that something is an
> >> emergency is
> >>>> purely a
> >>>> 	> judgement of the human that dials a special number.
> >>>> To deal with fraud, we
> >>>> 	> discussed in the group on what we can actually do to
> >> ensure that
> >>>> end users
> >>>> 	> do not bypass security procedures (such as
> >> authorization checks,
> >>>> charging
> >>>> 	> and so on). Part of this investigation was the publication of
> >>>> 	> http://www.ietf.org/rfc/rfc5069.txt that also describes this
> >>>> issue.
> >>>> 	>
> >>>> 	> So, imagine the implementation of a SIP proxy (and we
> >> implemented
> >>>> that
> >>>> 	> stuff) that receives a call that contains a Service
> >> URN. The code
> >>>> branches
> >>>> 	> into a special mode where everything is done so that the call
> >>>> receives
> >>>> 	> appropriate treatment and does not get dropped on the
> >> floor. The
> >>>> way how the
> >>>> 	> Service URN is placed in the message ensures that the
> >> call cannot
> >>>> go to my
> >>>> 	> friend (instead of the PSAP) unless the end host ran
> >> LoST already.
> >>>> In the
> >>>> 	> latter case, we discussed this also on the list for a
> >> while and
> >>>> Richard even
> >>>> 	> wrote a draft about it in the context of the location hiding
> >>>> topic, we said
> >>>> 	> that the proxy would have to run LoST if he cares about a
> >>>> potential
> >>>> 	> fraudulent usage.
> >>>> 	>
> >>>> 	> So, what do we need todo in order to provide secure RFC 4412
> >>>> functionality
> >>>> 	> in our context?
> >>>> 	>
> >>>> 	> Do you think that the current text in
> >>>> 	>
> >>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >>>> gency-rph-nam
> >>>> 	> espace-00.txt reflects any of the above-described issues:
> >>>> 	> "
> >>>> 	>    The Security considerations that apply to RFC 4412
> >>>> [RFC4412]
> >>>> apply
> >>>> 	>    here.  This document introduces no new security
> >>>> issues relative
> >>>> to
> >>>> 	>    RFC 4412.
> >>>> 	> "
> >>>> 	>
> >>>> 	> From various discussions in GEOPRIV I recall that you are
> >>>> super-sensitive
> >>>> 	> regarding security and privacy. For some reasons you
> >> don't seem to
> >>>> have the
> >>>> 	> same concerns here. I would like to understand your reasoning.
> >>>> 	>
> >>>> 	> Please also do me another favor: Don't always say
> >> that I don't
> >>>> understand
> >>>> 	> the subject. Even if that would be the case it isn't
> >> particular
> >>>> fair given
> >>>> 	> that different folks had to educate you on other
> >> topics in the
> >>>> past as well.
> >>>> 	> Additionally, if you listen to the audio recordings
> >> then you will
> >>>> notice
> >>>> 	> that Henning, Ted, and Jon do not seem to understand
> >> the issue
> >>>> either as
> >>>> 	> they have raised similar issues during the F2F meetings.
> >>>> 	>
> >>>> 	> Ciao
> >>>> 	> Hannes
> >>>> 	>
> >>>> 	>
> >>>> 	> >Hannes - I believe it is you who do not understand
> >> RFC 4412 --
> >>>> 	> >and many of us are trying to get that through to you, but you
> >>>> 	> >don't seem to want to listen/read.
> >>>> 	> >
> >>>> 	> >RFC 4412 is *for* priority marking SIP requests,
> >>>> 	> >
> >>>> 	> >One use is GETS.
> >>>> 	> >
> >>>> 	> >One use is MLPP.
> >>>> 	> >
> >>>> 	> >These examples are in RFC 4412 because there were specific
> >>>> 	> >namespaces being created for the IANA section of
> >> that document.
> >>>> 	> >
> >>>> 	> >Reading the whole document, you will see that RPH can be
> >>>> 	> >specified for other uses than GETS or MLPP specifically.
> >>>> 	> >
> >>>> 	> >I knew when I wrote RFC 4412 that one day we would specify a
> >>>> 	> >namespace for ECRIT (the "esnet" namespace now) -- but I also
> >>>> 	> >knew it was premature for RFC 4412 to incorporate that
> >>>> 	> >namespace, that a future doc to RFC 4412 would have to be
> >>>> 	> >written to do this. Brian and I talked about this at the
> >>>> 	> >original NENA meeting that created the IP WGs there
> >> (in August
> >>>> 	> >of 03).  We both agreed we should wait until it was
> >>>> 	> >appropriate to the work in the IETF to submit this document
> >>>> 	> >that is now
> >>>> 	>
> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >>>> 	> >gency-rph-namespace-00.txt
> >>>> 	> >
> >>>> 	> >Yet, you seem to want to use some additional mechanism to
> >>>> 	> >indicate priority of a call in SIP.  That means you want to
> >>>> 	> >introduce a second way to accomplish this in SIP.
> >>>> Why do you
> >>>> 	> >want to promote a separate way to do something SIP
> >> has already
> >>>> 	> >defined? That will cause interoperability issues and
> >> we both know
> >>>> that.
> >>>> 	> >
> >>>> 	> >You've said to me (and others) that you believe RPH is just
> >>>> 	> >another way to accomplish what sos or a URI can
> >> indicate - and
> >>>> 	> >you're wrong.  Your way would be _the_second_way_to_do_it,
> >>>> 	> >because SIP already considers RPH to be *the*way* to priority
> >>>> 	> >mark SIP requests.
> >>>> 	> >
> >>>> 	> >If you don't believe me (no comment), then why do you not
> >>>> 	> >believe the SIP WG chair (who knows more about SIP than both
> >>>> 	> >of us) - who, on this thread, has again said to you "RFC 4412
> >>>> 	> >(RPH) is the SIP mechanism to priority mark SIP requests"?
> >>>> 	> >
> >>>> 	> >Further, I believe it is inappropriate to prohibit endpoints
> >>>> 	> >from being able to set the esnet namespace.  I absolutely
> >>>> 	> >believe it will not be needed most of the time, but I believe
> >>>> 	> >if someone does find a valid use for endpoints to mark
> >>>> 	> >priority in SIP, this ID - once it has become an RFC -- will
> >>>> 	> >have to be obsoleted with a new RFC saying the exact
> >> opposite.
> >>>> 	> >
> >>>> 	> >(color me confused ... over and over again)
> >>>> 	> >
> >>>> 	> >James
> >>>> 	> >
> >>>> 	> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >>>> 	> >>Keith, please understand that the usage of RFC 4412
> >> for GETS and
> >>>> for
> >>>> 	> >>the type of emergency call we discuss here is
> >> different. Just
> >>>> looking
> >>>> 	> >>at the header and the name of the namespace is a bit
> >>>> 	> >artificial. I hope
> >>>> 	> >>you understand that.
> >>>> 	> >>
> >>>> 	> >> >-----Original Message-----
> >>>> 	> >> >From: DRAGE, Keith (Keith)
> >>>> [mailto:[email-masked]]
> >>>> 	> >> >Sent: 05 February, 2009 14:55
> >>>> 	> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
> >>>> Polk'; 'Tschofenig,
> >>>> 	> >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >>>> 	> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
> >>>> Meeting: Agenda (my
> >>>>
> >>>> 	> >> >mistake)
> >>>> 	> >> >
> >>>> 	> >> >Which is exactly what RFC 4412 specifies for all
> >> namespaces.
> >>>> 	> >> >
> >>>> 	> >> >regards
> >>>> 	> >> >
> >>>> 	> >> >Keith
> >>>> 	> >> >
> >>>> 	> >> >> -----Original Message-----
> >>>> 	> >> >> From: [email-masked]
> >> [mailto:[email-masked]]
> >>>> 	> >> >On Behalf
> >>>> 	> >> >> Of Brian Rosen
> >>>> 	> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >>>> 	> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
> >>>> 	> >Hannes (NSN
> >>>> 	> >> >> - FI/Espoo)'; 'ECRIT'
> >>>> 	> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >>>> Meeting: Agenda (my
> >>>> 	> >> >> mistake)
> >>>> 	> >> >>
> >>>> 	> >> >> The value is that in some networks where priority for
> >>>> 	> >> >emergency calls
> >>>> 	> >> >> is appropriate, and appropriate policing of marking is
> >>>> 	> >implemented,
> >>>> 	> >> >> emergency calls will receive resource priority.
> >>>> 	> >> >>
> >>>> 	> >> >> Not all networks would need policing.  Some
> >> will.  Policing
> >>>> could
> >>>> 	> >> >> be to Route header/R-URI content, but other
> >> criteria are
> >>>> possible.
> >>>> 	> >> >>
> >>>> 	> >> >> Not all networks will need resource priority
> >> for emergency
> >>>> calls.
> >>>> 	> >> >> Fine, ignore this marking/namespace.
> >>>> 	> >> >>
> >>>> 	> >> >> Brian
> >>>> 	> >> >> > -----Original Message-----
> >>>> 	> >> >> > From: Hannes Tschofenig
> >>>> [mailto:[email-masked]]
> >>>> 	> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >>>> 	> >> >> > To: 'Brian Rosen'; 'James M. Polk';
> >> Tschofenig, Hannes
> >>>> (NSN -
> >>>> 	> >> >> > FI/Espoo); 'ECRIT'
> >>>> 	> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
> >>>> Meeting: Agenda (my
> >>>> 	> >> >> > mistake)
> >>>> 	> >> >> >
> >>>> 	> >> >> > I don't even see the value in permitting the
> >> endpoint todo
> >>>> the
> >>>> 	> >> >> > RPH marking.
> >>>> 	> >> >> > In addition to the security concerns there is also the
> >>>> 	> >> >problem that
> >>>> 	> >> >> > there are more options to implement without
> >> an additional
> >>>> value.
> >>>> 	> >> >> >
> >>>> 	> >> >> > >-----Original Message-----
> >>>> 	> >> >> > >From: Brian Rosen [mailto:[email-masked]]
> >>>> 	> >> >> > >Sent: 05 February, 2009 00:03
> >>>> 	> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
> >> 'Tschofenig,
> >>>> 	> >> >> Hannes (NSN -
> >>>> 	> >> >> > >FI/Espoo)'; 'ECRIT'
> >>>> 	> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting:
> >>>> Agenda (my
> >>>> 	> >> >> > mistake)
> >>>> 	> >> >> > >
> >>>> 	> >> >> > >Hannes
> >>>> 	> >> >> > >
> >>>> 	> >> >> > >This matches my understanding precisely.  We wish to
> >>>> 	> >> >> permit endpoints
> >>>> 	> >> >> > >to mark. We do not require it, and don't necessarily
> >>>> expect it
> >>>> 	> >> >> > >in many (even
> >>>> 	> >> >> > >most) cases.  We don't wish to see the
> >> document prohibit
> >>>> it.
> >>>> 	> >> >> > >We all seem to agree it has value within the
> >> Emergency
> >>>> 	> >> >Services IP
> >>>> 	> >> >> > >Networks.
> >>>> 	> >> >> > >
> >>>> 	> >> >> > >Brian
> >>>> 	> >> >> > >
> >>>> 	> >> >> > >> -----Original Message-----
> >>>> 	> >> >> > >> From: [email-masked]
> >>>> [mailto:[email-masked]]
> >>>> 	> >> >> > >On Behalf
> >>>> 	> >> >> > >> Of James M. Polk
> >>>> 	> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> >>>> 	> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
> >>>> 	> >> >> FI/Espoo); 'ECRIT'
> >>>> 	> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >>>> Meeting:
> >>>> 	> >Agenda (my
> >>>> 	> >> >> > >> mistake)
> >>>> 	> >> >> > >>
> >>>> 	> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> >>>> 	> >> >> > >> > > James wrote:
> >>>> 	> >> >> > >> > >> you are the _lone_ voice not
> >> supporting this ID,
> >>>> 	> >> >> > >> >
> >>>> 	> >> >> > >> >Listening to the audio recording of past
> >> meetings I
> >>>> have to
> >>>> 	> >> >> > >say that
> >>>> 	> >> >> > >> >I
> >>>> 	> >> >> > >> was
> >>>> 	> >> >> > >> >not the only persons raising concerns about the
> >>>> document.
> >>>> 	> >> >> > >> >That was probably the reason why you
> >> agreed to limit
> >>>> the
> >>>> 	> >> >> > >scope of the
> >>>> 	> >> >> > >> >document (which you didn't later do) to
> >> get folks to
> >>>> agree
> >>>> 	> >> >> > >to make it
> >>>> 	> >> >> > >> a WG
> >>>> 	> >> >> > >> >item.
> >>>> 	> >> >> > >>
> >>>> 	> >> >> > >> re-listen to the audio please
> >>>> 	> >> >> > >>
> >>>> 	> >> >> > >> Ted's concerns were consistent with most
> >>>> (all?) other
> >>>> 	> >> >> concerns --
> >>>> 	> >> >> > >> which were based on the premise of whether
> >> or not the
> >>>> 	> >> >> UAC should be
> >>>> 	> >> >> > >> trusted to initiate the marking on the
> >> INVITE.  The
> >>>> most
> >>>> 	> >> >> > >> recent version has backed off this to a "can" --
> >>>> meaning not
> >>>> 	> >> >prohibited
> >>>> 	> >> >> > >> (i.e., no 2119 text).  I also backed off
> >> the text in
> >>>> the
> >>>> 	> >> >> SP domain
> >>>> 	> >> >> > >> part to "can", such that there is no 2119 text
> >>>> 	> >> >mandating or even
> >>>> 	> >> >> > >> recommending its usage there. I also do
> >> not prohibit
> >>>> its
> >>>> 	> >> >> > >use, based on
> >>>> 	> >> >> > >> local policy.  Keith has come forward with
> >> the specific
> >>>>
> >>>> 	> >> >> > >> request that non-ESInet networks be
> >> allowed to mark and
> >>>> pay
> >>>> 	> >> >attention to
> >>>> 	> >> >> > >> this priority indication -- with IMS as
> >> the specific
> >>>> example
> >>>> 	> >> >> > >> he wishes to have this valid for.
> >>>> 	> >> >> > >>
> >>>> 	> >> >> > >> Where there is no disagreement, save for
> >> your recent
> >>>> 	> >> >> > >pushback - is in
> >>>> 	> >> >> > >> the ESInet, which is where Brian has requested it's
> >>>> 	> >> >> > >definition in the
> >>>> 	> >> >> > >> IETF on behalf of NENA.  He's the i3 WG
> >> chair within
> >>>> 	> >> >> NENA, and if
> >>>> 	> >> >> > >> he asks for it, are you going to say you
> >> know better
> >>>> than he?
> >>>> 	> >> >> > >>
> >>>> 	> >> >> > >>
> >>>> 	> >> >> > >> >Btw, I not disagreeing with the document
> >> as such. I
> >>>> 	> >> >just want to
> >>>> 	> >> >> > the
> >>>> 	> >> >> > >> scope
> >>>> 	> >> >> > >> >to change. The usage of RPH within the emergency
> >>>> 	> >> >> services network
> >>>> 	> >> >> > is
> >>>> 	> >> >> > >> fine
> >>>> 	> >> >> > >> >for me. I may get convinced to start the
> >> RPH marking
> >>>> from
> >>>> 	> >> >> > >the the VSP
> >>>> 	> >> >> > >> >towards the PSAP. I feel uneasy about the
> >> end host
> >>>> doing
> >>>> 	> >> >> > >the marking.
> >>>> 	> >> >> > >>
> >>>> 	> >> >> > >> please read what I wrote above, and then
> >> re-read the
> >>>> 	> >> >most recent
> >>>> 	> >> >> > >> version of the ID. I don't have endpoints
> >> that SHOULD
> >>>> or
> >>>> 	> >> >> MUST mark
> >>>> 	> >> >> > >> anything wrt RPH.  I also don't want to
> >> prohibit it,
> >>>> 	> >> >> because there
> >>>> 	> >> >> > >> might be cases (that I don't know of) of valid uses
> >>>> 	> >> >> under certain
> >>>> 	> >> >> > >> circumstances.  Figure 1 is very clear
> >> that there are 3
> >>>> 	> >> >> networking
> >>>> 	> >> >> > >> parts to consider
> >>>> 	> >> >> > >>
> >>>> 	> >> >> > >> #1 - from the endpoint
> >>>> 	> >> >> > >> #2 - within the VSP
> >>>> 	> >> >> > >> #3 - within the ESInet
> >>>> 	> >> >> > >>
> >>>> 	> >> >> > >> the most recent ID version has "can" for
> >> #s 1 and 2,
> >>>> and
> >>>> 	> >> >> > >2119 language
> >>>> 	> >> >> > >> offering those supporting this
> >> specification will have
> >>>> RPH
> >>>> 	> >> >> > >> adherence within #3 (the ESInet).
> >>>> 	> >> >> > >>
> >>>> 	> >> >> > >> What other scope changes do you want,
> >> because I haven't
> >>>> 	> >> >> heard them.
> >>>> 	> >> >> > >>
> >>>> 	> >> >> > >> I only heard you claim in email during the
> >> last IETF
> >>>> and in
> >>>> 	> >> >> > >the ECRIT
> >>>> 	> >> >> > >> session that RPH should not be used for priority
> >>>> marking
> >>>> 	> >> >> requests.
> >>>> 	> >> >> > >> This is something Keith (SIP WG chair) voiced his
> >>>> opposition
> >>>> 	> >> >> > >> to your views regarding creating a second
> >> means for SIP
> >>>> to
> >>>> 	> >> >priority
> >>>> 	> >> >> > >> mark request "when SIP already has one
> >> interoperable
> >>>> way to
> >>>> 	> >> >> > >> accomplish this... it's call the RP header
> >> mechanism".
> >>>> 	> >> >> > >>
> >>>> 	> >> >> > >> >I don't see advantages -- only disadvantages.
> >>>> 	> >> >> > >> >
> >>>> 	> >> >> > >> >Ciao
> >>>> 	> >> >> > >> >Hannes
> >>>> 	> >> >> > >>
> >>>> 	> >> >> > >> _______________________________________________
> >>>> 	> >> >> > >> Ecrit mailing list
> >>>> 	> >> >> > >> [email-masked]
> >>>> 	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>> 	> >> >> > >
> >>>> 	> >> >>
> >>>> 	> >> >> _______________________________________________
> >>>> 	> >> >> Ecrit mailing list
> >>>> 	> >> >> [email-masked]
> >>>> 	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>> 	> >> >>
> >>>> 	> >> >
> >>>> 	> >
> >>>> 	>
> >>>> 	> _______________________________________________
> >>>> 	> Ecrit mailing list
> >>>> 	> [email-masked]
> >>>> 	> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Ecrit mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>
> >>>
> >>> _______________________________________________
> >>> Ecrit mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ecrit
> >

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Henning Schulzrinne <[email-masked]>, Hannes Tschofenig <[email-masked]>
Date: Fri, 6 Feb 2009 16:57:47 +0100
Accept-Language: en-US
acceptlanguage: en-US
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

One of the points I was going to make was that RPH in itself does not neces=
sarily create DOS as Hannes seems to be thinking. Henning seems to also be =
saying that below, in that after the event restrictions can be used to deal=
 with problems. As Brian has indicated you place traffic relating to differ=
ent namespaces and different priorities within namespaces (if defined) with=
in different queues. Unmarked traffic goes into another queue or queues. Yo=
u then process those queues according to some algorithm.

The main way of reaching a DOS attach with RPH is if the algorithm always p=
rocess all the traffic in a particular queue before processing any of the o=
thers, and I suspect most RPH usages will not do that, and in any case, the=
re are good reasons for not doing this on emergency calls. I believe I have=
 made the point repeatedly in the past that RPH does not mean first come fi=
rst served. It means I have made an commitment with the namespace owner to =
handle the traffic with certain defined criteria.

And in some respects any emergency call handling in the network that is not=
 well specified can cause a denial of service attack, whether it is RPH mar=
ked or not. This is merely because you are funnelling potentially large amo=
unts of traffic to few endpoints.

So RPH is a tool. Poor usage can cause problems, as can not setting up your=
 routing handling correctly to deal with multiple calls to a single destina=
tion. We don't specify good practice for either.

But in general authorisation works very simply, and I am not arguing for no=
 authorisation. Essentially it consists of:

Do I trust the prior entity in the chain to send me a request RPH header wi=
th a particular namespace and priority level. If yes I put it in the approp=
riate queue. In no I either throw the RPH header away, pass it on without s=
pecial handling of the request, or perform my own authorisation of that use=
r. Which I use is based on network design, and agrements between service pr=
oviders.

Authorisation of the user in this respect generally checks a very limited n=
umber of criteria:
-       Is this call addressed to a PSAP
-       Is this user allowed to make an emergency call

Keith

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Henning Schulzrinne
> Sent: Friday, February 06, 2009 3:33 PM
> To: Hannes Tschofenig
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
> Subject: Re: [Ecrit] RPH
>
> To chime in here:
>
> I don't think it's productive to simply state that 4412
> doesn't worry about authorization, so we shouldn't either
> (simplifying a bit).
> Authorization was discussed repeatedly, and the general
> assumption was that there were two conditions: Either the
> user invoking resource- priority was well known and had a set
> of permissions that could be checked in real time or there
> are ways to deal with abuse after the fact in ways that deter
> abuse (the court-martial kind of thing in a military context).
>
> The RFC 4412 security consideration (11.2) call this out in
> pretty strong language:
>
>   Prioritized access to network and end-system resources imposes
>     particularly stringent requirements on authentication and
>     authorization mechanisms, since access to prioritized
> resources may
>     impact overall system stability and performance and not
> just result
>     in theft of, say, a single phone call.
> Thus, the question is whether we have such strong
> authentication in emergency calling. In some cases, such as
> residential fixed line deployments where ISP =3D VSP, we're
> probably pretty close, in others, such as prepaid cell phones
> or hot spots or VSP-only providers, we aren't.
>
> The other point that I think Hannes is making is that the
> information is either redundant or dangerous. If a processing
> element recognizes the call as being an emergency call, it
> can apply whatever treatment it deems appropriate and doesn't
> need additional information. If it doesn't or can't, using
> just the RPH can be rather dangerous unless that element can
> be reasonably certain that there is strong authentication and
> recourse.
>
> I don't buy the argument that somehow finding the RPH is
> faster than just looking for the identifier. Thus, given that
> the information is either redundant or dangerous, I fail to
> see the advantage.
>
> Henning
>
>
> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
>
> > Don't get hung up on the details. There are ways to optimize it.
> > That was
> > not the point of the code example.
> >
> > The problem that my pseudo code should have shown you is that you
> > * don't gain anything with RPH marking for the emergency call case
> > from the SIP UA towards the outbound proxy since the
> functionality is
> > already provide otherwise. How often does the proxy need to
> get told
> > that this is an emergency call todo whatever emergency call
> handling
> > procedures are necessary?
> > * you only introduce fraud problems (if you are not careful and you
> > understand the security stuff well enough)
> >
> > If you can point me to people who implement the RPH emergency call
> > case please do so. I would love to talk to them.
> >
> > Ciao
> > Hannes
> >
> > PS: You need to parse incoming messages to some extend so that you
> > know what it contains :-) Only looking for the emergency RPH header
> > (and not for the Service URN/dial
> > string) would exactly be the DoS/fraud attack I am worried about.
> > That's the thing Henning was worried about (go and listen
> to the past
> > meeting minutes).
> >
> >
> >> Hannes
> >>
> >> You need to talk to people who really implement this kind
> of thing.
> >> You are way off.
> >>
> >> When you implement a resource priority system, the point of doing
> >> that is to look though the queue of work and pick out the
> ones with
> >> priority, handling them first.  You don't do all the parsing, you
> >> don't do a lot of decision tree.
> >>
> >> Typically:
> >> Check for DoS things, like too big messages, etc Do a
> quick scan for
> >> the RPH message header If found:
> >> Parse the message
> >> Determine validity
> >> Determine priority
> >> Queue on the correct work queue
> >>
> >> The first two actions have to be very fast.  Anyone who
> builds a SIP
> >> thingie will tell you that parsing is one of the big cycle
> consumers:
> >> if you have to parse every message BEFORE you determine
> priority, you
> >> can't give much resource priority.
> >> Once you get the whole message parsed, you might as well finish
> >> working on it, because you've done so much of the work.
> >> OTHOH, finding the end-of-message delimiter and doing a
> quick string
> >> search for RPH is fast.  If you are doing priority, you
> need to keep
> >> all the priority processing pretty uniform, and pretty
> simple, or you
> >> tend to spend too much time futzing around figuring out
> what to do.
> >> You put all the priority related stuff together, and use as much
> >> common code as possible.
> >>
> >> Brian
> >>
> >>> -----Original Message-----
> >>> From: [email-masked] [mailto:[email-masked]]
> >> On Behalf
> >>> Of Hannes Tschofenig
> >>> Sent: Friday, February 06, 2009 8:41 AM
> >>> To: 'Hannes Tschofenig'; 'Janet P Gunn'
> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-
> >>> [email-masked]
> >>> Subject: [Ecrit] RPH
> >>>
> >>> Over lunch I was also thinking how an outbound proxy
> would implement
> >>> some of the emergency procedures. Here are some thoughts:
> >>>
> >>> ---------------------------------------------------
> >>>
> >>> // Process incoming message
> >>> Parse(msg);
> >>>
> >>> // SIP INVITE without Service URN
> >>> // legacy devices
> >>> If (recognize-dialstring(msg)=3D=3DTRUE) {  // we got an
> emergency call
> >>> going on  emergency=3DTRUE;  if (dialstring(msg) =3D=3D 911)
> >>> serviceURN=3Durn:service:sos; } else if
> >>> (recognize-serviceURN(msg)=3D=3DTRUE) {
> >>>  // oh. A updated device that has a service URN attached
> to the call
> >>> serviceURN=3Dretrieve_ServiceURN(msg);
> >>>  emergency=3DTRUE;
> >>> } else {
> >>>  // standard SIP message
> >>>  // regular processing
> >>>  process(msg);
> >>>  emergency=3DFALSE;
> >>> }
> >>>
> >>> If (emergency =3D=3D TRUE) {
> >>>   // make sure that the emergency call does not get
> dropped on the
> >>> floor
> >>>   // skip authorization failures
> >>>   // give the call a special treatment
> >>>   lots-of-code-here();
> >>>
> >>>   // trigger all the QoS signaling you have in the
> network to make
> >>> James happy
> >>>   trigger-qos();
> >>>
> >>>   // query location
> >>>   location=3Dretrieve-location();
> >>>
> >>>   // determine next hop
> >>>   next-hop=3Dlost(location, serviceURN)
> >>>
> >>>   // attach RPH marking to outgoing msg to make James and
> >> Keith happy
> >>>   msg=3Dadd(msg, RPH);
> >>>
> >>>   send(msg, next-hop);
> >>> }
> >>>
> >>> If ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D TRUE)) {
> >>>   // all the emergency related processing done already upfront
> >>>   // hence I log something.
> >>>   log(RPH_WAS_PRESENT_JUHU);
> >>> } else if ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D
> FALSE)) {  //
> >>> this is not an emergency call  // this is something like GETS
> >>> result=3Dspecial-authorization-procedure(user);
> >>>
> >>>  if (result =3D=3D AUTHORIZED) {
> >>>    // do some priority & preemption thing here.
> >>>    // trigger all the QoS you have
> >>>    lots-of-code-here();
> >>>  } else {
> >>>    log("NOT AUTHORIZED; don't DoS my network");  } } else {  //
> >>> don't need todo any RPH processing  // this includes the
> case where
> >>> the call was an emergency call but the RPH
> >>>
> >>>  // marking was not there.
> >>>  nothing();
> >>> }
> >>>
> >>> ---------------------------------------------------
> >>>
> >>>
> >>> Ciao
> >>> Hannes
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>>> Behalf Of Hannes Tschofenig
> >>>> Sent: 06 February, 2009 15:07
> >>>> To: 'Janet P Gunn'
> >>>> Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
> >>> FI/Espoo)
> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
> >>>>
> >>>> Who would define something that could prevent DoS problems?
> >>>>
> >>>> ________________________________
> >>>>
> >>>>  From: Janet P Gunn [mailto:[email-masked]]
> >>>>  Sent: 06 February, 2009 14:11
> >>>>  To: Hannes Tschofenig
> >>>>  Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >>>> [email-masked]; Tschofenig, Hannes (NSN -
> FI/Espoo); 'James
> >>>> M. Polk'
> >>>>  Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
> >>>>
> >>>>
> >>>>
> >>>>  But there is nothing IN RFC4412 that specifically
> >> addresses how to
> >>>> prevent any particular namespace being used for DoS.
> Anyone/any UA
> >>>> can ATTEMPT to invoke priority treatment by attaching
> RPH.  For all
> >>>> of the 4412 namespaces, as with the new proposed namespace, the
> >>>> mechanisms for preventing DoS are not specified in the
> >> document that
> >>>> defines the namespace.
> >>>> They are/will be specified elsewhere.
> >>>>
> >>>>  Janet
> >>>>
> >>>>  This is a PRIVATE message. If you are not the intended
> >> recipient,
> >>>> please delete without copying and kindly advise us by
> e-mail of the
> >>>> mistake in delivery.
> >>>>  NOTE: Regardless of content, this e-mail shall not
> >> operate to bind
> >>>> CSC to any order or other contract unless pursuant to explicit
> >>>> written agreement or government initiative expressly
> permitting the
> >>>> use of e-mail for such purpose.
> >>>>
> >>>>  [email-masked] wrote on 02/06/2009 04:21:51 AM:
> >>>>
> >>>>  > Hi James,
> >>>>  >
> >>>>  > I have read RFC 4412 and also the GETS/MLPP IETF
> >> documents. What I
> >>>> would
> >>>>  > like to point out is that there is more than just a
> >> header and
> >>>> values within
> >>>>  > the header that have to be considered in order to
> >> make a judgement
> >>>> of what
> >>>>  > is appropriate and what isn't. There is an
> >> architectural question
> >>>> and
> >>>>  > whether the environment we are using the stuff is
> >> indeed providing
> >>>> the
> >>>>  > properties you need for the solution to be appropriate.
> >>>>  >
> >>>>  > Let me describe in more detail what I meant (and
> >> please correct me
> >>>> if I am
> >>>>  > wrong).
> >>>>  >
> >>>>  > Getting priority for SIP requests when using a GETS
> >> alike scenario
> >>>> means
> >>>>  > that the entity that issues the request is specially
> >> authorized
> >>>> since
> >>>>  > otherwise you introduce a nice denial of service attack. This
> >>>> authorization
> >>>>  > is tied to the entity that makes the request. For
> >> example, the
> >>>> person is
> >>>>  > working for the government and has special rights.
> >>>> James Bond as a (not so)
> >>>>  > secret agent might have these rights.
> >>>>  >
> >>>>  > The emergency services case (citizen-to-authority) is a bit
> >>>> different as
> >>>>  > there aren't really special rights with respect to
> >> authorization
> >>>> tied to
> >>>>  > individuals. Instead, the fact that something is an
> >> emergency is
> >>>> purely a
> >>>>  > judgement of the human that dials a special number.
> >>>> To deal with fraud, we
> >>>>  > discussed in the group on what we can actually do to
> >> ensure that
> >>>> end users
> >>>>  > do not bypass security procedures (such as
> >> authorization checks,
> >>>> charging
> >>>>  > and so on). Part of this investigation was the publication of
> >>>>  > http://www.ietf.org/rfc/rfc5069.txt that also describes this
> >>>> issue.
> >>>>  >
> >>>>  > So, imagine the implementation of a SIP proxy (and we
> >> implemented
> >>>> that
> >>>>  > stuff) that receives a call that contains a Service
> >> URN. The code
> >>>> branches
> >>>>  > into a special mode where everything is done so that the call
> >>>> receives
> >>>>  > appropriate treatment and does not get dropped on the
> >> floor. The
> >>>> way how the
> >>>>  > Service URN is placed in the message ensures that the
> >> call cannot
> >>>> go to my
> >>>>  > friend (instead of the PSAP) unless the end host ran
> >> LoST already.
> >>>> In the
> >>>>  > latter case, we discussed this also on the list for a
> >> while and
> >>>> Richard even
> >>>>  > wrote a draft about it in the context of the location hiding
> >>>> topic, we said
> >>>>  > that the proxy would have to run LoST if he cares about a
> >>>> potential
> >>>>  > fraudulent usage.
> >>>>  >
> >>>>  > So, what do we need todo in order to provide secure RFC 4412
> >>>> functionality
> >>>>  > in our context?
> >>>>  >
> >>>>  > Do you think that the current text in
> >>>>  >
> >>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >>>> gency-rph-nam
> >>>>  > espace-00.txt reflects any of the above-described issues:
> >>>>  > "
> >>>>  >    The Security considerations that apply to RFC 4412
> >>>> [RFC4412]
> >>>> apply
> >>>>  >    here.  This document introduces no new security
> >>>> issues relative
> >>>> to
> >>>>  >    RFC 4412.
> >>>>  > "
> >>>>  >
> >>>>  > From various discussions in GEOPRIV I recall that you are
> >>>> super-sensitive
> >>>>  > regarding security and privacy. For some reasons you
> >> don't seem to
> >>>> have the
> >>>>  > same concerns here. I would like to understand your reasoning.
> >>>>  >
> >>>>  > Please also do me another favor: Don't always say
> >> that I don't
> >>>> understand
> >>>>  > the subject. Even if that would be the case it isn't
> >> particular
> >>>> fair given
> >>>>  > that different folks had to educate you on other
> >> topics in the
> >>>> past as well.
> >>>>  > Additionally, if you listen to the audio recordings
> >> then you will
> >>>> notice
> >>>>  > that Henning, Ted, and Jon do not seem to understand
> >> the issue
> >>>> either as
> >>>>  > they have raised similar issues during the F2F meetings.
> >>>>  >
> >>>>  > Ciao
> >>>>  > Hannes
> >>>>  >
> >>>>  >
> >>>>  > >Hannes - I believe it is you who do not understand
> >> RFC 4412 --
> >>>>  > >and many of us are trying to get that through to you, but you
> >>>>  > >don't seem to want to listen/read.
> >>>>  > >
> >>>>  > >RFC 4412 is *for* priority marking SIP requests,
> >>>>  > >
> >>>>  > >One use is GETS.
> >>>>  > >
> >>>>  > >One use is MLPP.
> >>>>  > >
> >>>>  > >These examples are in RFC 4412 because there were specific
> >>>>  > >namespaces being created for the IANA section of
> >> that document.
> >>>>  > >
> >>>>  > >Reading the whole document, you will see that RPH can be
> >>>>  > >specified for other uses than GETS or MLPP specifically.
> >>>>  > >
> >>>>  > >I knew when I wrote RFC 4412 that one day we would specify a
> >>>>  > >namespace for ECRIT (the "esnet" namespace now) -- but I also
> >>>>  > >knew it was premature for RFC 4412 to incorporate that
> >>>>  > >namespace, that a future doc to RFC 4412 would have to be
> >>>>  > >written to do this. Brian and I talked about this at the
> >>>>  > >original NENA meeting that created the IP WGs there
> >> (in August
> >>>>  > >of 03).  We both agreed we should wait until it was
> >>>>  > >appropriate to the work in the IETF to submit this document
> >>>>  > >that is now
> >>>>  >
> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >>>>  > >gency-rph-namespace-00.txt
> >>>>  > >
> >>>>  > >Yet, you seem to want to use some additional mechanism to
> >>>>  > >indicate priority of a call in SIP.  That means you want to
> >>>>  > >introduce a second way to accomplish this in SIP.
> >>>> Why do you
> >>>>  > >want to promote a separate way to do something SIP
> >> has already
> >>>>  > >defined? That will cause interoperability issues and
> >> we both know
> >>>> that.
> >>>>  > >
> >>>>  > >You've said to me (and others) that you believe RPH is just
> >>>>  > >another way to accomplish what sos or a URI can
> >> indicate - and
> >>>>  > >you're wrong.  Your way would be _the_second_way_to_do_it,
> >>>>  > >because SIP already considers RPH to be *the*way* to priority
> >>>>  > >mark SIP requests.
> >>>>  > >
> >>>>  > >If you don't believe me (no comment), then why do you not
> >>>>  > >believe the SIP WG chair (who knows more about SIP than both
> >>>>  > >of us) - who, on this thread, has again said to you "RFC 4412
> >>>>  > >(RPH) is the SIP mechanism to priority mark SIP requests"?
> >>>>  > >
> >>>>  > >Further, I believe it is inappropriate to prohibit endpoints
> >>>>  > >from being able to set the esnet namespace.  I absolutely
> >>>>  > >believe it will not be needed most of the time, but I believe
> >>>>  > >if someone does find a valid use for endpoints to mark
> >>>>  > >priority in SIP, this ID - once it has become an RFC -- will
> >>>>  > >have to be obsoleted with a new RFC saying the exact
> >> opposite.
> >>>>  > >
> >>>>  > >(color me confused ... over and over again)
> >>>>  > >
> >>>>  > >James
> >>>>  > >
> >>>>  > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >>>>  > >>Keith, please understand that the usage of RFC 4412
> >> for GETS and
> >>>> for
> >>>>  > >>the type of emergency call we discuss here is
> >> different. Just
> >>>> looking
> >>>>  > >>at the header and the name of the namespace is a bit
> >>>>  > >artificial. I hope
> >>>>  > >>you understand that.
> >>>>  > >>
> >>>>  > >> >-----Original Message-----
> >>>>  > >> >From: DRAGE, Keith (Keith)
> >>>> [mailto:[email-masked]]
> >>>>  > >> >Sent: 05 February, 2009 14:55
> >>>>  > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
> >>>> Polk'; 'Tschofenig,
> >>>>  > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >>>>  > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
> >>>> Meeting: Agenda (my
> >>>>
> >>>>  > >> >mistake)
> >>>>  > >> >
> >>>>  > >> >Which is exactly what RFC 4412 specifies for all
> >> namespaces.
> >>>>  > >> >
> >>>>  > >> >regards
> >>>>  > >> >
> >>>>  > >> >Keith
> >>>>  > >> >
> >>>>  > >> >> -----Original Message-----
> >>>>  > >> >> From: [email-masked]
> >> [mailto:[email-masked]]
> >>>>  > >> >On Behalf
> >>>>  > >> >> Of Brian Rosen
> >>>>  > >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >>>>  > >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
> >>>>  > >Hannes (NSN
> >>>>  > >> >> - FI/Espoo)'; 'ECRIT'
> >>>>  > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >>>> Meeting: Agenda (my
> >>>>  > >> >> mistake)
> >>>>  > >> >>
> >>>>  > >> >> The value is that in some networks where priority for
> >>>>  > >> >emergency calls
> >>>>  > >> >> is appropriate, and appropriate policing of marking is
> >>>>  > >implemented,
> >>>>  > >> >> emergency calls will receive resource priority.
> >>>>  > >> >>
> >>>>  > >> >> Not all networks would need policing.  Some
> >> will.  Policing
> >>>> could
> >>>>  > >> >> be to Route header/R-URI content, but other
> >> criteria are
> >>>> possible.
> >>>>  > >> >>
> >>>>  > >> >> Not all networks will need resource priority
> >> for emergency
> >>>> calls.
> >>>>  > >> >> Fine, ignore this marking/namespace.
> >>>>  > >> >>
> >>>>  > >> >> Brian
> >>>>  > >> >> > -----Original Message-----
> >>>>  > >> >> > From: Hannes Tschofenig
> >>>> [mailto:[email-masked]]
> >>>>  > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >>>>  > >> >> > To: 'Brian Rosen'; 'James M. Polk';
> >> Tschofenig, Hannes
> >>>> (NSN -
> >>>>  > >> >> > FI/Espoo); 'ECRIT'
> >>>>  > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
> >>>> Meeting: Agenda (my
> >>>>  > >> >> > mistake)
> >>>>  > >> >> >
> >>>>  > >> >> > I don't even see the value in permitting the
> >> endpoint todo
> >>>> the
> >>>>  > >> >> > RPH marking.
> >>>>  > >> >> > In addition to the security concerns there is also the
> >>>>  > >> >problem that
> >>>>  > >> >> > there are more options to implement without
> >> an additional
> >>>> value.
> >>>>  > >> >> >
> >>>>  > >> >> > >-----Original Message-----
> >>>>  > >> >> > >From: Brian Rosen [mailto:[email-masked]]
> >>>>  > >> >> > >Sent: 05 February, 2009 00:03
> >>>>  > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
> >> 'Tschofenig,
> >>>>  > >> >> Hannes (NSN -
> >>>>  > >> >> > >FI/Espoo)'; 'ECRIT'
> >>>>  > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting:
> >>>> Agenda (my
> >>>>  > >> >> > mistake)
> >>>>  > >> >> > >
> >>>>  > >> >> > >Hannes
> >>>>  > >> >> > >
> >>>>  > >> >> > >This matches my understanding precisely.  We wish to
> >>>>  > >> >> permit endpoints
> >>>>  > >> >> > >to mark. We do not require it, and don't necessarily
> >>>> expect it
> >>>>  > >> >> > >in many (even
> >>>>  > >> >> > >most) cases.  We don't wish to see the
> >> document prohibit
> >>>> it.
> >>>>  > >> >> > >We all seem to agree it has value within the
> >> Emergency
> >>>>  > >> >Services IP
> >>>>  > >> >> > >Networks.
> >>>>  > >> >> > >
> >>>>  > >> >> > >Brian
> >>>>  > >> >> > >
> >>>>  > >> >> > >> -----Original Message-----
> >>>>  > >> >> > >> From: [email-masked]
> >>>> [mailto:[email-masked]]
> >>>>  > >> >> > >On Behalf
> >>>>  > >> >> > >> Of James M. Polk
> >>>>  > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> >>>>  > >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
> >>>>  > >> >> FI/Espoo); 'ECRIT'
> >>>>  > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >>>> Meeting:
> >>>>  > >Agenda (my
> >>>>  > >> >> > >> mistake)
> >>>>  > >> >> > >>
> >>>>  > >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> >>>>  > >> >> > >> > > James wrote:
> >>>>  > >> >> > >> > >> you are the _lone_ voice not
> >> supporting this ID,
> >>>>  > >> >> > >> >
> >>>>  > >> >> > >> >Listening to the audio recording of past
> >> meetings I
> >>>> have to
> >>>>  > >> >> > >say that
> >>>>  > >> >> > >> >I
> >>>>  > >> >> > >> was
> >>>>  > >> >> > >> >not the only persons raising concerns about the
> >>>> document.
> >>>>  > >> >> > >> >That was probably the reason why you
> >> agreed to limit
> >>>> the
> >>>>  > >> >> > >scope of the
> >>>>  > >> >> > >> >document (which you didn't later do) to
> >> get folks to
> >>>> agree
> >>>>  > >> >> > >to make it
> >>>>  > >> >> > >> a WG
> >>>>  > >> >> > >> >item.
> >>>>  > >> >> > >>
> >>>>  > >> >> > >> re-listen to the audio please
> >>>>  > >> >> > >>
> >>>>  > >> >> > >> Ted's concerns were consistent with most
> >>>> (all?) other
> >>>>  > >> >> concerns --
> >>>>  > >> >> > >> which were based on the premise of whether
> >> or not the
> >>>>  > >> >> UAC should be
> >>>>  > >> >> > >> trusted to initiate the marking on the
> >> INVITE.  The
> >>>> most
> >>>>  > >> >> > >> recent version has backed off this to a "can" --
> >>>> meaning not
> >>>>  > >> >prohibited
> >>>>  > >> >> > >> (i.e., no 2119 text).  I also backed off
> >> the text in
> >>>> the
> >>>>  > >> >> SP domain
> >>>>  > >> >> > >> part to "can", such that there is no 2119 text
> >>>>  > >> >mandating or even
> >>>>  > >> >> > >> recommending its usage there. I also do
> >> not prohibit
> >>>> its
> >>>>  > >> >> > >use, based on
> >>>>  > >> >> > >> local policy.  Keith has come forward with
> >> the specific
> >>>>
> >>>>  > >> >> > >> request that non-ESInet networks be
> >> allowed to mark and
> >>>> pay
> >>>>  > >> >attention to
> >>>>  > >> >> > >> this priority indication -- with IMS as
> >> the specific
> >>>> example
> >>>>  > >> >> > >> he wishes to have this valid for.
> >>>>  > >> >> > >>
> >>>>  > >> >> > >> Where there is no disagreement, save for
> >> your recent
> >>>>  > >> >> > >pushback - is in
> >>>>  > >> >> > >> the ESInet, which is where Brian has requested it's
> >>>>  > >> >> > >definition in the
> >>>>  > >> >> > >> IETF on behalf of NENA.  He's the i3 WG
> >> chair within
> >>>>  > >> >> NENA, and if
> >>>>  > >> >> > >> he asks for it, are you going to say you
> >> know better
> >>>> than he?
> >>>>  > >> >> > >>
> >>>>  > >> >> > >>
> >>>>  > >> >> > >> >Btw, I not disagreeing with the document
> >> as such. I
> >>>>  > >> >just want to
> >>>>  > >> >> > the
> >>>>  > >> >> > >> scope
> >>>>  > >> >> > >> >to change. The usage of RPH within the emergency
> >>>>  > >> >> services network
> >>>>  > >> >> > is
> >>>>  > >> >> > >> fine
> >>>>  > >> >> > >> >for me. I may get convinced to start the
> >> RPH marking
> >>>> from
> >>>>  > >> >> > >the the VSP
> >>>>  > >> >> > >> >towards the PSAP. I feel uneasy about the
> >> end host
> >>>> doing
> >>>>  > >> >> > >the marking.
> >>>>  > >> >> > >>
> >>>>  > >> >> > >> please read what I wrote above, and then
> >> re-read the
> >>>>  > >> >most recent
> >>>>  > >> >> > >> version of the ID. I don't have endpoints
> >> that SHOULD
> >>>> or
> >>>>  > >> >> MUST mark
> >>>>  > >> >> > >> anything wrt RPH.  I also don't want to
> >> prohibit it,
> >>>>  > >> >> because there
> >>>>  > >> >> > >> might be cases (that I don't know of) of valid uses
> >>>>  > >> >> under certain
> >>>>  > >> >> > >> circumstances.  Figure 1 is very clear
> >> that there are 3
> >>>>  > >> >> networking
> >>>>  > >> >> > >> parts to consider
> >>>>  > >> >> > >>
> >>>>  > >> >> > >> #1 - from the endpoint
> >>>>  > >> >> > >> #2 - within the VSP
> >>>>  > >> >> > >> #3 - within the ESInet
> >>>>  > >> >> > >>
> >>>>  > >> >> > >> the most recent ID version has "can" for
> >> #s 1 and 2,
> >>>> and
> >>>>  > >> >> > >2119 language
> >>>>  > >> >> > >> offering those supporting this
> >> specification will have
> >>>> RPH
> >>>>  > >> >> > >> adherence within #3 (the ESInet).
> >>>>  > >> >> > >>
> >>>>  > >> >> > >> What other scope changes do you want,
> >> because I haven't
> >>>>  > >> >> heard them.
> >>>>  > >> >> > >>
> >>>>  > >> >> > >> I only heard you claim in email during the
> >> last IETF
> >>>> and in
> >>>>  > >> >> > >the ECRIT
> >>>>  > >> >> > >> session that RPH should not be used for priority
> >>>> marking
> >>>>  > >> >> requests.
> >>>>  > >> >> > >> This is something Keith (SIP WG chair) voiced his
> >>>> opposition
> >>>>  > >> >> > >> to your views regarding creating a second
> >> means for SIP
> >>>> to
> >>>>  > >> >priority
> >>>>  > >> >> > >> mark request "when SIP already has one
> >> interoperable
> >>>> way to
> >>>>  > >> >> > >> accomplish this... it's call the RP header
> >> mechanism".
> >>>>  > >> >> > >>
> >>>>  > >> >> > >> >I don't see advantages -- only disadvantages.
> >>>>  > >> >> > >> >
> >>>>  > >> >> > >> >Ciao
> >>>>  > >> >> > >> >Hannes
> >>>>  > >> >> > >>
> >>>>  > >> >> > >> _______________________________________________
> >>>>  > >> >> > >> Ecrit mailing list
> >>>>  > >> >> > >> [email-masked]
> >>>>  > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>  > >> >> > >
> >>>>  > >> >>
> >>>>  > >> >> _______________________________________________
> >>>>  > >> >> Ecrit mailing list
> >>>>  > >> >> [email-masked]
> >>>>  > >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>  > >> >>
> >>>>  > >> >
> >>>>  > >
> >>>>  >
> >>>>  > _______________________________________________
> >>>>  > Ecrit mailing list
> >>>>  > [email-masked]
> >>>>  > https://www.ietf.org/mailman/listinfo/ecrit
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Ecrit mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>
> >>>
> >>> _______________________________________________
> >>> Ecrit mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ecrit
> >
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'Brian Rosen'" <[email-masked]>, "'Henning Schulzrinne'" <[email-masked]>
Date: Fri, 6 Feb 2009 20:33:25 +0200
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] RPH

To the story short here is the code for the proxy: 

---------------------

IF emergency call was recognized THEN
    execute emergency call specific procedures (priority queuing,
preemption, fetch location, determine routing, do funny QoS things & co)
ELSE
    normal call handling procedures. 

---------------------

If you can make this differentiation between an emergency call and a regular
call then you can also do everything that is necessary for emergency call
handling. 

Brian + Keith: Please tell me that we cannot do the above with our currently
specified mechanisms. 

Ciao
Hannes

>-----Original Message-----
>From: Brian Rosen [mailto:[email-masked]] 
>Sent: 06 February, 2009 17:49
>To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
>Subject: RE: [Ecrit] RPH
>
>I agree that not all networks will permit (or pay attention 
>to) a priority request from an end device.
>
>No one has asked for that.
>
>The namespace request has several uses, one of which is within 
>an emergency services IP network, one of which is between 
>elements within a public network controlled by the operator, 
>and one of which is an endpoint request for resource priority.
>
>Those of us requesting this work proceed are happy if the 
>endpoint part is simply left as possible (MAY), and, speaking 
>for myself, having the draft discuss the security implications 
>of endpoint marking is reasonable.
>
>Having discussed this issue with an implementation team who 
>worked on MLPP systems, I am confident I know what I'm talking 
>about, but YMMV.  The fact that you could, if you wanted to, 
>give resource priority to a call you decided, however you 
>decided, was an emergency call is an implementation decision, 
>and not subject to standardization.  
>
>RPH is the IETF standard way for one entity to request 
>resource priority of another entity in a SIP system.  We're 
>asking for a namespace to use that within the domain of 
>emergency calls.  That is, I think, a VERY reasonable request.
>
>Brian
>
>> -----Original Message-----
>> From: Henning Schulzrinne [mailto:[email-masked]]
>> Sent: Friday, February 06, 2009 10:33 AM
>> To: Hannes Tschofenig
>> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>> Subject: Re: [Ecrit] RPH
>> 
>> To chime in here:
>> 
>> I don't think it's productive to simply state that 4412 
>doesn't worry 
>> about authorization, so we shouldn't either (simplifying a bit).
>> Authorization was discussed repeatedly, and the general 
>assumption was 
>> that there were two conditions: Either the user invoking resource- 
>> priority was well known and had a set of permissions that could be 
>> checked in real time or there are ways to deal with abuse after the 
>> fact in ways that deter abuse (the court-martial kind of thing in a 
>> military context).
>> 
>> The RFC 4412 security consideration (11.2) call this out in pretty 
>> strong language:
>> 
>>   Prioritized access to network and end-system resources imposes
>>     particularly stringent requirements on authentication and
>>     authorization mechanisms, since access to prioritized 
>resources may
>>     impact overall system stability and performance and not 
>just result
>>     in theft of, say, a single phone call.
>> Thus, the question is whether we have such strong authentication in 
>> emergency calling. In some cases, such as residential fixed line 
>> deployments where ISP = VSP, we're probably pretty close, in others, 
>> such as prepaid cell phones or hot spots or VSP-only providers, we 
>> aren't.
>> 
>> The other point that I think Hannes is making is that the 
>information 
>> is either redundant or dangerous. If a processing element recognizes 
>> the call as being an emergency call, it can apply whatever treatment 
>> it deems appropriate and doesn't need additional information. If it 
>> doesn't or can't, using just the RPH can be rather dangerous unless 
>> that element can be reasonably certain that there is strong 
>> authentication and recourse.
>> 
>> I don't buy the argument that somehow finding the RPH is faster than 
>> just looking for the identifier. Thus, given that the information is 
>> either redundant or dangerous, I fail to see the advantage.
>> 
>> Henning
>> 
>> 
>> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
>> 
>> > Don't get hung up on the details. There are ways to optimize it.
>> > That was
>> > not the point of the code example.
>> >
>> > The problem that my pseudo code should have shown you is that you
>> > * don't gain anything with RPH marking for the emergency call case 
>> > from the SIP UA towards the outbound proxy since the functionality 
>> > is already provide otherwise. How often does the proxy need to get 
>> > told that this is an emergency call todo whatever emergency call 
>> > handling procedures are necessary?
>> > * you only introduce fraud problems (if you are not 
>careful and you 
>> > understand the security stuff well enough)
>> >
>> > If you can point me to people who implement the RPH emergency call 
>> > case please do so. I would love to talk to them.
>> >
>> > Ciao
>> > Hannes
>> >
>> > PS: You need to parse incoming messages to some extend so that you 
>> > know what it contains :-) Only looking for the emergency 
>RPH header 
>> > (and not for the Service URN/dial
>> > string) would exactly be the DoS/fraud attack I am worried about.
>> > That's the thing Henning was worried about (go and listen to the 
>> > past meeting minutes).
>> >
>> >
>> >> Hannes
>> >>
>> >> You need to talk to people who really implement this kind 
>of thing.  
>> >> You are way off.
>> >>
>> >> When you implement a resource priority system, the point of doing 
>> >> that is to look though the queue of work and pick out the 
>ones with 
>> >> priority, handling them first.  You don't do all the parsing, you 
>> >> don't do a lot of decision tree.
>> >>
>> >> Typically:
>> >> Check for DoS things, like too big messages, etc Do a quick scan 
>> >> for the RPH message header If found:
>> >> Parse the message
>> >> Determine validity
>> >> Determine priority
>> >> Queue on the correct work queue
>> >>
>> >> The first two actions have to be very fast.  Anyone who builds a 
>> >> SIP thingie will tell you that parsing is one of the big cycle 
>> >> consumers: if you have to parse every message BEFORE you 
>determine 
>> >> priority, you can't give much resource priority.
>> >> Once you get the whole message parsed, you might as well finish 
>> >> working on it, because you've done so much of the work.
>> >> OTHOH, finding the end-of-message delimiter and doing a quick 
>> >> string search for RPH is fast.  If you are doing 
>priority, you need 
>> >> to keep all the priority processing pretty uniform, and pretty 
>> >> simple, or you tend to spend too much time futzing around 
>figuring 
>> >> out what to do.  You put all the priority related stuff together, 
>> >> and use as much common code as possible.
>> >>
>> >> Brian
>> >>
>> >>> -----Original Message-----
>> >>> From: [email-masked] [mailto:[email-masked]]
>> >> On Behalf
>> >>> Of Hannes Tschofenig
>> >>> Sent: Friday, February 06, 2009 8:41 AM
>> >>> To: 'Hannes Tschofenig'; 'Janet P Gunn'
>> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- 
>> >>> [email-masked]
>> >>> Subject: [Ecrit] RPH
>> >>>
>> >>> Over lunch I was also thinking how an outbound proxy would
>> implement
>> >>> some of the emergency procedures. Here are some thoughts:
>> >>>
>> >>> ---------------------------------------------------
>> >>>
>> >>> // Process incoming message
>> >>> Parse(msg);
>> >>>
>> >>> // SIP INVITE without Service URN
>> >>> // legacy devices
>> >>> If (recognize-dialstring(msg)==TRUE) {  // we got an emergency 
>> >>> call going on  emergency=TRUE;  if (dialstring(msg) == 911) 
>> >>> serviceURN=urn:service:sos; } else if
>> >>> (recognize-serviceURN(msg)==TRUE) {  // oh. A updated 
>device that 
>> >>> has a service URN attached to the
>> call
>> >>>  serviceURN=retrieve_ServiceURN(msg);
>> >>>  emergency=TRUE;
>> >>> } else {
>> >>>  // standard SIP message
>> >>>  // regular processing
>> >>>  process(msg);
>> >>>  emergency=FALSE;
>> >>> }
>> >>>
>> >>> If (emergency == TRUE) {
>> >>>   // make sure that the emergency call does not get 
>dropped on the 
>> >>> floor
>> >>>   // skip authorization failures
>> >>>   // give the call a special treatment
>> >>>   lots-of-code-here();
>> >>>
>> >>>   // trigger all the QoS signaling you have in the 
>network to make 
>> >>> James happy
>> >>>   trigger-qos();
>> >>>
>> >>>   // query location
>> >>>   location=retrieve-location();
>> >>>
>> >>>   // determine next hop
>> >>>   next-hop=lost(location, serviceURN)
>> >>>
>> >>>   // attach RPH marking to outgoing msg to make James and
>> >> Keith happy
>> >>>   msg=add(msg, RPH);
>> >>>
>> >>>   send(msg, next-hop);
>> >>> }
>> >>>
>> >>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
>> >>>   // all the emergency related processing done already upfront
>> >>>   // hence I log something.
>> >>>   log(RPH_WAS_PRESENT_JUHU);
>> >>> } else if ((rph-present(msg) == TRUE) && (emergency == 
>FALSE)) {  
>> >>> // this is not an emergency call  // this is something 
>like GETS  
>> >>> result=special-authorization-procedure(user);
>> >>>
>> >>>  if (result == AUTHORIZED) {
>> >>>    // do some priority & preemption thing here.
>> >>>    // trigger all the QoS you have
>> >>>    lots-of-code-here();
>> >>>  } else {
>> >>>    log("NOT AUTHORIZED; don't DoS my network");  } } else {  // 
>> >>> don't need todo any RPH processing  // this includes the case 
>> >>> where the call was an emergency call but the RPH
>> >>>
>> >>>  // marking was not there.
>> >>>  nothing();
>> >>> }
>> >>>
>> >>> ---------------------------------------------------
>> >>>
>> >>>
>> >>> Ciao
>> >>> Hannes
>> >>>
>> >>>> -----Original Message-----
>> >>>> From: [email-masked] [mailto:[email-masked]] On 
>> >>>> Behalf Of Hannes Tschofenig
>> >>>> Sent: 06 February, 2009 15:07
>> >>>> To: 'Janet P Gunn'
>> >>>> Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
>> >>> FI/Espoo)
>> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
>> >>>>
>> >>>> Who would define something that could prevent DoS problems?
>> >>>>
>> >>>> ________________________________
>> >>>>
>> >>>> 	From: Janet P Gunn [mailto:[email-masked]]
>> >>>> 	Sent: 06 February, 2009 14:11
>> >>>> 	To: Hannes Tschofenig
>> >>>> 	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; 
>> >>>> [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
>> 'James
>> >>>> M. Polk'
>> >>>> 	Subject: Re: [Ecrit] ECRIT Virtual Interim 
>Meeting: Agenda (RPH)
>> >>>>
>> >>>>
>> >>>>
>> >>>> 	But there is nothing IN RFC4412 that specifically
>> >> addresses how to
>> >>>> prevent any particular namespace being used for DoS.  Anyone/any
>> UA
>> >>>> can ATTEMPT to invoke priority treatment by attaching RPH.  For
>> all
>> >>>> of the 4412 namespaces, as with the new proposed namespace, the 
>> >>>> mechanisms for preventing DoS are not specified in the
>> >> document that
>> >>>> defines the namespace.
>> >>>> They are/will be specified elsewhere.
>> >>>>
>> >>>> 	Janet
>> >>>>
>> >>>> 	This is a PRIVATE message. If you are not the intended
>> >> recipient,
>> >>>> please delete without copying and kindly advise us by e-mail of
>> the
>> >>>> mistake in delivery.
>> >>>> 	NOTE: Regardless of content, this e-mail shall not
>> >> operate to bind
>> >>>> CSC to any order or other contract unless pursuant to explicit 
>> >>>> written agreement or government initiative expressly permitting
>> the
>> >>>> use of e-mail for such purpose.
>> >>>>
>> >>>> 	[email-masked] wrote on 02/06/2009 04:21:51 AM:
>> >>>>
>> >>>> 	> Hi James,
>> >>>> 	>
>> >>>> 	> I have read RFC 4412 and also the GETS/MLPP IETF
>> >> documents. What I
>> >>>> would
>> >>>> 	> like to point out is that there is more than just a
>> >> header and
>> >>>> values within
>> >>>> 	> the header that have to be considered in order to
>> >> make a judgement
>> >>>> of what
>> >>>> 	> is appropriate and what isn't. There is an
>> >> architectural question
>> >>>> and
>> >>>> 	> whether the environment we are using the stuff is
>> >> indeed providing
>> >>>> the
>> >>>> 	> properties you need for the solution to be 
>appropriate.
>> >>>> 	>
>> >>>> 	> Let me describe in more detail what I meant (and
>> >> please correct me
>> >>>> if I am
>> >>>> 	> wrong).
>> >>>> 	>
>> >>>> 	> Getting priority for SIP requests when using a GETS
>> >> alike scenario
>> >>>> means
>> >>>> 	> that the entity that issues the request is specially
>> >> authorized
>> >>>> since
>> >>>> 	> otherwise you introduce a nice denial of 
>service attack. This 
>> >>>> authorization
>> >>>> 	> is tied to the entity that makes the request. For
>> >> example, the
>> >>>> person is
>> >>>> 	> working for the government and has special rights.
>> >>>> James Bond as a (not so)
>> >>>> 	> secret agent might have these rights.
>> >>>> 	>
>> >>>> 	> The emergency services case 
>(citizen-to-authority) is a bit 
>> >>>> different as
>> >>>> 	> there aren't really special rights with respect to
>> >> authorization
>> >>>> tied to
>> >>>> 	> individuals. Instead, the fact that something is an
>> >> emergency is
>> >>>> purely a
>> >>>> 	> judgement of the human that dials a special number.
>> >>>> To deal with fraud, we
>> >>>> 	> discussed in the group on what we can actually do to
>> >> ensure that
>> >>>> end users
>> >>>> 	> do not bypass security procedures (such as
>> >> authorization checks,
>> >>>> charging
>> >>>> 	> and so on). Part of this investigation was 
>the publication of
>> >>>> 	> http://www.ietf.org/rfc/rfc5069.txt that also 
>describes this 
>> >>>> issue.
>> >>>> 	>
>> >>>> 	> So, imagine the implementation of a SIP proxy (and we
>> >> implemented
>> >>>> that
>> >>>> 	> stuff) that receives a call that contains a Service
>> >> URN. The code
>> >>>> branches
>> >>>> 	> into a special mode where everything is done 
>so that the call 
>> >>>> receives
>> >>>> 	> appropriate treatment and does not get dropped on the
>> >> floor. The
>> >>>> way how the
>> >>>> 	> Service URN is placed in the message ensures that the
>> >> call cannot
>> >>>> go to my
>> >>>> 	> friend (instead of the PSAP) unless the end host ran
>> >> LoST already.
>> >>>> In the
>> >>>> 	> latter case, we discussed this also on the list for a
>> >> while and
>> >>>> Richard even
>> >>>> 	> wrote a draft about it in the context of the 
>location hiding 
>> >>>> topic, we said
>> >>>> 	> that the proxy would have to run LoST if he 
>cares about a 
>> >>>> potential
>> >>>> 	> fraudulent usage.
>> >>>> 	>
>> >>>> 	> So, what do we need todo in order to provide 
>secure RFC 4412 
>> >>>> functionality
>> >>>> 	> in our context?
>> >>>> 	>
>> >>>> 	> Do you think that the current text in
>> >>>> 	>
>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>> >>>> gency-rph-nam
>> >>>> 	> espace-00.txt reflects any of the 
>above-described issues:
>> >>>> 	> "
>> >>>> 	>    The Security considerations that apply to RFC 4412
>> >>>> [RFC4412]
>> >>>> apply
>> >>>> 	>    here.  This document introduces no new security
>> >>>> issues relative
>> >>>> to
>> >>>> 	>    RFC 4412.
>> >>>> 	> "
>> >>>> 	>
>> >>>> 	> From various discussions in GEOPRIV I recall 
>that you are 
>> >>>> super-sensitive
>> >>>> 	> regarding security and privacy. For some reasons you
>> >> don't seem to
>> >>>> have the
>> >>>> 	> same concerns here. I would like to 
>understand your reasoning.
>> >>>> 	>
>> >>>> 	> Please also do me another favor: Don't always say
>> >> that I don't
>> >>>> understand
>> >>>> 	> the subject. Even if that would be the case it isn't
>> >> particular
>> >>>> fair given
>> >>>> 	> that different folks had to educate you on other
>> >> topics in the
>> >>>> past as well.
>> >>>> 	> Additionally, if you listen to the audio recordings
>> >> then you will
>> >>>> notice
>> >>>> 	> that Henning, Ted, and Jon do not seem to understand
>> >> the issue
>> >>>> either as
>> >>>> 	> they have raised similar issues during the 
>F2F meetings.
>> >>>> 	>
>> >>>> 	> Ciao
>> >>>> 	> Hannes
>> >>>> 	>
>> >>>> 	>
>> >>>> 	> >Hannes - I believe it is you who do not understand
>> >> RFC 4412 --
>> >>>> 	> >and many of us are trying to get that 
>through to you, but you
>> >>>> 	> >don't seem to want to listen/read.
>> >>>> 	> >
>> >>>> 	> >RFC 4412 is *for* priority marking SIP requests,
>> >>>> 	> >
>> >>>> 	> >One use is GETS.
>> >>>> 	> >
>> >>>> 	> >One use is MLPP.
>> >>>> 	> >
>> >>>> 	> >These examples are in RFC 4412 because there 
>were specific
>> >>>> 	> >namespaces being created for the IANA section of
>> >> that document.
>> >>>> 	> >
>> >>>> 	> >Reading the whole document, you will see 
>that RPH can be
>> >>>> 	> >specified for other uses than GETS or MLPP 
>specifically.
>> >>>> 	> >
>> >>>> 	> >I knew when I wrote RFC 4412 that one day we 
>would specify a
>> >>>> 	> >namespace for ECRIT (the "esnet" namespace 
>now) -- but I also
>> >>>> 	> >knew it was premature for RFC 4412 to 
>incorporate that
>> >>>> 	> >namespace, that a future doc to RFC 4412 
>would have to be
>> >>>> 	> >written to do this. Brian and I talked about 
>this at the
>> >>>> 	> >original NENA meeting that created the IP WGs there
>> >> (in August
>> >>>> 	> >of 03).  We both agreed we should wait until it was
>> >>>> 	> >appropriate to the work in the IETF to 
>submit this document
>> >>>> 	> >that is now
>> >>>> 	>
>> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>> >>>> 	> >gency-rph-namespace-00.txt
>> >>>> 	> >
>> >>>> 	> >Yet, you seem to want to use some additional 
>mechanism to
>> >>>> 	> >indicate priority of a call in SIP.  That 
>means you want to
>> >>>> 	> >introduce a second way to accomplish this in SIP.
>> >>>> Why do you
>> >>>> 	> >want to promote a separate way to do something SIP
>> >> has already
>> >>>> 	> >defined? That will cause interoperability issues and
>> >> we both know
>> >>>> that.
>> >>>> 	> >
>> >>>> 	> >You've said to me (and others) that you 
>believe RPH is just
>> >>>> 	> >another way to accomplish what sos or a URI can
>> >> indicate - and
>> >>>> 	> >you're wrong.  Your way would be 
>_the_second_way_to_do_it,
>> >>>> 	> >because SIP already considers RPH to be 
>*the*way* to priority
>> >>>> 	> >mark SIP requests.
>> >>>> 	> >
>> >>>> 	> >If you don't believe me (no comment), then 
>why do you not
>> >>>> 	> >believe the SIP WG chair (who knows more 
>about SIP than both
>> >>>> 	> >of us) - who, on this thread, has again said 
>to you "RFC 4412
>> >>>> 	> >(RPH) is the SIP mechanism to priority mark 
>SIP requests"?
>> >>>> 	> >
>> >>>> 	> >Further, I believe it is inappropriate to 
>prohibit endpoints
>> >>>> 	> >from being able to set the esnet namespace.  
>I absolutely
>> >>>> 	> >believe it will not be needed most of the 
>time, but I believe
>> >>>> 	> >if someone does find a valid use for 
>endpoints to mark
>> >>>> 	> >priority in SIP, this ID - once it has 
>become an RFC -- will
>> >>>> 	> >have to be obsoleted with a new RFC saying the exact
>> >> opposite.
>> >>>> 	> >
>> >>>> 	> >(color me confused ... over and over again)
>> >>>> 	> >
>> >>>> 	> >James
>> >>>> 	> >
>> >>>> 	> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>> >>>> 	> >>Keith, please understand that the usage of RFC 4412
>> >> for GETS and
>> >>>> for
>> >>>> 	> >>the type of emergency call we discuss here is
>> >> different. Just
>> >>>> looking
>> >>>> 	> >>at the header and the name of the namespace is a bit
>> >>>> 	> >artificial. I hope
>> >>>> 	> >>you understand that.
>> >>>> 	> >>
>> >>>> 	> >> >-----Original Message-----
>> >>>> 	> >> >From: DRAGE, Keith (Keith) 
>> >>>> [mailto:[email-masked]]
>> >>>> 	> >> >Sent: 05 February, 2009 14:55
>> >>>> 	> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
>> >>>> Polk'; 'Tschofenig,
>> >>>> 	> >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
>> >>>> 	> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
>> >>>> Meeting: Agenda (my
>> >>>>
>> >>>> 	> >> >mistake)
>> >>>> 	> >> >
>> >>>> 	> >> >Which is exactly what RFC 4412 specifies for all
>> >> namespaces.
>> >>>> 	> >> >
>> >>>> 	> >> >regards
>> >>>> 	> >> >
>> >>>> 	> >> >Keith
>> >>>> 	> >> >
>> >>>> 	> >> >> -----Original Message-----
>> >>>> 	> >> >> From: [email-masked]
>> >> [mailto:[email-masked]]
>> >>>> 	> >> >On Behalf
>> >>>> 	> >> >> Of Brian Rosen
>> >>>> 	> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
>> >>>> 	> >> >> To: 'Hannes Tschofenig'; 'James M. 
>Polk'; 'Tschofenig,
>> >>>> 	> >Hannes (NSN
>> >>>> 	> >> >> - FI/Espoo)'; 'ECRIT'
>> >>>> 	> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>> >>>> Meeting: Agenda (my
>> >>>> 	> >> >> mistake)
>> >>>> 	> >> >>
>> >>>> 	> >> >> The value is that in some networks 
>where priority for
>> >>>> 	> >> >emergency calls
>> >>>> 	> >> >> is appropriate, and appropriate 
>policing of marking is
>> >>>> 	> >implemented,
>> >>>> 	> >> >> emergency calls will receive resource priority.
>> >>>> 	> >> >>
>> >>>> 	> >> >> Not all networks would need policing.  Some
>> >> will.  Policing
>> >>>> could
>> >>>> 	> >> >> be to Route header/R-URI content, but other
>> >> criteria are
>> >>>> possible.
>> >>>> 	> >> >>
>> >>>> 	> >> >> Not all networks will need resource priority
>> >> for emergency
>> >>>> calls.
>> >>>> 	> >> >> Fine, ignore this marking/namespace.
>> >>>> 	> >> >>
>> >>>> 	> >> >> Brian
>> >>>> 	> >> >> > -----Original Message-----
>> >>>> 	> >> >> > From: Hannes Tschofenig 
>> >>>> [mailto:[email-masked]]
>> >>>> 	> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>> >>>> 	> >> >> > To: 'Brian Rosen'; 'James M. Polk';
>> >> Tschofenig, Hannes
>> >>>> (NSN -
>> >>>> 	> >> >> > FI/Espoo); 'ECRIT'
>> >>>> 	> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
>> >>>> Meeting: Agenda (my
>> >>>> 	> >> >> > mistake)
>> >>>> 	> >> >> >
>> >>>> 	> >> >> > I don't even see the value in permitting the
>> >> endpoint todo
>> >>>> the
>> >>>> 	> >> >> > RPH marking.
>> >>>> 	> >> >> > In addition to the security concerns 
>there is also the
>> >>>> 	> >> >problem that
>> >>>> 	> >> >> > there are more options to implement without
>> >> an additional
>> >>>> value.
>> >>>> 	> >> >> >
>> >>>> 	> >> >> > >-----Original Message-----
>> >>>> 	> >> >> > >From: Brian Rosen [mailto:[email-masked]]
>> >>>> 	> >> >> > >Sent: 05 February, 2009 00:03
>> >>>> 	> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
>> >> 'Tschofenig,
>> >>>> 	> >> >> Hannes (NSN -
>> >>>> 	> >> >> > >FI/Espoo)'; 'ECRIT'
>> >>>> 	> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual 
>Interim Meeting:
>> >>>> Agenda (my
>> >>>> 	> >> >> > mistake)
>> >>>> 	> >> >> > >
>> >>>> 	> >> >> > >Hannes
>> >>>> 	> >> >> > >
>> >>>> 	> >> >> > >This matches my understanding 
>precisely.  We wish to
>> >>>> 	> >> >> permit endpoints
>> >>>> 	> >> >> > >to mark. We do not require it, and 
>don't necessarily 
>> >>>> expect it
>> >>>> 	> >> >> > >in many (even
>> >>>> 	> >> >> > >most) cases.  We don't wish to see the
>> >> document prohibit
>> >>>> it.
>> >>>> 	> >> >> > >We all seem to agree it has value within the
>> >> Emergency
>> >>>> 	> >> >Services IP
>> >>>> 	> >> >> > >Networks.
>> >>>> 	> >> >> > >
>> >>>> 	> >> >> > >Brian
>> >>>> 	> >> >> > >
>> >>>> 	> >> >> > >> -----Original Message-----
>> >>>> 	> >> >> > >> From: [email-masked] 
>> >>>> [mailto:[email-masked]]
>> >>>> 	> >> >> > >On Behalf
>> >>>> 	> >> >> > >> Of James M. Polk
>> >>>> 	> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
>> >>>> 	> >> >> > >> To: Hannes Tschofenig; Tschofenig, 
>Hannes (NSN -
>> >>>> 	> >> >> FI/Espoo); 'ECRIT'
>> >>>> 	> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>> >>>> Meeting:
>> >>>> 	> >Agenda (my
>> >>>> 	> >> >> > >> mistake)
>> >>>> 	> >> >> > >>
>> >>>> 	> >> >> > >> At 02:37 PM 2/4/2009, Hannes 
>Tschofenig wrote:
>> >>>> 	> >> >> > >> > > James wrote:
>> >>>> 	> >> >> > >> > >> you are the _lone_ voice not
>> >> supporting this ID,
>> >>>> 	> >> >> > >> >
>> >>>> 	> >> >> > >> >Listening to the audio recording of past
>> >> meetings I
>> >>>> have to
>> >>>> 	> >> >> > >say that
>> >>>> 	> >> >> > >> >I
>> >>>> 	> >> >> > >> was
>> >>>> 	> >> >> > >> >not the only persons raising 
>concerns about the 
>> >>>> document.
>> >>>> 	> >> >> > >> >That was probably the reason why you
>> >> agreed to limit
>> >>>> the
>> >>>> 	> >> >> > >scope of the
>> >>>> 	> >> >> > >> >document (which you didn't later do) to
>> >> get folks to
>> >>>> agree
>> >>>> 	> >> >> > >to make it
>> >>>> 	> >> >> > >> a WG
>> >>>> 	> >> >> > >> >item.
>> >>>> 	> >> >> > >>
>> >>>> 	> >> >> > >> re-listen to the audio please
>> >>>> 	> >> >> > >>
>> >>>> 	> >> >> > >> Ted's concerns were consistent with most
>> >>>> (all?) other
>> >>>> 	> >> >> concerns --
>> >>>> 	> >> >> > >> which were based on the premise of whether
>> >> or not the
>> >>>> 	> >> >> UAC should be
>> >>>> 	> >> >> > >> trusted to initiate the marking on the
>> >> INVITE.  The
>> >>>> most
>> >>>> 	> >> >> > >> recent version has backed off this 
>to a "can" -- 
>> >>>> meaning not
>> >>>> 	> >> >prohibited
>> >>>> 	> >> >> > >> (i.e., no 2119 text).  I also backed off
>> >> the text in
>> >>>> the
>> >>>> 	> >> >> SP domain
>> >>>> 	> >> >> > >> part to "can", such that there is 
>no 2119 text
>> >>>> 	> >> >mandating or even
>> >>>> 	> >> >> > >> recommending its usage there. I also do
>> >> not prohibit
>> >>>> its
>> >>>> 	> >> >> > >use, based on
>> >>>> 	> >> >> > >> local policy.  Keith has come forward with
>> >> the specific
>> >>>>
>> >>>> 	> >> >> > >> request that non-ESInet networks be
>> >> allowed to mark and
>> >>>> pay
>> >>>> 	> >> >attention to
>> >>>> 	> >> >> > >> this priority indication -- with IMS as
>> >> the specific
>> >>>> example
>> >>>> 	> >> >> > >> he wishes to have this valid for.
>> >>>> 	> >> >> > >>
>> >>>> 	> >> >> > >> Where there is no disagreement, save for
>> >> your recent
>> >>>> 	> >> >> > >pushback - is in
>> >>>> 	> >> >> > >> the ESInet, which is where Brian 
>has requested it's
>> >>>> 	> >> >> > >definition in the
>> >>>> 	> >> >> > >> IETF on behalf of NENA.  He's the i3 WG
>> >> chair within
>> >>>> 	> >> >> NENA, and if
>> >>>> 	> >> >> > >> he asks for it, are you going to say you
>> >> know better
>> >>>> than he?
>> >>>> 	> >> >> > >>
>> >>>> 	> >> >> > >>
>> >>>> 	> >> >> > >> >Btw, I not disagreeing with the document
>> >> as such. I
>> >>>> 	> >> >just want to
>> >>>> 	> >> >> > the
>> >>>> 	> >> >> > >> scope
>> >>>> 	> >> >> > >> >to change. The usage of RPH 
>within the emergency
>> >>>> 	> >> >> services network
>> >>>> 	> >> >> > is
>> >>>> 	> >> >> > >> fine
>> >>>> 	> >> >> > >> >for me. I may get convinced to start the
>> >> RPH marking
>> >>>> from
>> >>>> 	> >> >> > >the the VSP
>> >>>> 	> >> >> > >> >towards the PSAP. I feel uneasy about the
>> >> end host
>> >>>> doing
>> >>>> 	> >> >> > >the marking.
>> >>>> 	> >> >> > >>
>> >>>> 	> >> >> > >> please read what I wrote above, and then
>> >> re-read the
>> >>>> 	> >> >most recent
>> >>>> 	> >> >> > >> version of the ID. I don't have endpoints
>> >> that SHOULD
>> >>>> or
>> >>>> 	> >> >> MUST mark
>> >>>> 	> >> >> > >> anything wrt RPH.  I also don't want to
>> >> prohibit it,
>> >>>> 	> >> >> because there
>> >>>> 	> >> >> > >> might be cases (that I don't know 
>of) of valid uses
>> >>>> 	> >> >> under certain
>> >>>> 	> >> >> > >> circumstances.  Figure 1 is very clear
>> >> that there are 3
>> >>>> 	> >> >> networking
>> >>>> 	> >> >> > >> parts to consider
>> >>>> 	> >> >> > >>
>> >>>> 	> >> >> > >> #1 - from the endpoint
>> >>>> 	> >> >> > >> #2 - within the VSP
>> >>>> 	> >> >> > >> #3 - within the ESInet
>> >>>> 	> >> >> > >>
>> >>>> 	> >> >> > >> the most recent ID version has "can" for
>> >> #s 1 and 2,
>> >>>> and
>> >>>> 	> >> >> > >2119 language
>> >>>> 	> >> >> > >> offering those supporting this
>> >> specification will have
>> >>>> RPH
>> >>>> 	> >> >> > >> adherence within #3 (the ESInet).
>> >>>> 	> >> >> > >>
>> >>>> 	> >> >> > >> What other scope changes do you want,
>> >> because I haven't
>> >>>> 	> >> >> heard them.
>> >>>> 	> >> >> > >>
>> >>>> 	> >> >> > >> I only heard you claim in email during the
>> >> last IETF
>> >>>> and in
>> >>>> 	> >> >> > >the ECRIT
>> >>>> 	> >> >> > >> session that RPH should not be 
>used for priority 
>> >>>> marking
>> >>>> 	> >> >> requests.
>> >>>> 	> >> >> > >> This is something Keith (SIP WG 
>chair) voiced his 
>> >>>> opposition
>> >>>> 	> >> >> > >> to your views regarding creating a second
>> >> means for SIP
>> >>>> to
>> >>>> 	> >> >priority
>> >>>> 	> >> >> > >> mark request "when SIP already has one
>> >> interoperable
>> >>>> way to
>> >>>> 	> >> >> > >> accomplish this... it's call the RP header
>> >> mechanism".
>> >>>> 	> >> >> > >>
>> >>>> 	> >> >> > >> >I don't see advantages -- only 
>disadvantages.
>> >>>> 	> >> >> > >> >
>> >>>> 	> >> >> > >> >Ciao
>> >>>> 	> >> >> > >> >Hannes
>> >>>> 	> >> >> > >>
>> >>>> 	> >> >> > >> 
>_______________________________________________
>> >>>> 	> >> >> > >> Ecrit mailing list
>> >>>> 	> >> >> > >> [email-masked]
>> >>>> 	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>> >>>> 	> >> >> > >
>> >>>> 	> >> >>
>> >>>> 	> >> >> _______________________________________________
>> >>>> 	> >> >> Ecrit mailing list
>> >>>> 	> >> >> [email-masked]
>> >>>> 	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >>>> 	> >> >>
>> >>>> 	> >> >
>> >>>> 	> >
>> >>>> 	>
>> >>>> 	> _______________________________________________
>> >>>> 	> Ecrit mailing list
>> >>>> 	> [email-masked]
>> >>>> 	> https://www.ietf.org/mailman/listinfo/ecrit
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Ecrit mailing list
>> >>>> [email-masked]
>> >>>> https://www.ietf.org/mailman/listinfo/ecrit
>> >>>>
>> >>>
>> >>> _______________________________________________
>> >>> Ecrit mailing list
>> >>> [email-masked]
>> >>> https://www.ietf.org/mailman/listinfo/ecrit
>> >>
>> >
>> > _______________________________________________
>> > Ecrit mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/ecrit
>> >
>

Content-class: urn:content-classes:message
Date: Fri, 6 Feb 2009 14:01:37 -0600
From: "Winterbottom, James" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>, "Brian Rosen" <[email-masked]>, "Henning Schulzrinne" <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

Hi All,=0D=0A=0D=0AI have followed thi thread with some interest and I stru=
ggling to see a use case for the=0D=0Aproviding RPH for emergency calls fro=
m the end-point.=0D=0A=0D=0AThe reference-model call in ECRIT, for better o=
r worse, is for all calls to go back through a home-VSP.=0D=0AWe placed qui=
te a lot of emphasis, largely for traffing reasons, for the VSP to be able =
to verify that=20=0D=0Aa call is in fact an emergency call. This is done by=
 the proxy taking the inband location, doing a LoST=0D=0Aquery with the pro=
vided URN, and verifying that the resulting destination URI is the same as =
the destination=0D=0AURI provide in the SIP INVITE. My understanding was th=
at VSPs would always do this check so they could=0D=0Atell if they could bi=
ll for the call or not, and because the VSP can be use that the call is an =
emergency call=0D=0Ait can apply any special priorities that may be applica=
ble. This obviates the need for RPH from the end-point=0D=0Ato the network.=0D=
=0A=0D=0AThis leaves us with the argument of "it doesn't hurt to it", which=
 is not a good reason to write a specification.=0D=0AIt was intimated on th=
e geopriv mailing list last year that great pains had been taken to keep SI=
P with in the=0D=0AMTU limits of UDP over Ethernet (http://www.ietf.org/mai=
l-archive/web/geopriv/current/msg06120.html). Assuming=0D=0Athat this is th=
e case, perhaps there is harm in including information that we know will be=
 ignored.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A-----Original=
 Message-----=0D=0AFrom: [email-masked] on behalf of Hannes Tschofe=
nig=0D=0ASent: Fri 2/6/2009 12:33 PM=0D=0ATo: 'Brian Rosen'; 'Henning Schul=
zrinne'=0D=0ACc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'=0D=0ASubject:=
 Re: [Ecrit] RPH=0D=0A=20=0D=0ATo the story short here is the code for the =
proxy:=20=0D=0A=0D=0A---------------------=0D=0A=0D=0AIF emergency call was=
 recognized THEN=0D=0A    execute emergency call specific procedures (prior=
ity queuing,=0D=0Apreemption, fetch location, determine routing, do funny Q=
oS things & co)=0D=0AELSE=0D=0A    normal call handling procedures.=20=0D=0A=0D=
=0A---------------------=0D=0A=0D=0AIf you can make this differentiation be=
tween an emergency call and a regular=0D=0Acall then you can also do everyt=
hing that is necessary for emergency call=0D=0Ahandling.=20=0D=0A=0D=0ABria=
n + Keith: Please tell me that we cannot do the above with our currently=0D=
=0Aspecified mechanisms.=20=0D=0A=0D=0ACiao=0D=0AHannes=0D=0A=0D=0A>-----Or=
iginal Message-----=0D=0A>From: Brian Rosen [mailto:[email-masked]]=20=0D=
=0A>Sent: 06 February, 2009 17:49=0D=0A>To: 'Henning Schulzrinne'; 'Hannes =
Tschofenig'=0D=0A>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'=0D=0A>=
Subject: RE: [Ecrit] RPH=0D=0A>=0D=0A>I agree that not all networks will pe=
rmit (or pay attention=20=0D=0A>to) a priority request from an end device.=0D=
=0A>=0D=0A>No one has asked for that.=0D=0A>=0D=0A>The namespace request ha=
s several uses, one of which is within=20=0D=0A>an emergency services IP ne=
twork, one of which is between=20=0D=0A>elements within a public network co=
ntrolled by the operator,=20=0D=0A>and one of which is an endpoint request =
for resource priority.=0D=0A>=0D=0A>Those of us requesting this work procee=
d are happy if the=20=0D=0A>endpoint part is simply left as possible (MAY),=
 and, speaking=20=0D=0A>for myself, having the draft discuss the security i=
mplications=20=0D=0A>of endpoint marking is reasonable.=0D=0A>=0D=0A>Having=
 discussed this issue with an implementation team who=20=0D=0A>worked on ML=
PP systems, I am confident I know what I'm talking=20=0D=0A>about, but YMMV=
=2E  The fact that you could, if you wanted to,=20=0D=0A>give resource prio=
rity to a call you decided, however you=20=0D=0A>decided, was an emergency =
call is an implementation decision,=20=0D=0A>and not subject to standardiza=
tion. =20=0D=0A>=0D=0A>RPH is the IETF standard way for one entity to reque=
st=20=0D=0A>resource priority of another entity in a SIP system.  We're=20=0D=
=0A>asking for a namespace to use that within the domain of=20=0D=0A>emerge=
ncy calls.  That is, I think, a VERY reasonable request.=0D=0A>=0D=0A>Brian=0D=
=0A>=0D=0A>> -----Original Message-----=0D=0A>> From: Henning Schulzrinne [=
mailto:[email-masked]]=0D=0A>> Sent: Friday, February 06, 2009 10:33 A=
M=0D=0A>> To: Hannes Tschofenig=0D=0A>> Cc: Brian Rosen; Tschofenig, Hannes=
 (NSN - FI/Espoo); ECRIT=0D=0A>> Subject: Re: [Ecrit] RPH=0D=0A>>=20=0D=0A>=
> To chime in here:=0D=0A>>=20=0D=0A>> I don't think it's productive to sim=
ply state that 4412=20=0D=0A>doesn't worry=20=0D=0A>> about authorization, =
so we shouldn't either (simplifying a bit).=0D=0A>> Authorization was discu=
ssed repeatedly, and the general=20=0D=0A>assumption was=20=0D=0A>> that th=
ere were two conditions: Either the user invoking resource-=20=0D=0A>> prio=
rity was well known and had a set of permissions that could be=20=0D=0A>> c=
hecked in real time or there are ways to deal with abuse after the=20=0D=0A=
>> fact in ways that deter abuse (the court-martial kind of thing in a=20=0D=
=0A>> military context).=0D=0A>>=20=0D=0A>> The RFC 4412 security considera=
tion (11.2) call this out in pretty=20=0D=0A>> strong language:=0D=0A>>=20=0D=
=0A>>   Prioritized access to network and end-system resources imposes=0D=0A=
>>     particularly stringent requirements on authentication and=0D=0A>>   =
  authorization mechanisms, since access to prioritized=20=0D=0A>resources =
may=0D=0A>>     impact overall system stability and performance and not=20=0D=
=0A>just result=0D=0A>>     in theft of, say, a single phone call.=0D=0A>> =
Thus, the question is whether we have such strong authentication in=20=0D=0A=
>> emergency calling. In some cases, such as residential fixed line=20=0D=0A=
>> deployments where ISP =3D VSP, we're probably pretty close, in others, =0D=
=0A>> such as prepaid cell phones or hot spots or VSP-only providers, we =0D=
=0A>> aren't.=0D=0A>>=20=0D=0A>> The other point that I think Hannes is mak=
ing is that the=20=0D=0A>information=20=0D=0A>> is either redundant or dang=
erous. If a processing element recognizes=20=0D=0A>> the call as being an e=
mergency call, it can apply whatever treatment=20=0D=0A>> it deems appropri=
ate and doesn't need additional information. If it=20=0D=0A>> doesn't or ca=
n't, using just the RPH can be rather dangerous unless=20=0D=0A>> that elem=
ent can be reasonably certain that there is strong=20=0D=0A>> authenticatio=
n and recourse.=0D=0A>>=20=0D=0A>> I don't buy the argument that somehow fi=
nding the RPH is faster than=20=0D=0A>> just looking for the identifier. Th=
us, given that the information is=20=0D=0A>> either redundant or dangerous,=
 I fail to see the advantage.=0D=0A>>=20=0D=0A>> Henning=0D=0A>>=20=0D=0A>>=
=20=0D=0A>> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:=0D=0A>> =0D=
=0A>> > Don't get hung up on the details. There are ways to optimize it.=0D=
=0A>> > That was=0D=0A>> > not the point of the code example.=0D=0A>> >=0D=0A=
>> > The problem that my pseudo code should have shown you is that you=0D=0A=
>> > * don't gain anything with RPH marking for the emergency call case=20=0D=
=0A>> > from the SIP UA towards the outbound proxy since the functionality =0D=
=0A>> > is already provide otherwise. How often does the proxy need to get =0D=
=0A>> > told that this is an emergency call todo whatever emergency call =0D=
=0A>> > handling procedures are necessary=3F=0D=0A>> > * you only introduce=
 fraud problems (if you are not=20=0D=0A>careful and you=20=0D=0A>> > under=
stand the security stuff well enough)=0D=0A>> >=0D=0A>> > If you can point =
me to people who implement the RPH emergency call=20=0D=0A>> > case please =
do so. I would love to talk to them.=0D=0A>> >=0D=0A>> > Ciao=0D=0A>> > Han=
nes=0D=0A>> >=0D=0A>> > PS: You need to parse incoming messages to some ext=
end so that you=20=0D=0A>> > know what it contains :-) Only looking for the=
 emergency=20=0D=0A>RPH header=20=0D=0A>> > (and not for the Service URN/di=
al=0D=0A>> > string) would exactly be the DoS/fraud attack I am worried abo=
ut.=0D=0A>> > That's the thing Henning was worried about (go and listen to =
the=20=0D=0A>> > past meeting minutes).=0D=0A>> >=0D=0A>> >=0D=0A>> >> Hann=
es=0D=0A>> >>=0D=0A>> >> You need to talk to people who really implement th=
is kind=20=0D=0A>of thing. =20=0D=0A>> >> You are way off.=0D=0A>> >>=0D=0A=
>> >> When you implement a resource priority system, the point of doing=20=0D=
=0A>> >> that is to look though the queue of work and pick out the=20=0D=0A=
>ones with=20=0D=0A>> >> priority, handling them first.  You don't do all t=
he parsing, you=20=0D=0A>> >> don't do a lot of decision tree.=0D=0A>> >>=0D=
=0A>> >> Typically:=0D=0A>> >> Check for DoS things, like too big messages,=
 etc Do a quick scan=20=0D=0A>> >> for the RPH message header If found:=0D=0A=
>> >> Parse the message=0D=0A>> >> Determine validity=0D=0A>> >> Determine =
priority=0D=0A>> >> Queue on the correct work queue=0D=0A>> >>=0D=0A>> >> T=
he first two actions have to be very fast.  Anyone who builds a=20=0D=0A>> =
>> SIP thingie will tell you that parsing is one of the big cycle=20=0D=0A>=
> >> consumers: if you have to parse every message BEFORE you=20=0D=0A>dete=
rmine=20=0D=0A>> >> priority, you can't give much resource priority.=0D=0A>=
> >> Once you get the whole message parsed, you might as well finish=20=0D=0A=
>> >> working on it, because you've done so much of the work.=0D=0A>> >> OT=
HOH, finding the end-of-message delimiter and doing a quick=20=0D=0A>> >> s=
tring search for RPH is fast.  If you are doing=20=0D=0A>priority, you need=
=20=0D=0A>> >> to keep all the priority processing pretty uniform, and pret=
ty=20=0D=0A>> >> simple, or you tend to spend too much time futzing around =0D=
=0A>figuring=20=0D=0A>> >> out what to do.  You put all the priority relate=
d stuff together,=20=0D=0A>> >> and use as much common code as possible.=0D=
=0A>> >>=0D=0A>> >> Brian=0D=0A>> >>=0D=0A>> >>> -----Original Message-----=0D=
=0A>> >>> From: [email-masked] [mailto:[email-masked]]=0D=0A=
>> >> On Behalf=0D=0A>> >>> Of Hannes Tschofenig=0D=0A>> >>> Sent: Friday, =
February 06, 2009 8:41 AM=0D=0A>> >>> To: 'Hannes Tschofenig'; 'Janet P Gun=
n'=0D=0A>> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-=20=0D=
=0A>> >>> [email-masked]=0D=0A>> >>> Subject: [Ecrit] RPH=0D=0A>> >>>=0D=0A=
>> >>> Over lunch I was also thinking how an outbound proxy would=0D=0A>> i=
mplement=0D=0A>> >>> some of the emergency procedures. Here are some though=
ts:=0D=0A>> >>>=0D=0A>> >>> -----------------------------------------------=
----=0D=0A>> >>>=0D=0A>> >>> // Process incoming message=0D=0A>> >>> Parse(=
msg);=0D=0A>> >>>=0D=0A>> >>> // SIP INVITE without Service URN=0D=0A>> >>>=
 // legacy devices=0D=0A>> >>> If (recognize-dialstring(msg)=3D=3DTRUE) {  =
// we got an emergency=20=0D=0A>> >>> call going on  emergency=3DTRUE;  if =
(dialstring(msg) =3D=3D 911)=20=0D=0A>> >>> serviceURN=3Durn:service:sos; }=
 else if=0D=0A>> >>> (recognize-serviceURN(msg)=3D=3DTRUE) {  // oh. A upda=
ted=20=0D=0A>device that=20=0D=0A>> >>> has a service URN attached to the=0D=
=0A>> call=0D=0A>> >>>  serviceURN=3Dretrieve_ServiceURN(msg);=0D=0A>> >>> =
 emergency=3DTRUE;=0D=0A>> >>> } else {=0D=0A>> >>>  // standard SIP messag=
e=0D=0A>> >>>  // regular processing=0D=0A>> >>>  process(msg);=0D=0A>> >>>=
  emergency=3DFALSE;=0D=0A>> >>> }=0D=0A>> >>>=0D=0A>> >>> If (emergency =3D=
=3D TRUE) {=0D=0A>> >>>   // make sure that the emergency call does not get=
=20=0D=0A>dropped on the=20=0D=0A>> >>> floor=0D=0A>> >>>   // skip authori=
zation failures=0D=0A>> >>>   // give the call a special treatment=0D=0A>> =
>>>   lots-of-code-here();=0D=0A>> >>>=0D=0A>> >>>   // trigger all the QoS=
 signaling you have in the=20=0D=0A>network to make=20=0D=0A>> >>> James ha=
ppy=0D=0A>> >>>   trigger-qos();=0D=0A>> >>>=0D=0A>> >>>   // query locatio=
n=0D=0A>> >>>   location=3Dretrieve-location();=0D=0A>> >>>=0D=0A>> >>>   /=
/ determine next hop=0D=0A>> >>>   next-hop=3Dlost(location, serviceURN)=0D=
=0A>> >>>=0D=0A>> >>>   // attach RPH marking to outgoing msg to make James=
 and=0D=0A>> >> Keith happy=0D=0A>> >>>   msg=3Dadd(msg, RPH);=0D=0A>> >>>=0D=
=0A>> >>>   send(msg, next-hop);=0D=0A>> >>> }=0D=0A>> >>>=0D=0A>> >>> If (=
(rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D TRUE)) {=0D=0A>> >>>   =
// all the emergency related processing done already upfront=0D=0A>> >>>   =
// hence I log something.=0D=0A>> >>>   log(RPH_WAS_PRESENT_JUHU);=0D=0A>> =
>>> } else if ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D=20=0D=0A=
>FALSE)) { =20=0D=0A>> >>> // this is not an emergency call  // this is som=
ething=20=0D=0A>like GETS =20=0D=0A>> >>> result=3Dspecial-authorization-pr=
ocedure(user);=0D=0A>> >>>=0D=0A>> >>>  if (result =3D=3D AUTHORIZED) {=0D=0A=
>> >>>    // do some priority & preemption thing here.=0D=0A>> >>>    // tr=
igger all the QoS you have=0D=0A>> >>>    lots-of-code-here();=0D=0A>> >>> =
 } else {=0D=0A>> >>>    log("NOT AUTHORIZED; don't DoS my network");  } } =
else {  //=20=0D=0A>> >>> don't need todo any RPH processing  // this inclu=
des the case=20=0D=0A>> >>> where the call was an emergency call but the RP=
H=0D=0A>> >>>=0D=0A>> >>>  // marking was not there.=0D=0A>> >>>  nothing()=
;=0D=0A>> >>> }=0D=0A>> >>>=0D=0A>> >>> -----------------------------------=
----------------=0D=0A>> >>>=0D=0A>> >>>=0D=0A>> >>> Ciao=0D=0A>> >>> Hanne=
s=0D=0A>> >>>=0D=0A>> >>>> -----Original Message-----=0D=0A>> >>>> From: ec=
[email-masked] [mailto:[email-masked]] On=20=0D=0A>> >>>> Beh=
alf Of Hannes Tschofenig=0D=0A>> >>>> Sent: 06 February, 2009 15:07=0D=0A>>=
 >>>> To: 'Janet P Gunn'=0D=0A>> >>>> Cc: 'ECRIT'; [email-masked]; =
Tschofenig,Hannes (NSN -=0D=0A>> >>> FI/Espoo)=0D=0A>> >>>> Subject: Re: [E=
crit] ECRIT Virtual Interim Meeting: Agenda (RPH)=0D=0A>> >>>>=0D=0A>> >>>>=
 Who would define something that could prevent DoS problems=3F=0D=0A>> >>>>=0D=
=0A>> >>>> ________________________________=0D=0A>> >>>>=0D=0A>> >>>> =09Fr=
om: Janet P Gunn [mailto:[email-masked]]=0D=0A>> >>>> =09Sent: 06 February,=
 2009 14:11=0D=0A>> >>>> =09To: Hannes Tschofenig=0D=0A>> >>>> =09Cc: 'Bria=
n Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';=20=0D=0A>> >>>> ecrit-bounces@ie=
tf.org; Tschofenig, Hannes (NSN - FI/Espoo);=0D=0A>> 'James=0D=0A>> >>>> M.=
 Polk'=0D=0A>> >>>> =09Subject: Re: [Ecrit] ECRIT Virtual Interim=20=0D=0A>=
Meeting: Agenda (RPH)=0D=0A>> >>>>=0D=0A>> >>>>=0D=0A>> >>>>=0D=0A>> >>>> =09=
But there is nothing IN RFC4412 that specifically=0D=0A>> >> addresses how =
to=0D=0A>> >>>> prevent any particular namespace being used for DoS.  Anyon=
e/any=0D=0A>> UA=0D=0A>> >>>> can ATTEMPT to invoke priority treatment by a=
ttaching RPH.  For=0D=0A>> all=0D=0A>> >>>> of the 4412 namespaces, as with=
 the new proposed namespace, the=20=0D=0A>> >>>> mechanisms for preventing =
DoS are not specified in the=0D=0A>> >> document that=0D=0A>> >>>> defines =
the namespace.=0D=0A>> >>>> They are/will be specified elsewhere.=0D=0A>> >=
>>>=0D=0A>> >>>> =09Janet=0D=0A>> >>>>=0D=0A>> >>>> =09This is a PRIVATE me=
ssage. If you are not the intended=0D=0A>> >> recipient,=0D=0A>> >>>> pleas=
e delete without copying and kindly advise us by e-mail of=0D=0A>> the=0D=0A=
>> >>>> mistake in delivery.=0D=0A>> >>>> =09NOTE: Regardless of content, t=
his e-mail shall not=0D=0A>> >> operate to bind=0D=0A>> >>>> CSC to any ord=
er or other contract unless pursuant to explicit=20=0D=0A>> >>>> written ag=
reement or government initiative expressly permitting=0D=0A>> the=0D=0A>> >=
>>> use of e-mail for such purpose.=0D=0A>> >>>>=0D=0A>> >>>> =09ecrit-boun=
[email-masked] wrote on 02/06/2009 04:21:51 AM:=0D=0A>> >>>>=0D=0A>> >>>> =09=
> Hi James,=0D=0A>> >>>> =09>=0D=0A>> >>>> =09> I have read RFC 4412 and al=
so the GETS/MLPP IETF=0D=0A>> >> documents. What I=0D=0A>> >>>> would=0D=0A=
>> >>>> =09> like to point out is that there is more than just a=0D=0A>> >>=
 header and=0D=0A>> >>>> values within=0D=0A>> >>>> =09> the header that ha=
ve to be considered in order to=0D=0A>> >> make a judgement=0D=0A>> >>>> of=
 what=0D=0A>> >>>> =09> is appropriate and what isn't. There is an=0D=0A>> =
>> architectural question=0D=0A>> >>>> and=0D=0A>> >>>> =09> whether the en=
vironment we are using the stuff is=0D=0A>> >> indeed providing=0D=0A>> >>>=
> the=0D=0A>> >>>> =09> properties you need for the solution to be=20=0D=0A=
>appropriate.=0D=0A>> >>>> =09>=0D=0A>> >>>> =09> Let me describe in more d=
etail what I meant (and=0D=0A>> >> please correct me=0D=0A>> >>>> if I am=0D=
=0A>> >>>> =09> wrong).=0D=0A>> >>>> =09>=0D=0A>> >>>> =09> Getting priorit=
y for SIP requests when using a GETS=0D=0A>> >> alike scenario=0D=0A>> >>>>=
 means=0D=0A>> >>>> =09> that the entity that issues the request is special=
ly=0D=0A>> >> authorized=0D=0A>> >>>> since=0D=0A>> >>>> =09> otherwise you=
 introduce a nice denial of=20=0D=0A>service attack. This=20=0D=0A>> >>>> a=
uthorization=0D=0A>> >>>> =09> is tied to the entity that makes the request=
=2E For=0D=0A>> >> example, the=0D=0A>> >>>> person is=0D=0A>> >>>> =09> wo=
rking for the government and has special rights.=0D=0A>> >>>> James Bond as=
 a (not so)=0D=0A>> >>>> =09> secret agent might have these rights.=0D=0A>>=
 >>>> =09>=0D=0A>> >>>> =09> The emergency services case=20=0D=0A>(citizen-=
to-authority) is a bit=20=0D=0A>> >>>> different as=0D=0A>> >>>> =09> there=
 aren't really special rights with respect to=0D=0A>> >> authorization=0D=0A=
>> >>>> tied to=0D=0A>> >>>> =09> individuals. Instead, the fact that somet=
hing is an=0D=0A>> >> emergency is=0D=0A>> >>>> purely a=0D=0A>> >>>> =09> =
judgement of the human that dials a special number.=0D=0A>> >>>> To deal wi=
th fraud, we=0D=0A>> >>>> =09> discussed in the group on what we can actual=
ly do to=0D=0A>> >> ensure that=0D=0A>> >>>> end users=0D=0A>> >>>> =09> do=
 not bypass security procedures (such as=0D=0A>> >> authorization checks,=0D=
=0A>> >>>> charging=0D=0A>> >>>> =09> and so on). Part of this investigatio=
n was=20=0D=0A>the publication of=0D=0A>> >>>> =09> http://www.ietf.org/rfc=
/rfc5069.txt that also=20=0D=0A>describes this=20=0D=0A>> >>>> issue.=0D=0A=
>> >>>> =09>=0D=0A>> >>>> =09> So, imagine the implementation of a SIP prox=
y (and we=0D=0A>> >> implemented=0D=0A>> >>>> that=0D=0A>> >>>> =09> stuff)=
 that receives a call that contains a Service=0D=0A>> >> URN. The code=0D=0A=
>> >>>> branches=0D=0A>> >>>> =09> into a special mode where everything is =
done=20=0D=0A>so that the call=20=0D=0A>> >>>> receives=0D=0A>> >>>> =09> a=
ppropriate treatment and does not get dropped on the=0D=0A>> >> floor. The=0D=
=0A>> >>>> way how the=0D=0A>> >>>> =09> Service URN is placed in the messa=
ge ensures that the=0D=0A>> >> call cannot=0D=0A>> >>>> go to my=0D=0A>> >>=
>> =09> friend (instead of the PSAP) unless the end host ran=0D=0A>> >> LoS=
T already.=0D=0A>> >>>> In the=0D=0A>> >>>> =09> latter case, we discussed =
this also on the list for a=0D=0A>> >> while and=0D=0A>> >>>> Richard even=0D=
=0A>> >>>> =09> wrote a draft about it in the context of the=20=0D=0A>locat=
ion hiding=20=0D=0A>> >>>> topic, we said=0D=0A>> >>>> =09> that the proxy =
would have to run LoST if he=20=0D=0A>cares about a=20=0D=0A>> >>>> potenti=
al=0D=0A>> >>>> =09> fraudulent usage.=0D=0A>> >>>> =09>=0D=0A>> >>>> =09> =
So, what do we need todo in order to provide=20=0D=0A>secure RFC 4412=20=0D=
=0A>> >>>> functionality=0D=0A>> >>>> =09> in our context=3F=0D=0A>> >>>> =09=
>=0D=0A>> >>>> =09> Do you think that the current text in=0D=0A>> >>>> =09>=0D=
=0A>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer=0D=
=0A>> >>>> gency-rph-nam=0D=0A>> >>>> =09> espace-00.txt reflects any of th=
e=20=0D=0A>above-described issues:=0D=0A>> >>>> =09> "=0D=0A>> >>>> =09>   =
 The Security considerations that apply to RFC 4412=0D=0A>> >>>> [RFC4412]=0D=
=0A>> >>>> apply=0D=0A>> >>>> =09>    here.  This document introduces no ne=
w security=0D=0A>> >>>> issues relative=0D=0A>> >>>> to=0D=0A>> >>>> =09>  =
  RFC 4412.=0D=0A>> >>>> =09> "=0D=0A>> >>>> =09>=0D=0A>> >>>> =09> From va=
rious discussions in GEOPRIV I recall=20=0D=0A>that you are=20=0D=0A>> >>>>=
 super-sensitive=0D=0A>> >>>> =09> regarding security and privacy. For some=
 reasons you=0D=0A>> >> don't seem to=0D=0A>> >>>> have the=0D=0A>> >>>> =09=
> same concerns here. I would like to=20=0D=0A>understand your reasoning.=0D=
=0A>> >>>> =09>=0D=0A>> >>>> =09> Please also do me another favor: Don't al=
ways say=0D=0A>> >> that I don't=0D=0A>> >>>> understand=0D=0A>> >>>> =09> =
the subject. Even if that would be the case it isn't=0D=0A>> >> particular=0D=
=0A>> >>>> fair given=0D=0A>> >>>> =09> that different folks had to educate=
 you on other=0D=0A>> >> topics in the=0D=0A>> >>>> past as well.=0D=0A>> >=
>>> =09> Additionally, if you listen to the audio recordings=0D=0A>> >> the=
n you will=0D=0A>> >>>> notice=0D=0A>> >>>> =09> that Henning, Ted, and Jon=
 do not seem to understand=0D=0A>> >> the issue=0D=0A>> >>>> either as=0D=0A=
>> >>>> =09> they have raised similar issues during the=20=0D=0A>F2F meetin=
gs.=0D=0A>> >>>> =09>=0D=0A>> >>>> =09> Ciao=0D=0A>> >>>> =09> Hannes=0D=0A=
>> >>>> =09>=0D=0A>> >>>> =09>=0D=0A>> >>>> =09> >Hannes - I believe it is =
you who do not understand=0D=0A>> >> RFC 4412 --=0D=0A>> >>>> =09> >and man=
y of us are trying to get that=20=0D=0A>through to you, but you=0D=0A>> >>>=
> =09> >don't seem to want to listen/read.=0D=0A>> >>>> =09> >=0D=0A>> >>>>=
 =09> >RFC 4412 is *for* priority marking SIP requests,=0D=0A>> >>>> =09> >=0D=
=0A>> >>>> =09> >One use is GETS.=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09> >On=
e use is MLPP.=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09> >These examples are in=
 RFC 4412 because there=20=0D=0A>were specific=0D=0A>> >>>> =09> >namespace=
s being created for the IANA section of=0D=0A>> >> that document.=0D=0A>> >=
>>> =09> >=0D=0A>> >>>> =09> >Reading the whole document, you will see=20=0D=
=0A>that RPH can be=0D=0A>> >>>> =09> >specified for other uses than GETS o=
r MLPP=20=0D=0A>specifically.=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09> >I knew=
 when I wrote RFC 4412 that one day we=20=0D=0A>would specify a=0D=0A>> >>>=
> =09> >namespace for ECRIT (the "esnet" namespace=20=0D=0A>now) -- but I a=
lso=0D=0A>> >>>> =09> >knew it was premature for RFC 4412 to=20=0D=0A>incor=
porate that=0D=0A>> >>>> =09> >namespace, that a future doc to RFC 4412=20=0D=
=0A>would have to be=0D=0A>> >>>> =09> >written to do this. Brian and I tal=
ked about=20=0D=0A>this at the=0D=0A>> >>>> =09> >original NENA meeting tha=
t created the IP WGs there=0D=0A>> >> (in August=0D=0A>> >>>> =09> >of 03).=
  We both agreed we should wait until it was=0D=0A>> >>>> =09> >appropriate=
 to the work in the IETF to=20=0D=0A>submit this document=0D=0A>> >>>> =09>=
 >that is now=0D=0A>> >>>> =09>=0D=0A>> >>>>> http://www.ietf.org/internet-=
drafts/draft-ietf-ecrit-local-emer=0D=0A>> >>>> =09> >gency-rph-namespace-0=
0.txt=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09> >Yet, you seem to want to use s=
ome additional=20=0D=0A>mechanism to=0D=0A>> >>>> =09> >indicate priority o=
f a call in SIP.  That=20=0D=0A>means you want to=0D=0A>> >>>> =09> >introd=
uce a second way to accomplish this in SIP.=0D=0A>> >>>> Why do you=0D=0A>>=
 >>>> =09> >want to promote a separate way to do something SIP=0D=0A>> >> h=
as already=0D=0A>> >>>> =09> >defined=3F That will cause interoperability i=
ssues and=0D=0A>> >> we both know=0D=0A>> >>>> that.=0D=0A>> >>>> =09> >=0D=
=0A>> >>>> =09> >You've said to me (and others) that you=20=0D=0A>believe R=
PH is just=0D=0A>> >>>> =09> >another way to accomplish what sos or a URI c=
an=0D=0A>> >> indicate - and=0D=0A>> >>>> =09> >you're wrong.  Your way wou=
ld be=20=0D=0A>_the_second_way_to_do_it,=0D=0A>> >>>> =09> >because SIP alr=
eady considers RPH to be=20=0D=0A>*the*way* to priority=0D=0A>> >>>> =09> >=
mark SIP requests.=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09> >If you don't beli=
eve me (no comment), then=20=0D=0A>why do you not=0D=0A>> >>>> =09> >believ=
e the SIP WG chair (who knows more=20=0D=0A>about SIP than both=0D=0A>> >>>=
> =09> >of us) - who, on this thread, has again said=20=0D=0A>to you "RFC 4=
412=0D=0A>> >>>> =09> >(RPH) is the SIP mechanism to priority mark=20=0D=0A=
>SIP requests"=3F=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09> >Further, I believe=
 it is inappropriate to=20=0D=0A>prohibit endpoints=0D=0A>> >>>> =09> >from=
 being able to set the esnet namespace. =20=0D=0A>I absolutely=0D=0A>> >>>>=
 =09> >believe it will not be needed most of the=20=0D=0A>time, but I belie=
ve=0D=0A>> >>>> =09> >if someone does find a valid use for=20=0D=0A>endpoin=
ts to mark=0D=0A>> >>>> =09> >priority in SIP, this ID - once it has=20=0D=0A=
>become an RFC -- will=0D=0A>> >>>> =09> >have to be obsoleted with a new R=
FC saying the exact=0D=0A>> >> opposite.=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09=
> >(color me confused ... over and over again)=0D=0A>> >>>> =09> >=0D=0A>> =
>>>> =09> >James=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09> >At 01:05 PM 2/5/200=
9, Hannes Tschofenig wrote:=0D=0A>> >>>> =09> >>Keith, please understand th=
at the usage of RFC 4412=0D=0A>> >> for GETS and=0D=0A>> >>>> for=0D=0A>> >=
>>> =09> >>the type of emergency call we discuss here is=0D=0A>> >> differe=
nt. Just=0D=0A>> >>>> looking=0D=0A>> >>>> =09> >>at the header and the nam=
e of the namespace is a bit=0D=0A>> >>>> =09> >artificial. I hope=0D=0A>> >=
>>> =09> >>you understand that.=0D=0A>> >>>> =09> >>=0D=0A>> >>>> =09> >> >=
-----Original Message-----=0D=0A>> >>>> =09> >> >From: DRAGE, Keith (Keith)=
=20=0D=0A>> >>>> [mailto:[email-masked]]=0D=0A>> >>>> =09> >> >Se=
nt: 05 February, 2009 14:55=0D=0A>> >>>> =09> >> >To: Brian Rosen; 'Hannes =
Tschofenig'; 'James M.=0D=0A>> >>>> Polk'; 'Tschofenig,=0D=0A>> >>>> =09> >=
> >Hannes (NSN - FI/Espoo)'; 'ECRIT'=0D=0A>> >>>> =09> >> >Subject: RE: [Ec=
rit] ECRIT Virtual Interim=0D=0A>> >>>> Meeting: Agenda (my=0D=0A>> >>>>=0D=
=0A>> >>>> =09> >> >mistake)=0D=0A>> >>>> =09> >> >=0D=0A>> >>>> =09> >> >W=
hich is exactly what RFC 4412 specifies for all=0D=0A>> >> namespaces.=0D=0A=
>> >>>> =09> >> >=0D=0A>> >>>> =09> >> >regards=0D=0A>> >>>> =09> >> >=0D=0A=
>> >>>> =09> >> >Keith=0D=0A>> >>>> =09> >> >=0D=0A>> >>>> =09> >> >> -----=
Original Message-----=0D=0A>> >>>> =09> >> >> From: [email-masked]=0D=
=0A>> >> [mailto:[email-masked]]=0D=0A>> >>>> =09> >> >On Behalf=0D=
=0A>> >>>> =09> >> >> Of Brian Rosen=0D=0A>> >>>> =09> >> >> Sent: Wednesda=
y, February 04, 2009 10:19 PM=0D=0A>> >>>> =09> >> >> To: 'Hannes Tschofeni=
g'; 'James M.=20=0D=0A>Polk'; 'Tschofenig,=0D=0A>> >>>> =09> >Hannes (NSN=0D=
=0A>> >>>> =09> >> >> - FI/Espoo)'; 'ECRIT'=0D=0A>> >>>> =09> >> >> Subject=
: Re: [Ecrit] ECRIT Virtual Interim=0D=0A>> >>>> Meeting: Agenda (my=0D=0A>=
> >>>> =09> >> >> mistake)=0D=0A>> >>>> =09> >> >>=0D=0A>> >>>> =09> >> >> =
The value is that in some networks=20=0D=0A>where priority for=0D=0A>> >>>>=
 =09> >> >emergency calls=0D=0A>> >>>> =09> >> >> is appropriate, and appro=
priate=20=0D=0A>policing of marking is=0D=0A>> >>>> =09> >implemented,=0D=0A=
>> >>>> =09> >> >> emergency calls will receive resource priority.=0D=0A>> =
>>>> =09> >> >>=0D=0A>> >>>> =09> >> >> Not all networks would need policin=
g.  Some=0D=0A>> >> will.  Policing=0D=0A>> >>>> could=0D=0A>> >>>> =09> >>=
 >> be to Route header/R-URI content, but other=0D=0A>> >> criteria are=0D=0A=
>> >>>> possible.=0D=0A>> >>>> =09> >> >>=0D=0A>> >>>> =09> >> >> Not all n=
etworks will need resource priority=0D=0A>> >> for emergency=0D=0A>> >>>> c=
alls.=0D=0A>> >>>> =09> >> >> Fine, ignore this marking/namespace.=0D=0A>> =
>>>> =09> >> >>=0D=0A>> >>>> =09> >> >> Brian=0D=0A>> >>>> =09> >> >> > ---=
--Original Message-----=0D=0A>> >>>> =09> >> >> > From: Hannes Tschofenig =0D=
=0A>> >>>> [mailto:[email-masked]]=0D=0A>> >>>> =09> >> >> > Sen=
t: Wednesday, February 04, 2009 5:09 PM=0D=0A>> >>>> =09> >> >> > To: 'Bria=
n Rosen'; 'James M. Polk';=0D=0A>> >> Tschofenig, Hannes=0D=0A>> >>>> (NSN =
-=0D=0A>> >>>> =09> >> >> > FI/Espoo); 'ECRIT'=0D=0A>> >>>> =09> >> >> > Su=
bject: RE: [Ecrit] ECRIT Virtual Interim=0D=0A>> >>>> Meeting: Agenda (my=0D=
=0A>> >>>> =09> >> >> > mistake)=0D=0A>> >>>> =09> >> >> >=0D=0A>> >>>> =09=
> >> >> > I don't even see the value in permitting the=0D=0A>> >> endpoint =
todo=0D=0A>> >>>> the=0D=0A>> >>>> =09> >> >> > RPH marking.=0D=0A>> >>>> =09=
> >> >> > In addition to the security concerns=20=0D=0A>there is also the=0D=
=0A>> >>>> =09> >> >problem that=0D=0A>> >>>> =09> >> >> > there are more o=
ptions to implement without=0D=0A>> >> an additional=0D=0A>> >>>> value.=0D=
=0A>> >>>> =09> >> >> >=0D=0A>> >>>> =09> >> >> > >-----Original Message---=
--=0D=0A>> >>>> =09> >> >> > >From: Brian Rosen [mailto:[email-masked]]=0D=
=0A>> >>>> =09> >> >> > >Sent: 05 February, 2009 00:03=0D=0A>> >>>> =09> >>=
 >> > >To: 'James M. Polk'; 'Hannes Tschofenig';=0D=0A>> >> 'Tschofenig,=0D=
=0A>> >>>> =09> >> >> Hannes (NSN -=0D=0A>> >>>> =09> >> >> > >FI/Espoo)'; =
'ECRIT'=0D=0A>> >>>> =09> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual=20=0D=
=0A>Interim Meeting:=0D=0A>> >>>> Agenda (my=0D=0A>> >>>> =09> >> >> > mist=
ake)=0D=0A>> >>>> =09> >> >> > >=0D=0A>> >>>> =09> >> >> > >Hannes=0D=0A>> =
>>>> =09> >> >> > >=0D=0A>> >>>> =09> >> >> > >This matches my understandin=
g=20=0D=0A>precisely.  We wish to=0D=0A>> >>>> =09> >> >> permit endpoints=0D=
=0A>> >>>> =09> >> >> > >to mark. We do not require it, and=20=0D=0A>don't =
necessarily=20=0D=0A>> >>>> expect it=0D=0A>> >>>> =09> >> >> > >in many (e=
ven=0D=0A>> >>>> =09> >> >> > >most) cases.  We don't wish to see the=0D=0A=
>> >> document prohibit=0D=0A>> >>>> it.=0D=0A>> >>>> =09> >> >> > >We all =
seem to agree it has value within the=0D=0A>> >> Emergency=0D=0A>> >>>> =09=
> >> >Services IP=0D=0A>> >>>> =09> >> >> > >Networks.=0D=0A>> >>>> =09> >>=
 >> > >=0D=0A>> >>>> =09> >> >> > >Brian=0D=0A>> >>>> =09> >> >> > >=0D=0A>=
> >>>> =09> >> >> > >> -----Original Message-----=0D=0A>> >>>> =09> >> >> >=
 >> From: [email-masked]=20=0D=0A>> >>>> [mailto:ecrit-bounces@ietf=
=2Eorg]=0D=0A>> >>>> =09> >> >> > >On Behalf=0D=0A>> >>>> =09> >> >> > >> O=
f James M. Polk=0D=0A>> >>>> =09> >> >> > >> Sent: Wednesday, February 04, =
2009 4:01 PM=0D=0A>> >>>> =09> >> >> > >> To: Hannes Tschofenig; Tschofenig=
,=20=0D=0A>Hannes (NSN -=0D=0A>> >>>> =09> >> >> FI/Espoo); 'ECRIT'=0D=0A>>=
 >>>> =09> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim=0D=0A>> >>=
>> Meeting:=0D=0A>> >>>> =09> >Agenda (my=0D=0A>> >>>> =09> >> >> > >> mist=
ake)=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >> >> > >> At 02:37 PM =
2/4/2009, Hannes=20=0D=0A>Tschofenig wrote:=0D=0A>> >>>> =09> >> >> > >> > =
> James wrote:=0D=0A>> >>>> =09> >> >> > >> > >> you are the _lone_ voice n=
ot=0D=0A>> >> supporting this ID,=0D=0A>> >>>> =09> >> >> > >> >=0D=0A>> >>=
>> =09> >> >> > >> >Listening to the audio recording of past=0D=0A>> >> mee=
tings I=0D=0A>> >>>> have to=0D=0A>> >>>> =09> >> >> > >say that=0D=0A>> >>=
>> =09> >> >> > >> >I=0D=0A>> >>>> =09> >> >> > >> was=0D=0A>> >>>> =09> >>=
 >> > >> >not the only persons raising=20=0D=0A>concerns about the=20=0D=0A=
>> >>>> document.=0D=0A>> >>>> =09> >> >> > >> >That was probably the reaso=
n why you=0D=0A>> >> agreed to limit=0D=0A>> >>>> the=0D=0A>> >>>> =09> >> =
>> > >scope of the=0D=0A>> >>>> =09> >> >> > >> >document (which you didn't=
 later do) to=0D=0A>> >> get folks to=0D=0A>> >>>> agree=0D=0A>> >>>> =09> =
>> >> > >to make it=0D=0A>> >>>> =09> >> >> > >> a WG=0D=0A>> >>>> =09> >> =
>> > >> >item.=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >> >> > >> re=
-listen to the audio please=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> =
>> >> > >> Ted's concerns were consistent with most=0D=0A>> >>>> (all=3F) o=
ther=0D=0A>> >>>> =09> >> >> concerns --=0D=0A>> >>>> =09> >> >> > >> which=
 were based on the premise of whether=0D=0A>> >> or not the=0D=0A>> >>>> =09=
> >> >> UAC should be=0D=0A>> >>>> =09> >> >> > >> trusted to initiate the =
marking on the=0D=0A>> >> INVITE.  The=0D=0A>> >>>> most=0D=0A>> >>>> =09> =
>> >> > >> recent version has backed off this=20=0D=0A>to a "can" --=20=0D=0A=
>> >>>> meaning not=0D=0A>> >>>> =09> >> >prohibited=0D=0A>> >>>> =09> >> >=
> > >> (i.e., no 2119 text).  I also backed off=0D=0A>> >> the text in=0D=0A=
>> >>>> the=0D=0A>> >>>> =09> >> >> SP domain=0D=0A>> >>>> =09> >> >> > >> =
part to "can", such that there is=20=0D=0A>no 2119 text=0D=0A>> >>>> =09> >=
> >mandating or even=0D=0A>> >>>> =09> >> >> > >> recommending its usage th=
ere. I also do=0D=0A>> >> not prohibit=0D=0A>> >>>> its=0D=0A>> >>>> =09> >=
> >> > >use, based on=0D=0A>> >>>> =09> >> >> > >> local policy.  Keith has=
 come forward with=0D=0A>> >> the specific=0D=0A>> >>>>=0D=0A>> >>>> =09> >=
> >> > >> request that non-ESInet networks be=0D=0A>> >> allowed to mark an=
d=0D=0A>> >>>> pay=0D=0A>> >>>> =09> >> >attention to=0D=0A>> >>>> =09> >> =
>> > >> this priority indication -- with IMS as=0D=0A>> >> the specific=0D=0A=
>> >>>> example=0D=0A>> >>>> =09> >> >> > >> he wishes to have this valid f=
or.=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >> >> > >> Where there i=
s no disagreement, save for=0D=0A>> >> your recent=0D=0A>> >>>> =09> >> >> =
> >pushback - is in=0D=0A>> >>>> =09> >> >> > >> the ESInet, which is where=
 Brian=20=0D=0A>has requested it's=0D=0A>> >>>> =09> >> >> > >definition in=
 the=0D=0A>> >>>> =09> >> >> > >> IETF on behalf of NENA.  He's the i3 WG=0D=
=0A>> >> chair within=0D=0A>> >>>> =09> >> >> NENA, and if=0D=0A>> >>>> =09=
> >> >> > >> he asks for it, are you going to say you=0D=0A>> >> know bette=
r=0D=0A>> >>>> than he=3F=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >>=
 >> > >>=0D=0A>> >>>> =09> >> >> > >> >Btw, I not disagreeing with the docu=
ment=0D=0A>> >> as such. I=0D=0A>> >>>> =09> >> >just want to=0D=0A>> >>>> =
=09> >> >> > the=0D=0A>> >>>> =09> >> >> > >> scope=0D=0A>> >>>> =09> >> >>=
 > >> >to change. The usage of RPH=20=0D=0A>within the emergency=0D=0A>> >>=
>> =09> >> >> services network=0D=0A>> >>>> =09> >> >> > is=0D=0A>> >>>> =09=
> >> >> > >> fine=0D=0A>> >>>> =09> >> >> > >> >for me. I may get convinced=
 to start the=0D=0A>> >> RPH marking=0D=0A>> >>>> from=0D=0A>> >>>> =09> >>=
 >> > >the the VSP=0D=0A>> >>>> =09> >> >> > >> >towards the PSAP. I feel u=
neasy about the=0D=0A>> >> end host=0D=0A>> >>>> doing=0D=0A>> >>>> =09> >>=
 >> > >the marking.=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >> >> > =
>> please read what I wrote above, and then=0D=0A>> >> re-read the=0D=0A>> =
>>>> =09> >> >most recent=0D=0A>> >>>> =09> >> >> > >> version of the ID. I=
 don't have endpoints=0D=0A>> >> that SHOULD=0D=0A>> >>>> or=0D=0A>> >>>> =09=
> >> >> MUST mark=0D=0A>> >>>> =09> >> >> > >> anything wrt RPH.  I also do=
n't want to=0D=0A>> >> prohibit it,=0D=0A>> >>>> =09> >> >> because there=0D=
=0A>> >>>> =09> >> >> > >> might be cases (that I don't know=20=0D=0A>of) o=
f valid uses=0D=0A>> >>>> =09> >> >> under certain=0D=0A>> >>>> =09> >> >> =
> >> circumstances.  Figure 1 is very clear=0D=0A>> >> that there are 3=0D=0A=
>> >>>> =09> >> >> networking=0D=0A>> >>>> =09> >> >> > >> parts to conside=
r=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >> >> > >> #1 - from the e=
ndpoint=0D=0A>> >>>> =09> >> >> > >> #2 - within the VSP=0D=0A>> >>>> =09> =
>> >> > >> #3 - within the ESInet=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>>=
 =09> >> >> > >> the most recent ID version has "can" for=0D=0A>> >> #s 1 a=
nd 2,=0D=0A>> >>>> and=0D=0A>> >>>> =09> >> >> > >2119 language=0D=0A>> >>>=
> =09> >> >> > >> offering those supporting this=0D=0A>> >> specification w=
ill have=0D=0A>> >>>> RPH=0D=0A>> >>>> =09> >> >> > >> adherence within #3 =
(the ESInet).=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >> >> > >> Wha=
t other scope changes do you want,=0D=0A>> >> because I haven't=0D=0A>> >>>=
> =09> >> >> heard them.=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >> =
>> > >> I only heard you claim in email during the=0D=0A>> >> last IETF=0D=0A=
>> >>>> and in=0D=0A>> >>>> =09> >> >> > >the ECRIT=0D=0A>> >>>> =09> >> >>=
 > >> session that RPH should not be=20=0D=0A>used for priority=20=0D=0A>> =
>>>> marking=0D=0A>> >>>> =09> >> >> requests.=0D=0A>> >>>> =09> >> >> > >>=
 This is something Keith (SIP WG=20=0D=0A>chair) voiced his=20=0D=0A>> >>>>=
 opposition=0D=0A>> >>>> =09> >> >> > >> to your views regarding creating a=
 second=0D=0A>> >> means for SIP=0D=0A>> >>>> to=0D=0A>> >>>> =09> >> >prio=
rity=0D=0A>> >>>> =09> >> >> > >> mark request "when SIP already has one=0D=
=0A>> >> interoperable=0D=0A>> >>>> way to=0D=0A>> >>>> =09> >> >> > >> acc=
omplish this... it's call the RP header=0D=0A>> >> mechanism".=0D=0A>> >>>>=
 =09> >> >> > >>=0D=0A>> >>>> =09> >> >> > >> >I don't see advantages -- on=
ly=20=0D=0A>disadvantages.=0D=0A>> >>>> =09> >> >> > >> >=0D=0A>> >>>> =09>=
 >> >> > >> >Ciao=0D=0A>> >>>> =09> >> >> > >> >Hannes=0D=0A>> >>>> =09> >>=
 >> > >>=0D=0A>> >>>> =09> >> >> > >>=20=0D=0A>____________________________=
___________________=0D=0A>> >>>> =09> >> >> > >> Ecrit mailing list=0D=0A>>=
 >>>> =09> >> >> > >> [email-masked]=0D=0A>> >>>> =09> >> >> > >> https://w=
ww.ietf.org/mailman/listinfo/ecrit=0D=0A>> >>>> =09> >> >> > >=0D=0A>> >>>>=
 =09> >> >>=0D=0A>> >>>> =09> >> >> _______________________________________=
________=0D=0A>> >>>> =09> >> >> Ecrit mailing list=0D=0A>> >>>> =09> >> >>=
 [email-masked]=0D=0A>> >>>> =09> >> >> https://www.ietf.org/mailman/listin=
fo/ecrit=0D=0A>> >>>> =09> >> >>=0D=0A>> >>>> =09> >> >=0D=0A>> >>>> =09> >=0D=
=0A>> >>>> =09>=0D=0A>> >>>> =09> _________________________________________=
______=0D=0A>> >>>> =09> Ecrit mailing list=0D=0A>> >>>> =09> [email-masked]=
g=0D=0A>> >>>> =09> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>> >>>=
>=0D=0A>> >>>>=0D=0A>> >>>>=0D=0A>> >>>> __________________________________=
_____________=0D=0A>> >>>> Ecrit mailing list=0D=0A>> >>>> [email-masked]=0D=
=0A>> >>>> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>> >>>>=0D=0A>>=
 >>>=0D=0A>> >>> _______________________________________________=0D=0A>> >>=
> Ecrit mailing list=0D=0A>> >>> [email-masked]=0D=0A>> >>> https://www.iet=
f.org/mailman/listinfo/ecrit=0D=0A>> >>=0D=0A>> >=0D=0A>> > _______________=
________________________________=0D=0A>> > Ecrit mailing list=0D=0A>> > Ecr=
[email-masked]=0D=0A>> > https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>> >=0D=
=0A>=0D=0A=0D=0A_______________________________________________=0D=0AEcrit =
mailing list=0D=[email-masked]=0D=0Ahttps://www.ietf.org/mailman/listinfo=
/ecrit=0D=0A=0D=0A=0D=0A---------------------------------------------------=
---------------------------------------------=0D=0AThis message is for the =
designated recipient only and may=0D=0Acontain privileged, proprietary, or =
otherwise private information. =20=0D=0AIf you have received it in error, p=
lease notify the sender=0D=0Aimmediately and delete the original.  Any unau=
thorized use of=0D=0Athis email is prohibited.=0D=0A-----------------------=
-------------------------------------------------------------------------=0D=
=0A[mf2]=0D=0A

From: Henning Schulzrinne <[email-masked]>
To: "Winterbottom, James" <[email-masked]>
Date: Fri, 6 Feb 2009 16:05:07 -0500
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

There's another problem with the "it doesn't hurt argument". Assume  
for a moment we have a "UA MAY include RPH" wording. There are now two  
cases:

(1) All UAs implement it.

(2) Only some UAs implement it.

(1) seems unlikely for a MAY. If (2) occurs, we have the choice  
between two undesirable outcomes:

(a) some UAs that are otherwise compliant get worse service just  
because they didn't include the RPH;

OR

(b) the proxy has to look for the service URN to give the call the  
appropriate treatment, thus obviating any advantage of having the  
header, yet incurring more complicated processing logic.

I have no objection to whatever markings people want to apply to calls  
within an ESN - that's largely a private matter.

Henning

On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote:

> Hi All,
>
> I have followed thi thread with some interest and I struggling to  
> see a use case for the
> providing RPH for emergency calls from the end-point.
>
> The reference-model call in ECRIT, for better or worse, is for all  
> calls to go back through a home-VSP.
> We placed quite a lot of emphasis, largely for traffing reasons, for  
> the VSP to be able to verify that
> a call is in fact an emergency call. This is done by the proxy  
> taking the inband location, doing a LoST
> query with the provided URN, and verifying that the resulting  
> destination URI is the same as the destination
> URI provide in the SIP INVITE. My understanding was that VSPs would  
> always do this check so they could
> tell if they could bill for the call or not, and because the VSP can  
> be use that the call is an emergency call
> it can apply any special priorities that may be applicable. This  
> obviates the need for RPH from the end-point
> to the network.
>
> This leaves us with the argument of "it doesn't hurt to it", which  
> is not a good reason to write a specification.
> It was intimated on the geopriv mailing list last year that great  
> pains had been taken to keep SIP with in the
> MTU limits of UDP over Ethernet (http://www.ietf.org/mail-archive/web/geopriv/current/msg06120.html 
> ). Assuming
> that this is the case, perhaps there is harm in including  
> information that we know will be ignored.
>
> Cheers
> James
>
>
>
> -----Original Message-----
> From: [email-masked] on behalf of Hannes Tschofenig
> Sent: Fri 2/6/2009 12:33 PM
> To: 'Brian Rosen'; 'Henning Schulzrinne'
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
> Subject: Re: [Ecrit] RPH
>
> To the story short here is the code for the proxy:
>
> ---------------------
>
> IF emergency call was recognized THEN
>    execute emergency call specific procedures (priority queuing,
> preemption, fetch location, determine routing, do funny QoS things &  
> co)
> ELSE
>    normal call handling procedures.
>
> ---------------------
>
> If you can make this differentiation between an emergency call and a  
> regular
> call then you can also do everything that is necessary for emergency  
> call
> handling.
>
> Brian + Keith: Please tell me that we cannot do the above with our  
> currently
> specified mechanisms.
>
> Ciao
> Hannes
>
>> -----Original Message-----
>> From: Brian Rosen [mailto:[email-masked]]
>> Sent: 06 February, 2009 17:49
>> To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
>> Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
>> Subject: RE: [Ecrit] RPH
>>
>> I agree that not all networks will permit (or pay attention
>> to) a priority request from an end device.
>>
>> No one has asked for that.
>>
>> The namespace request has several uses, one of which is within
>> an emergency services IP network, one of which is between
>> elements within a public network controlled by the operator,
>> and one of which is an endpoint request for resource priority.
>>
>> Those of us requesting this work proceed are happy if the
>> endpoint part is simply left as possible (MAY), and, speaking
>> for myself, having the draft discuss the security implications
>> of endpoint marking is reasonable.
>>
>> Having discussed this issue with an implementation team who
>> worked on MLPP systems, I am confident I know what I'm talking
>> about, but YMMV.  The fact that you could, if you wanted to,
>> give resource priority to a call you decided, however you
>> decided, was an emergency call is an implementation decision,
>> and not subject to standardization.
>>
>> RPH is the IETF standard way for one entity to request
>> resource priority of another entity in a SIP system.  We're
>> asking for a namespace to use that within the domain of
>> emergency calls.  That is, I think, a VERY reasonable request.
>>
>> Brian
>>
>>> -----Original Message-----
>>> From: Henning Schulzrinne [mailto:[email-masked]]
>>> Sent: Friday, February 06, 2009 10:33 AM
>>> To: Hannes Tschofenig
>>> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>>> Subject: Re: [Ecrit] RPH
>>>
>>> To chime in here:
>>>
>>> I don't think it's productive to simply state that 4412
>> doesn't worry
>>> about authorization, so we shouldn't either (simplifying a bit).
>>> Authorization was discussed repeatedly, and the general
>> assumption was
>>> that there were two conditions: Either the user invoking resource-
>>> priority was well known and had a set of permissions that could be
>>> checked in real time or there are ways to deal with abuse after the
>>> fact in ways that deter abuse (the court-martial kind of thing in a
>>> military context).
>>>
>>> The RFC 4412 security consideration (11.2) call this out in pretty
>>> strong language:
>>>
>>>  Prioritized access to network and end-system resources imposes
>>>    particularly stringent requirements on authentication and
>>>    authorization mechanisms, since access to prioritized
>> resources may
>>>    impact overall system stability and performance and not
>> just result
>>>    in theft of, say, a single phone call.
>>> Thus, the question is whether we have such strong authentication in
>>> emergency calling. In some cases, such as residential fixed line
>>> deployments where ISP = VSP, we're probably pretty close, in others,
>>> such as prepaid cell phones or hot spots or VSP-only providers, we
>>> aren't.
>>>
>>> The other point that I think Hannes is making is that the
>> information
>>> is either redundant or dangerous. If a processing element recognizes
>>> the call as being an emergency call, it can apply whatever treatment
>>> it deems appropriate and doesn't need additional information. If it
>>> doesn't or can't, using just the RPH can be rather dangerous unless
>>> that element can be reasonably certain that there is strong
>>> authentication and recourse.
>>>
>>> I don't buy the argument that somehow finding the RPH is faster than
>>> just looking for the identifier. Thus, given that the information is
>>> either redundant or dangerous, I fail to see the advantage.
>>>
>>> Henning
>>>
>>>
>>> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
>>>
>>>> Don't get hung up on the details. There are ways to optimize it.
>>>> That was
>>>> not the point of the code example.
>>>>
>>>> The problem that my pseudo code should have shown you is that you
>>>> * don't gain anything with RPH marking for the emergency call case
>>>> from the SIP UA towards the outbound proxy since the functionality
>>>> is already provide otherwise. How often does the proxy need to get
>>>> told that this is an emergency call todo whatever emergency call
>>>> handling procedures are necessary?
>>>> * you only introduce fraud problems (if you are not
>> careful and you
>>>> understand the security stuff well enough)
>>>>
>>>> If you can point me to people who implement the RPH emergency call
>>>> case please do so. I would love to talk to them.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> PS: You need to parse incoming messages to some extend so that you
>>>> know what it contains :-) Only looking for the emergency
>> RPH header
>>>> (and not for the Service URN/dial
>>>> string) would exactly be the DoS/fraud attack I am worried about.
>>>> That's the thing Henning was worried about (go and listen to the
>>>> past meeting minutes).
>>>>
>>>>
>>>>> Hannes
>>>>>
>>>>> You need to talk to people who really implement this kind
>> of thing.
>>>>> You are way off.
>>>>>
>>>>> When you implement a resource priority system, the point of doing
>>>>> that is to look though the queue of work and pick out the
>> ones with
>>>>> priority, handling them first.  You don't do all the parsing, you
>>>>> don't do a lot of decision tree.
>>>>>
>>>>> Typically:
>>>>> Check for DoS things, like too big messages, etc Do a quick scan
>>>>> for the RPH message header If found:
>>>>> Parse the message
>>>>> Determine validity
>>>>> Determine priority
>>>>> Queue on the correct work queue
>>>>>
>>>>> The first two actions have to be very fast.  Anyone who builds a
>>>>> SIP thingie will tell you that parsing is one of the big cycle
>>>>> consumers: if you have to parse every message BEFORE you
>> determine
>>>>> priority, you can't give much resource priority.
>>>>> Once you get the whole message parsed, you might as well finish
>>>>> working on it, because you've done so much of the work.
>>>>> OTHOH, finding the end-of-message delimiter and doing a quick
>>>>> string search for RPH is fast.  If you are doing
>> priority, you need
>>>>> to keep all the priority processing pretty uniform, and pretty
>>>>> simple, or you tend to spend too much time futzing around
>> figuring
>>>>> out what to do.  You put all the priority related stuff together,
>>>>> and use as much common code as possible.
>>>>>
>>>>> Brian
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>> On Behalf
>>>>>> Of Hannes Tschofenig
>>>>>> Sent: Friday, February 06, 2009 8:41 AM
>>>>>> To: 'Hannes Tschofenig'; 'Janet P Gunn'
>>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-
>>>>>> [email-masked]
>>>>>> Subject: [Ecrit] RPH
>>>>>>
>>>>>> Over lunch I was also thinking how an outbound proxy would
>>> implement
>>>>>> some of the emergency procedures. Here are some thoughts:
>>>>>>
>>>>>> ---------------------------------------------------
>>>>>>
>>>>>> // Process incoming message
>>>>>> Parse(msg);
>>>>>>
>>>>>> // SIP INVITE without Service URN
>>>>>> // legacy devices
>>>>>> If (recognize-dialstring(msg)==TRUE) {  // we got an emergency
>>>>>> call going on  emergency=TRUE;  if (dialstring(msg) == 911)
>>>>>> serviceURN=urn:service:sos; } else if
>>>>>> (recognize-serviceURN(msg)==TRUE) {  // oh. A updated
>> device that
>>>>>> has a service URN attached to the
>>> call
>>>>>> serviceURN=retrieve_ServiceURN(msg);
>>>>>> emergency=TRUE;
>>>>>> } else {
>>>>>> // standard SIP message
>>>>>> // regular processing
>>>>>> process(msg);
>>>>>> emergency=FALSE;
>>>>>> }
>>>>>>
>>>>>> If (emergency == TRUE) {
>>>>>>  // make sure that the emergency call does not get
>> dropped on the
>>>>>> floor
>>>>>>  // skip authorization failures
>>>>>>  // give the call a special treatment
>>>>>>  lots-of-code-here();
>>>>>>
>>>>>>  // trigger all the QoS signaling you have in the
>> network to make
>>>>>> James happy
>>>>>>  trigger-qos();
>>>>>>
>>>>>>  // query location
>>>>>>  location=retrieve-location();
>>>>>>
>>>>>>  // determine next hop
>>>>>>  next-hop=lost(location, serviceURN)
>>>>>>
>>>>>>  // attach RPH marking to outgoing msg to make James and
>>>>> Keith happy
>>>>>>  msg=add(msg, RPH);
>>>>>>
>>>>>>  send(msg, next-hop);
>>>>>> }
>>>>>>
>>>>>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
>>>>>>  // all the emergency related processing done already upfront
>>>>>>  // hence I log something.
>>>>>>  log(RPH_WAS_PRESENT_JUHU);
>>>>>> } else if ((rph-present(msg) == TRUE) && (emergency ==
>> FALSE)) {
>>>>>> // this is not an emergency call  // this is something
>> like GETS
>>>>>> result=special-authorization-procedure(user);
>>>>>>
>>>>>> if (result == AUTHORIZED) {
>>>>>>   // do some priority & preemption thing here.
>>>>>>   // trigger all the QoS you have
>>>>>>   lots-of-code-here();
>>>>>> } else {
>>>>>>   log("NOT AUTHORIZED; don't DoS my network");  } } else {  //
>>>>>> don't need todo any RPH processing  // this includes the case
>>>>>> where the call was an emergency call but the RPH
>>>>>>
>>>>>> // marking was not there.
>>>>>> nothing();
>>>>>> }
>>>>>>
>>>>>> ---------------------------------------------------
>>>>>>
>>>>>>
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>>> Behalf Of Hannes Tschofenig
>>>>>>> Sent: 06 February, 2009 15:07
>>>>>>> To: 'Janet P Gunn'
>>>>>>> Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
>>>>>> FI/Espoo)
>>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
>>>>>>>
>>>>>>> Who would define something that could prevent DoS problems?
>>>>>>>
>>>>>>> ________________________________
>>>>>>>
>>>>>>> 	From: Janet P Gunn [mailto:[email-masked]]
>>>>>>> 	Sent: 06 February, 2009 14:11
>>>>>>> 	To: Hannes Tschofenig
>>>>>>> 	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
>>>>>>> [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
>>> 'James
>>>>>>> M. Polk'
>>>>>>> 	Subject: Re: [Ecrit] ECRIT Virtual Interim
>> Meeting: Agenda (RPH)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 	But there is nothing IN RFC4412 that specifically
>>>>> addresses how to
>>>>>>> prevent any particular namespace being used for DoS.  Anyone/any
>>> UA
>>>>>>> can ATTEMPT to invoke priority treatment by attaching RPH.  For
>>> all
>>>>>>> of the 4412 namespaces, as with the new proposed namespace, the
>>>>>>> mechanisms for preventing DoS are not specified in the
>>>>> document that
>>>>>>> defines the namespace.
>>>>>>> They are/will be specified elsewhere.
>>>>>>>
>>>>>>> 	Janet
>>>>>>>
>>>>>>> 	This is a PRIVATE message. If you are not the intended
>>>>> recipient,
>>>>>>> please delete without copying and kindly advise us by e-mail of
>>> the
>>>>>>> mistake in delivery.
>>>>>>> 	NOTE: Regardless of content, this e-mail shall not
>>>>> operate to bind
>>>>>>> CSC to any order or other contract unless pursuant to explicit
>>>>>>> written agreement or government initiative expressly permitting
>>> the
>>>>>>> use of e-mail for such purpose.
>>>>>>>
>>>>>>> 	[email-masked] wrote on 02/06/2009 04:21:51 AM:
>>>>>>>
>>>>>>> 	> Hi James,
>>>>>>> 	>
>>>>>>> 	> I have read RFC 4412 and also the GETS/MLPP IETF
>>>>> documents. What I
>>>>>>> would
>>>>>>> 	> like to point out is that there is more than just a
>>>>> header and
>>>>>>> values within
>>>>>>> 	> the header that have to be considered in order to
>>>>> make a judgement
>>>>>>> of what
>>>>>>> 	> is appropriate and what isn't. There is an
>>>>> architectural question
>>>>>>> and
>>>>>>> 	> whether the environment we are using the stuff is
>>>>> indeed providing
>>>>>>> the
>>>>>>> 	> properties you need for the solution to be
>> appropriate.
>>>>>>> 	>
>>>>>>> 	> Let me describe in more detail what I meant (and
>>>>> please correct me
>>>>>>> if I am
>>>>>>> 	> wrong).
>>>>>>> 	>
>>>>>>> 	> Getting priority for SIP requests when using a GETS
>>>>> alike scenario
>>>>>>> means
>>>>>>> 	> that the entity that issues the request is specially
>>>>> authorized
>>>>>>> since
>>>>>>> 	> otherwise you introduce a nice denial of
>> service attack. This
>>>>>>> authorization
>>>>>>> 	> is tied to the entity that makes the request. For
>>>>> example, the
>>>>>>> person is
>>>>>>> 	> working for the government and has special rights.
>>>>>>> James Bond as a (not so)
>>>>>>> 	> secret agent might have these rights.
>>>>>>> 	>
>>>>>>> 	> The emergency services case
>> (citizen-to-authority) is a bit
>>>>>>> different as
>>>>>>> 	> there aren't really special rights with respect to
>>>>> authorization
>>>>>>> tied to
>>>>>>> 	> individuals. Instead, the fact that something is an
>>>>> emergency is
>>>>>>> purely a
>>>>>>> 	> judgement of the human that dials a special number.
>>>>>>> To deal with fraud, we
>>>>>>> 	> discussed in the group on what we can actually do to
>>>>> ensure that
>>>>>>> end users
>>>>>>> 	> do not bypass security procedures (such as
>>>>> authorization checks,
>>>>>>> charging
>>>>>>> 	> and so on). Part of this investigation was
>> the publication of
>>>>>>> 	> http://www.ietf.org/rfc/rfc5069.txt that also
>> describes this
>>>>>>> issue.
>>>>>>> 	>
>>>>>>> 	> So, imagine the implementation of a SIP proxy (and we
>>>>> implemented
>>>>>>> that
>>>>>>> 	> stuff) that receives a call that contains a Service
>>>>> URN. The code
>>>>>>> branches
>>>>>>> 	> into a special mode where everything is done
>> so that the call
>>>>>>> receives
>>>>>>> 	> appropriate treatment and does not get dropped on the
>>>>> floor. The
>>>>>>> way how the
>>>>>>> 	> Service URN is placed in the message ensures that the
>>>>> call cannot
>>>>>>> go to my
>>>>>>> 	> friend (instead of the PSAP) unless the end host ran
>>>>> LoST already.
>>>>>>> In the
>>>>>>> 	> latter case, we discussed this also on the list for a
>>>>> while and
>>>>>>> Richard even
>>>>>>> 	> wrote a draft about it in the context of the
>> location hiding
>>>>>>> topic, we said
>>>>>>> 	> that the proxy would have to run LoST if he
>> cares about a
>>>>>>> potential
>>>>>>> 	> fraudulent usage.
>>>>>>> 	>
>>>>>>> 	> So, what do we need todo in order to provide
>> secure RFC 4412
>>>>>>> functionality
>>>>>>> 	> in our context?
>>>>>>> 	>
>>>>>>> 	> Do you think that the current text in
>>>>>>> 	>
>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>>>>>>> gency-rph-nam
>>>>>>> 	> espace-00.txt reflects any of the
>> above-described issues:
>>>>>>> 	> "
>>>>>>> 	>    The Security considerations that apply to RFC 4412
>>>>>>> [RFC4412]
>>>>>>> apply
>>>>>>> 	>    here.  This document introduces no new security
>>>>>>> issues relative
>>>>>>> to
>>>>>>> 	>    RFC 4412.
>>>>>>> 	> "
>>>>>>> 	>
>>>>>>> 	> From various discussions in GEOPRIV I recall
>> that you are
>>>>>>> super-sensitive
>>>>>>> 	> regarding security and privacy. For some reasons you
>>>>> don't seem to
>>>>>>> have the
>>>>>>> 	> same concerns here. I would like to
>> understand your reasoning.
>>>>>>> 	>
>>>>>>> 	> Please also do me another favor: Don't always say
>>>>> that I don't
>>>>>>> understand
>>>>>>> 	> the subject. Even if that would be the case it isn't
>>>>> particular
>>>>>>> fair given
>>>>>>> 	> that different folks had to educate you on other
>>>>> topics in the
>>>>>>> past as well.
>>>>>>> 	> Additionally, if you listen to the audio recordings
>>>>> then you will
>>>>>>> notice
>>>>>>> 	> that Henning, Ted, and Jon do not seem to understand
>>>>> the issue
>>>>>>> either as
>>>>>>> 	> they have raised similar issues during the
>> F2F meetings.
>>>>>>> 	>
>>>>>>> 	> Ciao
>>>>>>> 	> Hannes
>>>>>>> 	>
>>>>>>> 	>
>>>>>>> 	> >Hannes - I believe it is you who do not understand
>>>>> RFC 4412 --
>>>>>>> 	> >and many of us are trying to get that
>> through to you, but you
>>>>>>> 	> >don't seem to want to listen/read.
>>>>>>> 	> >
>>>>>>> 	> >RFC 4412 is *for* priority marking SIP requests,
>>>>>>> 	> >
>>>>>>> 	> >One use is GETS.
>>>>>>> 	> >
>>>>>>> 	> >One use is MLPP.
>>>>>>> 	> >
>>>>>>> 	> >These examples are in RFC 4412 because there
>> were specific
>>>>>>> 	> >namespaces being created for the IANA section of
>>>>> that document.
>>>>>>> 	> >
>>>>>>> 	> >Reading the whole document, you will see
>> that RPH can be
>>>>>>> 	> >specified for other uses than GETS or MLPP
>> specifically.
>>>>>>> 	> >
>>>>>>> 	> >I knew when I wrote RFC 4412 that one day we
>> would specify a
>>>>>>> 	> >namespace for ECRIT (the "esnet" namespace
>> now) -- but I also
>>>>>>> 	> >knew it was premature for RFC 4412 to
>> incorporate that
>>>>>>> 	> >namespace, that a future doc to RFC 4412
>> would have to be
>>>>>>> 	> >written to do this. Brian and I talked about
>> this at the
>>>>>>> 	> >original NENA meeting that created the IP WGs there
>>>>> (in August
>>>>>>> 	> >of 03).  We both agreed we should wait until it was
>>>>>>> 	> >appropriate to the work in the IETF to
>> submit this document
>>>>>>> 	> >that is now
>>>>>>> 	>
>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>>>>>>> 	> >gency-rph-namespace-00.txt
>>>>>>> 	> >
>>>>>>> 	> >Yet, you seem to want to use some additional
>> mechanism to
>>>>>>> 	> >indicate priority of a call in SIP.  That
>> means you want to
>>>>>>> 	> >introduce a second way to accomplish this in SIP.
>>>>>>> Why do you
>>>>>>> 	> >want to promote a separate way to do something SIP
>>>>> has already
>>>>>>> 	> >defined? That will cause interoperability issues and
>>>>> we both know
>>>>>>> that.
>>>>>>> 	> >
>>>>>>> 	> >You've said to me (and others) that you
>> believe RPH is just
>>>>>>> 	> >another way to accomplish what sos or a URI can
>>>>> indicate - and
>>>>>>> 	> >you're wrong.  Your way would be
>> _the_second_way_to_do_it,
>>>>>>> 	> >because SIP already considers RPH to be
>> *the*way* to priority
>>>>>>> 	> >mark SIP requests.
>>>>>>> 	> >
>>>>>>> 	> >If you don't believe me (no comment), then
>> why do you not
>>>>>>> 	> >believe the SIP WG chair (who knows more
>> about SIP than both
>>>>>>> 	> >of us) - who, on this thread, has again said
>> to you "RFC 4412
>>>>>>> 	> >(RPH) is the SIP mechanism to priority mark
>> SIP requests"?
>>>>>>> 	> >
>>>>>>> 	> >Further, I believe it is inappropriate to
>> prohibit endpoints
>>>>>>> 	> >from being able to set the esnet namespace.
>> I absolutely
>>>>>>> 	> >believe it will not be needed most of the
>> time, but I believe
>>>>>>> 	> >if someone does find a valid use for
>> endpoints to mark
>>>>>>> 	> >priority in SIP, this ID - once it has
>> become an RFC -- will
>>>>>>> 	> >have to be obsoleted with a new RFC saying the exact
>>>>> opposite.
>>>>>>> 	> >
>>>>>>> 	> >(color me confused ... over and over again)
>>>>>>> 	> >
>>>>>>> 	> >James
>>>>>>> 	> >
>>>>>>> 	> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>>>>>>> 	> >>Keith, please understand that the usage of RFC 4412
>>>>> for GETS and
>>>>>>> for
>>>>>>> 	> >>the type of emergency call we discuss here is
>>>>> different. Just
>>>>>>> looking
>>>>>>> 	> >>at the header and the name of the namespace is a bit
>>>>>>> 	> >artificial. I hope
>>>>>>> 	> >>you understand that.
>>>>>>> 	> >>
>>>>>>> 	> >> >-----Original Message-----
>>>>>>> 	> >> >From: DRAGE, Keith (Keith)
>>>>>>> [mailto:[email-masked]]
>>>>>>> 	> >> >Sent: 05 February, 2009 14:55
>>>>>>> 	> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
>>>>>>> Polk'; 'Tschofenig,
>>>>>>> 	> >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
>>>>>>> 	> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
>>>>>>> Meeting: Agenda (my
>>>>>>>
>>>>>>> 	> >> >mistake)
>>>>>>> 	> >> >
>>>>>>> 	> >> >Which is exactly what RFC 4412 specifies for all
>>>>> namespaces.
>>>>>>> 	> >> >
>>>>>>> 	> >> >regards
>>>>>>> 	> >> >
>>>>>>> 	> >> >Keith
>>>>>>> 	> >> >
>>>>>>> 	> >> >> -----Original Message-----
>>>>>>> 	> >> >> From: [email-masked]
>>>>> [mailto:[email-masked]]
>>>>>>> 	> >> >On Behalf
>>>>>>> 	> >> >> Of Brian Rosen
>>>>>>> 	> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
>>>>>>> 	> >> >> To: 'Hannes Tschofenig'; 'James M.
>> Polk'; 'Tschofenig,
>>>>>>> 	> >Hannes (NSN
>>>>>>> 	> >> >> - FI/Espoo)'; 'ECRIT'
>>>>>>> 	> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>>>>>>> Meeting: Agenda (my
>>>>>>> 	> >> >> mistake)
>>>>>>> 	> >> >>
>>>>>>> 	> >> >> The value is that in some networks
>> where priority for
>>>>>>> 	> >> >emergency calls
>>>>>>> 	> >> >> is appropriate, and appropriate
>> policing of marking is
>>>>>>> 	> >implemented,
>>>>>>> 	> >> >> emergency calls will receive resource priority.
>>>>>>> 	> >> >>
>>>>>>> 	> >> >> Not all networks would need policing.  Some
>>>>> will.  Policing
>>>>>>> could
>>>>>>> 	> >> >> be to Route header/R-URI content, but other
>>>>> criteria are
>>>>>>> possible.
>>>>>>> 	> >> >>
>>>>>>> 	> >> >> Not all networks will need resource priority
>>>>> for emergency
>>>>>>> calls.
>>>>>>> 	> >> >> Fine, ignore this marking/namespace.
>>>>>>> 	> >> >>
>>>>>>> 	> >> >> Brian
>>>>>>> 	> >> >> > -----Original Message-----
>>>>>>> 	> >> >> > From: Hannes Tschofenig
>>>>>>> [mailto:[email-masked]]
>>>>>>> 	> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>>>>>>> 	> >> >> > To: 'Brian Rosen'; 'James M. Polk';
>>>>> Tschofenig, Hannes
>>>>>>> (NSN -
>>>>>>> 	> >> >> > FI/Espoo); 'ECRIT'
>>>>>>> 	> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
>>>>>>> Meeting: Agenda (my
>>>>>>> 	> >> >> > mistake)
>>>>>>> 	> >> >> >
>>>>>>> 	> >> >> > I don't even see the value in permitting the
>>>>> endpoint todo
>>>>>>> the
>>>>>>> 	> >> >> > RPH marking.
>>>>>>> 	> >> >> > In addition to the security concerns
>> there is also the
>>>>>>> 	> >> >problem that
>>>>>>> 	> >> >> > there are more options to implement without
>>>>> an additional
>>>>>>> value.
>>>>>>> 	> >> >> >
>>>>>>> 	> >> >> > >-----Original Message-----
>>>>>>> 	> >> >> > >From: Brian Rosen [mailto:[email-masked]]
>>>>>>> 	> >> >> > >Sent: 05 February, 2009 00:03
>>>>>>> 	> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
>>>>> 'Tschofenig,
>>>>>>> 	> >> >> Hannes (NSN -
>>>>>>> 	> >> >> > >FI/Espoo)'; 'ECRIT'
>>>>>>> 	> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual
>> Interim Meeting:
>>>>>>> Agenda (my
>>>>>>> 	> >> >> > mistake)
>>>>>>> 	> >> >> > >
>>>>>>> 	> >> >> > >Hannes
>>>>>>> 	> >> >> > >
>>>>>>> 	> >> >> > >This matches my understanding
>> precisely.  We wish to
>>>>>>> 	> >> >> permit endpoints
>>>>>>> 	> >> >> > >to mark. We do not require it, and
>> don't necessarily
>>>>>>> expect it
>>>>>>> 	> >> >> > >in many (even
>>>>>>> 	> >> >> > >most) cases.  We don't wish to see the
>>>>> document prohibit
>>>>>>> it.
>>>>>>> 	> >> >> > >We all seem to agree it has value within the
>>>>> Emergency
>>>>>>> 	> >> >Services IP
>>>>>>> 	> >> >> > >Networks.
>>>>>>> 	> >> >> > >
>>>>>>> 	> >> >> > >Brian
>>>>>>> 	> >> >> > >
>>>>>>> 	> >> >> > >> -----Original Message-----
>>>>>>> 	> >> >> > >> From: [email-masked]
>>>>>>> [mailto:[email-masked]]
>>>>>>> 	> >> >> > >On Behalf
>>>>>>> 	> >> >> > >> Of James M. Polk
>>>>>>> 	> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
>>>>>>> 	> >> >> > >> To: Hannes Tschofenig; Tschofenig,
>> Hannes (NSN -
>>>>>>> 	> >> >> FI/Espoo); 'ECRIT'
>>>>>>> 	> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>>>>>>> Meeting:
>>>>>>> 	> >Agenda (my
>>>>>>> 	> >> >> > >> mistake)
>>>>>>> 	> >> >> > >>
>>>>>>> 	> >> >> > >> At 02:37 PM 2/4/2009, Hannes
>> Tschofenig wrote:
>>>>>>> 	> >> >> > >> > > James wrote:
>>>>>>> 	> >> >> > >> > >> you are the _lone_ voice not
>>>>> supporting this ID,
>>>>>>> 	> >> >> > >> >
>>>>>>> 	> >> >> > >> >Listening to the audio recording of past
>>>>> meetings I
>>>>>>> have to
>>>>>>> 	> >> >> > >say that
>>>>>>> 	> >> >> > >> >I
>>>>>>> 	> >> >> > >> was
>>>>>>> 	> >> >> > >> >not the only persons raising
>> concerns about the
>>>>>>> document.
>>>>>>> 	> >> >> > >> >That was probably the reason why you
>>>>> agreed to limit
>>>>>>> the
>>>>>>> 	> >> >> > >scope of the
>>>>>>> 	> >> >> > >> >document (which you didn't later do) to
>>>>> get folks to
>>>>>>> agree
>>>>>>> 	> >> >> > >to make it
>>>>>>> 	> >> >> > >> a WG
>>>>>>> 	> >> >> > >> >item.
>>>>>>> 	> >> >> > >>
>>>>>>> 	> >> >> > >> re-listen to the audio please
>>>>>>> 	> >> >> > >>
>>>>>>> 	> >> >> > >> Ted's concerns were consistent with most
>>>>>>> (all?) other
>>>>>>> 	> >> >> concerns --
>>>>>>> 	> >> >> > >> which were based on the premise of whether
>>>>> or not the
>>>>>>> 	> >> >> UAC should be
>>>>>>> 	> >> >> > >> trusted to initiate the marking on the
>>>>> INVITE.  The
>>>>>>> most
>>>>>>> 	> >> >> > >> recent version has backed off this
>> to a "can" --
>>>>>>> meaning not
>>>>>>> 	> >> >prohibited
>>>>>>> 	> >> >> > >> (i.e., no 2119 text).  I also backed off
>>>>> the text in
>>>>>>> the
>>>>>>> 	> >> >> SP domain
>>>>>>> 	> >> >> > >> part to "can", such that there is
>> no 2119 text
>>>>>>> 	> >> >mandating or even
>>>>>>> 	> >> >> > >> recommending its usage there. I also do
>>>>> not prohibit
>>>>>>> its
>>>>>>> 	> >> >> > >use, based on
>>>>>>> 	> >> >> > >> local policy.  Keith has come forward with
>>>>> the specific
>>>>>>>
>>>>>>> 	> >> >> > >> request that non-ESInet networks be
>>>>> allowed to mark and
>>>>>>> pay
>>>>>>> 	> >> >attention to
>>>>>>> 	> >> >> > >> this priority indication -- with IMS as
>>>>> the specific
>>>>>>> example
>>>>>>> 	> >> >> > >> he wishes to have this valid for.
>>>>>>> 	> >> >> > >>
>>>>>>> 	> >> >> > >> Where there is no disagreement, save for
>>>>> your recent
>>>>>>> 	> >> >> > >pushback - is in
>>>>>>> 	> >> >> > >> the ESInet, which is where Brian
>> has requested it's
>>>>>>> 	> >> >> > >definition in the
>>>>>>> 	> >> >> > >> IETF on behalf of NENA.  He's the i3 WG
>>>>> chair within
>>>>>>> 	> >> >> NENA, and if
>>>>>>> 	> >> >> > >> he asks for it, are you going to say you
>>>>> know better
>>>>>>> than he?
>>>>>>> 	> >> >> > >>
>>>>>>> 	> >> >> > >>
>>>>>>> 	> >> >> > >> >Btw, I not disagreeing with the document
>>>>> as such. I
>>>>>>> 	> >> >just want to
>>>>>>> 	> >> >> > the
>>>>>>> 	> >> >> > >> scope
>>>>>>> 	> >> >> > >> >to change. The usage of RPH
>> within the emergency
>>>>>>> 	> >> >> services network
>>>>>>> 	> >> >> > is
>>>>>>> 	> >> >> > >> fine
>>>>>>> 	> >> >> > >> >for me. I may get convinced to start the
>>>>> RPH marking
>>>>>>> from
>>>>>>> 	> >> >> > >the the VSP
>>>>>>> 	> >> >> > >> >towards the PSAP. I feel uneasy about the
>>>>> end host
>>>>>>> doing
>>>>>>> 	> >> >> > >the marking.
>>>>>>> 	> >> >> > >>
>>>>>>> 	> >> >> > >> please read what I wrote above, and then
>>>>> re-read the
>>>>>>> 	> >> >most recent
>>>>>>> 	> >> >> > >> version of the ID. I don't have endpoints
>>>>> that SHOULD
>>>>>>> or
>>>>>>> 	> >> >> MUST mark
>>>>>>> 	> >> >> > >> anything wrt RPH.  I also don't want to
>>>>> prohibit it,
>>>>>>> 	> >> >> because there
>>>>>>> 	> >> >> > >> might be cases (that I don't know
>> of) of valid uses
>>>>>>> 	> >> >> under certain
>>>>>>> 	> >> >> > >> circumstances.  Figure 1 is very clear
>>>>> that there are 3
>>>>>>> 	> >> >> networking
>>>>>>> 	> >> >> > >> parts to consider
>>>>>>> 	> >> >> > >>
>>>>>>> 	> >> >> > >> #1 - from the endpoint
>>>>>>> 	> >> >> > >> #2 - within the VSP
>>>>>>> 	> >> >> > >> #3 - within the ESInet
>>>>>>> 	> >> >> > >>
>>>>>>> 	> >> >> > >> the most recent ID version has "can" for
>>>>> #s 1 and 2,
>>>>>>> and
>>>>>>> 	> >> >> > >2119 language
>>>>>>> 	> >> >> > >> offering those supporting this
>>>>> specification will have
>>>>>>> RPH
>>>>>>> 	> >> >> > >> adherence within #3 (the ESInet).
>>>>>>> 	> >> >> > >>
>>>>>>> 	> >> >> > >> What other scope changes do you want,
>>>>> because I haven't
>>>>>>> 	> >> >> heard them.
>>>>>>> 	> >> >> > >>
>>>>>>> 	> >> >> > >> I only heard you claim in email during the
>>>>> last IETF
>>>>>>> and in
>>>>>>> 	> >> >> > >the ECRIT
>>>>>>> 	> >> >> > >> session that RPH should not be
>> used for priority
>>>>>>> marking
>>>>>>> 	> >> >> requests.
>>>>>>> 	> >> >> > >> This is something Keith (SIP WG
>> chair) voiced his
>>>>>>> opposition
>>>>>>> 	> >> >> > >> to your views regarding creating a second
>>>>> means for SIP
>>>>>>> to
>>>>>>> 	> >> >priority
>>>>>>> 	> >> >> > >> mark request "when SIP already has one
>>>>> interoperable
>>>>>>> way to
>>>>>>> 	> >> >> > >> accomplish this... it's call the RP header
>>>>> mechanism".
>>>>>>> 	> >> >> > >>
>>>>>>> 	> >> >> > >> >I don't see advantages -- only
>> disadvantages.
>>>>>>> 	> >> >> > >> >
>>>>>>> 	> >> >> > >> >Ciao
>>>>>>> 	> >> >> > >> >Hannes
>>>>>>> 	> >> >> > >>
>>>>>>> 	> >> >> > >>
>> _______________________________________________
>>>>>>> 	> >> >> > >> Ecrit mailing list
>>>>>>> 	> >> >> > >> [email-masked]
>>>>>>> 	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>> 	> >> >> > >
>>>>>>> 	> >> >>
>>>>>>> 	> >> >> _______________________________________________
>>>>>>> 	> >> >> Ecrit mailing list
>>>>>>> 	> >> >> [email-masked]
>>>>>>> 	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>> 	> >> >>
>>>>>>> 	> >> >
>>>>>>> 	> >
>>>>>>> 	>
>>>>>>> 	> _______________________________________________
>>>>>>> 	> Ecrit mailing list
>>>>>>> 	> [email-masked]
>>>>>>> 	> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ecrit mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ecrit mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>
>
> ------------------------------------------------------------------------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------------------------
> [mf2]
>
>

Date: Fri, 6 Feb 2009 13:27:54 -0800
To: Henning Schulzrinne <[email-masked]>, "Winterbottom, James" <[email-masked]>
From: Ted Hardie <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

At 1:05 PM -0800 2/6/09, Henning Schulzrinne wrote:
>There's another problem with the "it doesn't hurt argument". Assume
>for a moment we have a "UA MAY include RPH" wording. There are now two
>cases:

Is it ever a protocol error for a SIP entity to include RPH?  Or is it always
the expectation that it generally might be included, and may be roundly
ignored?

If the latter is true, then the key thing is for those interested in having this
work in a specific context to publish the namespace they will use in that
context.  Others in similar contexts may adopt that, if they like.   But
the UA/general SIP handling isn't different here just because it is an
emergency call.   It's only different in contexts where that RPH namespace
is in use, and only because of an agreement to do so; presumably the interested
party could assign RPH values to non-emergency calls too, so it isn't a
tight linkage between emergency-special handling.

I'm just trying to figure out whether we're introducing a new situation
in which the call processing for emergency calls is different.  We've
agreed previously to try to minimize those.  If the call processing here
is the standard RPH processing (which seems to be "your mileage may
vary"), then we probably don't even need to call it out.

Possibly confused,
				Ted

>(1) All UAs implement it.
>
>(2) Only some UAs implement it.
>
>(1) seems unlikely for a MAY. If (2) occurs, we have the choice
>between two undesirable outcomes:
>
>(a) some UAs that are otherwise compliant get worse service just
>because they didn't include the RPH;
>
>OR
>
>(b) the proxy has to look for the service URN to give the call the
>appropriate treatment, thus obviating any advantage of having the
>header, yet incurring more complicated processing logic.
>
>
>I have no objection to whatever markings people want to apply to calls
>within an ESN - that's largely a private matter.
>
>Henning
>
>On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote:
>
>> Hi All,
>>
>> I have followed thi thread with some interest and I struggling to
>> see a use case for the
>> providing RPH for emergency calls from the end-point.
>>
>> The reference-model call in ECRIT, for better or worse, is for all
>> calls to go back through a home-VSP.
>> We placed quite a lot of emphasis, largely for traffing reasons, for
>> the VSP to be able to verify that
>> a call is in fact an emergency call. This is done by the proxy
>> taking the inband location, doing a LoST
>> query with the provided URN, and verifying that the resulting
>> destination URI is the same as the destination
>> URI provide in the SIP INVITE. My understanding was that VSPs would
>> always do this check so they could
>> tell if they could bill for the call or not, and because the VSP can
>> be use that the call is an emergency call
>> it can apply any special priorities that may be applicable. This
>> obviates the need for RPH from the end-point
>> to the network.
>>
>> This leaves us with the argument of "it doesn't hurt to it", which
>> is not a good reason to write a specification.
>> It was intimated on the geopriv mailing list last year that great
>> pains had been taken to keep SIP with in the
>> MTU limits of UDP over Ethernet (http://www.ietf.org/mail-archive/web/geopriv/current/msg06120.html
>> ). Assuming
>> that this is the case, perhaps there is harm in including
>> information that we know will be ignored.
>>
>> Cheers
>> James
>>
>>
>>
>> -----Original Message-----
>> From: [email-masked] on behalf of Hannes Tschofenig
>> Sent: Fri 2/6/2009 12:33 PM
>> To: 'Brian Rosen'; 'Henning Schulzrinne'
>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
>> Subject: Re: [Ecrit] RPH
>>
>> To the story short here is the code for the proxy:
>>
>> ---------------------
>>
>> IF emergency call was recognized THEN
>>    execute emergency call specific procedures (priority queuing,
> > preemption, fetch location, determine routing, do funny QoS things &
>> co)
>> ELSE
>>    normal call handling procedures.
>>
>> ---------------------
>>
>> If you can make this differentiation between an emergency call and a
>> regular
>> call then you can also do everything that is necessary for emergency
>> call
>> handling.
>>
>> Brian + Keith: Please tell me that we cannot do the above with our
>> currently
>> specified mechanisms.
>>
>> Ciao
>> Hannes
>>
>>> -----Original Message-----
>>> From: Brian Rosen [mailto:[email-masked]]
>>> Sent: 06 February, 2009 17:49
>>> To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
>>> Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
>>> Subject: RE: [Ecrit] RPH
>>>
>>> I agree that not all networks will permit (or pay attention
>>> to) a priority request from an end device.
>>>
>>> No one has asked for that.
>>>
>>> The namespace request has several uses, one of which is within
>>> an emergency services IP network, one of which is between
>>> elements within a public network controlled by the operator,
>>> and one of which is an endpoint request for resource priority.
>>>
>>> Those of us requesting this work proceed are happy if the
>>> endpoint part is simply left as possible (MAY), and, speaking
>>> for myself, having the draft discuss the security implications
>>> of endpoint marking is reasonable.
>>>
>>> Having discussed this issue with an implementation team who
>>> worked on MLPP systems, I am confident I know what I'm talking
>>> about, but YMMV.  The fact that you could, if you wanted to,
>>> give resource priority to a call you decided, however you
>>> decided, was an emergency call is an implementation decision,
>>> and not subject to standardization.
>>>
>>> RPH is the IETF standard way for one entity to request
>>> resource priority of another entity in a SIP system.  We're
>>> asking for a namespace to use that within the domain of
>>> emergency calls.  That is, I think, a VERY reasonable request.
>>>
>>> Brian
>>>
>>>> -----Original Message-----
>>>> From: Henning Schulzrinne [mailto:[email-masked]]
>>>> Sent: Friday, February 06, 2009 10:33 AM
>>>> To: Hannes Tschofenig
>>>> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>>>> Subject: Re: [Ecrit] RPH
>>>>
>>>> To chime in here:
>>>>
>>>> I don't think it's productive to simply state that 4412
>>> doesn't worry
>>>> about authorization, so we shouldn't either (simplifying a bit).
>>>> Authorization was discussed repeatedly, and the general
>>> assumption was
>>>> that there were two conditions: Either the user invoking resource-
>>>> priority was well known and had a set of permissions that could be
>>>> checked in real time or there are ways to deal with abuse after the
>>>> fact in ways that deter abuse (the court-martial kind of thing in a
>>>> military context).
>>>>
>>>> The RFC 4412 security consideration (11.2) call this out in pretty
>>>> strong language:
>>>>
>>>>  Prioritized access to network and end-system resources imposes
>>>>    particularly stringent requirements on authentication and
>>>>    authorization mechanisms, since access to prioritized
>>> resources may
>>>>    impact overall system stability and performance and not
>>> just result
>>>>    in theft of, say, a single phone call.
>>>> Thus, the question is whether we have such strong authentication in
>>>> emergency calling. In some cases, such as residential fixed line
>>>> deployments where ISP = VSP, we're probably pretty close, in others,
>>>> such as prepaid cell phones or hot spots or VSP-only providers, we
>>>> aren't.
>>>>
>>>> The other point that I think Hannes is making is that the
>>> information
>>>> is either redundant or dangerous. If a processing element recognizes
>>>> the call as being an emergency call, it can apply whatever treatment
>>>> it deems appropriate and doesn't need additional information. If it
>>>> doesn't or can't, using just the RPH can be rather dangerous unless
>>>> that element can be reasonably certain that there is strong
>>>> authentication and recourse.
>>>>
>>>> I don't buy the argument that somehow finding the RPH is faster than
>>>> just looking for the identifier. Thus, given that the information is
> >>> either redundant or dangerous, I fail to see the advantage.
>>>>
>>>> Henning
>>>>
>>>>
>>>> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
>>>>
>>>>> Don't get hung up on the details. There are ways to optimize it.
>>>>> That was
>>>>> not the point of the code example.
>>>>>
>>>>> The problem that my pseudo code should have shown you is that you
>>>>> * don't gain anything with RPH marking for the emergency call case
>>>>> from the SIP UA towards the outbound proxy since the functionality
>>>>> is already provide otherwise. How often does the proxy need to get
>>>>> told that this is an emergency call todo whatever emergency call
>>>>> handling procedures are necessary?
>>>>> * you only introduce fraud problems (if you are not
>>> careful and you
>>>>> understand the security stuff well enough)
>>>>>
>>>>> If you can point me to people who implement the RPH emergency call
>>>>> case please do so. I would love to talk to them.
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>>
>>>>> PS: You need to parse incoming messages to some extend so that you
>>>>> know what it contains :-) Only looking for the emergency
>>> RPH header
>>>>> (and not for the Service URN/dial
>>>>> string) would exactly be the DoS/fraud attack I am worried about.
>>>>> That's the thing Henning was worried about (go and listen to the
>>>>> past meeting minutes).
>>>>>
>>>>>
>>>>>> Hannes
>>>>>>
>>>>>> You need to talk to people who really implement this kind
>>> of thing.
>>>>>> You are way off.
>>>>>>
>>>>>> When you implement a resource priority system, the point of doing
>>>>>> that is to look though the queue of work and pick out the
>>> ones with
>>>>>> priority, handling them first.  You don't do all the parsing, you
>>>>>> don't do a lot of decision tree.
>>>>>>
>>>>>> Typically:
>>>>>> Check for DoS things, like too big messages, etc Do a quick scan
>>>>>> for the RPH message header If found:
>>>>>> Parse the message
>>>>>> Determine validity
>>>>>> Determine priority
>>>>>> Queue on the correct work queue
>>>>>>
>>>>>> The first two actions have to be very fast.  Anyone who builds a
>>>>>> SIP thingie will tell you that parsing is one of the big cycle
>>>>>> consumers: if you have to parse every message BEFORE you
>>> determine
>>>>>> priority, you can't give much resource priority.
>>>>>> Once you get the whole message parsed, you might as well finish
>>>>>> working on it, because you've done so much of the work.
>>>>>> OTHOH, finding the end-of-message delimiter and doing a quick
>>>>>> string search for RPH is fast.  If you are doing
>>> priority, you need
>>>>>> to keep all the priority processing pretty uniform, and pretty
>>>>>> simple, or you tend to spend too much time futzing around
>>> figuring
>>>>>> out what to do.  You put all the priority related stuff together,
>>>>>> and use as much common code as possible.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>> On Behalf
>>>>>>> Of Hannes Tschofenig
>>>>>>> Sent: Friday, February 06, 2009 8:41 AM
>>>>>>> To: 'Hannes Tschofenig'; 'Janet P Gunn'
>>>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-
>>>>>>> [email-masked]
>>>>>>> Subject: [Ecrit] RPH
>>>>>>>
>>>>>>> Over lunch I was also thinking how an outbound proxy would
>>>> implement
>>>>>>> some of the emergency procedures. Here are some thoughts:
>>>>>>>
>>>>>>> ---------------------------------------------------
>>>>>>>
>>>>>>> // Process incoming message
>>>>>>> Parse(msg);
>>>>>>>
>>>>>>> // SIP INVITE without Service URN
>>>>>>> // legacy devices
>>>>>>> If (recognize-dialstring(msg)==TRUE) {  // we got an emergency
>>>>>>> call going on  emergency=TRUE;  if (dialstring(msg) == 911)
>>>>>>> serviceURN=urn:service:sos; } else if
>>>>>>> (recognize-serviceURN(msg)==TRUE) {  // oh. A updated
>>> device that
>>>>>>> has a service URN attached to the
>>>> call
>>>>>>> serviceURN=retrieve_ServiceURN(msg);
>>>>>>> emergency=TRUE;
>>>>>>> } else {
>>>>>>> // standard SIP message
>>>>>>> // regular processing
>>>>>>> process(msg);
>>>>>>> emergency=FALSE;
>>>>>>> }
>>>>>>>
>>>>>>> If (emergency == TRUE) {
>>>>>>>  // make sure that the emergency call does not get
> >> dropped on the
>>>>>>> floor
>>>>>>>  // skip authorization failures
>>>>>>>  // give the call a special treatment
>>>>>>>  lots-of-code-here();
>>>>>>>
>>>>>>>  // trigger all the QoS signaling you have in the
>>> network to make
>>>>>>> James happy
>>>>>>>  trigger-qos();
>>>>>>>
>>>>>>>  // query location
>>>>>>>  location=retrieve-location();
>>>>>>>
>>>>>>>  // determine next hop
>>>>>>>  next-hop=lost(location, serviceURN)
>>>>>>>
>>>>>>>  // attach RPH marking to outgoing msg to make James and
>>>>>> Keith happy
>>>>>>>  msg=add(msg, RPH);
>>>>>>>
>>>>>>>  send(msg, next-hop);
>>>>>>> }
>>>>>>>
>>>>>>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
>>>>>>>  // all the emergency related processing done already upfront
>>>>>>>  // hence I log something.
>>>>>>>  log(RPH_WAS_PRESENT_JUHU);
>>>>>>> } else if ((rph-present(msg) == TRUE) && (emergency ==
>>> FALSE)) {
>>>>>>> // this is not an emergency call  // this is something
>>> like GETS
>>>>>>> result=special-authorization-procedure(user);
>>>>>>>
>>>>>>> if (result == AUTHORIZED) {
>>>>>>>   // do some priority & preemption thing here.
>>>>>>>   // trigger all the QoS you have
>>>>>>>   lots-of-code-here();
>>>>>>> } else {
>>>>>>>   log("NOT AUTHORIZED; don't DoS my network");  } } else {  //
>>>>>>> don't need todo any RPH processing  // this includes the case
>>>>>>> where the call was an emergency call but the RPH
>>>>>>>
>>>>>>> // marking was not there.
>>>>>>> nothing();
>>>>>>> }
>>>>>>>
>>>>>>> ---------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> Ciao
>>>>>>> Hannes
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>>>> Behalf Of Hannes Tschofenig
>>>>>>>> Sent: 06 February, 2009 15:07
>>>>>>>> To: 'Janet P Gunn'
>>>>>>>> Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
>>>>>>> FI/Espoo)
>>>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
>>>>>>>>
>>>>>>>> Who would define something that could prevent DoS problems?
>>>>>>>>
>>>>>>>> ________________________________
>>>>>>>>
>>>>>>>>         From: Janet P Gunn [mailto:[email-masked]]
>>>>>>>>         Sent: 06 February, 2009 14:11
>>>>>>>>         To: Hannes Tschofenig
>>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
>>>>>>>> [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
>>>> 'James
>>>>>>>> M. Polk'
>>>>>>>>         Subject: Re: [Ecrit] ECRIT Virtual Interim
>>> Meeting: Agenda (RPH)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>         But there is nothing IN RFC4412 that specifically
>>>>>> addresses how to
>>>>>>>> prevent any particular namespace being used for DoS.  Anyone/any
>>>> UA
>>>>>>>> can ATTEMPT to invoke priority treatment by attaching RPH.  For
>>>> all
>>>>>>>> of the 4412 namespaces, as with the new proposed namespace, the
>>>>>>>> mechanisms for preventing DoS are not specified in the
>>>>>> document that
>>>>>>>> defines the namespace.
>>>>>>>> They are/will be specified elsewhere.
>>>>>>>>
>>>>>>>>         Janet
>>>>>>>>
>>>>>>>>         This is a PRIVATE message. If you are not the intended
>>>>>> recipient,
>>>>>>>> please delete without copying and kindly advise us by e-mail of
>>>> the
>>>>>>>> mistake in delivery.
>>>>>>>>         NOTE: Regardless of content, this e-mail shall not
>>>>>> operate to bind
>>>>>>>> CSC to any order or other contract unless pursuant to explicit
>>>>>>>> written agreement or government initiative expressly permitting
>>>> the
>>>>>>>> use of e-mail for such purpose.
>>>>>>>>
>>>>>>>>         [email-masked] wrote on 02/06/2009 04:21:51 AM:
>>>>>>>>
>>>>>>>>         > Hi James,
>>>>>>>>         >
>>>>>>>>         > I have read RFC 4412 and also the GETS/MLPP IETF
>>>>>> documents. What I
>>>>>>>> would
>>>>>>>>         > like to point out is that there is more than just a
>>>>>> header and
>>>>>>>> values within
>>>>>>>>         > the header that have to be considered in order to
>>>>>> make a judgement
>>>>>>>> of what
>>>>>>>>         > is appropriate and what isn't. There is an
>>>>>> architectural question
>>>>>>>> and
>>>>>>>>         > whether the environment we are using the stuff is
>>>>>> indeed providing
> >>>>>>> the
>>>>>>>>         > properties you need for the solution to be
>>> appropriate.
>>>>>>>>         >
>>>>>>>>         > Let me describe in more detail what I meant (and
>>>>>> please correct me
>>>>>>>> if I am
>>>>>>>>         > wrong).
>>>>>>>>         >
>>>>>>>>         > Getting priority for SIP requests when using a GETS
>>>>>> alike scenario
>>>>>>>> means
>>>>>>>>         > that the entity that issues the request is specially
>>>>>> authorized
>>>>>>>> since
>>>>>>>>         > otherwise you introduce a nice denial of
>>> service attack. This
>>>>>>>> authorization
>>>>>>>>         > is tied to the entity that makes the request. For
>>>>>> example, the
>>>>>>>> person is
>>>>>>>>         > working for the government and has special rights.
>>>>>>>> James Bond as a (not so)
>>>>>>>>         > secret agent might have these rights.
>>>>>>>>         >
>>>>>>>>         > The emergency services case
>>> (citizen-to-authority) is a bit
>>>>>>>> different as
>>>>>>>>         > there aren't really special rights with respect to
>>>>>> authorization
>>>>>>>> tied to
>>>>>>>>         > individuals. Instead, the fact that something is an
>>>>>> emergency is
>>>>>>>> purely a
>>>>>>>>         > judgement of the human that dials a special number.
>>>>>>>> To deal with fraud, we
>>>>>>>>         > discussed in the group on what we can actually do to
>>>>>> ensure that
>>>>>>>> end users
>>>>>>>>         > do not bypass security procedures (such as
>>>>>> authorization checks,
>>>>>>>> charging
>>>>>>>>         > and so on). Part of this investigation was
>>> the publication of
>>>>>>>>         > http://www.ietf.org/rfc/rfc5069.txt that also
>>> describes this
>>>>>>>> issue.
>>>>>>>>         >
>>>>>>>>         > So, imagine the implementation of a SIP proxy (and we
>>>>>> implemented
>>>>>>>> that
>>>>>>>>         > stuff) that receives a call that contains a Service
>>>>>> URN. The code
>>>>>>>> branches
>>>>>>>>         > into a special mode where everything is done
>>> so that the call
>>>>>>>> receives
>>>>>>>>         > appropriate treatment and does not get dropped on the
>>>>>> floor. The
>>>>>>>> way how the
>>>>>>>>         > Service URN is placed in the message ensures that the
>>>>>> call cannot
>>>>>>>> go to my
>>>>>>>>         > friend (instead of the PSAP) unless the end host ran
>>>>>> LoST already.
>>>>>>>> In the
>>>>>>>>         > latter case, we discussed this also on the list for a
>>>>>> while and
>>>>>>>> Richard even
>>>>>>>>         > wrote a draft about it in the context of the
>>> location hiding
>>>>>>>> topic, we said
>>>>>>>>         > that the proxy would have to run LoST if he
>>> cares about a
>>>>>>>> potential
>>>>>>>>         > fraudulent usage.
>>>>>>>>         >
>>>>>>>>         > So, what do we need todo in order to provide
>>> secure RFC 4412
>>>>>>>> functionality
>>>>>>>>         > in our context?
>>>>>>>>         >
>>>>>>>>         > Do you think that the current text in
>>>>>>>>         >
>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>>>>>>>> gency-rph-nam
>>>>>>>>         > espace-00.txt reflects any of the
>>> above-described issues:
>>>>>>>>         > "
>>>>>>>>         >    The Security considerations that apply to RFC 4412
>>>>>>>> [RFC4412]
>>>>>>>> apply
>>>>>>>>         >    here.  This document introduces no new security
>>>>>>>> issues relative
>>>>>>>> to
>>>>>>>>         >    RFC 4412.
>>>>>>>>         > "
>>>>>>>>         >
>>>>>>>>         > From various discussions in GEOPRIV I recall
>>> that you are
>>>>>>>> super-sensitive
>>>>>>>>         > regarding security and privacy. For some reasons you
>>>>>> don't seem to
>>>>>>>> have the
>>>>>>>>         > same concerns here. I would like to
>>> understand your reasoning.
>>>>>>>>         >
>>>>>>>>         > Please also do me another favor: Don't always say
>>>>>> that I don't
>>>>>>>> understand
>>>>>>>>         > the subject. Even if that would be the case it isn't
>>>>>> particular
>>>>>>>> fair given
>>>>>>>>         > that different folks had to educate you on other
>>>>>> topics in the
>>>>>>>> past as well.
>>>>>>>>         > Additionally, if you listen to the audio recordings
>>>>>> then you will
> >>>>>>> notice
>>>>>>>>         > that Henning, Ted, and Jon do not seem to understand
>>>>>> the issue
>>>>>>>> either as
>>>>>>>>         > they have raised similar issues during the
>>> F2F meetings.
>>>>>>>>         >
>>>>>>>>         > Ciao
>>>>>>>>         > Hannes
>>>>>>>>         >
>>>>>>>>         >
>>>>>>>>         > >Hannes - I believe it is you who do not understand
>>>>>> RFC 4412 --
>>>>>>>>         > >and many of us are trying to get that
>>> through to you, but you
>>>>>>>>         > >don't seem to want to listen/read.
>>>>>>>>         > >
>>>>>>>>         > >RFC 4412 is *for* priority marking SIP requests,
>>>>>>>>         > >
>>>>>>>>         > >One use is GETS.
>>>>>>>>         > >
>>>>>>>>         > >One use is MLPP.
>>>>>>>>         > >
>>>>>>>>         > >These examples are in RFC 4412 because there
>>> were specific
>>>>>>>>         > >namespaces being created for the IANA section of
>>>>>> that document.
>>>>>>>>         > >
>>>>>>>>         > >Reading the whole document, you will see
>>> that RPH can be
>>>>>>>>         > >specified for other uses than GETS or MLPP
>>> specifically.
>>>>>>>>         > >
>>>>>>>>         > >I knew when I wrote RFC 4412 that one day we
>>> would specify a
>>>>>>>>         > >namespace for ECRIT (the "esnet" namespace
>>> now) -- but I also
>>>>>>>>         > >knew it was premature for RFC 4412 to
>>> incorporate that
>>>>>>>>         > >namespace, that a future doc to RFC 4412
>>> would have to be
>>>>>>>>         > >written to do this. Brian and I talked about
>>> this at the
>>>>>>>>         > >original NENA meeting that created the IP WGs there
>>>>>> (in August
>>>>>>>>         > >of 03).  We both agreed we should wait until it was
>>>>>>>>         > >appropriate to the work in the IETF to
>>> submit this document
>>>>>>>>         > >that is now
>>>>>>>>         >
>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>>>>>>>>         > >gency-rph-namespace-00.txt
>>>>>>>>         > >
>>>>>>>>         > >Yet, you seem to want to use some additional
>>> mechanism to
>>>>>>>>         > >indicate priority of a call in SIP.  That
>>> means you want to
>>>>>>>>         > >introduce a second way to accomplish this in SIP.
>>>>>>>> Why do you
>>>>>>>>         > >want to promote a separate way to do something SIP
>>>>>> has already
>>>>>>>>         > >defined? That will cause interoperability issues and
>>>>>> we both know
>>>>>>>> that.
>>>>>>>>         > >
>>>>>>>>         > >You've said to me (and others) that you
>>> believe RPH is just
>>>>>>>>         > >another way to accomplish what sos or a URI can
>>>>>> indicate - and
>>>>>>>>         > >you're wrong.  Your way would be
>>> _the_second_way_to_do_it,
>>>>>>>>         > >because SIP already considers RPH to be
>>> *the*way* to priority
>>>>>>>>         > >mark SIP requests.
>>>>>>>>         > >
>>>>>>>>         > >If you don't believe me (no comment), then
>>> why do you not
>>>>>>>>         > >believe the SIP WG chair (who knows more
>>> about SIP than both
>>>>>>>>         > >of us) - who, on this thread, has again said
>>> to you "RFC 4412
>>>>>>>>         > >(RPH) is the SIP mechanism to priority mark
>>> SIP requests"?
>>>>>>>>         > >
>>>>>>>>         > >Further, I believe it is inappropriate to
>>> prohibit endpoints
>>>>>>>>         > >from being able to set the esnet namespace.
>>> I absolutely
>>>>>>>>         > >believe it will not be needed most of the
>>> time, but I believe
>>>>>>>>         > >if someone does find a valid use for
>>> endpoints to mark
>>>>>>>>         > >priority in SIP, this ID - once it has
>>> become an RFC -- will
>>>>>>>>         > >have to be obsoleted with a new RFC saying the exact
>>>>>> opposite.
>>>>>>>>         > >
>>>>>>>>         > >(color me confused ... over and over again)
>>>>>>>>         > >
>>>>>>>>         > >James
>>>>>>>>         > >
>>>>>>>>         > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>>>>>>>>         > >>Keith, please understand that the usage of RFC 4412
>>>>>> for GETS and
>>>>>>>> for
>>>>>>>>         > >>the type of emergency call we discuss here is
>>>>>> different. Just
>>>>>>>> looking
>>>>>>>>         > >>at the header and the name of the namespace is a bit
> >>>>>>>         > >artificial. I hope
>>>>>>>>         > >>you understand that.
>>>>>>>>         > >>
>>>>>>>>         > >> >-----Original Message-----
>>>>>>>>         > >> >From: DRAGE, Keith (Keith)
>>>>>>>> [mailto:[email-masked]]
>>>>>>>>         > >> >Sent: 05 February, 2009 14:55
>>>>>>>>         > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
>>>>>>>> Polk'; 'Tschofenig,
>>>>>>>>         > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
>>>>>>>>         > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
>>>>>>>> Meeting: Agenda (my
>>>>>>>>
>>>>>>>>         > >> >mistake)
>>>>>>>>         > >> >
>>>>>>>>         > >> >Which is exactly what RFC 4412 specifies for all
>>>>>> namespaces.
>>>>>>>>         > >> >
>>>>>>>>         > >> >regards
>>>>>>>>         > >> >
>>>>>>>>         > >> >Keith
>>>>>>>>         > >> >
>>>>>>>>         > >> >> -----Original Message-----
>>>>>>>>         > >> >> From: [email-masked]
>>>>>> [mailto:[email-masked]]
>>>>>>>>         > >> >On Behalf
>>>>>>>>         > >> >> Of Brian Rosen
>>>>>>>>         > >> >> Sent: Wednesday, February 04, 2009 10:19 PM
>>>>>>>>         > >> >> To: 'Hannes Tschofenig'; 'James M.
>>> Polk'; 'Tschofenig,
>>>>>>>>         > >Hannes (NSN
>>>>>>>>         > >> >> - FI/Espoo)'; 'ECRIT'
>>>>>>>>         > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>>>>>>>> Meeting: Agenda (my
>>>>>>>>         > >> >> mistake)
>>>>>>>>         > >> >>
>>>>>>>>         > >> >> The value is that in some networks
>>> where priority for
>>>>>>>>         > >> >emergency calls
>>>>>>>>         > >> >> is appropriate, and appropriate
>>> policing of marking is
>>>>>>>>         > >implemented,
>>>>>>>>         > >> >> emergency calls will receive resource priority.
>>>>>>>>         > >> >>
>>>>>>>>         > >> >> Not all networks would need policing.  Some
>>>>>> will.  Policing
>>>>>>>> could
>>>>>>>>         > >> >> be to Route header/R-URI content, but other
>>>>>> criteria are
>>>>>>>> possible.
>>>>>>>>         > >> >>
>>>>>>>>         > >> >> Not all networks will need resource priority
>>>>>> for emergency
>>>>>>>> calls.
>>>>>>>>         > >> >> Fine, ignore this marking/namespace.
>>>>>>>>         > >> >>
>>>>>>>>         > >> >> Brian
>>>>>>>>         > >> >> > -----Original Message-----
>>>>>>>>         > >> >> > From: Hannes Tschofenig
>>>>>>>> [mailto:[email-masked]]
>>>>>>>>         > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>>>>>>>>         > >> >> > To: 'Brian Rosen'; 'James M. Polk';
>>>>>> Tschofenig, Hannes
>>>>>>>> (NSN -
>>>>>>>>         > >> >> > FI/Espoo); 'ECRIT'
>>>>>>>>         > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
>>>>>>>> Meeting: Agenda (my
>>>>>>>>         > >> >> > mistake)
>>>>>>>>         > >> >> >
>>>>>>>>         > >> >> > I don't even see the value in permitting the
>>>>>> endpoint todo
>>>>>>>> the
>>>>>>>>         > >> >> > RPH marking.
>>>>>>>>         > >> >> > In addition to the security concerns
>>> there is also the
>>>>>>>>         > >> >problem that
>>>>>>>>         > >> >> > there are more options to implement without
>>>>>> an additional
>>>>>>>> value.
>>>>>>>>         > >> >> >
>>>>>>>>         > >> >> > >-----Original Message-----
>>>>>>>>         > >> >> > >From: Brian Rosen [mailto:[email-masked]]
>>>>>>>>         > >> >> > >Sent: 05 February, 2009 00:03
>>>>>>>>         > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
>>>>>> 'Tschofenig,
>>>>>>>>         > >> >> Hannes (NSN -
>>>>>>>>         > >> >> > >FI/Espoo)'; 'ECRIT'
>>>>>>>>         > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual
>>> Interim Meeting:
>>>>>>>> Agenda (my
>>>>>>>>         > >> >> > mistake)
>>>>>>>>         > >> >> > >
>>>>>>>>         > >> >> > >Hannes
>>>>>>>>         > >> >> > >
>>>>>>>>         > >> >> > >This matches my understanding
>>> precisely.  We wish to
>>>>>>>>         > >> >> permit endpoints
>>>>>>>>         > >> >> > >to mark. We do not require it, and
>>> don't necessarily
>>>>>>>> expect it
>>>>>>>>         > >> >> > >in many (even
>>>>>>>>         > >> >> > >most) cases.  We don't wish to see the
>>>>>> document prohibit
>>>>>>>> it.
>>>>>>>>         > >> >> > >We all seem to agree it has value within the
> >>>>> Emergency
>>>>>>>>         > >> >Services IP
>>>>>>>>         > >> >> > >Networks.
>>>>>>>>         > >> >> > >
>>>>>>>>         > >> >> > >Brian
>>>>>>>>         > >> >> > >
>>>>>>>>         > >> >> > >> -----Original Message-----
>>>>>>>>         > >> >> > >> From: [email-masked]
>>>>>>>> [mailto:[email-masked]]
>>>>>>>>         > >> >> > >On Behalf
>>>>>>>>         > >> >> > >> Of James M. Polk
>>>>>>>>         > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
>>>>>>>>         > >> >> > >> To: Hannes Tschofenig; Tschofenig,
>>> Hannes (NSN -
>>>>>>>>         > >> >> FI/Espoo); 'ECRIT'
>>>>>>>>         > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>>>>>>>> Meeting:
>>>>>>>>         > >Agenda (my
>>>>>>>>         > >> >> > >> mistake)
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> At 02:37 PM 2/4/2009, Hannes
>>> Tschofenig wrote:
>>>>>>>>         > >> >> > >> > > James wrote:
>>>>>>>>         > >> >> > >> > >> you are the _lone_ voice not
>>>>>> supporting this ID,
>>>>>>>>         > >> >> > >> >
>>>>>>>>         > >> >> > >> >Listening to the audio recording of past
>>>>>> meetings I
>>>>>>>> have to
>>>>>>>>         > >> >> > >say that
>>>>>>>>         > >> >> > >> >I
>>>>>>>>         > >> >> > >> was
>>>>>>>>         > >> >> > >> >not the only persons raising
>>> concerns about the
>>>>>>>> document.
>>>>>>>>         > >> >> > >> >That was probably the reason why you
>>>>>> agreed to limit
>>>>>>>> the
>>>>>>>>         > >> >> > >scope of the
>>>>>>>>         > >> >> > >> >document (which you didn't later do) to
>>>>>> get folks to
>>>>>>>> agree
>>>>>>>>         > >> >> > >to make it
>>>>>>>>         > >> >> > >> a WG
>>>>>>>>         > >> >> > >> >item.
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> re-listen to the audio please
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> Ted's concerns were consistent with most
>>>>>>>> (all?) other
>>>>>>>>         > >> >> concerns --
>>>>>>>>         > >> >> > >> which were based on the premise of whether
>>>>>> or not the
>>>>>>>>         > >> >> UAC should be
>>>>>>>>         > >> >> > >> trusted to initiate the marking on the
>>>>>> INVITE.  The
>>>>>>>> most
>>>>>>>>         > >> >> > >> recent version has backed off this
>>> to a "can" --
>>>>>>>> meaning not
>>>>>>>>         > >> >prohibited
>>>>>>>>         > >> >> > >> (i.e., no 2119 text).  I also backed off
>>>>>> the text in
>>>>>>>> the
>>>>>>>>         > >> >> SP domain
>>>>>>>>         > >> >> > >> part to "can", such that there is
>>> no 2119 text
>>>>>>>>         > >> >mandating or even
>>>>>>>>         > >> >> > >> recommending its usage there. I also do
>>>>>> not prohibit
>>>>>>>> its
>>>>>>>>         > >> >> > >use, based on
>>>>>>>>         > >> >> > >> local policy.  Keith has come forward with
>>>>>> the specific
>>>>>>>>
>>>>>>>>         > >> >> > >> request that non-ESInet networks be
>>>>>> allowed to mark and
>>>>>>>> pay
>>>>>>>>         > >> >attention to
>>>>>>>>         > >> >> > >> this priority indication -- with IMS as
>>>>>> the specific
>>>>>>>> example
>>>>>>>>         > >> >> > >> he wishes to have this valid for.
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> Where there is no disagreement, save for
>>>>>> your recent
>>>>>>>>         > >> >> > >pushback - is in
>>>>>>>>         > >> >> > >> the ESInet, which is where Brian
>>> has requested it's
>>>>>>>>         > >> >> > >definition in the
>>>>>>>>         > >> >> > >> IETF on behalf of NENA.  He's the i3 WG
>>>>>> chair within
>>>>>>>>         > >> >> NENA, and if
>>>>>>>>         > >> >> > >> he asks for it, are you going to say you
>>>>>> know better
>>>>>>>> than he?
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> >Btw, I not disagreeing with the document
>>>>>> as such. I
>>>>>>>>         > >> >just want to
>>>>>>>>         > >> >> > the
>>>>>>>>         > >> >> > >> scope
>>>>>>>>         > >> >> > >> >to change. The usage of RPH
>>> within the emergency
>>>>>>>>         > >> >> services network
>>>>>>>>         > >> >> > is
>>>>>>>>         > >> >> > >> fine
>>>>>>>>         > >> >> > >> >for me. I may get convinced to start the
> >>>>> RPH marking
>>>>>>>> from
>>>>>>>>         > >> >> > >the the VSP
>>>>>>>>         > >> >> > >> >towards the PSAP. I feel uneasy about the
>>>>>> end host
>>>>>>>> doing
>>>>>>>>         > >> >> > >the marking.
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> please read what I wrote above, and then
>>>>>> re-read the
>>>>>>>>         > >> >most recent
>>>>>>>>         > >> >> > >> version of the ID. I don't have endpoints
>>>>>> that SHOULD
>>>>>>>> or
>>>>>>>>         > >> >> MUST mark
>>>>>>>>         > >> >> > >> anything wrt RPH.  I also don't want to
>>>>>> prohibit it,
>>>>>>>>         > >> >> because there
>>>>>>>>         > >> >> > >> might be cases (that I don't know
>>> of) of valid uses
>>>>>>>>         > >> >> under certain
>>>>>>>>         > >> >> > >> circumstances.  Figure 1 is very clear
>>>>>> that there are 3
>>>>>>>>         > >> >> networking
>>>>>>>>         > >> >> > >> parts to consider
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> #1 - from the endpoint
>>>>>>>>         > >> >> > >> #2 - within the VSP
>>>>>>>>         > >> >> > >> #3 - within the ESInet
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> the most recent ID version has "can" for
>>>>>> #s 1 and 2,
>>>>>>>> and
>>>>>>>>         > >> >> > >2119 language
>>>>>>>>         > >> >> > >> offering those supporting this
>>>>>> specification will have
>>>>>>>> RPH
>>>>>>>>         > >> >> > >> adherence within #3 (the ESInet).
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> What other scope changes do you want,
>>>>>> because I haven't
>>>>>>>>         > >> >> heard them.
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> I only heard you claim in email during the
>>>>>> last IETF
>>>>>>>> and in
>>>>>>>>         > >> >> > >the ECRIT
>>>>>>>>         > >> >> > >> session that RPH should not be
>>> used for priority
>>>>>>>> marking
>>>>>>>>         > >> >> requests.
>>>>>>>>         > >> >> > >> This is something Keith (SIP WG
>>> chair) voiced his
>>>>>>>> opposition
>>>>>>>>         > >> >> > >> to your views regarding creating a second
>>>>>> means for SIP
>>>>>>>> to
>>>>>>>>         > >> >priority
>>>>>>>>         > >> >> > >> mark request "when SIP already has one
>>>>>> interoperable
>>>>>>>> way to
>>>>>>>>         > >> >> > >> accomplish this... it's call the RP header
>>>>>> mechanism".
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> >I don't see advantages -- only
>>> disadvantages.
>>>>>>>>         > >> >> > >> >
>>>>>>>>         > >> >> > >> >Ciao
>>>>>>>>         > >> >> > >> >Hannes
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >>
>>> _______________________________________________
>>>>>>>>         > >> >> > >> Ecrit mailing list
>>>>>>>>         > >> >> > >> [email-masked]
>>>>>>>>         > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>         > >> >> > >
>>>>>>>>         > >> >>
>>>>>>>>         > >> >> _______________________________________________
>>>>>>>>         > >> >> Ecrit mailing list
>>>>>>>>         > >> >> [email-masked]
>>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>         > >> >>
>>>>>>>>         > >> >
>>>>>>>>         > >
>>>>>>>>         >
>>>>>>>>         > _______________________________________________
>>>>>>>>         > Ecrit mailing list
>>>>>>>>         > [email-masked]
>>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Ecrit mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ecrit mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>>
>> ------------------------------------------------------------------------------------------------
> > This message is for the designated recipient only and may
>> contain privileged, proprietary, or otherwise private information.
>> If you have received it in error, please notify the sender
>> immediately and delete the original.  Any unauthorized use of
>> this email is prohibited.
>> ------------------------------------------------------------------------------------------------
>> [mf2]
>>
>>
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

Date: Fri, 06 Feb 2009 15:45:31 -0600
To: "Winterbottom, James" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>, "Brian Rosen" <[email-masked]>, "Henning Schulzrinne" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

At 02:01 PM 2/6/2009, Winterbottom, James wrote:
>Hi All,
>
>I have followed thi thread with some interest and I struggling to 
>see a use case for the
>providing RPH for emergency calls from the end-point.

ok, let's address this concern only for a minute.

If there is no use-case you can think of (for endpoints insertion of 
RP namespace esnet), does that mean this RFC to-be has to prevent 
(i.e., MUST NOT) endpoints from being allowed to insert esnet?  That 
means, you feel and believe, you know about all customer requirements 
everywhere, doesn't it?

I'm not kidding or being snide here.

Remember, this is a Standards Track doc for implementers, allowing 
them the idea that some future specification MAY allow endpoints to 
insert the RP header from endpoints gives them the ability to adjust 
their code to that possibility.  There is the (good?) chance that at 
least one customer (somewhere) of one or more vendors has this as a 
requirement _now_, but we haven't heard about it yet.

Stating in this to-be RFC that endpoints are forbidden from inserting 
an RP header would prevent them from implementing/satisfying their 
customer requirement while still supporting this specification.

Remember, this RFC to-be DOES NOT say anything about endpoints MUST 
or even SHOULD implement the "esnet" RP namespace in order to be 
compliant with this spec.  It merely says MAY, which means "some 
future spec MAY recommend or mandate it".

I agree with Brian that robust security considerations stating that 
endpoint implementations need to very careful about configuring this 
capability needs to be written, and I will commit to writing that 
text in the next rev of the doc.

James

>The reference-model call in ECRIT, for better or worse, is for all 
>calls to go back through a home-VSP.
>We placed quite a lot of emphasis, largely for traffing reasons, for 
>the VSP to be able to verify that
>a call is in fact an emergency call. This is done by the proxy 
>taking the inband location, doing a LoST
>query with the provided URN, and verifying that the resulting 
>destination URI is the same as the destination
>URI provide in the SIP INVITE. My understanding was that VSPs would 
>always do this check so they could
>tell if they could bill for the call or not, and because the VSP can 
>be use that the call is an emergency call
>it can apply any special priorities that may be applicable. This 
>obviates the need for RPH from the end-point
>to the network.
>
>This leaves us with the argument of "it doesn't hurt to it", which 
>is not a good reason to write a specification.
>It was intimated on the geopriv mailing list last year that great 
>pains had been taken to keep SIP with in the
>MTU limits of UDP over Ethernet 
>(http://www.ietf.org/mail-archive/web/geopriv/current/msg06120.html). Assuming
>that this is the case, perhaps there is harm in including 
>information that we know will be ignored.
>
>Cheers
>James
>
>
>
>-----Original Message-----
>From: [email-masked] on behalf of Hannes Tschofenig
>Sent: Fri 2/6/2009 12:33 PM
>To: 'Brian Rosen'; 'Henning Schulzrinne'
>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
>Subject: Re: [Ecrit] RPH
>
>To the story short here is the code for the proxy:
>
>---------------------
>
>IF emergency call was recognized THEN
>     execute emergency call specific procedures (priority queuing,
>preemption, fetch location, determine routing, do funny QoS things & co)
>ELSE
>     normal call handling procedures.
>
>---------------------
>
>If you can make this differentiation between an emergency call and a regular
>call then you can also do everything that is necessary for emergency call
>handling.
>
>Brian + Keith: Please tell me that we cannot do the above with our currently
>specified mechanisms.
>
>Ciao
>Hannes
>
> >-----Original Message-----
> >From: Brian Rosen [mailto:[email-masked]]
> >Sent: 06 February, 2009 17:49
> >To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
> >Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >Subject: RE: [Ecrit] RPH
> >
> >I agree that not all networks will permit (or pay attention
> >to) a priority request from an end device.
> >
> >No one has asked for that.
> >
> >The namespace request has several uses, one of which is within
> >an emergency services IP network, one of which is between
> >elements within a public network controlled by the operator,
> >and one of which is an endpoint request for resource priority.
> >
> >Those of us requesting this work proceed are happy if the
> >endpoint part is simply left as possible (MAY), and, speaking
> >for myself, having the draft discuss the security implications
> >of endpoint marking is reasonable.
> >
> >Having discussed this issue with an implementation team who
> >worked on MLPP systems, I am confident I know what I'm talking
> >about, but YMMV.  The fact that you could, if you wanted to,
> >give resource priority to a call you decided, however you
> >decided, was an emergency call is an implementation decision,
> >and not subject to standardization.
> >
> >RPH is the IETF standard way for one entity to request
> >resource priority of another entity in a SIP system.  We're
> >asking for a namespace to use that within the domain of
> >emergency calls.  That is, I think, a VERY reasonable request.
> >
> >Brian
> >
> >> -----Original Message-----
> >> From: Henning Schulzrinne [mailto:[email-masked]]
> >> Sent: Friday, February 06, 2009 10:33 AM
> >> To: Hannes Tschofenig
> >> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
> >> Subject: Re: [Ecrit] RPH
> >>
> >> To chime in here:
> >>
> >> I don't think it's productive to simply state that 4412
> >doesn't worry
> >> about authorization, so we shouldn't either (simplifying a bit).
> >> Authorization was discussed repeatedly, and the general
> >assumption was
> >> that there were two conditions: Either the user invoking resource-
> >> priority was well known and had a set of permissions that could be
> >> checked in real time or there are ways to deal with abuse after the
> >> fact in ways that deter abuse (the court-martial kind of thing in a
> >> military context).
> >>
> >> The RFC 4412 security consideration (11.2) call this out in pretty
> >> strong language:
> >>
> >>   Prioritized access to network and end-system resources imposes
> >>     particularly stringent requirements on authentication and
> >>     authorization mechanisms, since access to prioritized
> >resources may
> >>     impact overall system stability and performance and not
> >just result
> >>     in theft of, say, a single phone call.
> >> Thus, the question is whether we have such strong authentication in
> >> emergency calling. In some cases, such as residential fixed line
> >> deployments where ISP = VSP, we're probably pretty close, in others,
> >> such as prepaid cell phones or hot spots or VSP-only providers, we
> >> aren't.
> >>
> >> The other point that I think Hannes is making is that the
> >information
> >> is either redundant or dangerous. If a processing element recognizes
> >> the call as being an emergency call, it can apply whatever treatment
> >> it deems appropriate and doesn't need additional information. If it
> >> doesn't or can't, using just the RPH can be rather dangerous unless
> >> that element can be reasonably certain that there is strong
> >> authentication and recourse.
> >>
> >> I don't buy the argument that somehow finding the RPH is faster than
> >> just looking for the identifier. Thus, given that the information is
> >> either redundant or dangerous, I fail to see the advantage.
> >>
> >> Henning
> >>
> >>
> >> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
> >>
> >> > Don't get hung up on the details. There are ways to optimize it.
> >> > That was
> >> > not the point of the code example.
> >> >
> >> > The problem that my pseudo code should have shown you is that you
> >> > * don't gain anything with RPH marking for the emergency call case
> >> > from the SIP UA towards the outbound proxy since the functionality
> >> > is already provide otherwise. How often does the proxy need to get
> >> > told that this is an emergency call todo whatever emergency call
> >> > handling procedures are necessary?
> >> > * you only introduce fraud problems (if you are not
> >careful and you
> >> > understand the security stuff well enough)
> >> >
> >> > If you can point me to people who implement the RPH emergency call
> >> > case please do so. I would love to talk to them.
> >> >
> >> > Ciao
> >> > Hannes
> >> >
> >> > PS: You need to parse incoming messages to some extend so that you
> >> > know what it contains :-) Only looking for the emergency
> >RPH header
> >> > (and not for the Service URN/dial
> >> > string) would exactly be the DoS/fraud attack I am worried about.
> >> > That's the thing Henning was worried about (go and listen to the
> >> > past meeting minutes).
> >> >
> >> >
> >> >> Hannes
> >> >>
> >> >> You need to talk to people who really implement this kind
> >of thing.
> >> >> You are way off.
> >> >>
> >> >> When you implement a resource priority system, the point of doing
> >> >> that is to look though the queue of work and pick out the
> >ones with
> >> >> priority, handling them first.  You don't do all the parsing, you
> >> >> don't do a lot of decision tree.
> >> >>
> >> >> Typically:
> >> >> Check for DoS things, like too big messages, etc Do a quick scan
> >> >> for the RPH message header If found:
> >> >> Parse the message
> >> >> Determine validity
> >> >> Determine priority
> >> >> Queue on the correct work queue
> >> >>
> >> >> The first two actions have to be very fast.  Anyone who builds a
> >> >> SIP thingie will tell you that parsing is one of the big cycle
> >> >> consumers: if you have to parse every message BEFORE you
> >determine
> >> >> priority, you can't give much resource priority.
> >> >> Once you get the whole message parsed, you might as well finish
> >> >> working on it, because you've done so much of the work.
> >> >> OTHOH, finding the end-of-message delimiter and doing a quick
> >> >> string search for RPH is fast.  If you are doing
> >priority, you need
> >> >> to keep all the priority processing pretty uniform, and pretty
> >> >> simple, or you tend to spend too much time futzing around
> >figuring
> >> >> out what to do.  You put all the priority related stuff together,
> >> >> and use as much common code as possible.
> >> >>
> >> >> Brian
> >> >>
> >> >>> -----Original Message-----
> >> >>> From: [email-masked] [mailto:[email-masked]]
> >> >> On Behalf
> >> >>> Of Hannes Tschofenig
> >> >>> Sent: Friday, February 06, 2009 8:41 AM
> >> >>> To: 'Hannes Tschofenig'; 'Janet P Gunn'
> >> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-
> >> >>> [email-masked]
> >> >>> Subject: [Ecrit] RPH
> >> >>>
> >> >>> Over lunch I was also thinking how an outbound proxy would
> >> implement
> >> >>> some of the emergency procedures. Here are some thoughts:
> >> >>>
> >> >>> ---------------------------------------------------
> >> >>>
> >> >>> // Process incoming message
> >> >>> Parse(msg);
> >> >>>
> >> >>> // SIP INVITE without Service URN
> >> >>> // legacy devices
> >> >>> If (recognize-dialstring(msg)==TRUE) {  // we got an emergency
> >> >>> call going on  emergency=TRUE;  if (dialstring(msg) == 911)
> >> >>> serviceURN=urn:service:sos; } else if
> >> >>> (recognize-serviceURN(msg)==TRUE) {  // oh. A updated
> >device that
> >> >>> has a service URN attached to the
> >> call
> >> >>>  serviceURN=retrieve_ServiceURN(msg);
> >> >>>  emergency=TRUE;
> >> >>> } else {
> >> >>>  // standard SIP message
> >> >>>  // regular processing
> >> >>>  process(msg);
> >> >>>  emergency=FALSE;
> >> >>> }
> >> >>>
> >> >>> If (emergency == TRUE) {
> >> >>>   // make sure that the emergency call does not get
> >dropped on the
> >> >>> floor
> >> >>>   // skip authorization failures
> >> >>>   // give the call a special treatment
> >> >>>   lots-of-code-here();
> >> >>>
> >> >>>   // trigger all the QoS signaling you have in the
> >network to make
> >> >>> James happy
> >> >>>   trigger-qos();
> >> >>>
> >> >>>   // query location
> >> >>>   location=retrieve-location();
> >> >>>
> >> >>>   // determine next hop
> >> >>>   next-hop=lost(location, serviceURN)
> >> >>>
> >> >>>   // attach RPH marking to outgoing msg to make James and
> >> >> Keith happy
> >> >>>   msg=add(msg, RPH);
> >> >>>
> >> >>>   send(msg, next-hop);
> >> >>> }
> >> >>>
> >> >>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
> >> >>>   // all the emergency related processing done already upfront
> >> >>>   // hence I log something.
> >> >>>   log(RPH_WAS_PRESENT_JUHU);
> >> >>> } else if ((rph-present(msg) == TRUE) && (emergency ==
> >FALSE)) {
> >> >>> // this is not an emergency call  // this is something
> >like GETS
> >> >>> result=special-authorization-procedure(user);
> >> >>>
> >> >>>  if (result == AUTHORIZED) {
> >> >>>    // do some priority & preemption thing here.
> >> >>>    // trigger all the QoS you have
> >> >>>    lots-of-code-here();
> >> >>>  } else {
> >> >>>    log("NOT AUTHORIZED; don't DoS my network");  } } else {  //
> >> >>> don't need todo any RPH processing  // this includes the case
> >> >>> where the call was an emergency call but the RPH
> >> >>>
> >> >>>  // marking was not there.
> >> >>>  nothing();
> >> >>> }
> >> >>>
> >> >>> ---------------------------------------------------
> >> >>>
> >> >>>
> >> >>> Ciao
> >> >>> Hannes
> >> >>>
> >> >>>> -----Original Message-----
> >> >>>> From: [email-masked] [mailto:[email-masked]] On
> >> >>>> Behalf Of Hannes Tschofenig
> >> >>>> Sent: 06 February, 2009 15:07
> >> >>>> To: 'Janet P Gunn'
> >> >>>> Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
> >> >>> FI/Espoo)
> >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
> >> >>>>
> >> >>>> Who would define something that could prevent DoS problems?
> >> >>>>
> >> >>>> ________________________________
> >> >>>>
> >> >>>>         From: Janet P Gunn [mailto:[email-masked]]
> >> >>>>         Sent: 06 February, 2009 14:11
> >> >>>>         To: Hannes Tschofenig
> >> >>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >> >>>> [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
> >> 'James
> >> >>>> M. Polk'
> >> >>>>         Subject: Re: [Ecrit] ECRIT Virtual Interim
> >Meeting: Agenda (RPH)
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>         But there is nothing IN RFC4412 that specifically
> >> >> addresses how to
> >> >>>> prevent any particular namespace being used for DoS.  Anyone/any
> >> UA
> >> >>>> can ATTEMPT to invoke priority treatment by attaching RPH.  For
> >> all
> >> >>>> of the 4412 namespaces, as with the new proposed namespace, the
> >> >>>> mechanisms for preventing DoS are not specified in the
> >> >> document that
> >> >>>> defines the namespace.
> >> >>>> They are/will be specified elsewhere.
> >> >>>>
> >> >>>>         Janet
> >> >>>>
> >> >>>>         This is a PRIVATE message. If you are not the intended
> >> >> recipient,
> >> >>>> please delete without copying and kindly advise us by e-mail of
> >> the
> >> >>>> mistake in delivery.
> >> >>>>         NOTE: Regardless of content, this e-mail shall not
> >> >> operate to bind
> >> >>>> CSC to any order or other contract unless pursuant to explicit
> >> >>>> written agreement or government initiative expressly permitting
> >> the
> >> >>>> use of e-mail for such purpose.
> >> >>>>
> >> >>>>         [email-masked] wrote on 02/06/2009 04:21:51 AM:
> >> >>>>
> >> >>>>         > Hi James,
> >> >>>>         >
> >> >>>>         > I have read RFC 4412 and also the GETS/MLPP IETF
> >> >> documents. What I
> >> >>>> would
> >> >>>>         > like to point out is that there is more than just a
> >> >> header and
> >> >>>> values within
> >> >>>>         > the header that have to be considered in order to
> >> >> make a judgement
> >> >>>> of what
> >> >>>>         > is appropriate and what isn't. There is an
> >> >> architectural question
> >> >>>> and
> >> >>>>         > whether the environment we are using the stuff is
> >> >> indeed providing
> >> >>>> the
> >> >>>>         > properties you need for the solution to be
> >appropriate.
> >> >>>>         >
> >> >>>>         > Let me describe in more detail what I meant (and
> >> >> please correct me
> >> >>>> if I am
> >> >>>>         > wrong).
> >> >>>>         >
> >> >>>>         > Getting priority for SIP requests when using a GETS
> >> >> alike scenario
> >> >>>> means
> >> >>>>         > that the entity that issues the request is specially
> >> >> authorized
> >> >>>> since
> >> >>>>         > otherwise you introduce a nice denial of
> >service attack. This
> >> >>>> authorization
> >> >>>>         > is tied to the entity that makes the request. For
> >> >> example, the
> >> >>>> person is
> >> >>>>         > working for the government and has special rights.
> >> >>>> James Bond as a (not so)
> >> >>>>         > secret agent might have these rights.
> >> >>>>         >
> >> >>>>         > The emergency services case
> >(citizen-to-authority) is a bit
> >> >>>> different as
> >> >>>>         > there aren't really special rights with respect to
> >> >> authorization
> >> >>>> tied to
> >> >>>>         > individuals. Instead, the fact that something is an
> >> >> emergency is
> >> >>>> purely a
> >> >>>>         > judgement of the human that dials a special number.
> >> >>>> To deal with fraud, we
> >> >>>>         > discussed in the group on what we can actually do to
> >> >> ensure that
> >> >>>> end users
> >> >>>>         > do not bypass security procedures (such as
> >> >> authorization checks,
> >> >>>> charging
> >> >>>>         > and so on). Part of this investigation was
> >the publication of
> >> >>>>         > http://www.ietf.org/rfc/rfc5069.txt that also
> >describes this
> >> >>>> issue.
> >> >>>>         >
> >> >>>>         > So, imagine the implementation of a SIP proxy (and we
> >> >> implemented
> >> >>>> that
> >> >>>>         > stuff) that receives a call that contains a Service
> >> >> URN. The code
> >> >>>> branches
> >> >>>>         > into a special mode where everything is done
> >so that the call
> >> >>>> receives
> >> >>>>         > appropriate treatment and does not get dropped on the
> >> >> floor. The
> >> >>>> way how the
> >> >>>>         > Service URN is placed in the message ensures that the
> >> >> call cannot
> >> >>>> go to my
> >> >>>>         > friend (instead of the PSAP) unless the end host ran
> >> >> LoST already.
> >> >>>> In the
> >> >>>>         > latter case, we discussed this also on the list for a
> >> >> while and
> >> >>>> Richard even
> >> >>>>         > wrote a draft about it in the context of the
> >location hiding
> >> >>>> topic, we said
> >> >>>>         > that the proxy would have to run LoST if he
> >cares about a
> >> >>>> potential
> >> >>>>         > fraudulent usage.
> >> >>>>         >
> >> >>>>         > So, what do we need todo in order to provide
> >secure RFC 4412
> >> >>>> functionality
> >> >>>>         > in our context?
> >> >>>>         >
> >> >>>>         > Do you think that the current text in
> >> >>>>         >
> >> >>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >> >>>> gency-rph-nam
> >> >>>>         > espace-00.txt reflects any of the
> >above-described issues:
> >> >>>>         > "
> >> >>>>         >    The Security considerations that apply to RFC 4412
> >> >>>> [RFC4412]
> >> >>>> apply
> >> >>>>         >    here.  This document introduces no new security
> >> >>>> issues relative
> >> >>>> to
> >> >>>>         >    RFC 4412.
> >> >>>>         > "
> >> >>>>         >
> >> >>>>         > From various discussions in GEOPRIV I recall
> >that you are
> >> >>>> super-sensitive
> >> >>>>         > regarding security and privacy. For some reasons you
> >> >> don't seem to
> >> >>>> have the
> >> >>>>         > same concerns here. I would like to
> >understand your reasoning.
> >> >>>>         >
> >> >>>>         > Please also do me another favor: Don't always say
> >> >> that I don't
> >> >>>> understand
> >> >>>>         > the subject. Even if that would be the case it isn't
> >> >> particular
> >> >>>> fair given
> >> >>>>         > that different folks had to educate you on other
> >> >> topics in the
> >> >>>> past as well.
> >> >>>>         > Additionally, if you listen to the audio recordings
> >> >> then you will
> >> >>>> notice
> >> >>>>         > that Henning, Ted, and Jon do not seem to understand
> >> >> the issue
> >> >>>> either as
> >> >>>>         > they have raised similar issues during the
> >F2F meetings.
> >> >>>>         >
> >> >>>>         > Ciao
> >> >>>>         > Hannes
> >> >>>>         >
> >> >>>>         >
> >> >>>>         > >Hannes - I believe it is you who do not understand
> >> >> RFC 4412 --
> >> >>>>         > >and many of us are trying to get that
> >through to you, but you
> >> >>>>         > >don't seem to want to listen/read.
> >> >>>>         > >
> >> >>>>         > >RFC 4412 is *for* priority marking SIP requests,
> >> >>>>         > >
> >> >>>>         > >One use is GETS.
> >> >>>>         > >
> >> >>>>         > >One use is MLPP.
> >> >>>>         > >
> >> >>>>         > >These examples are in RFC 4412 because there
> >were specific
> >> >>>>         > >namespaces being created for the IANA section of
> >> >> that document.
> >> >>>>         > >
> >> >>>>         > >Reading the whole document, you will see
> >that RPH can be
> >> >>>>         > >specified for other uses than GETS or MLPP
> >specifically.
> >> >>>>         > >
> >> >>>>         > >I knew when I wrote RFC 4412 that one day we
> >would specify a
> >> >>>>         > >namespace for ECRIT (the "esnet" namespace
> >now) -- but I also
> >> >>>>         > >knew it was premature for RFC 4412 to
> >incorporate that
> >> >>>>         > >namespace, that a future doc to RFC 4412
> >would have to be
> >> >>>>         > >written to do this. Brian and I talked about
> >this at the
> >> >>>>         > >original NENA meeting that created the IP WGs there
> >> >> (in August
> >> >>>>         > >of 03).  We both agreed we should wait until it was
> >> >>>>         > >appropriate to the work in the IETF to
> >submit this document
> >> >>>>         > >that is now
> >> >>>>         >
> >> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >> >>>>         > >gency-rph-namespace-00.txt
> >> >>>>         > >
> >> >>>>         > >Yet, you seem to want to use some additional
> >mechanism to
> >> >>>>         > >indicate priority of a call in SIP.  That
> >means you want to
> >> >>>>         > >introduce a second way to accomplish this in SIP.
> >> >>>> Why do you
> >> >>>>         > >want to promote a separate way to do something SIP
> >> >> has already
> >> >>>>         > >defined? That will cause interoperability issues and
> >> >> we both know
> >> >>>> that.
> >> >>>>         > >
> >> >>>>         > >You've said to me (and others) that you
> >believe RPH is just
> >> >>>>         > >another way to accomplish what sos or a URI can
> >> >> indicate - and
> >> >>>>         > >you're wrong.  Your way would be
> >_the_second_way_to_do_it,
> >> >>>>         > >because SIP already considers RPH to be
> >*the*way* to priority
> >> >>>>         > >mark SIP requests.
> >> >>>>         > >
> >> >>>>         > >If you don't believe me (no comment), then
> >why do you not
> >> >>>>         > >believe the SIP WG chair (who knows more
> >about SIP than both
> >> >>>>         > >of us) - who, on this thread, has again said
> >to you "RFC 4412
> >> >>>>         > >(RPH) is the SIP mechanism to priority mark
> >SIP requests"?
> >> >>>>         > >
> >> >>>>         > >Further, I believe it is inappropriate to
> >prohibit endpoints
> >> >>>>         > >from being able to set the esnet namespace.
> >I absolutely
> >> >>>>         > >believe it will not be needed most of the
> >time, but I believe
> >> >>>>         > >if someone does find a valid use for
> >endpoints to mark
> >> >>>>         > >priority in SIP, this ID - once it has
> >become an RFC -- will
> >> >>>>         > >have to be obsoleted with a new RFC saying the exact
> >> >> opposite.
> >> >>>>         > >
> >> >>>>         > >(color me confused ... over and over again)
> >> >>>>         > >
> >> >>>>         > >James
> >> >>>>         > >
> >> >>>>         > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >> >>>>         > >>Keith, please understand that the usage of RFC 4412
> >> >> for GETS and
> >> >>>> for
> >> >>>>         > >>the type of emergency call we discuss here is
> >> >> different. Just
> >> >>>> looking
> >> >>>>         > >>at the header and the name of the namespace is a bit
> >> >>>>         > >artificial. I hope
> >> >>>>         > >>you understand that.
> >> >>>>         > >>
> >> >>>>         > >> >-----Original Message-----
> >> >>>>         > >> >From: DRAGE, Keith (Keith)
> >> >>>> [mailto:[email-masked]]
> >> >>>>         > >> >Sent: 05 February, 2009 14:55
> >> >>>>         > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
> >> >>>> Polk'; 'Tschofenig,
> >> >>>>         > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >> >>>>         > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
> >> >>>> Meeting: Agenda (my
> >> >>>>
> >> >>>>         > >> >mistake)
> >> >>>>         > >> >
> >> >>>>         > >> >Which is exactly what RFC 4412 specifies for all
> >> >> namespaces.
> >> >>>>         > >> >
> >> >>>>         > >> >regards
> >> >>>>         > >> >
> >> >>>>         > >> >Keith
> >> >>>>         > >> >
> >> >>>>         > >> >> -----Original Message-----
> >> >>>>         > >> >> From: [email-masked]
> >> >> [mailto:[email-masked]]
> >> >>>>         > >> >On Behalf
> >> >>>>         > >> >> Of Brian Rosen
> >> >>>>         > >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >> >>>>         > >> >> To: 'Hannes Tschofenig'; 'James M.
> >Polk'; 'Tschofenig,
> >> >>>>         > >Hannes (NSN
> >> >>>>         > >> >> - FI/Espoo)'; 'ECRIT'
> >> >>>>         > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >> >>>> Meeting: Agenda (my
> >> >>>>         > >> >> mistake)
> >> >>>>         > >> >>
> >> >>>>         > >> >> The value is that in some networks
> >where priority for
> >> >>>>         > >> >emergency calls
> >> >>>>         > >> >> is appropriate, and appropriate
> >policing of marking is
> >> >>>>         > >implemented,
> >> >>>>         > >> >> emergency calls will receive resource priority.
> >> >>>>         > >> >>
> >> >>>>         > >> >> Not all networks would need policing.  Some
> >> >> will.  Policing
> >> >>>> could
> >> >>>>         > >> >> be to Route header/R-URI content, but other
> >> >> criteria are
> >> >>>> possible.
> >> >>>>         > >> >>
> >> >>>>         > >> >> Not all networks will need resource priority
> >> >> for emergency
> >> >>>> calls.
> >> >>>>         > >> >> Fine, ignore this marking/namespace.
> >> >>>>         > >> >>
> >> >>>>         > >> >> Brian
> >> >>>>         > >> >> > -----Original Message-----
> >> >>>>         > >> >> > From: Hannes Tschofenig
> >> >>>> [mailto:[email-masked]]
> >> >>>>         > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >> >>>>         > >> >> > To: 'Brian Rosen'; 'James M. Polk';
> >> >> Tschofenig, Hannes
> >> >>>> (NSN -
> >> >>>>         > >> >> > FI/Espoo); 'ECRIT'
> >> >>>>         > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
> >> >>>> Meeting: Agenda (my
> >> >>>>         > >> >> > mistake)
> >> >>>>         > >> >> >
> >> >>>>         > >> >> > I don't even see the value in permitting the
> >> >> endpoint todo
> >> >>>> the
> >> >>>>         > >> >> > RPH marking.
> >> >>>>         > >> >> > In addition to the security concerns
> >there is also the
> >> >>>>         > >> >problem that
> >> >>>>         > >> >> > there are more options to implement without
> >> >> an additional
> >> >>>> value.
> >> >>>>         > >> >> >
> >> >>>>         > >> >> > >-----Original Message-----
> >> >>>>         > >> >> > >From: Brian Rosen [mailto:[email-masked]]
> >> >>>>         > >> >> > >Sent: 05 February, 2009 00:03
> >> >>>>         > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
> >> >> 'Tschofenig,
> >> >>>>         > >> >> Hannes (NSN -
> >> >>>>         > >> >> > >FI/Espoo)'; 'ECRIT'
> >> >>>>         > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual
> >Interim Meeting:
> >> >>>> Agenda (my
> >> >>>>         > >> >> > mistake)
> >> >>>>         > >> >> > >
> >> >>>>         > >> >> > >Hannes
> >> >>>>         > >> >> > >
> >> >>>>         > >> >> > >This matches my understanding
> >precisely.  We wish to
> >> >>>>         > >> >> permit endpoints
> >> >>>>         > >> >> > >to mark. We do not require it, and
> >don't necessarily
> >> >>>> expect it
> >> >>>>         > >> >> > >in many (even
> >> >>>>         > >> >> > >most) cases.  We don't wish to see the
> >> >> document prohibit
> >> >>>> it.
> >> >>>>         > >> >> > >We all seem to agree it has value within the
> >> >> Emergency
> >> >>>>         > >> >Services IP
> >> >>>>         > >> >> > >Networks.
> >> >>>>         > >> >> > >
> >> >>>>         > >> >> > >Brian
> >> >>>>         > >> >> > >
> >> >>>>         > >> >> > >> -----Original Message-----
> >> >>>>         > >> >> > >> From: [email-masked]
> >> >>>> [mailto:[email-masked]]
> >> >>>>         > >> >> > >On Behalf
> >> >>>>         > >> >> > >> Of James M. Polk
> >> >>>>         > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> >> >>>>         > >> >> > >> To: Hannes Tschofenig; Tschofenig,
> >Hannes (NSN -
> >> >>>>         > >> >> FI/Espoo); 'ECRIT'
> >> >>>>         > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >> >>>> Meeting:
> >> >>>>         > >Agenda (my
> >> >>>>         > >> >> > >> mistake)
> >> >>>>         > >> >> > >>
> >> >>>>         > >> >> > >> At 02:37 PM 2/4/2009, Hannes
> >Tschofenig wrote:
> >> >>>>         > >> >> > >> > > James wrote:
> >> >>>>         > >> >> > >> > >> you are the _lone_ voice not
> >> >> supporting this ID,
> >> >>>>         > >> >> > >> >
> >> >>>>         > >> >> > >> >Listening to the audio recording of past
> >> >> meetings I
> >> >>>> have to
> >> >>>>         > >> >> > >say that
> >> >>>>         > >> >> > >> >I
> >> >>>>         > >> >> > >> was
> >> >>>>         > >> >> > >> >not the only persons raising
> >concerns about the
> >> >>>> document.
> >> >>>>         > >> >> > >> >That was probably the reason why you
> >> >> agreed to limit
> >> >>>> the
> >> >>>>         > >> >> > >scope of the
> >> >>>>         > >> >> > >> >document (which you didn't later do) to
> >> >> get folks to
> >> >>>> agree
> >> >>>>         > >> >> > >to make it
> >> >>>>         > >> >> > >> a WG
> >> >>>>         > >> >> > >> >item.
> >> >>>>         > >> >> > >>
> >> >>>>         > >> >> > >> re-listen to the audio please
> >> >>>>         > >> >> > >>
> >> >>>>         > >> >> > >> Ted's concerns were consistent with most
> >> >>>> (all?) other
> >> >>>>         > >> >> concerns --
> >> >>>>         > >> >> > >> which were based on the premise of whether
> >> >> or not the
> >> >>>>         > >> >> UAC should be
> >> >>>>         > >> >> > >> trusted to initiate the marking on the
> >> >> INVITE.  The
> >> >>>> most
> >> >>>>         > >> >> > >> recent version has backed off this
> >to a "can" --
> >> >>>> meaning not
> >> >>>>         > >> >prohibited
> >> >>>>         > >> >> > >> (i.e., no 2119 text).  I also backed off
> >> >> the text in
> >> >>>> the
> >> >>>>         > >> >> SP domain
> >> >>>>         > >> >> > >> part to "can", such that there is
> >no 2119 text
> >> >>>>         > >> >mandating or even
> >> >>>>         > >> >> > >> recommending its usage there. I also do
> >> >> not prohibit
> >> >>>> its
> >> >>>>         > >> >> > >use, based on
> >> >>>>         > >> >> > >> local policy.  Keith has come forward with
> >> >> the specific
> >> >>>>
> >> >>>>         > >> >> > >> request that non-ESInet networks be
> >> >> allowed to mark and
> >> >>>> pay
> >> >>>>         > >> >attention to
> >> >>>>         > >> >> > >> this priority indication -- with IMS as
> >> >> the specific
> >> >>>> example
> >> >>>>         > >> >> > >> he wishes to have this valid for.
> >> >>>>         > >> >> > >>
> >> >>>>         > >> >> > >> Where there is no disagreement, save for
> >> >> your recent
> >> >>>>         > >> >> > >pushback - is in
> >> >>>>         > >> >> > >> the ESInet, which is where Brian
> >has requested it's
> >> >>>>         > >> >> > >definition in the
> >> >>>>         > >> >> > >> IETF on behalf of NENA.  He's the i3 WG
> >> >> chair within
> >> >>>>         > >> >> NENA, and if
> >> >>>>         > >> >> > >> he asks for it, are you going to say you
> >> >> know better
> >> >>>> than he?
> >> >>>>         > >> >> > >>
> >> >>>>         > >> >> > >>
> >> >>>>         > >> >> > >> >Btw, I not disagreeing with the document
> >> >> as such. I
> >> >>>>         > >> >just want to
> >> >>>>         > >> >> > the
> >> >>>>         > >> >> > >> scope
> >> >>>>         > >> >> > >> >to change. The usage of RPH
> >within the emergency
> >> >>>>         > >> >> services network
> >> >>>>         > >> >> > is
> >> >>>>         > >> >> > >> fine
> >> >>>>         > >> >> > >> >for me. I may get convinced to start the
> >> >> RPH marking
> >> >>>> from
> >> >>>>         > >> >> > >the the VSP
> >> >>>>         > >> >> > >> >towards the PSAP. I feel uneasy about the
> >> >> end host
> >> >>>> doing
> >> >>>>         > >> >> > >the marking.
> >> >>>>         > >> >> > >>
> >> >>>>         > >> >> > >> please read what I wrote above, and then
> >> >> re-read the
> >> >>>>         > >> >most recent
> >> >>>>         > >> >> > >> version of the ID. I don't have endpoints
> >> >> that SHOULD
> >> >>>> or
> >> >>>>         > >> >> MUST mark
> >> >>>>         > >> >> > >> anything wrt RPH.  I also don't want to
> >> >> prohibit it,
> >> >>>>         > >> >> because there
> >> >>>>         > >> >> > >> might be cases (that I don't know
> >of) of valid uses
> >> >>>>         > >> >> under certain
> >> >>>>         > >> >> > >> circumstances.  Figure 1 is very clear
> >> >> that there are 3
> >> >>>>         > >> >> networking
> >> >>>>         > >> >> > >> parts to consider
> >> >>>>         > >> >> > >>
> >> >>>>         > >> >> > >> #1 - from the endpoint
> >> >>>>         > >> >> > >> #2 - within the VSP
> >> >>>>         > >> >> > >> #3 - within the ESInet
> >> >>>>         > >> >> > >>
> >> >>>>         > >> >> > >> the most recent ID version has "can" for
> >> >> #s 1 and 2,
> >> >>>> and
> >> >>>>         > >> >> > >2119 language
> >> >>>>         > >> >> > >> offering those supporting this
> >> >> specification will have
> >> >>>> RPH
> >> >>>>         > >> >> > >> adherence within #3 (the ESInet).
> >> >>>>         > >> >> > >>
> >> >>>>         > >> >> > >> What other scope changes do you want,
> >> >> because I haven't
> >> >>>>         > >> >> heard them.
> >> >>>>         > >> >> > >>
> >> >>>>         > >> >> > >> I only heard you claim in email during the
> >> >> last IETF
> >> >>>> and in
> >> >>>>         > >> >> > >the ECRIT
> >> >>>>         > >> >> > >> session that RPH should not be
> >used for priority
> >> >>>> marking
> >> >>>>         > >> >> requests.
> >> >>>>         > >> >> > >> This is something Keith (SIP WG
> >chair) voiced his
> >> >>>> opposition
> >> >>>>         > >> >> > >> to your views regarding creating a second
> >> >> means for SIP
> >> >>>> to
> >> >>>>         > >> >priority
> >> >>>>         > >> >> > >> mark request "when SIP already has one
> >> >> interoperable
> >> >>>> way to
> >> >>>>         > >> >> > >> accomplish this... it's call the RP header
> >> >> mechanism".
> >> >>>>         > >> >> > >>
> >> >>>>         > >> >> > >> >I don't see advantages -- only
> >disadvantages.
> >> >>>>         > >> >> > >> >
> >> >>>>         > >> >> > >> >Ciao
> >> >>>>         > >> >> > >> >Hannes
> >> >>>>         > >> >> > >>
> >> >>>>         > >> >> > >>
> >_______________________________________________
> >> >>>>         > >> >> > >> Ecrit mailing list
> >> >>>>         > >> >> > >> [email-masked]
> >> >>>>         > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>         > >> >> > >
> >> >>>>         > >> >>
> >> >>>>         > >> >> _______________________________________________
> >> >>>>         > >> >> Ecrit mailing list
> >> >>>>         > >> >> [email-masked]
> >> >>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>         > >> >>
> >> >>>>         > >> >
> >> >>>>         > >
> >> >>>>         >
> >> >>>>         > _______________________________________________
> >> >>>>         > Ecrit mailing list
> >> >>>>         > [email-masked]
> >> >>>>         > https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> Ecrit mailing list
> >> >>>> [email-masked]
> >> >>>> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> Ecrit mailing list
> >> >>> [email-masked]
> >> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>
> >> >
> >> > _______________________________________________
> >> > Ecrit mailing list
> >> > [email-masked]
> >> > https://www.ietf.org/mailman/listinfo/ecrit
> >> >
> >
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>
>
>------------------------------------------------------------------------------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information.
>If you have received it in error, please notify the sender
>immediately and delete the original.  Any unauthorized use of
>this email is prohibited.
>------------------------------------------------------------------------------------------------
>[mf2]
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

Date: Fri, 06 Feb 2009 16:02:03 -0600
To: "Hannes Tschofenig" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)

At 03:21 AM 2/6/2009, Hannes Tschofenig wrote:
>Hi James,
>
>I have read RFC 4412 and also the GETS/MLPP IETF documents. What I would
>like to point out is that there is more than just a header and values within
>the header that have to be considered in order to make a judgement of what
>is appropriate and what isn't. There is an architectural question and
>whether the environment we are using the stuff is indeed providing the
>properties you need for the solution to be appropriate.
>
>Let me describe in more detail what I meant (and please correct me if I am
>wrong).
>
>Getting priority for SIP requests when using a GETS alike scenario means
>that the entity that issues the request is specially authorized since
>otherwise you introduce a nice denial of service attack.

You are missing a step in GETS here.  The endpoint, who sends the 
GETS set-up as an INVITE is not already authorized (not the device, 
not the user).  In North America, there is a 10 digit GETS number 
that is dialed (that I won't give out right now on an open list) - 
and there literally is only 1 number available to dial for this 
service.  Literally anyone can dial this number today in North 
America (no matter where the phone is - as long as it is in North 
America -- and I might be too limiting in that it is dialable from 
anywhere, because it is going to a North American destination).

Once this number is dialed, it is answered by an authentication and 
authorization IVR.  This IVR challenges each caller for their 
authentication passcode, and a password). Once this has been 
successfully entered, then call is NOW authorized to proceed towards 
its destination number - this step is only known to the authorizing 
system because the destination 10 digit number is NOT entered until 
after the authentication and authorization step has completed.

The authorized caller is prompted with a new dial tone - in which 
they can enter any number on the planet and receive preferential 
treatment through as many carriers (in IP, it's SPs) that have 
implemented this GETS service (which is an SLA with the Department of 
Homeland Security now).

Merely entering the GETS RP namespace is never intended, alone, to 
gain any preferential treatment -- other than towards this 
authentication & authorization IVR.

I hope you can see that this is a completely separate type of service 
and implementation type than ECRIT based emergency calling will use.

BTW - to your comment below about me not calling your name out when 
you are incorrect because I have been equally incorrect -- I'm not 
sure I've been spared as much as you think, given that many have 
called me out by name when they've felt I've been wrong over the years.

>This authorization
>is tied to the entity that makes the request. For example, the person is
>working for the government and has special rights. James Bond as a (not so)
>secret agent might have these rights.
>
>The emergency services case (citizen-to-authority) is a bit different as
>there aren't really special rights with respect to authorization tied to
>individuals. Instead, the fact that something is an emergency is purely a
>judgement of the human that dials a special number. To deal with fraud, we
>discussed in the group on what we can actually do to ensure that end users
>do not bypass security procedures (such as authorization checks, charging
>and so on). Part of this investigation was the publication of
>http://www.ietf.org/rfc/rfc5069.txt that also describes this issue.
>
>So, imagine the implementation of a SIP proxy (and we implemented that
>stuff) that receives a call that contains a Service URN. The code branches
>into a special mode where everything is done so that the call receives
>appropriate treatment and does not get dropped on the floor. The way how the
>Service URN is placed in the message ensures that the call cannot go to my
>friend (instead of the PSAP) unless the end host ran LoST already. In the
>latter case, we discussed this also on the list for a while and Richard even
>wrote a draft about it in the context of the location hiding topic, we said
>that the proxy would have to run LoST if he cares about a potential
>fraudulent usage.
>
>So, what do we need todo in order to provide secure RFC 4412 functionality
>in our context?
>
>Do you think that the current text in
>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-nam
>espace-00.txt reflects any of the above-described issues:
>"
>    The Security considerations that apply to RFC 4412 [RFC4412] apply
>    here.  This document introduces no new security issues relative to
>    RFC 4412.
>"
>
> From various discussions in GEOPRIV I recall that you are super-sensitive
>regarding security and privacy. For some reasons you don't seem to have the
>same concerns here. I would like to understand your reasoning.
>
>Please also do me another favor: Don't always say that I don't understand
>the subject. Even if that would be the case it isn't particular fair given
>that different folks had to educate you on other topics in the past as well.
>Additionally, if you listen to the audio recordings then you will notice
>that Henning, Ted, and Jon do not seem to understand the issue either as
>they have raised similar issues during the F2F meetings.
>
>Ciao
>Hannes
>
>
> >Hannes - I believe it is you who do not understand RFC 4412 --
> >and many of us are trying to get that through to you, but you
> >don't seem to want to listen/read.
> >
> >RFC 4412 is *for* priority marking SIP requests,
> >
> >One use is GETS.
> >
> >One use is MLPP.
> >
> >These examples are in RFC 4412 because there were specific
> >namespaces being created for the IANA section of that document.
> >
> >Reading the whole document, you will see that RPH can be
> >specified for other uses than GETS or MLPP specifically.
> >
> >I knew when I wrote RFC 4412 that one day we would specify a
> >namespace for ECRIT (the "esnet" namespace now) -- but I also
> >knew it was premature for RFC 4412 to incorporate that
> >namespace, that a future doc to RFC 4412 would have to be
> >written to do this. Brian and I talked about this at the
> >original NENA meeting that created the IP WGs there (in August
> >of 03).  We both agreed we should wait until it was
> >appropriate to the work in the IETF to submit this document
> >that is now
> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >gency-rph-namespace-00.txt
> >
> >Yet, you seem to want to use some additional mechanism to
> >indicate priority of a call in SIP.  That means you want to
> >introduce a second way to accomplish this in SIP.  Why do you
> >want to promote a separate way to do something SIP has already
> >defined? That will cause interoperability issues and we both know that.
> >
> >You've said to me (and others) that you believe RPH is just
> >another way to accomplish what sos or a URI can indicate - and
> >you're wrong.  Your way would be _the_second_way_to_do_it,
> >because SIP already considers RPH to be *the*way* to priority
> >mark SIP requests.
> >
> >If you don't believe me (no comment), then why do you not
> >believe the SIP WG chair (who knows more about SIP than both
> >of us) - who, on this thread, has again said to you "RFC 4412
> >(RPH) is the SIP mechanism to priority mark SIP requests"?
> >
> >Further, I believe it is inappropriate to prohibit endpoints
> >from being able to set the esnet namespace.  I absolutely
> >believe it will not be needed most of the time, but I believe
> >if someone does find a valid use for endpoints to mark
> >priority in SIP, this ID - once it has become an RFC -- will
> >have to be obsoleted with a new RFC saying the exact opposite.
> >
> >(color me confused ... over and over again)
> >
> >James
> >
> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >>Keith, please understand that the usage of RFC 4412 for GETS and for
> >>the type of emergency call we discuss here is different. Just looking
> >>at the header and the name of the namespace is a bit
> >artificial. I hope
> >>you understand that.
> >>
> >> >-----Original Message-----
> >> >From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> >> >Sent: 05 February, 2009 14:55
> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
> >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >mistake)
> >> >
> >> >Which is exactly what RFC 4412 specifies for all namespaces.
> >> >
> >> >regards
> >> >
> >> >Keith
> >> >
> >> >> -----Original Message-----
> >> >> From: [email-masked] [mailto:[email-masked]]
> >> >On Behalf
> >> >> Of Brian Rosen
> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
> >Hannes (NSN
> >> >> - FI/Espoo)'; 'ECRIT'
> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >> mistake)
> >> >>
> >> >> The value is that in some networks where priority for
> >> >emergency calls
> >> >> is appropriate, and appropriate policing of marking is
> >implemented,
> >> >> emergency calls will receive resource priority.
> >> >>
> >> >> Not all networks would need policing.  Some will.  Policing could
> >> >> be to Route header/R-URI content, but other criteria are possible.
> >> >>
> >> >> Not all networks will need resource priority for emergency calls.
> >> >> Fine, ignore this marking/namespace.
> >> >>
> >> >> Brian
> >> >> > -----Original Message-----
> >> >> > From: Hannes Tschofenig [mailto:[email-masked]]
> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN -
> >> >> > FI/Espoo); 'ECRIT'
> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >> > mistake)
> >> >> >
> >> >> > I don't even see the value in permitting the endpoint todo the
> >> >> > RPH marking.
> >> >> > In addition to the security concerns there is also the
> >> >problem that
> >> >> > there are more options to implement without an additional value.
> >> >> >
> >> >> > >-----Original Message-----
> >> >> > >From: Brian Rosen [mailto:[email-masked]]
> >> >> > >Sent: 05 February, 2009 00:03
> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,
> >> >> Hannes (NSN -
> >> >> > >FI/Espoo)'; 'ECRIT'
> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >> > mistake)
> >> >> > >
> >> >> > >Hannes
> >> >> > >
> >> >> > >This matches my understanding precisely.  We wish to
> >> >> permit endpoints
> >> >> > >to mark. We do not require it, and don't necessarily expect it
> >> >> > >in many (even
> >> >> > >most) cases.  We don't wish to see the document prohibit it.
> >> >> > >We all seem to agree it has value within the Emergency
> >> >Services IP
> >> >> > >Networks.
> >> >> > >
> >> >> > >Brian
> >> >> > >
> >> >> > >> -----Original Message-----
> >> >> > >> From: [email-masked] [mailto:[email-masked]]
> >> >> > >On Behalf
> >> >> > >> Of James M. Polk
> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
> >> >> FI/Espoo); 'ECRIT'
> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
> >Agenda (my
> >> >> > >> mistake)
> >> >> > >>
> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> >> >> > >> > > James wrote:
> >> >> > >> > >> you are the _lone_ voice not supporting this ID,
> >> >> > >> >
> >> >> > >> >Listening to the audio recording of past meetings I have to
> >> >> > >say that
> >> >> > >> >I
> >> >> > >> was
> >> >> > >> >not the only persons raising concerns about the document.
> >> >> > >> >That was probably the reason why you agreed to limit the
> >> >> > >scope of the
> >> >> > >> >document (which you didn't later do) to get folks to agree
> >> >> > >to make it
> >> >> > >> a WG
> >> >> > >> >item.
> >> >> > >>
> >> >> > >> re-listen to the audio please
> >> >> > >>
> >> >> > >> Ted's concerns were consistent with most (all?) other
> >> >> concerns --
> >> >> > >> which were based on the premise of whether or not the
> >> >> UAC should be
> >> >> > >> trusted to initiate the marking on the INVITE.  The most
> >> >> > >> recent version has backed off this to a "can" -- meaning not
> >> >prohibited
> >> >> > >> (i.e., no 2119 text).  I also backed off the text in the
> >> >> SP domain
> >> >> > >> part to "can", such that there is no 2119 text
> >> >mandating or even
> >> >> > >> recommending its usage there. I also do not prohibit its
> >> >> > >use, based on
> >> >> > >> local policy.  Keith has come forward with the specific
> >> >> > >> request that non-ESInet networks be allowed to mark and pay
> >> >attention to
> >> >> > >> this priority indication -- with IMS as the specific example
> >> >> > >> he wishes to have this valid for.
> >> >> > >>
> >> >> > >> Where there is no disagreement, save for your recent
> >> >> > >pushback - is in
> >> >> > >> the ESInet, which is where Brian has requested it's
> >> >> > >definition in the
> >> >> > >> IETF on behalf of NENA.  He's the i3 WG chair within
> >> >> NENA, and if
> >> >> > >> he asks for it, are you going to say you know better than he?
> >> >> > >>
> >> >> > >>
> >> >> > >> >Btw, I not disagreeing with the document as such. I
> >> >just want to
> >> >> > the
> >> >> > >> scope
> >> >> > >> >to change. The usage of RPH within the emergency
> >> >> services network
> >> >> > is
> >> >> > >> fine
> >> >> > >> >for me. I may get convinced to start the RPH marking from
> >> >> > >the the VSP
> >> >> > >> >towards the PSAP. I feel uneasy about the end host doing
> >> >> > >the marking.
> >> >> > >>
> >> >> > >> please read what I wrote above, and then re-read the
> >> >most recent
> >> >> > >> version of the ID. I don't have endpoints that SHOULD or
> >> >> MUST mark
> >> >> > >> anything wrt RPH.  I also don't want to prohibit it,
> >> >> because there
> >> >> > >> might be cases (that I don't know of) of valid uses
> >> >> under certain
> >> >> > >> circumstances.  Figure 1 is very clear that there are 3
> >> >> networking
> >> >> > >> parts to consider
> >> >> > >>
> >> >> > >> #1 - from the endpoint
> >> >> > >> #2 - within the VSP
> >> >> > >> #3 - within the ESInet
> >> >> > >>
> >> >> > >> the most recent ID version has "can" for #s 1 and 2, and
> >> >> > >2119 language
> >> >> > >> offering those supporting this specification will have RPH
> >> >> > >> adherence within #3 (the ESInet).
> >> >> > >>
> >> >> > >> What other scope changes do you want, because I haven't
> >> >> heard them.
> >> >> > >>
> >> >> > >> I only heard you claim in email during the last IETF and in
> >> >> > >the ECRIT
> >> >> > >> session that RPH should not be used for priority marking
> >> >> requests.
> >> >> > >> This is something Keith (SIP WG chair) voiced his opposition
> >> >> > >> to your views regarding creating a second means for SIP to
> >> >priority
> >> >> > >> mark request "when SIP already has one interoperable way to
> >> >> > >> accomplish this... it's call the RP header mechanism".
> >> >> > >>
> >> >> > >> >I don't see advantages -- only disadvantages.
> >> >> > >> >
> >> >> > >> >Ciao
> >> >> > >> >Hannes
> >> >> > >>
> >> >> > >> _______________________________________________
> >> >> > >> Ecrit mailing list
> >> >> > >> [email-masked]
> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> > >
> >> >>
> >> >> _______________________________________________
> >> >> Ecrit mailing list
> >> >> [email-masked]
> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>
> >> >
> >

From: Henning Schulzrinne <[email-masked]>
To: "James M. Polk" <[email-masked]>
Date: Fri, 6 Feb 2009 17:05:21 -0500
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

James,

we don't go through every possible SIP header that might be inserted  
into emergency requests. Yes, somebody could add RPH, but this applies  
to PAI and dozens of other SIP headers as well. So far, nobody has  
provided, in my opinion, a compelling use case that is worth  
documenting. "It could be useful somewhere for something" doesn't cut  
it. I have provided multiple reasons why I think that it is a bad idea  
for (normal) UAs to do so, none of which you address. I see no need to  
say "do not insert RPH", as it would have to be be a no-op for the  
reasons I mentioned.

Henning

On Feb 6, 2009, at 4:45 PM, James M. Polk wrote:

> At 02:01 PM 2/6/2009, Winterbottom, James wrote:
>> Hi All,
>>
>> I have followed thi thread with some interest and I struggling to  
>> see a use case for the
>> providing RPH for emergency calls from the end-point.
>
> ok, let's address this concern only for a minute.
>
> If there is no use-case you can think of (for endpoints insertion of  
> RP namespace esnet), does that mean this RFC to-be has to prevent  
> (i.e., MUST NOT) endpoints from being allowed to insert esnet?  That  
> means, you feel and believe, you know about all customer  
> requirements everywhere, doesn't it?
>
> I'm not kidding or being snide here.
>
> Remember, this is a Standards Track doc for implementers, allowing  
> them the idea that some future specification MAY allow endpoints to  
> insert the RP header from endpoints gives them the ability to adjust  
> their code to that possibility.  There is the (good?) chance that at  
> least one customer (somewhere) of one or more vendors has this as a  
> requirement _now_, but we haven't heard about it yet.
>
> Stating in this to-be RFC that endpoints are forbidden from  
> inserting an RP header would prevent them from implementing/ 
> satisfying their customer requirement while still supporting this  
> specification.
>
> Remember, this RFC to-be DOES NOT say anything about endpoints MUST  
> or even SHOULD implement the "esnet" RP namespace in order to be  
> compliant with this spec.  It merely says MAY, which means "some  
> future spec MAY recommend or mandate it".
>
> I agree with Brian that robust security considerations stating that  
> endpoint implementations need to very careful about configuring this  
> capability needs to be written, and I will commit to writing that  
> text in the next rev of the doc.
>
> James
>

Date: Fri, 06 Feb 2009 16:10:08 -0600
To: Henning Schulzrinne <[email-masked]>, "Winterbottom, James" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

At 03:05 PM 2/6/2009, Henning Schulzrinne wrote:
>There's another problem with the "it doesn't hurt argument". Assume
>for a moment we have a "UA MAY include RPH" wording. There are now two
>cases:
>
>(1) All UAs implement it.
>
>(2) Only some UAs implement it.
>
>(1) seems unlikely for a MAY. If (2) occurs, we have the choice
>between two undesirable outcomes:
>
>(a) some UAs that are otherwise compliant get worse service just
>because they didn't include the RPH;

am I reading this correctly - that unless all UAs implement this 
capability this should never be implemented by any UAs?

This flies in the face of vendors solving for their customer's requirements.

I will admit that at this time, I know of no Cisco customers that 
want this capability, so I'm not angling for any of our revenue 
here.  I'm saying that I think I hear you saying this ID should say 
something like

         UAs are prevented from implementing the RP namespace esnet

I'm fighting against that, because customers are always coming to 
every vendor with new requirements, some of them unique at the 
time.  This prevention text would prevent a vendor from complying 
with this specification and still meet the customer's needs.

I believe that this ID needs to retain the endpoints MAY insert 
esnet, and have appropriate security considerations text that 
highlights the concerns expressed here.

Some future ID can then update this current RFC (to-be) within the 
2119 rules of the use of MAY here.

>OR
>
>(b) the proxy has to look for the service URN to give the call the
>appropriate treatment, thus obviating any advantage of having the
>header, yet incurring more complicated processing logic.
>
>
>I have no objection to whatever markings people want to apply to calls
>within an ESN - that's largely a private matter.
>
>Henning
>
>On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote:
>
>>Hi All,
>>
>>I have followed thi thread with some interest and I struggling to
>>see a use case for the
>>providing RPH for emergency calls from the end-point.
>>
>>The reference-model call in ECRIT, for better or worse, is for all
>>calls to go back through a home-VSP.
>>We placed quite a lot of emphasis, largely for traffing reasons, for
>>the VSP to be able to verify that
>>a call is in fact an emergency call. This is done by the proxy
>>taking the inband location, doing a LoST
>>query with the provided URN, and verifying that the resulting
>>destination URI is the same as the destination
>>URI provide in the SIP INVITE. My understanding was that VSPs would
>>always do this check so they could
>>tell if they could bill for the call or not, and because the VSP can
>>be use that the call is an emergency call
>>it can apply any special priorities that may be applicable. This
>>obviates the need for RPH from the end-point
>>to the network.
>>
>>This leaves us with the argument of "it doesn't hurt to it", which
>>is not a good reason to write a specification.
>>It was intimated on the geopriv mailing list last year that great
>>pains had been taken to keep SIP with in the
>>MTU limits of UDP over Ethernet 
>>(http://www.ietf.org/mail-archive/web/geopriv/current/msg06120.html ). Assuming
>>that this is the case, perhaps there is harm in including
>>information that we know will be ignored.
>>
>>Cheers
>>James
>>
>>
>>
>>-----Original Message-----
>>From: [email-masked] on behalf of Hannes Tschofenig
>>Sent: Fri 2/6/2009 12:33 PM
>>To: 'Brian Rosen'; 'Henning Schulzrinne'
>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
>>Subject: Re: [Ecrit] RPH
>>
>>To the story short here is the code for the proxy:
>>
>>---------------------
>>
>>IF emergency call was recognized THEN
>>    execute emergency call specific procedures (priority queuing,
>>preemption, fetch location, determine routing, do funny QoS things &
>>co)
>>ELSE
>>    normal call handling procedures.
>>
>>---------------------
>>
>>If you can make this differentiation between an emergency call and a
>>regular
>>call then you can also do everything that is necessary for emergency
>>call
>>handling.
>>
>>Brian + Keith: Please tell me that we cannot do the above with our
>>currently
>>specified mechanisms.
>>
>>Ciao
>>Hannes
>>
>>>-----Original Message-----
>>>From: Brian Rosen [mailto:[email-masked]]
>>>Sent: 06 February, 2009 17:49
>>>To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
>>>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
>>>Subject: RE: [Ecrit] RPH
>>>
>>>I agree that not all networks will permit (or pay attention
>>>to) a priority request from an end device.
>>>
>>>No one has asked for that.
>>>
>>>The namespace request has several uses, one of which is within
>>>an emergency services IP network, one of which is between
>>>elements within a public network controlled by the operator,
>>>and one of which is an endpoint request for resource priority.
>>>
>>>Those of us requesting this work proceed are happy if the
>>>endpoint part is simply left as possible (MAY), and, speaking
>>>for myself, having the draft discuss the security implications
>>>of endpoint marking is reasonable.
>>>
>>>Having discussed this issue with an implementation team who
>>>worked on MLPP systems, I am confident I know what I'm talking
>>>about, but YMMV.  The fact that you could, if you wanted to,
>>>give resource priority to a call you decided, however you
>>>decided, was an emergency call is an implementation decision,
>>>and not subject to standardization.
>>>
>>>RPH is the IETF standard way for one entity to request
>>>resource priority of another entity in a SIP system.  We're
>>>asking for a namespace to use that within the domain of
>>>emergency calls.  That is, I think, a VERY reasonable request.
>>>
>>>Brian
>>>
>>>>-----Original Message-----
>>>>From: Henning Schulzrinne [mailto:[email-masked]]
>>>>Sent: Friday, February 06, 2009 10:33 AM
>>>>To: Hannes Tschofenig
>>>>Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>>>>Subject: Re: [Ecrit] RPH
>>>>
>>>>To chime in here:
>>>>
>>>>I don't think it's productive to simply state that 4412
>>>doesn't worry
>>>>about authorization, so we shouldn't either (simplifying a bit).
>>>>Authorization was discussed repeatedly, and the general
>>>assumption was
>>>>that there were two conditions: Either the user invoking resource-
>>>>priority was well known and had a set of permissions that could be
>>>>checked in real time or there are ways to deal with abuse after the
>>>>fact in ways that deter abuse (the court-martial kind of thing in a
>>>>military context).
>>>>
>>>>The RFC 4412 security consideration (11.2) call this out in pretty
>>>>strong language:
>>>>
>>>>  Prioritized access to network and end-system resources imposes
>>>>    particularly stringent requirements on authentication and
>>>>    authorization mechanisms, since access to prioritized
>>>resources may
>>>>    impact overall system stability and performance and not
>>>just result
>>>>    in theft of, say, a single phone call.
>>>>Thus, the question is whether we have such strong authentication in
>>>>emergency calling. In some cases, such as residential fixed line
>>>>deployments where ISP = VSP, we're probably pretty close, in others,
>>>>such as prepaid cell phones or hot spots or VSP-only providers, we
>>>>aren't.
>>>>
>>>>The other point that I think Hannes is making is that the
>>>information
>>>>is either redundant or dangerous. If a processing element recognizes
>>>>the call as being an emergency call, it can apply whatever treatment
>>>>it deems appropriate and doesn't need additional information. If it
>>>>doesn't or can't, using just the RPH can be rather dangerous unless
>>>>that element can be reasonably certain that there is strong
>>>>authentication and recourse.
>>>>
>>>>I don't buy the argument that somehow finding the RPH is faster than
>>>>just looking for the identifier. Thus, given that the information is
>>>>either redundant or dangerous, I fail to see the advantage.
>>>>
>>>>Henning
>>>>
>>>>
>>>>On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
>>>>
>>>>>Don't get hung up on the details. There are ways to optimize it.
>>>>>That was
>>>>>not the point of the code example.
>>>>>
>>>>>The problem that my pseudo code should have shown you is that you
>>>>>* don't gain anything with RPH marking for the emergency call case
>>>>>from the SIP UA towards the outbound proxy since the functionality
>>>>>is already provide otherwise. How often does the proxy need to get
>>>>>told that this is an emergency call todo whatever emergency call
>>>>>handling procedures are necessary?
>>>>>* you only introduce fraud problems (if you are not
>>>careful and you
>>>>>understand the security stuff well enough)
>>>>>
>>>>>If you can point me to people who implement the RPH emergency call
>>>>>case please do so. I would love to talk to them.
>>>>>
>>>>>Ciao
>>>>>Hannes
>>>>>
>>>>>PS: You need to parse incoming messages to some extend so that you
>>>>>know what it contains :-) Only looking for the emergency
>>>RPH header
>>>>>(and not for the Service URN/dial
>>>>>string) would exactly be the DoS/fraud attack I am worried about.
>>>>>That's the thing Henning was worried about (go and listen to the
>>>>>past meeting minutes).
>>>>>
>>>>>
>>>>>>Hannes
>>>>>>
>>>>>>You need to talk to people who really implement this kind
>>>of thing.
>>>>>>You are way off.
>>>>>>
>>>>>>When you implement a resource priority system, the point of doing
>>>>>>that is to look though the queue of work and pick out the
>>>ones with
>>>>>>priority, handling them first.  You don't do all the parsing, you
>>>>>>don't do a lot of decision tree.
>>>>>>
>>>>>>Typically:
>>>>>>Check for DoS things, like too big messages, etc Do a quick scan
>>>>>>for the RPH message header If found:
>>>>>>Parse the message
>>>>>>Determine validity
>>>>>>Determine priority
>>>>>>Queue on the correct work queue
>>>>>>
>>>>>>The first two actions have to be very fast.  Anyone who builds a
>>>>>>SIP thingie will tell you that parsing is one of the big cycle
>>>>>>consumers: if you have to parse every message BEFORE you
>>>determine
>>>>>>priority, you can't give much resource priority.
>>>>>>Once you get the whole message parsed, you might as well finish
>>>>>>working on it, because you've done so much of the work.
>>>>>>OTHOH, finding the end-of-message delimiter and doing a quick
>>>>>>string search for RPH is fast.  If you are doing
>>>priority, you need
>>>>>>to keep all the priority processing pretty uniform, and pretty
>>>>>>simple, or you tend to spend too much time futzing around
>>>figuring
>>>>>>out what to do.  You put all the priority related stuff together,
>>>>>>and use as much common code as possible.
>>>>>>
>>>>>>Brian
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: [email-masked] [mailto:[email-masked]]
>>>>>>On Behalf
>>>>>>>Of Hannes Tschofenig
>>>>>>>Sent: Friday, February 06, 2009 8:41 AM
>>>>>>>To: 'Hannes Tschofenig'; 'Janet P Gunn'
>>>>>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-
>>>>>>>[email-masked]
>>>>>>>Subject: [Ecrit] RPH
>>>>>>>
>>>>>>>Over lunch I was also thinking how an outbound proxy would
>>>>implement
>>>>>>>some of the emergency procedures. Here are some thoughts:
>>>>>>>
>>>>>>>---------------------------------------------------
>>>>>>>
>>>>>>>// Process incoming message
>>>>>>>Parse(msg);
>>>>>>>
>>>>>>>// SIP INVITE without Service URN
>>>>>>>// legacy devices
>>>>>>>If (recognize-dialstring(msg)==TRUE) {  // we got an emergency
>>>>>>>call going on  emergency=TRUE;  if (dialstring(msg) == 911)
>>>>>>>serviceURN=urn:service:sos; } else if
>>>>>>>(recognize-serviceURN(msg)==TRUE) {  // oh. A updated
>>>device that
>>>>>>>has a service URN attached to the
>>>>call
>>>>>>>serviceURN=retrieve_ServiceURN(msg);
>>>>>>>emergency=TRUE;
>>>>>>>} else {
>>>>>>>// standard SIP message
>>>>>>>// regular processing
>>>>>>>process(msg);
>>>>>>>emergency=FALSE;
>>>>>>>}
>>>>>>>
>>>>>>>If (emergency == TRUE) {
>>>>>>>  // make sure that the emergency call does not get
>>>dropped on the
>>>>>>>floor
>>>>>>>  // skip authorization failures
>>>>>>>  // give the call a special treatment
>>>>>>>  lots-of-code-here();
>>>>>>>
>>>>>>>  // trigger all the QoS signaling you have in the
>>>network to make
>>>>>>>James happy
>>>>>>>  trigger-qos();
>>>>>>>
>>>>>>>  // query location
>>>>>>>  location=retrieve-location();
>>>>>>>
>>>>>>>  // determine next hop
>>>>>>>  next-hop=lost(location, serviceURN)
>>>>>>>
>>>>>>>  // attach RPH marking to outgoing msg to make James and
>>>>>>Keith happy
>>>>>>>  msg=add(msg, RPH);
>>>>>>>
>>>>>>>  send(msg, next-hop);
>>>>>>>}
>>>>>>>
>>>>>>>If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
>>>>>>>  // all the emergency related processing done already upfront
>>>>>>>  // hence I log something.
>>>>>>>  log(RPH_WAS_PRESENT_JUHU);
>>>>>>>} else if ((rph-present(msg) == TRUE) && (emergency ==
>>>FALSE)) {
>>>>>>>// this is not an emergency call  // this is something
>>>like GETS
>>>>>>>result=special-authorization-procedure(user);
>>>>>>>
>>>>>>>if (result == AUTHORIZED) {
>>>>>>>   // do some priority & preemption thing here.
>>>>>>>   // trigger all the QoS you have
>>>>>>>   lots-of-code-here();
>>>>>>>} else {
>>>>>>>   log("NOT AUTHORIZED; don't DoS my network");  } } else {  //
>>>>>>>don't need todo any RPH processing  // this includes the case
>>>>>>>where the call was an emergency call but the RPH
>>>>>>>
>>>>>>>// marking was not there.
>>>>>>>nothing();
>>>>>>>}
>>>>>>>
>>>>>>>---------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>Ciao
>>>>>>>Hannes
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: [email-masked] [mailto:[email-masked]] On
>>>>>>>>Behalf Of Hannes Tschofenig
>>>>>>>>Sent: 06 February, 2009 15:07
>>>>>>>>To: 'Janet P Gunn'
>>>>>>>>Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
>>>>>>>FI/Espoo)
>>>>>>>>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
>>>>>>>>
>>>>>>>>Who would define something that could prevent DoS problems?
>>>>>>>>
>>>>>>>>________________________________
>>>>>>>>
>>>>>>>>         From: Janet P Gunn [mailto:[email-masked]]
>>>>>>>>         Sent: 06 February, 2009 14:11
>>>>>>>>         To: Hannes Tschofenig
>>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
>>>>>>>>[email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
>>>>'James
>>>>>>>>M. Polk'
>>>>>>>>         Subject: Re: [Ecrit] ECRIT Virtual Interim
>>>Meeting: Agenda (RPH)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>         But there is nothing IN RFC4412 that specifically
>>>>>>addresses how to
>>>>>>>>prevent any particular namespace being used for DoS.  Anyone/any
>>>>UA
>>>>>>>>can ATTEMPT to invoke priority treatment by attaching RPH.  For
>>>>all
>>>>>>>>of the 4412 namespaces, as with the new proposed namespace, the
>>>>>>>>mechanisms for preventing DoS are not specified in the
>>>>>>document that
>>>>>>>>defines the namespace.
>>>>>>>>They are/will be specified elsewhere.
>>>>>>>>
>>>>>>>>         Janet
>>>>>>>>
>>>>>>>>         This is a PRIVATE message. If you are not the intended
>>>>>>recipient,
>>>>>>>>please delete without copying and kindly advise us by e-mail of
>>>>the
>>>>>>>>mistake in delivery.
>>>>>>>>         NOTE: Regardless of content, this e-mail shall not
>>>>>>operate to bind
>>>>>>>>CSC to any order or other contract unless pursuant to explicit
>>>>>>>>written agreement or government initiative expressly permitting
>>>>the
>>>>>>>>use of e-mail for such purpose.
>>>>>>>>
>>>>>>>>         [email-masked] wrote on 02/06/2009 04:21:51 AM:
>>>>>>>>
>>>>>>>>         > Hi James,
>>>>>>>>         >
>>>>>>>>         > I have read RFC 4412 and also the GETS/MLPP IETF
>>>>>>documents. What I
>>>>>>>>would
>>>>>>>>         > like to point out is that there is more than just a
>>>>>>header and
>>>>>>>>values within
>>>>>>>>         > the header that have to be considered in order to
>>>>>>make a judgement
>>>>>>>>of what
>>>>>>>>         > is appropriate and what isn't. There is an
>>>>>>architectural question
>>>>>>>>and
>>>>>>>>         > whether the environment we are using the stuff is
>>>>>>indeed providing
>>>>>>>>the
>>>>>>>>         > properties you need for the solution to be
>>>appropriate.
>>>>>>>>         >
>>>>>>>>         > Let me describe in more detail what I meant (and
>>>>>>please correct me
>>>>>>>>if I am
>>>>>>>>         > wrong).
>>>>>>>>         >
>>>>>>>>         > Getting priority for SIP requests when using a GETS
>>>>>>alike scenario
>>>>>>>>means
>>>>>>>>         > that the entity that issues the request is specially
>>>>>>authorized
>>>>>>>>since
>>>>>>>>         > otherwise you introduce a nice denial of
>>>service attack. This
>>>>>>>>authorization
>>>>>>>>         > is tied to the entity that makes the request. For
>>>>>>example, the
>>>>>>>>person is
>>>>>>>>         > working for the government and has special rights.
>>>>>>>>James Bond as a (not so)
>>>>>>>>         > secret agent might have these rights.
>>>>>>>>         >
>>>>>>>>         > The emergency services case
>>>(citizen-to-authority) is a bit
>>>>>>>>different as
>>>>>>>>         > there aren't really special rights with respect to
>>>>>>authorization
>>>>>>>>tied to
>>>>>>>>         > individuals. Instead, the fact that something is an
>>>>>>emergency is
>>>>>>>>purely a
>>>>>>>>         > judgement of the human that dials a special number.
>>>>>>>>To deal with fraud, we
>>>>>>>>         > discussed in the group on what we can actually do to
>>>>>>ensure that
>>>>>>>>end users
>>>>>>>>         > do not bypass security procedures (such as
>>>>>>authorization checks,
>>>>>>>>charging
>>>>>>>>         > and so on). Part of this investigation was
>>>the publication of
>>>>>>>>         > http://www.ietf.org/rfc/rfc5069.txt that also
>>>describes this
>>>>>>>>issue.
>>>>>>>>         >
>>>>>>>>         > So, imagine the implementation of a SIP proxy (and we
>>>>>>implemented
>>>>>>>>that
>>>>>>>>         > stuff) that receives a call that contains a Service
>>>>>>URN. The code
>>>>>>>>branches
>>>>>>>>         > into a special mode where everything is done
>>>so that the call
>>>>>>>>receives
>>>>>>>>         > appropriate treatment and does not get dropped on the
>>>>>>floor. The
>>>>>>>>way how the
>>>>>>>>         > Service URN is placed in the message ensures that the
>>>>>>call cannot
>>>>>>>>go to my
>>>>>>>>         > friend (instead of the PSAP) unless the end host ran
>>>>>>LoST already.
>>>>>>>>In the
>>>>>>>>         > latter case, we discussed this also on the list for a
>>>>>>while and
>>>>>>>>Richard even
>>>>>>>>         > wrote a draft about it in the context of the
>>>location hiding
>>>>>>>>topic, we said
>>>>>>>>         > that the proxy would have to run LoST if he
>>>cares about a
>>>>>>>>potential
>>>>>>>>         > fraudulent usage.
>>>>>>>>         >
>>>>>>>>         > So, what do we need todo in order to provide
>>>secure RFC 4412
>>>>>>>>functionality
>>>>>>>>         > in our context?
>>>>>>>>         >
>>>>>>>>         > Do you think that the current text in
>>>>>>>>         >
>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>>>>>>>>gency-rph-nam
>>>>>>>>         > espace-00.txt reflects any of the
>>>above-described issues:
>>>>>>>>         > "
>>>>>>>>         >    The Security considerations that apply to RFC 4412
>>>>>>>>[RFC4412]
>>>>>>>>apply
>>>>>>>>         >    here.  This document introduces no new security
>>>>>>>>issues relative
>>>>>>>>to
>>>>>>>>         >    RFC 4412.
>>>>>>>>         > "
>>>>>>>>         >
>>>>>>>>         > From various discussions in GEOPRIV I recall
>>>that you are
>>>>>>>>super-sensitive
>>>>>>>>         > regarding security and privacy. For some reasons you
>>>>>>don't seem to
>>>>>>>>have the
>>>>>>>>         > same concerns here. I would like to
>>>understand your reasoning.
>>>>>>>>         >
>>>>>>>>         > Please also do me another favor: Don't always say
>>>>>>that I don't
>>>>>>>>understand
>>>>>>>>         > the subject. Even if that would be the case it isn't
>>>>>>particular
>>>>>>>>fair given
>>>>>>>>         > that different folks had to educate you on other
>>>>>>topics in the
>>>>>>>>past as well.
>>>>>>>>         > Additionally, if you listen to the audio recordings
>>>>>>then you will
>>>>>>>>notice
>>>>>>>>         > that Henning, Ted, and Jon do not seem to understand
>>>>>>the issue
>>>>>>>>either as
>>>>>>>>         > they have raised similar issues during the
>>>F2F meetings.
>>>>>>>>         >
>>>>>>>>         > Ciao
>>>>>>>>         > Hannes
>>>>>>>>         >
>>>>>>>>         >
>>>>>>>>         > >Hannes - I believe it is you who do not understand
>>>>>>RFC 4412 --
>>>>>>>>         > >and many of us are trying to get that
>>>through to you, but you
>>>>>>>>         > >don't seem to want to listen/read.
>>>>>>>>         > >
>>>>>>>>         > >RFC 4412 is *for* priority marking SIP requests,
>>>>>>>>         > >
>>>>>>>>         > >One use is GETS.
>>>>>>>>         > >
>>>>>>>>         > >One use is MLPP.
>>>>>>>>         > >
>>>>>>>>         > >These examples are in RFC 4412 because there
>>>were specific
>>>>>>>>         > >namespaces being created for the IANA section of
>>>>>>that document.
>>>>>>>>         > >
>>>>>>>>         > >Reading the whole document, you will see
>>>that RPH can be
>>>>>>>>         > >specified for other uses than GETS or MLPP
>>>specifically.
>>>>>>>>         > >
>>>>>>>>         > >I knew when I wrote RFC 4412 that one day we
>>>would specify a
>>>>>>>>         > >namespace for ECRIT (the "esnet" namespace
>>>now) -- but I also
>>>>>>>>         > >knew it was premature for RFC 4412 to
>>>incorporate that
>>>>>>>>         > >namespace, that a future doc to RFC 4412
>>>would have to be
>>>>>>>>         > >written to do this. Brian and I talked about
>>>this at the
>>>>>>>>         > >original NENA meeting that created the IP WGs there
>>>>>>(in August
>>>>>>>>         > >of 03).  We both agreed we should wait until it was
>>>>>>>>         > >appropriate to the work in the IETF to
>>>submit this document
>>>>>>>>         > >that is now
>>>>>>>>         >
>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>>>>>>>>         > >gency-rph-namespace-00.txt
>>>>>>>>         > >
>>>>>>>>         > >Yet, you seem to want to use some additional
>>>mechanism to
>>>>>>>>         > >indicate priority of a call in SIP.  That
>>>means you want to
>>>>>>>>         > >introduce a second way to accomplish this in SIP.
>>>>>>>>Why do you
>>>>>>>>         > >want to promote a separate way to do something SIP
>>>>>>has already
>>>>>>>>         > >defined? That will cause interoperability issues and
>>>>>>we both know
>>>>>>>>that.
>>>>>>>>         > >
>>>>>>>>         > >You've said to me (and others) that you
>>>believe RPH is just
>>>>>>>>         > >another way to accomplish what sos or a URI can
>>>>>>indicate - and
>>>>>>>>         > >you're wrong.  Your way would be
>>>_the_second_way_to_do_it,
>>>>>>>>         > >because SIP already considers RPH to be
>>>*the*way* to priority
>>>>>>>>         > >mark SIP requests.
>>>>>>>>         > >
>>>>>>>>         > >If you don't believe me (no comment), then
>>>why do you not
>>>>>>>>         > >believe the SIP WG chair (who knows more
>>>about SIP than both
>>>>>>>>         > >of us) - who, on this thread, has again said
>>>to you "RFC 4412
>>>>>>>>         > >(RPH) is the SIP mechanism to priority mark
>>>SIP requests"?
>>>>>>>>         > >
>>>>>>>>         > >Further, I believe it is inappropriate to
>>>prohibit endpoints
>>>>>>>>         > >from being able to set the esnet namespace.
>>>I absolutely
>>>>>>>>         > >believe it will not be needed most of the
>>>time, but I believe
>>>>>>>>         > >if someone does find a valid use for
>>>endpoints to mark
>>>>>>>>         > >priority in SIP, this ID - once it has
>>>become an RFC -- will
>>>>>>>>         > >have to be obsoleted with a new RFC saying the exact
>>>>>>opposite.
>>>>>>>>         > >
>>>>>>>>         > >(color me confused ... over and over again)
>>>>>>>>         > >
>>>>>>>>         > >James
>>>>>>>>         > >
>>>>>>>>         > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>>>>>>>>         > >>Keith, please understand that the usage of RFC 4412
>>>>>>for GETS and
>>>>>>>>for
>>>>>>>>         > >>the type of emergency call we discuss here is
>>>>>>different. Just
>>>>>>>>looking
>>>>>>>>         > >>at the header and the name of the namespace is a bit
>>>>>>>>         > >artificial. I hope
>>>>>>>>         > >>you understand that.
>>>>>>>>         > >>
>>>>>>>>         > >> >-----Original Message-----
>>>>>>>>         > >> >From: DRAGE, Keith (Keith)
>>>>>>>>[mailto:[email-masked]]
>>>>>>>>         > >> >Sent: 05 February, 2009 14:55
>>>>>>>>         > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
>>>>>>>>Polk'; 'Tschofenig,
>>>>>>>>         > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
>>>>>>>>         > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
>>>>>>>>Meeting: Agenda (my
>>>>>>>>
>>>>>>>>         > >> >mistake)
>>>>>>>>         > >> >
>>>>>>>>         > >> >Which is exactly what RFC 4412 specifies for all
>>>>>>namespaces.
>>>>>>>>         > >> >
>>>>>>>>         > >> >regards
>>>>>>>>         > >> >
>>>>>>>>         > >> >Keith
>>>>>>>>         > >> >
>>>>>>>>         > >> >> -----Original Message-----
>>>>>>>>         > >> >> From: [email-masked]
>>>>>>[mailto:[email-masked]]
>>>>>>>>         > >> >On Behalf
>>>>>>>>         > >> >> Of Brian Rosen
>>>>>>>>         > >> >> Sent: Wednesday, February 04, 2009 10:19 PM
>>>>>>>>         > >> >> To: 'Hannes Tschofenig'; 'James M.
>>>Polk'; 'Tschofenig,
>>>>>>>>         > >Hannes (NSN
>>>>>>>>         > >> >> - FI/Espoo)'; 'ECRIT'
>>>>>>>>         > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>>>>>>>>Meeting: Agenda (my
>>>>>>>>         > >> >> mistake)
>>>>>>>>         > >> >>
>>>>>>>>         > >> >> The value is that in some networks
>>>where priority for
>>>>>>>>         > >> >emergency calls
>>>>>>>>         > >> >> is appropriate, and appropriate
>>>policing of marking is
>>>>>>>>         > >implemented,
>>>>>>>>         > >> >> emergency calls will receive resource priority.
>>>>>>>>         > >> >>
>>>>>>>>         > >> >> Not all networks would need policing.  Some
>>>>>>will.  Policing
>>>>>>>>could
>>>>>>>>         > >> >> be to Route header/R-URI content, but other
>>>>>>criteria are
>>>>>>>>possible.
>>>>>>>>         > >> >>
>>>>>>>>         > >> >> Not all networks will need resource priority
>>>>>>for emergency
>>>>>>>>calls.
>>>>>>>>         > >> >> Fine, ignore this marking/namespace.
>>>>>>>>         > >> >>
>>>>>>>>         > >> >> Brian
>>>>>>>>         > >> >> > -----Original Message-----
>>>>>>>>         > >> >> > From: Hannes Tschofenig
>>>>>>>>[mailto:[email-masked]]
>>>>>>>>         > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>>>>>>>>         > >> >> > To: 'Brian Rosen'; 'James M. Polk';
>>>>>>Tschofenig, Hannes
>>>>>>>>(NSN -
>>>>>>>>         > >> >> > FI/Espoo); 'ECRIT'
>>>>>>>>         > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
>>>>>>>>Meeting: Agenda (my
>>>>>>>>         > >> >> > mistake)
>>>>>>>>         > >> >> >
>>>>>>>>         > >> >> > I don't even see the value in permitting the
>>>>>>endpoint todo
>>>>>>>>the
>>>>>>>>         > >> >> > RPH marking.
>>>>>>>>         > >> >> > In addition to the security concerns
>>>there is also the
>>>>>>>>         > >> >problem that
>>>>>>>>         > >> >> > there are more options to implement without
>>>>>>an additional
>>>>>>>>value.
>>>>>>>>         > >> >> >
>>>>>>>>         > >> >> > >-----Original Message-----
>>>>>>>>         > >> >> > >From: Brian Rosen [mailto:[email-masked]]
>>>>>>>>         > >> >> > >Sent: 05 February, 2009 00:03
>>>>>>>>         > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
>>>>>>'Tschofenig,
>>>>>>>>         > >> >> Hannes (NSN -
>>>>>>>>         > >> >> > >FI/Espoo)'; 'ECRIT'
>>>>>>>>         > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual
>>>Interim Meeting:
>>>>>>>>Agenda (my
>>>>>>>>         > >> >> > mistake)
>>>>>>>>         > >> >> > >
>>>>>>>>         > >> >> > >Hannes
>>>>>>>>         > >> >> > >
>>>>>>>>         > >> >> > >This matches my understanding
>>>precisely.  We wish to
>>>>>>>>         > >> >> permit endpoints
>>>>>>>>         > >> >> > >to mark. We do not require it, and
>>>don't necessarily
>>>>>>>>expect it
>>>>>>>>         > >> >> > >in many (even
>>>>>>>>         > >> >> > >most) cases.  We don't wish to see the
>>>>>>document prohibit
>>>>>>>>it.
>>>>>>>>         > >> >> > >We all seem to agree it has value within the
>>>>>>Emergency
>>>>>>>>         > >> >Services IP
>>>>>>>>         > >> >> > >Networks.
>>>>>>>>         > >> >> > >
>>>>>>>>         > >> >> > >Brian
>>>>>>>>         > >> >> > >
>>>>>>>>         > >> >> > >> -----Original Message-----
>>>>>>>>         > >> >> > >> From: [email-masked]
>>>>>>>>[mailto:[email-masked]]
>>>>>>>>         > >> >> > >On Behalf
>>>>>>>>         > >> >> > >> Of James M. Polk
>>>>>>>>         > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
>>>>>>>>         > >> >> > >> To: Hannes Tschofenig; Tschofenig,
>>>Hannes (NSN -
>>>>>>>>         > >> >> FI/Espoo); 'ECRIT'
>>>>>>>>         > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>>>>>>>>Meeting:
>>>>>>>>         > >Agenda (my
>>>>>>>>         > >> >> > >> mistake)
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> At 02:37 PM 2/4/2009, Hannes
>>>Tschofenig wrote:
>>>>>>>>         > >> >> > >> > > James wrote:
>>>>>>>>         > >> >> > >> > >> you are the _lone_ voice not
>>>>>>supporting this ID,
>>>>>>>>         > >> >> > >> >
>>>>>>>>         > >> >> > >> >Listening to the audio recording of past
>>>>>>meetings I
>>>>>>>>have to
>>>>>>>>         > >> >> > >say that
>>>>>>>>         > >> >> > >> >I
>>>>>>>>         > >> >> > >> was
>>>>>>>>         > >> >> > >> >not the only persons raising
>>>concerns about the
>>>>>>>>document.
>>>>>>>>         > >> >> > >> >That was probably the reason why you
>>>>>>agreed to limit
>>>>>>>>the
>>>>>>>>         > >> >> > >scope of the
>>>>>>>>         > >> >> > >> >document (which you didn't later do) to
>>>>>>get folks to
>>>>>>>>agree
>>>>>>>>         > >> >> > >to make it
>>>>>>>>         > >> >> > >> a WG
>>>>>>>>         > >> >> > >> >item.
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> re-listen to the audio please
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> Ted's concerns were consistent with most
>>>>>>>>(all?) other
>>>>>>>>         > >> >> concerns --
>>>>>>>>         > >> >> > >> which were based on the premise of whether
>>>>>>or not the
>>>>>>>>         > >> >> UAC should be
>>>>>>>>         > >> >> > >> trusted to initiate the marking on the
>>>>>>INVITE.  The
>>>>>>>>most
>>>>>>>>         > >> >> > >> recent version has backed off this
>>>to a "can" --
>>>>>>>>meaning not
>>>>>>>>         > >> >prohibited
>>>>>>>>         > >> >> > >> (i.e., no 2119 text).  I also backed off
>>>>>>the text in
>>>>>>>>the
>>>>>>>>         > >> >> SP domain
>>>>>>>>         > >> >> > >> part to "can", such that there is
>>>no 2119 text
>>>>>>>>         > >> >mandating or even
>>>>>>>>         > >> >> > >> recommending its usage there. I also do
>>>>>>not prohibit
>>>>>>>>its
>>>>>>>>         > >> >> > >use, based on
>>>>>>>>         > >> >> > >> local policy.  Keith has come forward with
>>>>>>the specific
>>>>>>>>
>>>>>>>>         > >> >> > >> request that non-ESInet networks be
>>>>>>allowed to mark and
>>>>>>>>pay
>>>>>>>>         > >> >attention to
>>>>>>>>         > >> >> > >> this priority indication -- with IMS as
>>>>>>the specific
>>>>>>>>example
>>>>>>>>         > >> >> > >> he wishes to have this valid for.
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> Where there is no disagreement, save for
>>>>>>your recent
>>>>>>>>         > >> >> > >pushback - is in
>>>>>>>>         > >> >> > >> the ESInet, which is where Brian
>>>has requested it's
>>>>>>>>         > >> >> > >definition in the
>>>>>>>>         > >> >> > >> IETF on behalf of NENA.  He's the i3 WG
>>>>>>chair within
>>>>>>>>         > >> >> NENA, and if
>>>>>>>>         > >> >> > >> he asks for it, are you going to say you
>>>>>>know better
>>>>>>>>than he?
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> >Btw, I not disagreeing with the document
>>>>>>as such. I
>>>>>>>>         > >> >just want to
>>>>>>>>         > >> >> > the
>>>>>>>>         > >> >> > >> scope
>>>>>>>>         > >> >> > >> >to change. The usage of RPH
>>>within the emergency
>>>>>>>>         > >> >> services network
>>>>>>>>         > >> >> > is
>>>>>>>>         > >> >> > >> fine
>>>>>>>>         > >> >> > >> >for me. I may get convinced to start the
>>>>>>RPH marking
>>>>>>>>from
>>>>>>>>         > >> >> > >the the VSP
>>>>>>>>         > >> >> > >> >towards the PSAP. I feel uneasy about the
>>>>>>end host
>>>>>>>>doing
>>>>>>>>         > >> >> > >the marking.
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> please read what I wrote above, and then
>>>>>>re-read the
>>>>>>>>         > >> >most recent
>>>>>>>>         > >> >> > >> version of the ID. I don't have endpoints
>>>>>>that SHOULD
>>>>>>>>or
>>>>>>>>         > >> >> MUST mark
>>>>>>>>         > >> >> > >> anything wrt RPH.  I also don't want to
>>>>>>prohibit it,
>>>>>>>>         > >> >> because there
>>>>>>>>         > >> >> > >> might be cases (that I don't know
>>>of) of valid uses
>>>>>>>>         > >> >> under certain
>>>>>>>>         > >> >> > >> circumstances.  Figure 1 is very clear
>>>>>>that there are 3
>>>>>>>>         > >> >> networking
>>>>>>>>         > >> >> > >> parts to consider
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> #1 - from the endpoint
>>>>>>>>         > >> >> > >> #2 - within the VSP
>>>>>>>>         > >> >> > >> #3 - within the ESInet
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> the most recent ID version has "can" for
>>>>>>#s 1 and 2,
>>>>>>>>and
>>>>>>>>         > >> >> > >2119 language
>>>>>>>>         > >> >> > >> offering those supporting this
>>>>>>specification will have
>>>>>>>>RPH
>>>>>>>>         > >> >> > >> adherence within #3 (the ESInet).
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> What other scope changes do you want,
>>>>>>because I haven't
>>>>>>>>         > >> >> heard them.
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> I only heard you claim in email during the
>>>>>>last IETF
>>>>>>>>and in
>>>>>>>>         > >> >> > >the ECRIT
>>>>>>>>         > >> >> > >> session that RPH should not be
>>>used for priority
>>>>>>>>marking
>>>>>>>>         > >> >> requests.
>>>>>>>>         > >> >> > >> This is something Keith (SIP WG
>>>chair) voiced his
>>>>>>>>opposition
>>>>>>>>         > >> >> > >> to your views regarding creating a second
>>>>>>means for SIP
>>>>>>>>to
>>>>>>>>         > >> >priority
>>>>>>>>         > >> >> > >> mark request "when SIP already has one
>>>>>>interoperable
>>>>>>>>way to
>>>>>>>>         > >> >> > >> accomplish this... it's call the RP header
>>>>>>mechanism".
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >> >I don't see advantages -- only
>>>disadvantages.
>>>>>>>>         > >> >> > >> >
>>>>>>>>         > >> >> > >> >Ciao
>>>>>>>>         > >> >> > >> >Hannes
>>>>>>>>         > >> >> > >>
>>>>>>>>         > >> >> > >>
>>>_______________________________________________
>>>>>>>>         > >> >> > >> Ecrit mailing list
>>>>>>>>         > >> >> > >> [email-masked]
>>>>>>>>         > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>         > >> >> > >
>>>>>>>>         > >> >>
>>>>>>>>         > >> >> _______________________________________________
>>>>>>>>         > >> >> Ecrit mailing list
>>>>>>>>         > >> >> [email-masked]
>>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>         > >> >>
>>>>>>>>         > >> >
>>>>>>>>         > >
>>>>>>>>         >
>>>>>>>>         > _______________________________________________
>>>>>>>>         > Ecrit mailing list
>>>>>>>>         > [email-masked]
>>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>_______________________________________________
>>>>>>>>Ecrit mailing list
>>>>>>>>[email-masked]
>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>Ecrit mailing list
>>>>>>>[email-masked]
>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>>>_______________________________________________
>>>>>Ecrit mailing list
>>>>>[email-masked]
>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/ecrit
>>
>>
>>------------------------------------------------------------------------------------------------
>>This message is for the designated recipient only and may
>>contain privileged, proprietary, or otherwise private information.
>>If you have received it in error, please notify the sender
>>immediately and delete the original.  Any unauthorized use of
>>this email is prohibited.
>>------------------------------------------------------------------------------------------------
>>[mf2]
>>
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

Content-class: urn:content-classes:message
Date: Fri, 6 Feb 2009 17:14:46 -0500
From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Ecrit] RPH

Date: Fri, 06 Feb 2009 16:15:54 -0600
To: Ted Hardie <[email-masked]>, Henning Schulzrinne <[email-masked]>, "Winterbottom, James" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

At 03:27 PM 2/6/2009, Ted Hardie wrote:
>At 1:05 PM -0800 2/6/09, Henning Schulzrinne wrote:
> >There's another problem with the "it doesn't hurt argument". Assume
> >for a moment we have a "UA MAY include RPH" wording. There are now two
> >cases:
>
>Is it ever a protocol error for a SIP entity to include RPH?

no - no error exists for this. The SIP rule about headers comes from 
RFC 3261 (SIP base spec) that non-understood headers are ignored.

>Or is it always the expectation that it generally might be included, 
>and may be roundly
>ignored?

I'm not sure "it generally might be included"... unless you are in a 
network that mandates its inclusion, for now, such as US military networks.

>If the latter is true, then the key thing is for those interested in 
>having this
>work in a specific context to publish the namespace they will use in that
>context.  Others in similar contexts may adopt that, if they like.   But
>the UA/general SIP handling isn't different here just because it is an
>emergency call.   It's only different in contexts where that RPH namespace
>is in use, and only because of an agreement to do so; presumably the 
>interested
>party could assign RPH values to non-emergency calls too

sure

>, so it isn't a tight linkage between emergency-special handling.
>
>I'm just trying to figure out whether we're introducing a new situation
>in which the call processing for emergency calls is different.  We've
>agreed previously to try to minimize those.  If the call processing here
>is the standard RPH processing (which seems to be "your mileage may
>vary"), then we probably don't even need to call it out.

I'm not sure I understand your "then we probably don't even need to 
call it out"...

Does this mean you are advocating preventing UAs from including it in 
the text, or saying UA are allowed to, but there are potentially 
serious concerns you (mr customer) need to consider if you are 
thinking of including this header?

>Possibly confused,
>                                 Ted
>
>
>
> >(1) All UAs implement it.
> >
> >(2) Only some UAs implement it.
> >
> >(1) seems unlikely for a MAY. If (2) occurs, we have the choice
> >between two undesirable outcomes:
> >
> >(a) some UAs that are otherwise compliant get worse service just
> >because they didn't include the RPH;
> >
> >OR
> >
> >(b) the proxy has to look for the service URN to give the call the
> >appropriate treatment, thus obviating any advantage of having the
> >header, yet incurring more complicated processing logic.
> >
> >
> >I have no objection to whatever markings people want to apply to calls
> >within an ESN - that's largely a private matter.
> >
> >Henning
> >
> >On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote:
> >
> >> Hi All,
> >>
> >> I have followed thi thread with some interest and I struggling to
> >> see a use case for the
> >> providing RPH for emergency calls from the end-point.
> >>
> >> The reference-model call in ECRIT, for better or worse, is for all
> >> calls to go back through a home-VSP.
> >> We placed quite a lot of emphasis, largely for traffing reasons, for
> >> the VSP to be able to verify that
> >> a call is in fact an emergency call. This is done by the proxy
> >> taking the inband location, doing a LoST
> >> query with the provided URN, and verifying that the resulting
> >> destination URI is the same as the destination
> >> URI provide in the SIP INVITE. My understanding was that VSPs would
> >> always do this check so they could
> >> tell if they could bill for the call or not, and because the VSP can
> >> be use that the call is an emergency call
> >> it can apply any special priorities that may be applicable. This
> >> obviates the need for RPH from the end-point
> >> to the network.
> >>
> >> This leaves us with the argument of "it doesn't hurt to it", which
> >> is not a good reason to write a specification.
> >> It was intimated on the geopriv mailing list last year that great
> >> pains had been taken to keep SIP with in the
> >> MTU limits of UDP over Ethernet 
> (http://www.ietf.org/mail-archive/web/geopriv/current/msg06120.html
> >> ). Assuming
> >> that this is the case, perhaps there is harm in including
> >> information that we know will be ignored.
> >>
> >> Cheers
> >> James
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: [email-masked] on behalf of Hannes Tschofenig
> >> Sent: Fri 2/6/2009 12:33 PM
> >> To: 'Brian Rosen'; 'Henning Schulzrinne'
> >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
> >> Subject: Re: [Ecrit] RPH
> >>
> >> To the story short here is the code for the proxy:
> >>
> >> ---------------------
> >>
> >> IF emergency call was recognized THEN
> >>    execute emergency call specific procedures (priority queuing,
> > > preemption, fetch location, determine routing, do funny QoS things &
> >> co)
> >> ELSE
> >>    normal call handling procedures.
> >>
> >> ---------------------
> >>
> >> If you can make this differentiation between an emergency call and a
> >> regular
> >> call then you can also do everything that is necessary for emergency
> >> call
> >> handling.
> >>
> >> Brian + Keith: Please tell me that we cannot do the above with our
> >> currently
> >> specified mechanisms.
> >>
> >> Ciao
> >> Hannes
> >>
> >>> -----Original Message-----
> >>> From: Brian Rosen [mailto:[email-masked]]
> >>> Sent: 06 February, 2009 17:49
> >>> To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
> >>> Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >>> Subject: RE: [Ecrit] RPH
> >>>
> >>> I agree that not all networks will permit (or pay attention
> >>> to) a priority request from an end device.
> >>>
> >>> No one has asked for that.
> >>>
> >>> The namespace request has several uses, one of which is within
> >>> an emergency services IP network, one of which is between
> >>> elements within a public network controlled by the operator,
> >>> and one of which is an endpoint request for resource priority.
> >>>
> >>> Those of us requesting this work proceed are happy if the
> >>> endpoint part is simply left as possible (MAY), and, speaking
> >>> for myself, having the draft discuss the security implications
> >>> of endpoint marking is reasonable.
> >>>
> >>> Having discussed this issue with an implementation team who
> >>> worked on MLPP systems, I am confident I know what I'm talking
> >>> about, but YMMV.  The fact that you could, if you wanted to,
> >>> give resource priority to a call you decided, however you
> >>> decided, was an emergency call is an implementation decision,
> >>> and not subject to standardization.
> >>>
> >>> RPH is the IETF standard way for one entity to request
> >>> resource priority of another entity in a SIP system.  We're
> >>> asking for a namespace to use that within the domain of
> >>> emergency calls.  That is, I think, a VERY reasonable request.
> >>>
> >>> Brian
> >>>
> >>>> -----Original Message-----
> >>>> From: Henning Schulzrinne [mailto:[email-masked]]
> >>>> Sent: Friday, February 06, 2009 10:33 AM
> >>>> To: Hannes Tschofenig
> >>>> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
> >>>> Subject: Re: [Ecrit] RPH
> >>>>
> >>>> To chime in here:
> >>>>
> >>>> I don't think it's productive to simply state that 4412
> >>> doesn't worry
> >>>> about authorization, so we shouldn't either (simplifying a bit).
> >>>> Authorization was discussed repeatedly, and the general
> >>> assumption was
> >>>> that there were two conditions: Either the user invoking resource-
> >>>> priority was well known and had a set of permissions that could be
> >>>> checked in real time or there are ways to deal with abuse after the
> >>>> fact in ways that deter abuse (the court-martial kind of thing in a
> >>>> military context).
> >>>>
> >>>> The RFC 4412 security consideration (11.2) call this out in pretty
> >>>> strong language:
> >>>>
> >>>>  Prioritized access to network and end-system resources imposes
> >>>>    particularly stringent requirements on authentication and
> >>>>    authorization mechanisms, since access to prioritized
> >>> resources may
> >>>>    impact overall system stability and performance and not
> >>> just result
> >>>>    in theft of, say, a single phone call.
> >>>> Thus, the question is whether we have such strong authentication in
> >>>> emergency calling. In some cases, such as residential fixed line
> >>>> deployments where ISP = VSP, we're probably pretty close, in others,
> >>>> such as prepaid cell phones or hot spots or VSP-only providers, we
> >>>> aren't.
> >>>>
> >>>> The other point that I think Hannes is making is that the
> >>> information
> >>>> is either redundant or dangerous. If a processing element recognizes
> >>>> the call as being an emergency call, it can apply whatever treatment
> >>>> it deems appropriate and doesn't need additional information. If it
> >>>> doesn't or can't, using just the RPH can be rather dangerous unless
> >>>> that element can be reasonably certain that there is strong
> >>>> authentication and recourse.
> >>>>
> >>>> I don't buy the argument that somehow finding the RPH is faster than
> >>>> just looking for the identifier. Thus, given that the information is
> > >>> either redundant or dangerous, I fail to see the advantage.
> >>>>
> >>>> Henning
> >>>>
> >>>>
> >>>> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
> >>>>
> >>>>> Don't get hung up on the details. There are ways to optimize it.
> >>>>> That was
> >>>>> not the point of the code example.
> >>>>>
> >>>>> The problem that my pseudo code should have shown you is that you
> >>>>> * don't gain anything with RPH marking for the emergency call case
> >>>>> from the SIP UA towards the outbound proxy since the functionality
> >>>>> is already provide otherwise. How often does the proxy need to get
> >>>>> told that this is an emergency call todo whatever emergency call
> >>>>> handling procedures are necessary?
> >>>>> * you only introduce fraud problems (if you are not
> >>> careful and you
> >>>>> understand the security stuff well enough)
> >>>>>
> >>>>> If you can point me to people who implement the RPH emergency call
> >>>>> case please do so. I would love to talk to them.
> >>>>>
> >>>>> Ciao
> >>>>> Hannes
> >>>>>
> >>>>> PS: You need to parse incoming messages to some extend so that you
> >>>>> know what it contains :-) Only looking for the emergency
> >>> RPH header
> >>>>> (and not for the Service URN/dial
> >>>>> string) would exactly be the DoS/fraud attack I am worried about.
> >>>>> That's the thing Henning was worried about (go and listen to the
> >>>>> past meeting minutes).
> >>>>>
> >>>>>
> >>>>>> Hannes
> >>>>>>
> >>>>>> You need to talk to people who really implement this kind
> >>> of thing.
> >>>>>> You are way off.
> >>>>>>
> >>>>>> When you implement a resource priority system, the point of doing
> >>>>>> that is to look though the queue of work and pick out the
> >>> ones with
> >>>>>> priority, handling them first.  You don't do all the parsing, you
> >>>>>> don't do a lot of decision tree.
> >>>>>>
> >>>>>> Typically:
> >>>>>> Check for DoS things, like too big messages, etc Do a quick scan
> >>>>>> for the RPH message header If found:
> >>>>>> Parse the message
> >>>>>> Determine validity
> >>>>>> Determine priority
> >>>>>> Queue on the correct work queue
> >>>>>>
> >>>>>> The first two actions have to be very fast.  Anyone who builds a
> >>>>>> SIP thingie will tell you that parsing is one of the big cycle
> >>>>>> consumers: if you have to parse every message BEFORE you
> >>> determine
> >>>>>> priority, you can't give much resource priority.
> >>>>>> Once you get the whole message parsed, you might as well finish
> >>>>>> working on it, because you've done so much of the work.
> >>>>>> OTHOH, finding the end-of-message delimiter and doing a quick
> >>>>>> string search for RPH is fast.  If you are doing
> >>> priority, you need
> >>>>>> to keep all the priority processing pretty uniform, and pretty
> >>>>>> simple, or you tend to spend too much time futzing around
> >>> figuring
> >>>>>> out what to do.  You put all the priority related stuff together,
> >>>>>> and use as much common code as possible.
> >>>>>>
> >>>>>> Brian
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: [email-masked] [mailto:[email-masked]]
> >>>>>> On Behalf
> >>>>>>> Of Hannes Tschofenig
> >>>>>>> Sent: Friday, February 06, 2009 8:41 AM
> >>>>>>> To: 'Hannes Tschofenig'; 'Janet P Gunn'
> >>>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-
> >>>>>>> [email-masked]
> >>>>>>> Subject: [Ecrit] RPH
> >>>>>>>
> >>>>>>> Over lunch I was also thinking how an outbound proxy would
> >>>> implement
> >>>>>>> some of the emergency procedures. Here are some thoughts:
> >>>>>>>
> >>>>>>> ---------------------------------------------------
> >>>>>>>
> >>>>>>> // Process incoming message
> >>>>>>> Parse(msg);
> >>>>>>>
> >>>>>>> // SIP INVITE without Service URN
> >>>>>>> // legacy devices
> >>>>>>> If (recognize-dialstring(msg)==TRUE) {  // we got an emergency
> >>>>>>> call going on  emergency=TRUE;  if (dialstring(msg) == 911)
> >>>>>>> serviceURN=urn:service:sos; } else if
> >>>>>>> (recognize-serviceURN(msg)==TRUE) {  // oh. A updated
> >>> device that
> >>>>>>> has a service URN attached to the
> >>>> call
> >>>>>>> serviceURN=retrieve_ServiceURN(msg);
> >>>>>>> emergency=TRUE;
> >>>>>>> } else {
> >>>>>>> // standard SIP message
> >>>>>>> // regular processing
> >>>>>>> process(msg);
> >>>>>>> emergency=FALSE;
> >>>>>>> }
> >>>>>>>
> >>>>>>> If (emergency == TRUE) {
> >>>>>>>  // make sure that the emergency call does not get
> > >> dropped on the
> >>>>>>> floor
> >>>>>>>  // skip authorization failures
> >>>>>>>  // give the call a special treatment
> >>>>>>>  lots-of-code-here();
> >>>>>>>
> >>>>>>>  // trigger all the QoS signaling you have in the
> >>> network to make
> >>>>>>> James happy
> >>>>>>>  trigger-qos();
> >>>>>>>
> >>>>>>>  // query location
> >>>>>>>  location=retrieve-location();
> >>>>>>>
> >>>>>>>  // determine next hop
> >>>>>>>  next-hop=lost(location, serviceURN)
> >>>>>>>
> >>>>>>>  // attach RPH marking to outgoing msg to make James and
> >>>>>> Keith happy
> >>>>>>>  msg=add(msg, RPH);
> >>>>>>>
> >>>>>>>  send(msg, next-hop);
> >>>>>>> }
> >>>>>>>
> >>>>>>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
> >>>>>>>  // all the emergency related processing done already upfront
> >>>>>>>  // hence I log something.
> >>>>>>>  log(RPH_WAS_PRESENT_JUHU);
> >>>>>>> } else if ((rph-present(msg) == TRUE) && (emergency ==
> >>> FALSE)) {
> >>>>>>> // this is not an emergency call  // this is something
> >>> like GETS
> >>>>>>> result=special-authorization-procedure(user);
> >>>>>>>
> >>>>>>> if (result == AUTHORIZED) {
> >>>>>>>   // do some priority & preemption thing here.
> >>>>>>>   // trigger all the QoS you have
> >>>>>>>   lots-of-code-here();
> >>>>>>> } else {
> >>>>>>>   log("NOT AUTHORIZED; don't DoS my network");  } } else {  //
> >>>>>>> don't need todo any RPH processing  // this includes the case
> >>>>>>> where the call was an emergency call but the RPH
> >>>>>>>
> >>>>>>> // marking was not there.
> >>>>>>> nothing();
> >>>>>>> }
> >>>>>>>
> >>>>>>> ---------------------------------------------------
> >>>>>>>
> >>>>>>>
> >>>>>>> Ciao
> >>>>>>> Hannes
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: [email-masked] [mailto:[email-masked]] On
> >>>>>>>> Behalf Of Hannes Tschofenig
> >>>>>>>> Sent: 06 February, 2009 15:07
> >>>>>>>> To: 'Janet P Gunn'
> >>>>>>>> Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
> >>>>>>> FI/Espoo)
> >>>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
> >>>>>>>>
> >>>>>>>> Who would define something that could prevent DoS problems?
> >>>>>>>>
> >>>>>>>> ________________________________
> >>>>>>>>
> >>>>>>>>         From: Janet P Gunn [mailto:[email-masked]]
> >>>>>>>>         Sent: 06 February, 2009 14:11
> >>>>>>>>         To: Hannes Tschofenig
> >>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >>>>>>>> [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
> >>>> 'James
> >>>>>>>> M. Polk'
> >>>>>>>>         Subject: Re: [Ecrit] ECRIT Virtual Interim
> >>> Meeting: Agenda (RPH)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>         But there is nothing IN RFC4412 that specifically
> >>>>>> addresses how to
> >>>>>>>> prevent any particular namespace being used for DoS.  Anyone/any
> >>>> UA
> >>>>>>>> can ATTEMPT to invoke priority treatment by attaching RPH.  For
> >>>> all
> >>>>>>>> of the 4412 namespaces, as with the new proposed namespace, the
> >>>>>>>> mechanisms for preventing DoS are not specified in the
> >>>>>> document that
> >>>>>>>> defines the namespace.
> >>>>>>>> They are/will be specified elsewhere.
> >>>>>>>>
> >>>>>>>>         Janet
> >>>>>>>>
> >>>>>>>>         This is a PRIVATE message. If you are not the intended
> >>>>>> recipient,
> >>>>>>>> please delete without copying and kindly advise us by e-mail of
> >>>> the
> >>>>>>>> mistake in delivery.
> >>>>>>>>         NOTE: Regardless of content, this e-mail shall not
> >>>>>> operate to bind
> >>>>>>>> CSC to any order or other contract unless pursuant to explicit
> >>>>>>>> written agreement or government initiative expressly permitting
> >>>> the
> >>>>>>>> use of e-mail for such purpose.
> >>>>>>>>
> >>>>>>>>         [email-masked] wrote on 02/06/2009 04:21:51 AM:
> >>>>>>>>
> >>>>>>>>         > Hi James,
> >>>>>>>>         >
> >>>>>>>>         > I have read RFC 4412 and also the GETS/MLPP IETF
> >>>>>> documents. What I
> >>>>>>>> would
> >>>>>>>>         > like to point out is that there is more than just a
> >>>>>> header and
> >>>>>>>> values within
> >>>>>>>>         > the header that have to be considered in order to
> >>>>>> make a judgement
> >>>>>>>> of what
> >>>>>>>>         > is appropriate and what isn't. There is an
> >>>>>> architectural question
> >>>>>>>> and
> >>>>>>>>         > whether the environment we are using the stuff is
> >>>>>> indeed providing
> > >>>>>>> the
> >>>>>>>>         > properties you need for the solution to be
> >>> appropriate.
> >>>>>>>>         >
> >>>>>>>>         > Let me describe in more detail what I meant (and
> >>>>>> please correct me
> >>>>>>>> if I am
> >>>>>>>>         > wrong).
> >>>>>>>>         >
> >>>>>>>>         > Getting priority for SIP requests when using a GETS
> >>>>>> alike scenario
> >>>>>>>> means
> >>>>>>>>         > that the entity that issues the request is specially
> >>>>>> authorized
> >>>>>>>> since
> >>>>>>>>         > otherwise you introduce a nice denial of
> >>> service attack. This
> >>>>>>>> authorization
> >>>>>>>>         > is tied to the entity that makes the request. For
> >>>>>> example, the
> >>>>>>>> person is
> >>>>>>>>         > working for the government and has special rights.
> >>>>>>>> James Bond as a (not so)
> >>>>>>>>         > secret agent might have these rights.
> >>>>>>>>         >
> >>>>>>>>         > The emergency services case
> >>> (citizen-to-authority) is a bit
> >>>>>>>> different as
> >>>>>>>>         > there aren't really special rights with respect to
> >>>>>> authorization
> >>>>>>>> tied to
> >>>>>>>>         > individuals. Instead, the fact that something is an
> >>>>>> emergency is
> >>>>>>>> purely a
> >>>>>>>>         > judgement of the human that dials a special number.
> >>>>>>>> To deal with fraud, we
> >>>>>>>>         > discussed in the group on what we can actually do to
> >>>>>> ensure that
> >>>>>>>> end users
> >>>>>>>>         > do not bypass security procedures (such as
> >>>>>> authorization checks,
> >>>>>>>> charging
> >>>>>>>>         > and so on). Part of this investigation was
> >>> the publication of
> >>>>>>>>         > http://www.ietf.org/rfc/rfc5069.txt that also
> >>> describes this
> >>>>>>>> issue.
> >>>>>>>>         >
> >>>>>>>>         > So, imagine the implementation of a SIP proxy (and we
> >>>>>> implemented
> >>>>>>>> that
> >>>>>>>>         > stuff) that receives a call that contains a Service
> >>>>>> URN. The code
> >>>>>>>> branches
> >>>>>>>>         > into a special mode where everything is done
> >>> so that the call
> >>>>>>>> receives
> >>>>>>>>         > appropriate treatment and does not get dropped on the
> >>>>>> floor. The
> >>>>>>>> way how the
> >>>>>>>>         > Service URN is placed in the message ensures that the
> >>>>>> call cannot
> >>>>>>>> go to my
> >>>>>>>>         > friend (instead of the PSAP) unless the end host ran
> >>>>>> LoST already.
> >>>>>>>> In the
> >>>>>>>>         > latter case, we discussed this also on the list for a
> >>>>>> while and
> >>>>>>>> Richard even
> >>>>>>>>         > wrote a draft about it in the context of the
> >>> location hiding
> >>>>>>>> topic, we said
> >>>>>>>>         > that the proxy would have to run LoST if he
> >>> cares about a
> >>>>>>>> potential
> >>>>>>>>         > fraudulent usage.
> >>>>>>>>         >
> >>>>>>>>         > So, what do we need todo in order to provide
> >>> secure RFC 4412
> >>>>>>>> functionality
> >>>>>>>>         > in our context?
> >>>>>>>>         >
> >>>>>>>>         > Do you think that the current text in
> >>>>>>>>         >
> >>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >>>>>>>> gency-rph-nam
> >>>>>>>>         > espace-00.txt reflects any of the
> >>> above-described issues:
> >>>>>>>>         > "
> >>>>>>>>         >    The Security considerations that apply to RFC 4412
> >>>>>>>> [RFC4412]
> >>>>>>>> apply
> >>>>>>>>         >    here.  This document introduces no new security
> >>>>>>>> issues relative
> >>>>>>>> to
> >>>>>>>>         >    RFC 4412.
> >>>>>>>>         > "
> >>>>>>>>         >
> >>>>>>>>         > From various discussions in GEOPRIV I recall
> >>> that you are
> >>>>>>>> super-sensitive
> >>>>>>>>         > regarding security and privacy. For some reasons you
> >>>>>> don't seem to
> >>>>>>>> have the
> >>>>>>>>         > same concerns here. I would like to
> >>> understand your reasoning.
> >>>>>>>>         >
> >>>>>>>>         > Please also do me another favor: Don't always say
> >>>>>> that I don't
> >>>>>>>> understand
> >>>>>>>>         > the subject. Even if that would be the case it isn't
> >>>>>> particular
> >>>>>>>> fair given
> >>>>>>>>         > that different folks had to educate you on other
> >>>>>> topics in the
> >>>>>>>> past as well.
> >>>>>>>>         > Additionally, if you listen to the audio recordings
> >>>>>> then you will
> > >>>>>>> notice
> >>>>>>>>         > that Henning, Ted, and Jon do not seem to understand
> >>>>>> the issue
> >>>>>>>> either as
> >>>>>>>>         > they have raised similar issues during the
> >>> F2F meetings.
> >>>>>>>>         >
> >>>>>>>>         > Ciao
> >>>>>>>>         > Hannes
> >>>>>>>>         >
> >>>>>>>>         >
> >>>>>>>>         > >Hannes - I believe it is you who do not understand
> >>>>>> RFC 4412 --
> >>>>>>>>         > >and many of us are trying to get that
> >>> through to you, but you
> >>>>>>>>         > >don't seem to want to listen/read.
> >>>>>>>>         > >
> >>>>>>>>         > >RFC 4412 is *for* priority marking SIP requests,
> >>>>>>>>         > >
> >>>>>>>>         > >One use is GETS.
> >>>>>>>>         > >
> >>>>>>>>         > >One use is MLPP.
> >>>>>>>>         > >
> >>>>>>>>         > >These examples are in RFC 4412 because there
> >>> were specific
> >>>>>>>>         > >namespaces being created for the IANA section of
> >>>>>> that document.
> >>>>>>>>         > >
> >>>>>>>>         > >Reading the whole document, you will see
> >>> that RPH can be
> >>>>>>>>         > >specified for other uses than GETS or MLPP
> >>> specifically.
> >>>>>>>>         > >
> >>>>>>>>         > >I knew when I wrote RFC 4412 that one day we
> >>> would specify a
> >>>>>>>>         > >namespace for ECRIT (the "esnet" namespace
> >>> now) -- but I also
> >>>>>>>>         > >knew it was premature for RFC 4412 to
> >>> incorporate that
> >>>>>>>>         > >namespace, that a future doc to RFC 4412
> >>> would have to be
> >>>>>>>>         > >written to do this. Brian and I talked about
> >>> this at the
> >>>>>>>>         > >original NENA meeting that created the IP WGs there
> >>>>>> (in August
> >>>>>>>>         > >of 03).  We both agreed we should wait until it was
> >>>>>>>>         > >appropriate to the work in the IETF to
> >>> submit this document
> >>>>>>>>         > >that is now
> >>>>>>>>         >
> >>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >>>>>>>>         > >gency-rph-namespace-00.txt
> >>>>>>>>         > >
> >>>>>>>>         > >Yet, you seem to want to use some additional
> >>> mechanism to
> >>>>>>>>         > >indicate priority of a call in SIP.  That
> >>> means you want to
> >>>>>>>>         > >introduce a second way to accomplish this in SIP.
> >>>>>>>> Why do you
> >>>>>>>>         > >want to promote a separate way to do something SIP
> >>>>>> has already
> >>>>>>>>         > >defined? That will cause interoperability issues and
> >>>>>> we both know
> >>>>>>>> that.
> >>>>>>>>         > >
> >>>>>>>>         > >You've said to me (and others) that you
> >>> believe RPH is just
> >>>>>>>>         > >another way to accomplish what sos or a URI can
> >>>>>> indicate - and
> >>>>>>>>         > >you're wrong.  Your way would be
> >>> _the_second_way_to_do_it,
> >>>>>>>>         > >because SIP already considers RPH to be
> >>> *the*way* to priority
> >>>>>>>>         > >mark SIP requests.
> >>>>>>>>         > >
> >>>>>>>>         > >If you don't believe me (no comment), then
> >>> why do you not
> >>>>>>>>         > >believe the SIP WG chair (who knows more
> >>> about SIP than both
> >>>>>>>>         > >of us) - who, on this thread, has again said
> >>> to you "RFC 4412
> >>>>>>>>         > >(RPH) is the SIP mechanism to priority mark
> >>> SIP requests"?
> >>>>>>>>         > >
> >>>>>>>>         > >Further, I believe it is inappropriate to
> >>> prohibit endpoints
> >>>>>>>>         > >from being able to set the esnet namespace.
> >>> I absolutely
> >>>>>>>>         > >believe it will not be needed most of the
> >>> time, but I believe
> >>>>>>>>         > >if someone does find a valid use for
> >>> endpoints to mark
> >>>>>>>>         > >priority in SIP, this ID - once it has
> >>> become an RFC -- will
> >>>>>>>>         > >have to be obsoleted with a new RFC saying the exact
> >>>>>> opposite.
> >>>>>>>>         > >
> >>>>>>>>         > >(color me confused ... over and over again)
> >>>>>>>>         > >
> >>>>>>>>         > >James
> >>>>>>>>         > >
> >>>>>>>>         > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >>>>>>>>         > >>Keith, please understand that the usage of RFC 4412
> >>>>>> for GETS and
> >>>>>>>> for
> >>>>>>>>         > >>the type of emergency call we discuss here is
> >>>>>> different. Just
> >>>>>>>> looking
> >>>>>>>>         > >>at the header and the name of the namespace is a bit
> > >>>>>>>         > >artificial. I hope
> >>>>>>>>         > >>you understand that.
> >>>>>>>>         > >>
> >>>>>>>>         > >> >-----Original Message-----
> >>>>>>>>         > >> >From: DRAGE, Keith (Keith)
> >>>>>>>> [mailto:[email-masked]]
> >>>>>>>>         > >> >Sent: 05 February, 2009 14:55
> >>>>>>>>         > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
> >>>>>>>> Polk'; 'Tschofenig,
> >>>>>>>>         > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >>>>>>>>         > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
> >>>>>>>> Meeting: Agenda (my
> >>>>>>>>
> >>>>>>>>         > >> >mistake)
> >>>>>>>>         > >> >
> >>>>>>>>         > >> >Which is exactly what RFC 4412 specifies for all
> >>>>>> namespaces.
> >>>>>>>>         > >> >
> >>>>>>>>         > >> >regards
> >>>>>>>>         > >> >
> >>>>>>>>         > >> >Keith
> >>>>>>>>         > >> >
> >>>>>>>>         > >> >> -----Original Message-----
> >>>>>>>>         > >> >> From: [email-masked]
> >>>>>> [mailto:[email-masked]]
> >>>>>>>>         > >> >On Behalf
> >>>>>>>>         > >> >> Of Brian Rosen
> >>>>>>>>         > >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >>>>>>>>         > >> >> To: 'Hannes Tschofenig'; 'James M.
> >>> Polk'; 'Tschofenig,
> >>>>>>>>         > >Hannes (NSN
> >>>>>>>>         > >> >> - FI/Espoo)'; 'ECRIT'
> >>>>>>>>         > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >>>>>>>> Meeting: Agenda (my
> >>>>>>>>         > >> >> mistake)
> >>>>>>>>         > >> >>
> >>>>>>>>         > >> >> The value is that in some networks
> >>> where priority for
> >>>>>>>>         > >> >emergency calls
> >>>>>>>>         > >> >> is appropriate, and appropriate
> >>> policing of marking is
> >>>>>>>>         > >implemented,
> >>>>>>>>         > >> >> emergency calls will receive resource priority.
> >>>>>>>>         > >> >>
> >>>>>>>>         > >> >> Not all networks would need policing.  Some
> >>>>>> will.  Policing
> >>>>>>>> could
> >>>>>>>>         > >> >> be to Route header/R-URI content, but other
> >>>>>> criteria are
> >>>>>>>> possible.
> >>>>>>>>         > >> >>
> >>>>>>>>         > >> >> Not all networks will need resource priority
> >>>>>> for emergency
> >>>>>>>> calls.
> >>>>>>>>         > >> >> Fine, ignore this marking/namespace.
> >>>>>>>>         > >> >>
> >>>>>>>>         > >> >> Brian
> >>>>>>>>         > >> >> > -----Original Message-----
> >>>>>>>>         > >> >> > From: Hannes Tschofenig
> >>>>>>>> [mailto:[email-masked]]
> >>>>>>>>         > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >>>>>>>>         > >> >> > To: 'Brian Rosen'; 'James M. Polk';
> >>>>>> Tschofenig, Hannes
> >>>>>>>> (NSN -
> >>>>>>>>         > >> >> > FI/Espoo); 'ECRIT'
> >>>>>>>>         > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
> >>>>>>>> Meeting: Agenda (my
> >>>>>>>>         > >> >> > mistake)
> >>>>>>>>         > >> >> >
> >>>>>>>>         > >> >> > I don't even see the value in permitting the
> >>>>>> endpoint todo
> >>>>>>>> the
> >>>>>>>>         > >> >> > RPH marking.
> >>>>>>>>         > >> >> > In addition to the security concerns
> >>> there is also the
> >>>>>>>>         > >> >problem that
> >>>>>>>>         > >> >> > there are more options to implement without
> >>>>>> an additional
> >>>>>>>> value.
> >>>>>>>>         > >> >> >
> >>>>>>>>         > >> >> > >-----Original Message-----
> >>>>>>>>         > >> >> > >From: Brian Rosen [mailto:[email-masked]]
> >>>>>>>>         > >> >> > >Sent: 05 February, 2009 00:03
> >>>>>>>>         > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
> >>>>>> 'Tschofenig,
> >>>>>>>>         > >> >> Hannes (NSN -
> >>>>>>>>         > >> >> > >FI/Espoo)'; 'ECRIT'
> >>>>>>>>         > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual
> >>> Interim Meeting:
> >>>>>>>> Agenda (my
> >>>>>>>>         > >> >> > mistake)
> >>>>>>>>         > >> >> > >
> >>>>>>>>         > >> >> > >Hannes
> >>>>>>>>         > >> >> > >
> >>>>>>>>         > >> >> > >This matches my understanding
> >>> precisely.  We wish to
> >>>>>>>>         > >> >> permit endpoints
> >>>>>>>>         > >> >> > >to mark. We do not require it, and
> >>> don't necessarily
> >>>>>>>> expect it
> >>>>>>>>         > >> >> > >in many (even
> >>>>>>>>         > >> >> > >most) cases.  We don't wish to see the
> >>>>>> document prohibit
> >>>>>>>> it.
> >>>>>>>>         > >> >> > >We all seem to agree it has value within the
> > >>>>> Emergency
> >>>>>>>>         > >> >Services IP
> >>>>>>>>         > >> >> > >Networks.
> >>>>>>>>         > >> >> > >
> >>>>>>>>         > >> >> > >Brian
> >>>>>>>>         > >> >> > >
> >>>>>>>>         > >> >> > >> -----Original Message-----
> >>>>>>>>         > >> >> > >> From: [email-masked]
> >>>>>>>> [mailto:[email-masked]]
> >>>>>>>>         > >> >> > >On Behalf
> >>>>>>>>         > >> >> > >> Of James M. Polk
> >>>>>>>>         > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> >>>>>>>>         > >> >> > >> To: Hannes Tschofenig; Tschofenig,
> >>> Hannes (NSN -
> >>>>>>>>         > >> >> FI/Espoo); 'ECRIT'
> >>>>>>>>         > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >>>>>>>> Meeting:
> >>>>>>>>         > >Agenda (my
> >>>>>>>>         > >> >> > >> mistake)
> >>>>>>>>         > >> >> > >>
> >>>>>>>>         > >> >> > >> At 02:37 PM 2/4/2009, Hannes
> >>> Tschofenig wrote:
> >>>>>>>>         > >> >> > >> > > James wrote:
> >>>>>>>>         > >> >> > >> > >> you are the _lone_ voice not
> >>>>>> supporting this ID,
> >>>>>>>>         > >> >> > >> >
> >>>>>>>>         > >> >> > >> >Listening to the audio recording of past
> >>>>>> meetings I
> >>>>>>>> have to
> >>>>>>>>         > >> >> > >say that
> >>>>>>>>         > >> >> > >> >I
> >>>>>>>>         > >> >> > >> was
> >>>>>>>>         > >> >> > >> >not the only persons raising
> >>> concerns about the
> >>>>>>>> document.
> >>>>>>>>         > >> >> > >> >That was probably the reason why you
> >>>>>> agreed to limit
> >>>>>>>> the
> >>>>>>>>         > >> >> > >scope of the
> >>>>>>>>         > >> >> > >> >document (which you didn't later do) to
> >>>>>> get folks to
> >>>>>>>> agree
> >>>>>>>>         > >> >> > >to make it
> >>>>>>>>         > >> >> > >> a WG
> >>>>>>>>         > >> >> > >> >item.
> >>>>>>>>         > >> >> > >>
> >>>>>>>>         > >> >> > >> re-listen to the audio please
> >>>>>>>>         > >> >> > >>
> >>>>>>>>         > >> >> > >> Ted's concerns were consistent with most
> >>>>>>>> (all?) other
> >>>>>>>>         > >> >> concerns --
> >>>>>>>>         > >> >> > >> which were based on the premise of whether
> >>>>>> or not the
> >>>>>>>>         > >> >> UAC should be
> >>>>>>>>         > >> >> > >> trusted to initiate the marking on the
> >>>>>> INVITE.  The
> >>>>>>>> most
> >>>>>>>>         > >> >> > >> recent version has backed off this
> >>> to a "can" --
> >>>>>>>> meaning not
> >>>>>>>>         > >> >prohibited
> >>>>>>>>         > >> >> > >> (i.e., no 2119 text).  I also backed off
> >>>>>> the text in
> >>>>>>>> the
> >>>>>>>>         > >> >> SP domain
> >>>>>>>>         > >> >> > >> part to "can", such that there is
> >>> no 2119 text
> >>>>>>>>         > >> >mandating or even
> >>>>>>>>         > >> >> > >> recommending its usage there. I also do
> >>>>>> not prohibit
> >>>>>>>> its
> >>>>>>>>         > >> >> > >use, based on
> >>>>>>>>         > >> >> > >> local policy.  Keith has come forward with
> >>>>>> the specific
> >>>>>>>>
> >>>>>>>>         > >> >> > >> request that non-ESInet networks be
> >>>>>> allowed to mark and
> >>>>>>>> pay
> >>>>>>>>         > >> >attention to
> >>>>>>>>         > >> >> > >> this priority indication -- with IMS as
> >>>>>> the specific
> >>>>>>>> example
> >>>>>>>>         > >> >> > >> he wishes to have this valid for.
> >>>>>>>>         > >> >> > >>
> >>>>>>>>         > >> >> > >> Where there is no disagreement, save for
> >>>>>> your recent
> >>>>>>>>         > >> >> > >pushback - is in
> >>>>>>>>         > >> >> > >> the ESInet, which is where Brian
> >>> has requested it's
> >>>>>>>>         > >> >> > >definition in the
> >>>>>>>>         > >> >> > >> IETF on behalf of NENA.  He's the i3 WG
> >>>>>> chair within
> >>>>>>>>         > >> >> NENA, and if
> >>>>>>>>         > >> >> > >> he asks for it, are you going to say you
> >>>>>> know better
> >>>>>>>> than he?
> >>>>>>>>         > >> >> > >>
> >>>>>>>>         > >> >> > >>
> >>>>>>>>         > >> >> > >> >Btw, I not disagreeing with the document
> >>>>>> as such. I
> >>>>>>>>         > >> >just want to
> >>>>>>>>         > >> >> > the
> >>>>>>>>         > >> >> > >> scope
> >>>>>>>>         > >> >> > >> >to change. The usage of RPH
> >>> within the emergency
> >>>>>>>>         > >> >> services network
> >>>>>>>>         > >> >> > is
> >>>>>>>>         > >> >> > >> fine
> >>>>>>>>         > >> >> > >> >for me. I may get convinced to start the
> > >>>>> RPH marking
> >>>>>>>> from
> >>>>>>>>         > >> >> > >the the VSP
> >>>>>>>>         > >> >> > >> >towards the PSAP. I feel uneasy about the
> >>>>>> end host
> >>>>>>>> doing
> >>>>>>>>         > >> >> > >the marking.
> >>>>>>>>         > >> >> > >>
> >>>>>>>>         > >> >> > >> please read what I wrote above, and then
> >>>>>> re-read the
> >>>>>>>>         > >> >most recent
> >>>>>>>>         > >> >> > >> version of the ID. I don't have endpoints
> >>>>>> that SHOULD
> >>>>>>>> or
> >>>>>>>>         > >> >> MUST mark
> >>>>>>>>         > >> >> > >> anything wrt RPH.  I also don't want to
> >>>>>> prohibit it,
> >>>>>>>>         > >> >> because there
> >>>>>>>>         > >> >> > >> might be cases (that I don't know
> >>> of) of valid uses
> >>>>>>>>         > >> >> under certain
> >>>>>>>>         > >> >> > >> circumstances.  Figure 1 is very clear
> >>>>>> that there are 3
> >>>>>>>>         > >> >> networking
> >>>>>>>>         > >> >> > >> parts to consider
> >>>>>>>>         > >> >> > >>
> >>>>>>>>         > >> >> > >> #1 - from the endpoint
> >>>>>>>>         > >> >> > >> #2 - within the VSP
> >>>>>>>>         > >> >> > >> #3 - within the ESInet
> >>>>>>>>         > >> >> > >>
> >>>>>>>>         > >> >> > >> the most recent ID version has "can" for
> >>>>>> #s 1 and 2,
> >>>>>>>> and
> >>>>>>>>         > >> >> > >2119 language
> >>>>>>>>         > >> >> > >> offering those supporting this
> >>>>>> specification will have
> >>>>>>>> RPH
> >>>>>>>>         > >> >> > >> adherence within #3 (the ESInet).
> >>>>>>>>         > >> >> > >>
> >>>>>>>>         > >> >> > >> What other scope changes do you want,
> >>>>>> because I haven't
> >>>>>>>>         > >> >> heard them.
> >>>>>>>>         > >> >> > >>
> >>>>>>>>         > >> >> > >> I only heard you claim in email during the
> >>>>>> last IETF
> >>>>>>>> and in
> >>>>>>>>         > >> >> > >the ECRIT
> >>>>>>>>         > >> >> > >> session that RPH should not be
> >>> used for priority
> >>>>>>>> marking
> >>>>>>>>         > >> >> requests.
> >>>>>>>>         > >> >> > >> This is something Keith (SIP WG
> >>> chair) voiced his
> >>>>>>>> opposition
> >>>>>>>>         > >> >> > >> to your views regarding creating a second
> >>>>>> means for SIP
> >>>>>>>> to
> >>>>>>>>         > >> >priority
> >>>>>>>>         > >> >> > >> mark request "when SIP already has one
> >>>>>> interoperable
> >>>>>>>> way to
> >>>>>>>>         > >> >> > >> accomplish this... it's call the RP header
> >>>>>> mechanism".
> >>>>>>>>         > >> >> > >>
> >>>>>>>>         > >> >> > >> >I don't see advantages -- only
> >>> disadvantages.
> >>>>>>>>         > >> >> > >> >
> >>>>>>>>         > >> >> > >> >Ciao
> >>>>>>>>         > >> >> > >> >Hannes
> >>>>>>>>         > >> >> > >>
> >>>>>>>>         > >> >> > >>
> >>> _______________________________________________
> >>>>>>>>         > >> >> > >> Ecrit mailing list
> >>>>>>>>         > >> >> > >> [email-masked]
> >>>>>>>>         > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>         > >> >> > >
> >>>>>>>>         > >> >>
> >>>>>>>>         > >> >> _______________________________________________
> >>>>>>>>         > >> >> Ecrit mailing list
> >>>>>>>>         > >> >> [email-masked]
> >>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>         > >> >>
> >>>>>>>>         > >> >
> >>>>>>>>         > >
> >>>>>>>>         >
> >>>>>>>>         > _______________________________________________
> >>>>>>>>         > Ecrit mailing list
> >>>>>>>>         > [email-masked]
> >>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Ecrit mailing list
> >>>>>>>> [email-masked]
> >>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Ecrit mailing list
> >>>>>>> [email-masked]
> >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Ecrit mailing list
> >>>>> [email-masked]
> >>>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>
> >>>
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >>
> >> 
> ------------------------------------------------------------------------------------------------
> > > This message is for the designated recipient only and may
> >> contain privileged, proprietary, or otherwise private information.
> >> If you have received it in error, please notify the sender
> >> immediately and delete the original.  Any unauthorized use of
> >> this email is prohibited.
> >> 
> ------------------------------------------------------------------------------------------------
> >> [mf2]
> >>
> >>
> >
> >_______________________________________________
> >Ecrit mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/ecrit
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

Date: Fri, 06 Feb 2009 16:21:10 -0600
To: Henning Schulzrinne <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

At 04:05 PM 2/6/2009, Henning Schulzrinne wrote:
>James,
>
>we don't go through every possible SIP header that might be inserted
>into emergency requests. Yes, somebody could add RPH, but this applies
>to PAI and dozens of other SIP headers as well. So far, nobody has
>provided, in my opinion, a compelling use case that is worth
>documenting. "It could be useful somewhere for something" doesn't cut
>it. I have provided multiple reasons why I think that it is a bad idea
>for (normal) UAs to do so, none of which you address.

>I see no need to  say "do not insert RPH",

this is the only thing - right now - that I'm afraid one of us 
believes should be the case. I'm glad you are not joining that 
position.  I really do not want to highlight the idea fo UAs 
inserting esnet, but I believe sometime down the road - some customer 
will come up with a valid reason for this, and I don't want to state 
in text that it is prevented from being inserted (and yet have the 
vendor who wants to sell to that customer also want that vendor to 
adhere to this spec as well).

I'm just advocating we not have the text prevent its inclusion.

As I've said, I will beef up the security considerations section wrt 
UA insertion of esnet - unless others object to this...

>as it would have to be be a no-op for the
>reasons I mentioned.
>
>Henning
>
>On Feb 6, 2009, at 4:45 PM, James M. Polk wrote:
>
>>At 02:01 PM 2/6/2009, Winterbottom, James wrote:
>>>Hi All,
>>>
>>>I have followed thi thread with some interest and I struggling to
>>>see a use case for the
>>>providing RPH for emergency calls from the end-point.
>>
>>ok, let's address this concern only for a minute.
>>
>>If there is no use-case you can think of (for endpoints insertion of
>>RP namespace esnet), does that mean this RFC to-be has to prevent
>>(i.e., MUST NOT) endpoints from being allowed to insert esnet?  That
>>means, you feel and believe, you know about all customer
>>requirements everywhere, doesn't it?
>>
>>I'm not kidding or being snide here.
>>
>>Remember, this is a Standards Track doc for implementers, allowing
>>them the idea that some future specification MAY allow endpoints to
>>insert the RP header from endpoints gives them the ability to adjust
>>their code to that possibility.  There is the (good?) chance that at
>>least one customer (somewhere) of one or more vendors has this as a
>>requirement _now_, but we haven't heard about it yet.
>>
>>Stating in this to-be RFC that endpoints are forbidden from
>>inserting an RP header would prevent them from implementing/ 
>>satisfying their customer requirement while still supporting this
>>specification.
>>
>>Remember, this RFC to-be DOES NOT say anything about endpoints MUST
>>or even SHOULD implement the "esnet" RP namespace in order to be
>>compliant with this spec.  It merely says MAY, which means "some
>>future spec MAY recommend or mandate it".
>>
>>I agree with Brian that robust security considerations stating that
>>endpoint implementations need to very careful about configuring this
>>capability needs to be written, and I will commit to writing that
>>text in the next rev of the doc.
>>
>>James

From: Henning Schulzrinne <[email-masked]>
To: "James M. Polk" <[email-masked]>
Date: Fri, 6 Feb 2009 17:29:09 -0500
Cc: ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

To restate: I will object to any text mentioning use of ESNET in UAs.  
It's useless (since under-specified), likely to be harmful to reliable  
network operation and just causes confusion. The text should describe  
when it is useful (within a "closed" ESNET, presumably) and what  
conditions need to be met in order to ensure reliable and secure  
usage. That something might be useful somewhere else is always true,  
in any specification, but we don't add a "This document does not  
prevent the use of this mechanism somewhere else." in documents.

Henning

On Feb 6, 2009, at 5:21 PM, James M. Polk wrote:

> At 04:05 PM 2/6/2009, Henning Schulzrinne wrote:
>> James,
>>
>> we don't go through every possible SIP header that might be inserted
>> into emergency requests. Yes, somebody could add RPH, but this  
>> applies
>> to PAI and dozens of other SIP headers as well. So far, nobody has
>> provided, in my opinion, a compelling use case that is worth
>> documenting. "It could be useful somewhere for something" doesn't cut
>> it. I have provided multiple reasons why I think that it is a bad  
>> idea
>> for (normal) UAs to do so, none of which you address.
>
>
>> I see no need to  say "do not insert RPH",
>
> this is the only thing - right now - that I'm afraid one of us  
> believes should be the case. I'm glad you are not joining that  
> position.  I really do not want to highlight the idea fo UAs  
> inserting esnet, but I believe sometime down the road - some  
> customer will come up with a valid reason for this, and I don't want  
> to state in text that it is prevented from being inserted (and yet  
> have the vendor who wants to sell to that customer also want that  
> vendor to adhere to this spec as well).
>
> I'm just advocating we not have the text prevent its inclusion.
>
> As I've said, I will beef up the security considerations section wrt  
> UA insertion of esnet - unless others object to this...

Date: Fri, 06 Feb 2009 16:37:26 -0600
To: Henning Schulzrinne <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

Henning

I agree with your statement

         "This document does not prevent the use of this
         mechanism somewhere else." in documents.

I just want to avoid having to write in (something like)

         'UAs are prevented from including RP namespace esnet"

That was pretty much suggested by one person on the list.

Is this agreeable?

Taking this statement further

         "I will object to any text mentioning use of ESNET in UAs."

Does that mean you do _not_ want UA insertion of esnet to be added to 
the security considerations section?

James

At 04:29 PM 2/6/2009, Henning Schulzrinne wrote:
>To restate: I will object to any text mentioning use of ESNET in UAs.
>It's useless (since under-specified), likely to be harmful to reliable
>network operation and just causes confusion. The text should describe
>when it is useful (within a "closed" ESNET, presumably) and what
>conditions need to be met in order to ensure reliable and secure
>usage. That something might be useful somewhere else is always true,
>in any specification, but we don't add a "This document does not
>prevent the use of this mechanism somewhere else." in documents.
>
>Henning
>
>On Feb 6, 2009, at 5:21 PM, James M. Polk wrote:
>
>>At 04:05 PM 2/6/2009, Henning Schulzrinne wrote:
>>>James,
>>>
>>>we don't go through every possible SIP header that might be inserted
>>>into emergency requests. Yes, somebody could add RPH, but this
>>>applies
>>>to PAI and dozens of other SIP headers as well. So far, nobody has
>>>provided, in my opinion, a compelling use case that is worth
>>>documenting. "It could be useful somewhere for something" doesn't cut
>>>it. I have provided multiple reasons why I think that it is a bad
>>>idea
>>>for (normal) UAs to do so, none of which you address.
>>
>>
>>>I see no need to  say "do not insert RPH",
>>
>>this is the only thing - right now - that I'm afraid one of us
>>believes should be the case. I'm glad you are not joining that
>>position.  I really do not want to highlight the idea fo UAs
>>inserting esnet, but I believe sometime down the road - some
>>customer will come up with a valid reason for this, and I don't want
>>to state in text that it is prevented from being inserted (and yet
>>have the vendor who wants to sell to that customer also want that
>>vendor to adhere to this spec as well).
>>
>>I'm just advocating we not have the text prevent its inclusion.
>>
>>As I've said, I will beef up the security considerations section wrt
>>UA insertion of esnet - unless others object to this...

From: "Hannes Tschofenig" <[email-masked]>
To: "'James M. Polk'" <[email-masked]>
Date: Sat, 7 Feb 2009 00:46:53 +0200
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)

Good that you agree that GETS usage of RPH and the one we discuss in ECRIT
is different. 
So far, some folks have been saying "what works for GETS works for the ECRIT
case as well". 

I argued that the environment is different and hence just referencing RFC
4412 isn't good enough.  

>-----Original Message-----
>From: James M. Polk [mailto:[email-masked]] 
>Sent: 07 February, 2009 00:02
>To: Hannes Tschofenig
>Cc: 'DRAGE, Keith (Keith)'; 'Brian Rosen'; Tschofenig, Hannes 
>(NSN - FI/Espoo); 'ECRIT'
>Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
>
>At 03:21 AM 2/6/2009, Hannes Tschofenig wrote:
>>Hi James,
>>
>>I have read RFC 4412 and also the GETS/MLPP IETF documents. What I 
>>would like to point out is that there is more than just a header and 
>>values within the header that have to be considered in order 
>to make a 
>>judgement of what is appropriate and what isn't. There is an 
>>architectural question and whether the environment we are using the 
>>stuff is indeed providing the properties you need for the 
>solution to be appropriate.
>>
>>Let me describe in more detail what I meant (and please 
>correct me if I 
>>am wrong).
>>
>>Getting priority for SIP requests when using a GETS alike scenario 
>>means that the entity that issues the request is specially authorized 
>>since otherwise you introduce a nice denial of service attack.
>
>You are missing a step in GETS here.  The endpoint, who sends 
>the GETS set-up as an INVITE is not already authorized (not 
>the device, not the user).  In North America, there is a 10 
>digit GETS number that is dialed (that I won't give out right 
>now on an open list) - and there literally is only 1 number 
>available to dial for this service.  Literally anyone can dial 
>this number today in North America (no matter where the phone 
>is - as long as it is in North America -- and I might be too 
>limiting in that it is dialable from anywhere, because it is 
>going to a North American destination).
>
>Once this number is dialed, it is answered by an 
>authentication and authorization IVR.  This IVR challenges 
>each caller for their authentication passcode, and a 
>password). Once this has been successfully entered, then call 
>is NOW authorized to proceed towards its destination number - 
>this step is only known to the authorizing system because the 
>destination 10 digit number is NOT entered until after the 
>authentication and authorization step has completed.
>
>The authorized caller is prompted with a new dial tone - in 
>which they can enter any number on the planet and receive 
>preferential treatment through as many carriers (in IP, it's 
>SPs) that have implemented this GETS service (which is an SLA 
>with the Department of Homeland Security now).
>
>Merely entering the GETS RP namespace is never intended, 
>alone, to gain any preferential treatment -- other than 
>towards this authentication & authorization IVR.
>
>I hope you can see that this is a completely separate type of 
>service and implementation type than ECRIT based emergency 
>calling will use.
>
>BTW - to your comment below about me not calling your name out 
>when you are incorrect because I have been equally incorrect 
>-- I'm not sure I've been spared as much as you think, given 
>that many have called me out by name when they've felt I've 
>been wrong over the years.
>
>>This authorization
>>is tied to the entity that makes the request. For example, the person 
>>is working for the government and has special rights. James Bond as a 
>>(not so) secret agent might have these rights.
>>
>>The emergency services case (citizen-to-authority) is a bit different 
>>as there aren't really special rights with respect to authorization 
>>tied to individuals. Instead, the fact that something is an emergency 
>>is purely a judgement of the human that dials a special 
>number. To deal 
>>with fraud, we discussed in the group on what we can actually do to 
>>ensure that end users do not bypass security procedures (such as 
>>authorization checks, charging and so on). Part of this investigation 
>>was the publication of http://www.ietf.org/rfc/rfc5069.txt 
>that also describes this issue.
>>
>>So, imagine the implementation of a SIP proxy (and we implemented that
>>stuff) that receives a call that contains a Service URN. The code 
>>branches into a special mode where everything is done so that 
>the call 
>>receives appropriate treatment and does not get dropped on the floor. 
>>The way how the Service URN is placed in the message ensures that the 
>>call cannot go to my friend (instead of the PSAP) unless the end host 
>>ran LoST already. In the latter case, we discussed this also on the 
>>list for a while and Richard even wrote a draft about it in 
>the context 
>>of the location hiding topic, we said that the proxy would 
>have to run 
>>LoST if he cares about a potential fraudulent usage.
>>
>>So, what do we need todo in order to provide secure RFC 4412 
>>functionality in our context?
>>
>>Do you think that the current text in
>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-eme
>rgency-rp
>>h-nam espace-00.txt reflects any of the above-described issues:
>>"
>>    The Security considerations that apply to RFC 4412 [RFC4412] apply
>>    here.  This document introduces no new security issues relative to
>>    RFC 4412.
>>"
>>
>> From various discussions in GEOPRIV I recall that you are 
>>super-sensitive regarding security and privacy. For some reasons you 
>>don't seem to have the same concerns here. I would like to 
>understand your reasoning.
>>
>>Please also do me another favor: Don't always say that I don't 
>>understand the subject. Even if that would be the case it isn't 
>>particular fair given that different folks had to educate you 
>on other topics in the past as well.
>>Additionally, if you listen to the audio recordings then you will 
>>notice that Henning, Ted, and Jon do not seem to understand the issue 
>>either as they have raised similar issues during the F2F meetings.
>>
>>Ciao
>>Hannes
>>
>>
>> >Hannes - I believe it is you who do not understand RFC 4412 -- and 
>> >many of us are trying to get that through to you, but you 
>don't seem 
>> >to want to listen/read.
>> >
>> >RFC 4412 is *for* priority marking SIP requests,
>> >
>> >One use is GETS.
>> >
>> >One use is MLPP.
>> >
>> >These examples are in RFC 4412 because there were specific 
>namespaces 
>> >being created for the IANA section of that document.
>> >
>> >Reading the whole document, you will see that RPH can be specified 
>> >for other uses than GETS or MLPP specifically.
>> >
>> >I knew when I wrote RFC 4412 that one day we would specify a 
>> >namespace for ECRIT (the "esnet" namespace now) -- but I 
>also knew it 
>> >was premature for RFC 4412 to incorporate that namespace, that a 
>> >future doc to RFC 4412 would have to be written to do this. 
>Brian and 
>> >I talked about this at the original NENA meeting that 
>created the IP 
>> >WGs there (in August of 03).  We both agreed we should wait 
>until it 
>> >was appropriate to the work in the IETF to submit this 
>document that 
>> >is now 
>> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>> >gency-rph-namespace-00.txt
>> >
>> >Yet, you seem to want to use some additional mechanism to indicate 
>> >priority of a call in SIP.  That means you want to 
>introduce a second 
>> >way to accomplish this in SIP.  Why do you want to promote 
>a separate 
>> >way to do something SIP has already defined? That will cause 
>> >interoperability issues and we both know that.
>> >
>> >You've said to me (and others) that you believe RPH is just another 
>> >way to accomplish what sos or a URI can indicate - and 
>you're wrong.  
>> >Your way would be _the_second_way_to_do_it, because SIP already 
>> >considers RPH to be *the*way* to priority mark SIP requests.
>> >
>> >If you don't believe me (no comment), then why do you not 
>believe the 
>> >SIP WG chair (who knows more about SIP than both of us) - who, on 
>> >this thread, has again said to you "RFC 4412
>> >(RPH) is the SIP mechanism to priority mark SIP requests"?
>> >
>> >Further, I believe it is inappropriate to prohibit endpoints from 
>> >being able to set the esnet namespace.  I absolutely 
>believe it will 
>> >not be needed most of the time, but I believe if someone 
>does find a 
>> >valid use for endpoints to mark priority in SIP, this ID - once it 
>> >has become an RFC -- will have to be obsoleted with a new 
>RFC saying 
>> >the exact opposite.
>> >
>> >(color me confused ... over and over again)
>> >
>> >James
>> >
>> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>> >>Keith, please understand that the usage of RFC 4412 for 
>GETS and for 
>> >>the type of emergency call we discuss here is different. Just 
>> >>looking at the header and the name of the namespace is a bit
>> >artificial. I hope
>> >>you understand that.
>> >>
>> >> >-----Original Message-----
>> >> >From: DRAGE, Keith (Keith) [mailto:[email-masked]]
>> >> >Sent: 05 February, 2009 14:55
>> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 
>> >> >'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
>> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
>> >> >mistake)
>> >> >
>> >> >Which is exactly what RFC 4412 specifies for all namespaces.
>> >> >
>> >> >regards
>> >> >
>> >> >Keith
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: [email-masked] [mailto:[email-masked]]
>> >> >On Behalf
>> >> >> Of Brian Rosen
>> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
>> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
>> >Hannes (NSN
>> >> >> - FI/Espoo)'; 'ECRIT'
>> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
>> >> >> mistake)
>> >> >>
>> >> >> The value is that in some networks where priority for
>> >> >emergency calls
>> >> >> is appropriate, and appropriate policing of marking is
>> >implemented,
>> >> >> emergency calls will receive resource priority.
>> >> >>
>> >> >> Not all networks would need policing.  Some will.  Policing 
>> >> >> could be to Route header/R-URI content, but other 
>criteria are possible.
>> >> >>
>> >> >> Not all networks will need resource priority for 
>emergency calls.
>> >> >> Fine, ignore this marking/namespace.
>> >> >>
>> >> >> Brian
>> >> >> > -----Original Message-----
>> >> >> > From: Hannes Tschofenig [mailto:[email-masked]]
>> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>> >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, 
>Hannes (NSN - 
>> >> >> > FI/Espoo); 'ECRIT'
>> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: 
>Agenda (my
>> >> >> > mistake)
>> >> >> >
>> >> >> > I don't even see the value in permitting the 
>endpoint todo the 
>> >> >> > RPH marking.
>> >> >> > In addition to the security concerns there is also the
>> >> >problem that
>> >> >> > there are more options to implement without an 
>additional value.
>> >> >> >
>> >> >> > >-----Original Message-----
>> >> >> > >From: Brian Rosen [mailto:[email-masked]]
>> >> >> > >Sent: 05 February, 2009 00:03
>> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,
>> >> >> Hannes (NSN -
>> >> >> > >FI/Espoo)'; 'ECRIT'
>> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda 
>> >> >> > >(my
>> >> >> > mistake)
>> >> >> > >
>> >> >> > >Hannes
>> >> >> > >
>> >> >> > >This matches my understanding precisely.  We wish to
>> >> >> permit endpoints
>> >> >> > >to mark. We do not require it, and don't necessarily expect 
>> >> >> > >it in many (even
>> >> >> > >most) cases.  We don't wish to see the document prohibit it.
>> >> >> > >We all seem to agree it has value within the Emergency
>> >> >Services IP
>> >> >> > >Networks.
>> >> >> > >
>> >> >> > >Brian
>> >> >> > >
>> >> >> > >> -----Original Message-----
>> >> >> > >> From: [email-masked] 
>> >> >> > >> [mailto:[email-masked]]
>> >> >> > >On Behalf
>> >> >> > >> Of James M. Polk
>> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
>> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
>> >> >> FI/Espoo); 'ECRIT'
>> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
>> >Agenda (my
>> >> >> > >> mistake)
>> >> >> > >>
>> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
>> >> >> > >> > > James wrote:
>> >> >> > >> > >> you are the _lone_ voice not supporting this ID,
>> >> >> > >> >
>> >> >> > >> >Listening to the audio recording of past meetings I have 
>> >> >> > >> >to
>> >> >> > >say that
>> >> >> > >> >I
>> >> >> > >> was
>> >> >> > >> >not the only persons raising concerns about the document.
>> >> >> > >> >That was probably the reason why you agreed to limit the
>> >> >> > >scope of the
>> >> >> > >> >document (which you didn't later do) to get 
>folks to agree
>> >> >> > >to make it
>> >> >> > >> a WG
>> >> >> > >> >item.
>> >> >> > >>
>> >> >> > >> re-listen to the audio please
>> >> >> > >>
>> >> >> > >> Ted's concerns were consistent with most (all?) other
>> >> >> concerns --
>> >> >> > >> which were based on the premise of whether or not the
>> >> >> UAC should be
>> >> >> > >> trusted to initiate the marking on the INVITE.  The most 
>> >> >> > >> recent version has backed off this to a "can" -- meaning 
>> >> >> > >> not
>> >> >prohibited
>> >> >> > >> (i.e., no 2119 text).  I also backed off the text in the
>> >> >> SP domain
>> >> >> > >> part to "can", such that there is no 2119 text
>> >> >mandating or even
>> >> >> > >> recommending its usage there. I also do not prohibit its
>> >> >> > >use, based on
>> >> >> > >> local policy.  Keith has come forward with the specific 
>> >> >> > >> request that non-ESInet networks be allowed to 
>mark and pay
>> >> >attention to
>> >> >> > >> this priority indication -- with IMS as the specific 
>> >> >> > >> example he wishes to have this valid for.
>> >> >> > >>
>> >> >> > >> Where there is no disagreement, save for your recent
>> >> >> > >pushback - is in
>> >> >> > >> the ESInet, which is where Brian has requested it's
>> >> >> > >definition in the
>> >> >> > >> IETF on behalf of NENA.  He's the i3 WG chair within
>> >> >> NENA, and if
>> >> >> > >> he asks for it, are you going to say you know 
>better than he?
>> >> >> > >>
>> >> >> > >>
>> >> >> > >> >Btw, I not disagreeing with the document as such. I
>> >> >just want to
>> >> >> > the
>> >> >> > >> scope
>> >> >> > >> >to change. The usage of RPH within the emergency
>> >> >> services network
>> >> >> > is
>> >> >> > >> fine
>> >> >> > >> >for me. I may get convinced to start the RPH marking from
>> >> >> > >the the VSP
>> >> >> > >> >towards the PSAP. I feel uneasy about the end host doing
>> >> >> > >the marking.
>> >> >> > >>
>> >> >> > >> please read what I wrote above, and then re-read the
>> >> >most recent
>> >> >> > >> version of the ID. I don't have endpoints that SHOULD or
>> >> >> MUST mark
>> >> >> > >> anything wrt RPH.  I also don't want to prohibit it,
>> >> >> because there
>> >> >> > >> might be cases (that I don't know of) of valid uses
>> >> >> under certain
>> >> >> > >> circumstances.  Figure 1 is very clear that there are 3
>> >> >> networking
>> >> >> > >> parts to consider
>> >> >> > >>
>> >> >> > >> #1 - from the endpoint
>> >> >> > >> #2 - within the VSP
>> >> >> > >> #3 - within the ESInet
>> >> >> > >>
>> >> >> > >> the most recent ID version has "can" for #s 1 and 2, and
>> >> >> > >2119 language
>> >> >> > >> offering those supporting this specification will 
>have RPH 
>> >> >> > >> adherence within #3 (the ESInet).
>> >> >> > >>
>> >> >> > >> What other scope changes do you want, because I haven't
>> >> >> heard them.
>> >> >> > >>
>> >> >> > >> I only heard you claim in email during the last 
>IETF and in
>> >> >> > >the ECRIT
>> >> >> > >> session that RPH should not be used for priority marking
>> >> >> requests.
>> >> >> > >> This is something Keith (SIP WG chair) voiced his 
>> >> >> > >> opposition to your views regarding creating a 
>second means 
>> >> >> > >> for SIP to
>> >> >priority
>> >> >> > >> mark request "when SIP already has one 
>interoperable way to 
>> >> >> > >> accomplish this... it's call the RP header mechanism".
>> >> >> > >>
>> >> >> > >> >I don't see advantages -- only disadvantages.
>> >> >> > >> >
>> >> >> > >> >Ciao
>> >> >> > >> >Hannes
>> >> >> > >>
>> >> >> > >> _______________________________________________
>> >> >> > >> Ecrit mailing list
>> >> >> > >> [email-masked]
>> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> > >
>> >> >>
>> >> >> _______________________________________________
>> >> >> Ecrit mailing list
>> >> >> [email-masked]
>> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>
>> >> >
>> >
>

Content-class: urn:content-classes:message
Date: Fri, 6 Feb 2009 17:50:24 -0500
From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ecrit] RPH

From: "Hannes Tschofenig" <[email-masked]>
To: "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sat, 7 Feb 2009 00:52:07 +0200
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] RPH

Hi Martin, 

I am arguing that if the UE does mark the call with the ECRIT RPH (I call it
that way to differentiate it from RFC 4412 RPH usage, which is very
different) then it should be ignored. 
Processing it will not help in any way (as I described in my pseudo code
snippet). Incorrectly processing it (which is a possibility when the
implementer does not understand the security implications -- they will not
get it from the current version of the draft) will lead to security problems
(fraud & DoS potential). 

While you cannot prevent someone from sending you, there is certainly the
chance to document what the receiver should do with it.

Ciao
Hannes 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of DOLLY, MARTIN C, ATTLABS
>Sent: 07 February, 2009 00:15
>To: [email-masked]; [email-masked]; 
>[email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: [Ecrit] RPH
>
>You can not disallow this from an UE. The trust relationship 
>will dictate whether it is accepted or not
>
>----- Original Message -----
>From: [email-masked] <[email-masked]>
>To: Henning Schulzrinne <[email-masked]>; Winterbottom, 
>James <[email-masked]>
>Cc: Tschofenig, Hannes (NSN - FI/Espoo) 
><[email-masked]>; ECRIT <[email-masked]>
>Sent: Fri Feb 06 17:10:08 2009
>Subject: Re: [Ecrit] RPH
>
>At 03:05 PM 2/6/2009, Henning Schulzrinne wrote:
>>There's another problem with the "it doesn't hurt argument". 
>Assume for 
>>a moment we have a "UA MAY include RPH" wording. There are now two
>>cases:
>>
>>(1) All UAs implement it.
>>
>>(2) Only some UAs implement it.
>>
>>(1) seems unlikely for a MAY. If (2) occurs, we have the 
>choice between 
>>two undesirable outcomes:
>>
>>(a) some UAs that are otherwise compliant get worse service just 
>>because they didn't include the RPH;
>
>am I reading this correctly - that unless all UAs implement 
>this capability this should never be implemented by any UAs?
>
>This flies in the face of vendors solving for their customer's 
>requirements.
>
>I will admit that at this time, I know of no Cisco customers 
>that want this capability, so I'm not angling for any of our 
>revenue here.  I'm saying that I think I hear you saying this 
>ID should say something like
>
>         UAs are prevented from implementing the RP namespace esnet
>
>I'm fighting against that, because customers are always coming 
>to every vendor with new requirements, some of them unique at 
>the time.  This prevention text would prevent a vendor from 
>complying with this specification and still meet the customer's needs.
>
>I believe that this ID needs to retain the endpoints MAY 
>insert esnet, and have appropriate security considerations 
>text that highlights the concerns expressed here.
>
>Some future ID can then update this current RFC (to-be) within the
>2119 rules of the use of MAY here.
>
>
>>OR
>>
>>(b) the proxy has to look for the service URN to give the call the
>>appropriate treatment, thus obviating any advantage of having the
>>header, yet incurring more complicated processing logic.
>>
>>
>>I have no objection to whatever markings people want to apply to calls
>>within an ESN - that's largely a private matter.
>>
>>Henning
>>
>>On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote:
>>
>>>Hi All,
>>>
>>>I have followed thi thread with some interest and I struggling to
>>>see a use case for the
>>>providing RPH for emergency calls from the end-point.
>>>
>>>The reference-model call in ECRIT, for better or worse, is for all
>>>calls to go back through a home-VSP.
>>>We placed quite a lot of emphasis, largely for traffing reasons, for
>>>the VSP to be able to verify that
>>>a call is in fact an emergency call. This is done by the proxy
>>>taking the inband location, doing a LoST
>>>query with the provided URN, and verifying that the resulting
>>>destination URI is the same as the destination
>>>URI provide in the SIP INVITE. My understanding was that VSPs would
>>>always do this check so they could
>>>tell if they could bill for the call or not, and because the VSP can
>>>be use that the call is an emergency call
>>>it can apply any special priorities that may be applicable. This
>>>obviates the need for RPH from the end-point
>>>to the network.
>>>
>>>This leaves us with the argument of "it doesn't hurt to it", which
>>>is not a good reason to write a specification.
>>>It was intimated on the geopriv mailing list last year that great
>>>pains had been taken to keep SIP with in the
>>>MTU limits of UDP over Ethernet 
>>>(http://www.ietf.org/mail-archive/web/geopriv/current/msg0612
>0.html ). Assuming
>>>that this is the case, perhaps there is harm in including
>>>information that we know will be ignored.
>>>
>>>Cheers
>>>James
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: [email-masked] on behalf of Hannes Tschofenig
>>>Sent: Fri 2/6/2009 12:33 PM
>>>To: 'Brian Rosen'; 'Henning Schulzrinne'
>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
>>>Subject: Re: [Ecrit] RPH
>>>
>>>To the story short here is the code for the proxy:
>>>
>>>---------------------
>>>
>>>IF emergency call was recognized THEN
>>>    execute emergency call specific procedures (priority queuing,
>>>preemption, fetch location, determine routing, do funny QoS things &
>>>co)
>>>ELSE
>>>    normal call handling procedures.
>>>
>>>---------------------
>>>
>>>If you can make this differentiation between an emergency call and a
>>>regular
>>>call then you can also do everything that is necessary for emergency
>>>call
>>>handling.
>>>
>>>Brian + Keith: Please tell me that we cannot do the above with our
>>>currently
>>>specified mechanisms.
>>>
>>>Ciao
>>>Hannes
>>>
>>>>-----Original Message-----
>>>>From: Brian Rosen [mailto:[email-masked]]
>>>>Sent: 06 February, 2009 17:49
>>>>To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
>>>>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
>>>>Subject: RE: [Ecrit] RPH
>>>>
>>>>I agree that not all networks will permit (or pay attention
>>>>to) a priority request from an end device.
>>>>
>>>>No one has asked for that.
>>>>
>>>>The namespace request has several uses, one of which is within
>>>>an emergency services IP network, one of which is between
>>>>elements within a public network controlled by the operator,
>>>>and one of which is an endpoint request for resource priority.
>>>>
>>>>Those of us requesting this work proceed are happy if the
>>>>endpoint part is simply left as possible (MAY), and, speaking
>>>>for myself, having the draft discuss the security implications
>>>>of endpoint marking is reasonable.
>>>>
>>>>Having discussed this issue with an implementation team who
>>>>worked on MLPP systems, I am confident I know what I'm talking
>>>>about, but YMMV.  The fact that you could, if you wanted to,
>>>>give resource priority to a call you decided, however you
>>>>decided, was an emergency call is an implementation decision,
>>>>and not subject to standardization.
>>>>
>>>>RPH is the IETF standard way for one entity to request
>>>>resource priority of another entity in a SIP system.  We're
>>>>asking for a namespace to use that within the domain of
>>>>emergency calls.  That is, I think, a VERY reasonable request.
>>>>
>>>>Brian
>>>>
>>>>>-----Original Message-----
>>>>>From: Henning Schulzrinne [mailto:[email-masked]]
>>>>>Sent: Friday, February 06, 2009 10:33 AM
>>>>>To: Hannes Tschofenig
>>>>>Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>>>>>Subject: Re: [Ecrit] RPH
>>>>>
>>>>>To chime in here:
>>>>>
>>>>>I don't think it's productive to simply state that 4412
>>>>doesn't worry
>>>>>about authorization, so we shouldn't either (simplifying a bit).
>>>>>Authorization was discussed repeatedly, and the general
>>>>assumption was
>>>>>that there were two conditions: Either the user invoking resource-
>>>>>priority was well known and had a set of permissions that could be
>>>>>checked in real time or there are ways to deal with abuse after the
>>>>>fact in ways that deter abuse (the court-martial kind of thing in a
>>>>>military context).
>>>>>
>>>>>The RFC 4412 security consideration (11.2) call this out in pretty
>>>>>strong language:
>>>>>
>>>>>  Prioritized access to network and end-system resources imposes
>>>>>    particularly stringent requirements on authentication and
>>>>>    authorization mechanisms, since access to prioritized
>>>>resources may
>>>>>    impact overall system stability and performance and not
>>>>just result
>>>>>    in theft of, say, a single phone call.
>>>>>Thus, the question is whether we have such strong authentication in
>>>>>emergency calling. In some cases, such as residential fixed line
>>>>>deployments where ISP = VSP, we're probably pretty close, 
>in others,
>>>>>such as prepaid cell phones or hot spots or VSP-only providers, we
>>>>>aren't.
>>>>>
>>>>>The other point that I think Hannes is making is that the
>>>>information
>>>>>is either redundant or dangerous. If a processing element 
>recognizes
>>>>>the call as being an emergency call, it can apply whatever 
>treatment
>>>>>it deems appropriate and doesn't need additional information. If it
>>>>>doesn't or can't, using just the RPH can be rather dangerous unless
>>>>>that element can be reasonably certain that there is strong
>>>>>authentication and recourse.
>>>>>
>>>>>I don't buy the argument that somehow finding the RPH is 
>faster than
>>>>>just looking for the identifier. Thus, given that the 
>information is
>>>>>either redundant or dangerous, I fail to see the advantage.
>>>>>
>>>>>Henning
>>>>>
>>>>>
>>>>>On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
>>>>>
>>>>>>Don't get hung up on the details. There are ways to optimize it.
>>>>>>That was
>>>>>>not the point of the code example.
>>>>>>
>>>>>>The problem that my pseudo code should have shown you is that you
>>>>>>* don't gain anything with RPH marking for the emergency call case
>>>>>>from the SIP UA towards the outbound proxy since the functionality
>>>>>>is already provide otherwise. How often does the proxy need to get
>>>>>>told that this is an emergency call todo whatever emergency call
>>>>>>handling procedures are necessary?
>>>>>>* you only introduce fraud problems (if you are not
>>>>careful and you
>>>>>>understand the security stuff well enough)
>>>>>>
>>>>>>If you can point me to people who implement the RPH emergency call
>>>>>>case please do so. I would love to talk to them.
>>>>>>
>>>>>>Ciao
>>>>>>Hannes
>>>>>>
>>>>>>PS: You need to parse incoming messages to some extend so that you
>>>>>>know what it contains :-) Only looking for the emergency
>>>>RPH header
>>>>>>(and not for the Service URN/dial
>>>>>>string) would exactly be the DoS/fraud attack I am worried about.
>>>>>>That's the thing Henning was worried about (go and listen to the
>>>>>>past meeting minutes).
>>>>>>
>>>>>>
>>>>>>>Hannes
>>>>>>>
>>>>>>>You need to talk to people who really implement this kind
>>>>of thing.
>>>>>>>You are way off.
>>>>>>>
>>>>>>>When you implement a resource priority system, the point of doing
>>>>>>>that is to look though the queue of work and pick out the
>>>>ones with
>>>>>>>priority, handling them first.  You don't do all the parsing, you
>>>>>>>don't do a lot of decision tree.
>>>>>>>
>>>>>>>Typically:
>>>>>>>Check for DoS things, like too big messages, etc Do a quick scan
>>>>>>>for the RPH message header If found:
>>>>>>>Parse the message
>>>>>>>Determine validity
>>>>>>>Determine priority
>>>>>>>Queue on the correct work queue
>>>>>>>
>>>>>>>The first two actions have to be very fast.  Anyone who builds a
>>>>>>>SIP thingie will tell you that parsing is one of the big cycle
>>>>>>>consumers: if you have to parse every message BEFORE you
>>>>determine
>>>>>>>priority, you can't give much resource priority.
>>>>>>>Once you get the whole message parsed, you might as well finish
>>>>>>>working on it, because you've done so much of the work.
>>>>>>>OTHOH, finding the end-of-message delimiter and doing a quick
>>>>>>>string search for RPH is fast.  If you are doing
>>>>priority, you need
>>>>>>>to keep all the priority processing pretty uniform, and pretty
>>>>>>>simple, or you tend to spend too much time futzing around
>>>>figuring
>>>>>>>out what to do.  You put all the priority related stuff together,
>>>>>>>and use as much common code as possible.
>>>>>>>
>>>>>>>Brian
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: [email-masked] [mailto:[email-masked]]
>>>>>>>On Behalf
>>>>>>>>Of Hannes Tschofenig
>>>>>>>>Sent: Friday, February 06, 2009 8:41 AM
>>>>>>>>To: 'Hannes Tschofenig'; 'Janet P Gunn'
>>>>>>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-
>>>>>>>>[email-masked]
>>>>>>>>Subject: [Ecrit] RPH
>>>>>>>>
>>>>>>>>Over lunch I was also thinking how an outbound proxy would
>>>>>implement
>>>>>>>>some of the emergency procedures. Here are some thoughts:
>>>>>>>>
>>>>>>>>---------------------------------------------------
>>>>>>>>
>>>>>>>>// Process incoming message
>>>>>>>>Parse(msg);
>>>>>>>>
>>>>>>>>// SIP INVITE without Service URN
>>>>>>>>// legacy devices
>>>>>>>>If (recognize-dialstring(msg)==TRUE) {  // we got an emergency
>>>>>>>>call going on  emergency=TRUE;  if (dialstring(msg) == 911)
>>>>>>>>serviceURN=urn:service:sos; } else if
>>>>>>>>(recognize-serviceURN(msg)==TRUE) {  // oh. A updated
>>>>device that
>>>>>>>>has a service URN attached to the
>>>>>call
>>>>>>>>serviceURN=retrieve_ServiceURN(msg);
>>>>>>>>emergency=TRUE;
>>>>>>>>} else {
>>>>>>>>// standard SIP message
>>>>>>>>// regular processing
>>>>>>>>process(msg);
>>>>>>>>emergency=FALSE;
>>>>>>>>}
>>>>>>>>
>>>>>>>>If (emergency == TRUE) {
>>>>>>>>  // make sure that the emergency call does not get
>>>>dropped on the
>>>>>>>>floor
>>>>>>>>  // skip authorization failures
>>>>>>>>  // give the call a special treatment
>>>>>>>>  lots-of-code-here();
>>>>>>>>
>>>>>>>>  // trigger all the QoS signaling you have in the
>>>>network to make
>>>>>>>>James happy
>>>>>>>>  trigger-qos();
>>>>>>>>
>>>>>>>>  // query location
>>>>>>>>  location=retrieve-location();
>>>>>>>>
>>>>>>>>  // determine next hop
>>>>>>>>  next-hop=lost(location, serviceURN)
>>>>>>>>
>>>>>>>>  // attach RPH marking to outgoing msg to make James and
>>>>>>>Keith happy
>>>>>>>>  msg=add(msg, RPH);
>>>>>>>>
>>>>>>>>  send(msg, next-hop);
>>>>>>>>}
>>>>>>>>
>>>>>>>>If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
>>>>>>>>  // all the emergency related processing done already upfront
>>>>>>>>  // hence I log something.
>>>>>>>>  log(RPH_WAS_PRESENT_JUHU);
>>>>>>>>} else if ((rph-present(msg) == TRUE) && (emergency ==
>>>>FALSE)) {
>>>>>>>>// this is not an emergency call  // this is something
>>>>like GETS
>>>>>>>>result=special-authorization-procedure(user);
>>>>>>>>
>>>>>>>>if (result == AUTHORIZED) {
>>>>>>>>   // do some priority & preemption thing here.
>>>>>>>>   // trigger all the QoS you have
>>>>>>>>   lots-of-code-here();
>>>>>>>>} else {
>>>>>>>>   log("NOT AUTHORIZED; don't DoS my network");  } } else {  //
>>>>>>>>don't need todo any RPH processing  // this includes the case
>>>>>>>>where the call was an emergency call but the RPH
>>>>>>>>
>>>>>>>>// marking was not there.
>>>>>>>>nothing();
>>>>>>>>}
>>>>>>>>
>>>>>>>>---------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>Ciao
>>>>>>>>Hannes
>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: [email-masked] [mailto:[email-masked]] On
>>>>>>>>>Behalf Of Hannes Tschofenig
>>>>>>>>>Sent: 06 February, 2009 15:07
>>>>>>>>>To: 'Janet P Gunn'
>>>>>>>>>Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
>>>>>>>>FI/Espoo)
>>>>>>>>>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: 
>Agenda (RPH)
>>>>>>>>>
>>>>>>>>>Who would define something that could prevent DoS problems?
>>>>>>>>>
>>>>>>>>>________________________________
>>>>>>>>>
>>>>>>>>>         From: Janet P Gunn [mailto:[email-masked]]
>>>>>>>>>         Sent: 06 February, 2009 14:11
>>>>>>>>>         To: Hannes Tschofenig
>>>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
>>>>>>>>>[email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
>>>>>'James
>>>>>>>>>M. Polk'
>>>>>>>>>         Subject: Re: [Ecrit] ECRIT Virtual Interim
>>>>Meeting: Agenda (RPH)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         But there is nothing IN RFC4412 that specifically
>>>>>>>addresses how to
>>>>>>>>>prevent any particular namespace being used for DoS.  
>Anyone/any
>>>>>UA
>>>>>>>>>can ATTEMPT to invoke priority treatment by attaching RPH.  For
>>>>>all
>>>>>>>>>of the 4412 namespaces, as with the new proposed namespace, the
>>>>>>>>>mechanisms for preventing DoS are not specified in the
>>>>>>>document that
>>>>>>>>>defines the namespace.
>>>>>>>>>They are/will be specified elsewhere.
>>>>>>>>>
>>>>>>>>>         Janet
>>>>>>>>>
>>>>>>>>>         This is a PRIVATE message. If you are not the intended
>>>>>>>recipient,
>>>>>>>>>please delete without copying and kindly advise us by e-mail of
>>>>>the
>>>>>>>>>mistake in delivery.
>>>>>>>>>         NOTE: Regardless of content, this e-mail shall not
>>>>>>>operate to bind
>>>>>>>>>CSC to any order or other contract unless pursuant to explicit
>>>>>>>>>written agreement or government initiative expressly permitting
>>>>>the
>>>>>>>>>use of e-mail for such purpose.
>>>>>>>>>
>>>>>>>>>         [email-masked] wrote on 02/06/2009 
>04:21:51 AM:
>>>>>>>>>
>>>>>>>>>         > Hi James,
>>>>>>>>>         >
>>>>>>>>>         > I have read RFC 4412 and also the GETS/MLPP IETF
>>>>>>>documents. What I
>>>>>>>>>would
>>>>>>>>>         > like to point out is that there is more than just a
>>>>>>>header and
>>>>>>>>>values within
>>>>>>>>>         > the header that have to be considered in order to
>>>>>>>make a judgement
>>>>>>>>>of what
>>>>>>>>>         > is appropriate and what isn't. There is an
>>>>>>>architectural question
>>>>>>>>>and
>>>>>>>>>         > whether the environment we are using the stuff is
>>>>>>>indeed providing
>>>>>>>>>the
>>>>>>>>>         > properties you need for the solution to be
>>>>appropriate.
>>>>>>>>>         >
>>>>>>>>>         > Let me describe in more detail what I meant (and
>>>>>>>please correct me
>>>>>>>>>if I am
>>>>>>>>>         > wrong).
>>>>>>>>>         >
>>>>>>>>>         > Getting priority for SIP requests when using a GETS
>>>>>>>alike scenario
>>>>>>>>>means
>>>>>>>>>         > that the entity that issues the request is specially
>>>>>>>authorized
>>>>>>>>>since
>>>>>>>>>         > otherwise you introduce a nice denial of
>>>>service attack. This
>>>>>>>>>authorization
>>>>>>>>>         > is tied to the entity that makes the request. For
>>>>>>>example, the
>>>>>>>>>person is
>>>>>>>>>         > working for the government and has special rights.
>>>>>>>>>James Bond as a (not so)
>>>>>>>>>         > secret agent might have these rights.
>>>>>>>>>         >
>>>>>>>>>         > The emergency services case
>>>>(citizen-to-authority) is a bit
>>>>>>>>>different as
>>>>>>>>>         > there aren't really special rights with respect to
>>>>>>>authorization
>>>>>>>>>tied to
>>>>>>>>>         > individuals. Instead, the fact that something is an
>>>>>>>emergency is
>>>>>>>>>purely a
>>>>>>>>>         > judgement of the human that dials a special number.
>>>>>>>>>To deal with fraud, we
>>>>>>>>>         > discussed in the group on what we can actually do to
>>>>>>>ensure that
>>>>>>>>>end users
>>>>>>>>>         > do not bypass security procedures (such as
>>>>>>>authorization checks,
>>>>>>>>>charging
>>>>>>>>>         > and so on). Part of this investigation was
>>>>the publication of
>>>>>>>>>         > http://www.ietf.org/rfc/rfc5069.txt that also
>>>>describes this
>>>>>>>>>issue.
>>>>>>>>>         >
>>>>>>>>>         > So, imagine the implementation of a SIP 
>proxy (and we
>>>>>>>implemented
>>>>>>>>>that
>>>>>>>>>         > stuff) that receives a call that contains a Service
>>>>>>>URN. The code
>>>>>>>>>branches
>>>>>>>>>         > into a special mode where everything is done
>>>>so that the call
>>>>>>>>>receives
>>>>>>>>>         > appropriate treatment and does not get 
>dropped on the
>>>>>>>floor. The
>>>>>>>>>way how the
>>>>>>>>>         > Service URN is placed in the message 
>ensures that the
>>>>>>>call cannot
>>>>>>>>>go to my
>>>>>>>>>         > friend (instead of the PSAP) unless the end host ran
>>>>>>>LoST already.
>>>>>>>>>In the
>>>>>>>>>         > latter case, we discussed this also on the 
>list for a
>>>>>>>while and
>>>>>>>>>Richard even
>>>>>>>>>         > wrote a draft about it in the context of the
>>>>location hiding
>>>>>>>>>topic, we said
>>>>>>>>>         > that the proxy would have to run LoST if he
>>>>cares about a
>>>>>>>>>potential
>>>>>>>>>         > fraudulent usage.
>>>>>>>>>         >
>>>>>>>>>         > So, what do we need todo in order to provide
>>>>secure RFC 4412
>>>>>>>>>functionality
>>>>>>>>>         > in our context?
>>>>>>>>>         >
>>>>>>>>>         > Do you think that the current text in
>>>>>>>>>         >
>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>>>>>>>>>gency-rph-nam
>>>>>>>>>         > espace-00.txt reflects any of the
>>>>above-described issues:
>>>>>>>>>         > "
>>>>>>>>>         >    The Security considerations that apply 
>to RFC 4412
>>>>>>>>>[RFC4412]
>>>>>>>>>apply
>>>>>>>>>         >    here.  This document introduces no new security
>>>>>>>>>issues relative
>>>>>>>>>to
>>>>>>>>>         >    RFC 4412.
>>>>>>>>>         > "
>>>>>>>>>         >
>>>>>>>>>         > From various discussions in GEOPRIV I recall
>>>>that you are
>>>>>>>>>super-sensitive
>>>>>>>>>         > regarding security and privacy. For some reasons you
>>>>>>>don't seem to
>>>>>>>>>have the
>>>>>>>>>         > same concerns here. I would like to
>>>>understand your reasoning.
>>>>>>>>>         >
>>>>>>>>>         > Please also do me another favor: Don't always say
>>>>>>>that I don't
>>>>>>>>>understand
>>>>>>>>>         > the subject. Even if that would be the case it isn't
>>>>>>>particular
>>>>>>>>>fair given
>>>>>>>>>         > that different folks had to educate you on other
>>>>>>>topics in the
>>>>>>>>>past as well.
>>>>>>>>>         > Additionally, if you listen to the audio recordings
>>>>>>>then you will
>>>>>>>>>notice
>>>>>>>>>         > that Henning, Ted, and Jon do not seem to understand
>>>>>>>the issue
>>>>>>>>>either as
>>>>>>>>>         > they have raised similar issues during the
>>>>F2F meetings.
>>>>>>>>>         >
>>>>>>>>>         > Ciao
>>>>>>>>>         > Hannes
>>>>>>>>>         >
>>>>>>>>>         >
>>>>>>>>>         > >Hannes - I believe it is you who do not understand
>>>>>>>RFC 4412 --
>>>>>>>>>         > >and many of us are trying to get that
>>>>through to you, but you
>>>>>>>>>         > >don't seem to want to listen/read.
>>>>>>>>>         > >
>>>>>>>>>         > >RFC 4412 is *for* priority marking SIP requests,
>>>>>>>>>         > >
>>>>>>>>>         > >One use is GETS.
>>>>>>>>>         > >
>>>>>>>>>         > >One use is MLPP.
>>>>>>>>>         > >
>>>>>>>>>         > >These examples are in RFC 4412 because there
>>>>were specific
>>>>>>>>>         > >namespaces being created for the IANA section of
>>>>>>>that document.
>>>>>>>>>         > >
>>>>>>>>>         > >Reading the whole document, you will see
>>>>that RPH can be
>>>>>>>>>         > >specified for other uses than GETS or MLPP
>>>>specifically.
>>>>>>>>>         > >
>>>>>>>>>         > >I knew when I wrote RFC 4412 that one day we
>>>>would specify a
>>>>>>>>>         > >namespace for ECRIT (the "esnet" namespace
>>>>now) -- but I also
>>>>>>>>>         > >knew it was premature for RFC 4412 to
>>>>incorporate that
>>>>>>>>>         > >namespace, that a future doc to RFC 4412
>>>>would have to be
>>>>>>>>>         > >written to do this. Brian and I talked about
>>>>this at the
>>>>>>>>>         > >original NENA meeting that created the IP WGs there
>>>>>>>(in August
>>>>>>>>>         > >of 03).  We both agreed we should wait until it was
>>>>>>>>>         > >appropriate to the work in the IETF to
>>>>submit this document
>>>>>>>>>         > >that is now
>>>>>>>>>         >
>>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-l
>ocal-emer
>>>>>>>>>         > >gency-rph-namespace-00.txt
>>>>>>>>>         > >
>>>>>>>>>         > >Yet, you seem to want to use some additional
>>>>mechanism to
>>>>>>>>>         > >indicate priority of a call in SIP.  That
>>>>means you want to
>>>>>>>>>         > >introduce a second way to accomplish this in SIP.
>>>>>>>>>Why do you
>>>>>>>>>         > >want to promote a separate way to do something SIP
>>>>>>>has already
>>>>>>>>>         > >defined? That will cause interoperability 
>issues and
>>>>>>>we both know
>>>>>>>>>that.
>>>>>>>>>         > >
>>>>>>>>>         > >You've said to me (and others) that you
>>>>believe RPH is just
>>>>>>>>>         > >another way to accomplish what sos or a URI can
>>>>>>>indicate - and
>>>>>>>>>         > >you're wrong.  Your way would be
>>>>_the_second_way_to_do_it,
>>>>>>>>>         > >because SIP already considers RPH to be
>>>>*the*way* to priority
>>>>>>>>>         > >mark SIP requests.
>>>>>>>>>         > >
>>>>>>>>>         > >If you don't believe me (no comment), then
>>>>why do you not
>>>>>>>>>         > >believe the SIP WG chair (who knows more
>>>>about SIP than both
>>>>>>>>>         > >of us) - who, on this thread, has again said
>>>>to you "RFC 4412
>>>>>>>>>         > >(RPH) is the SIP mechanism to priority mark
>>>>SIP requests"?
>>>>>>>>>         > >
>>>>>>>>>         > >Further, I believe it is inappropriate to
>>>>prohibit endpoints
>>>>>>>>>         > >from being able to set the esnet namespace.
>>>>I absolutely
>>>>>>>>>         > >believe it will not be needed most of the
>>>>time, but I believe
>>>>>>>>>         > >if someone does find a valid use for
>>>>endpoints to mark
>>>>>>>>>         > >priority in SIP, this ID - once it has
>>>>become an RFC -- will
>>>>>>>>>         > >have to be obsoleted with a new RFC saying 
>the exact
>>>>>>>opposite.
>>>>>>>>>         > >
>>>>>>>>>         > >(color me confused ... over and over again)
>>>>>>>>>         > >
>>>>>>>>>         > >James
>>>>>>>>>         > >
>>>>>>>>>         > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>>>>>>>>>         > >>Keith, please understand that the usage 
>of RFC 4412
>>>>>>>for GETS and
>>>>>>>>>for
>>>>>>>>>         > >>the type of emergency call we discuss here is
>>>>>>>different. Just
>>>>>>>>>looking
>>>>>>>>>         > >>at the header and the name of the 
>namespace is a bit
>>>>>>>>>         > >artificial. I hope
>>>>>>>>>         > >>you understand that.
>>>>>>>>>         > >>
>>>>>>>>>         > >> >-----Original Message-----
>>>>>>>>>         > >> >From: DRAGE, Keith (Keith)
>>>>>>>>>[mailto:[email-masked]]
>>>>>>>>>         > >> >Sent: 05 February, 2009 14:55
>>>>>>>>>         > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
>>>>>>>>>Polk'; 'Tschofenig,
>>>>>>>>>         > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
>>>>>>>>>         > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
>>>>>>>>>Meeting: Agenda (my
>>>>>>>>>
>>>>>>>>>         > >> >mistake)
>>>>>>>>>         > >> >
>>>>>>>>>         > >> >Which is exactly what RFC 4412 specifies for all
>>>>>>>namespaces.
>>>>>>>>>         > >> >
>>>>>>>>>         > >> >regards
>>>>>>>>>         > >> >
>>>>>>>>>         > >> >Keith
>>>>>>>>>         > >> >
>>>>>>>>>         > >> >> -----Original Message-----
>>>>>>>>>         > >> >> From: [email-masked]
>>>>>>>[mailto:[email-masked]]
>>>>>>>>>         > >> >On Behalf
>>>>>>>>>         > >> >> Of Brian Rosen
>>>>>>>>>         > >> >> Sent: Wednesday, February 04, 2009 10:19 PM
>>>>>>>>>         > >> >> To: 'Hannes Tschofenig'; 'James M.
>>>>Polk'; 'Tschofenig,
>>>>>>>>>         > >Hannes (NSN
>>>>>>>>>         > >> >> - FI/Espoo)'; 'ECRIT'
>>>>>>>>>         > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>>>>>>>>>Meeting: Agenda (my
>>>>>>>>>         > >> >> mistake)
>>>>>>>>>         > >> >>
>>>>>>>>>         > >> >> The value is that in some networks
>>>>where priority for
>>>>>>>>>         > >> >emergency calls
>>>>>>>>>         > >> >> is appropriate, and appropriate
>>>>policing of marking is
>>>>>>>>>         > >implemented,
>>>>>>>>>         > >> >> emergency calls will receive resource 
>priority.
>>>>>>>>>         > >> >>
>>>>>>>>>         > >> >> Not all networks would need policing.  Some
>>>>>>>will.  Policing
>>>>>>>>>could
>>>>>>>>>         > >> >> be to Route header/R-URI content, but other
>>>>>>>criteria are
>>>>>>>>>possible.
>>>>>>>>>         > >> >>
>>>>>>>>>         > >> >> Not all networks will need resource priority
>>>>>>>for emergency
>>>>>>>>>calls.
>>>>>>>>>         > >> >> Fine, ignore this marking/namespace.
>>>>>>>>>         > >> >>
>>>>>>>>>         > >> >> Brian
>>>>>>>>>         > >> >> > -----Original Message-----
>>>>>>>>>         > >> >> > From: Hannes Tschofenig
>>>>>>>>>[mailto:[email-masked]]
>>>>>>>>>         > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>>>>>>>>>         > >> >> > To: 'Brian Rosen'; 'James M. Polk';
>>>>>>>Tschofenig, Hannes
>>>>>>>>>(NSN -
>>>>>>>>>         > >> >> > FI/Espoo); 'ECRIT'
>>>>>>>>>         > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
>>>>>>>>>Meeting: Agenda (my
>>>>>>>>>         > >> >> > mistake)
>>>>>>>>>         > >> >> >
>>>>>>>>>         > >> >> > I don't even see the value in permitting the
>>>>>>>endpoint todo
>>>>>>>>>the
>>>>>>>>>         > >> >> > RPH marking.
>>>>>>>>>         > >> >> > In addition to the security concerns
>>>>there is also the
>>>>>>>>>         > >> >problem that
>>>>>>>>>         > >> >> > there are more options to implement without
>>>>>>>an additional
>>>>>>>>>value.
>>>>>>>>>         > >> >> >
>>>>>>>>>         > >> >> > >-----Original Message-----
>>>>>>>>>         > >> >> > >From: Brian Rosen 
>[mailto:[email-masked]]
>>>>>>>>>         > >> >> > >Sent: 05 February, 2009 00:03
>>>>>>>>>         > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
>>>>>>>'Tschofenig,
>>>>>>>>>         > >> >> Hannes (NSN -
>>>>>>>>>         > >> >> > >FI/Espoo)'; 'ECRIT'
>>>>>>>>>         > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual
>>>>Interim Meeting:
>>>>>>>>>Agenda (my
>>>>>>>>>         > >> >> > mistake)
>>>>>>>>>         > >> >> > >
>>>>>>>>>         > >> >> > >Hannes
>>>>>>>>>         > >> >> > >
>>>>>>>>>         > >> >> > >This matches my understanding
>>>>precisely.  We wish to
>>>>>>>>>         > >> >> permit endpoints
>>>>>>>>>         > >> >> > >to mark. We do not require it, and
>>>>don't necessarily
>>>>>>>>>expect it
>>>>>>>>>         > >> >> > >in many (even
>>>>>>>>>         > >> >> > >most) cases.  We don't wish to see the
>>>>>>>document prohibit
>>>>>>>>>it.
>>>>>>>>>         > >> >> > >We all seem to agree it has value 
>within the
>>>>>>>Emergency
>>>>>>>>>         > >> >Services IP
>>>>>>>>>         > >> >> > >Networks.
>>>>>>>>>         > >> >> > >
>>>>>>>>>         > >> >> > >Brian
>>>>>>>>>         > >> >> > >
>>>>>>>>>         > >> >> > >> -----Original Message-----
>>>>>>>>>         > >> >> > >> From: [email-masked]
>>>>>>>>>[mailto:[email-masked]]
>>>>>>>>>         > >> >> > >On Behalf
>>>>>>>>>         > >> >> > >> Of James M. Polk
>>>>>>>>>         > >> >> > >> Sent: Wednesday, February 04, 
>2009 4:01 PM
>>>>>>>>>         > >> >> > >> To: Hannes Tschofenig; Tschofenig,
>>>>Hannes (NSN -
>>>>>>>>>         > >> >> FI/Espoo); 'ECRIT'
>>>>>>>>>         > >> >> > >> Subject: Re: [Ecrit] ECRIT 
>Virtual Interim
>>>>>>>>>Meeting:
>>>>>>>>>         > >Agenda (my
>>>>>>>>>         > >> >> > >> mistake)
>>>>>>>>>         > >> >> > >>
>>>>>>>>>         > >> >> > >> At 02:37 PM 2/4/2009, Hannes
>>>>Tschofenig wrote:
>>>>>>>>>         > >> >> > >> > > James wrote:
>>>>>>>>>         > >> >> > >> > >> you are the _lone_ voice not
>>>>>>>supporting this ID,
>>>>>>>>>         > >> >> > >> >
>>>>>>>>>         > >> >> > >> >Listening to the audio recording of past
>>>>>>>meetings I
>>>>>>>>>have to
>>>>>>>>>         > >> >> > >say that
>>>>>>>>>         > >> >> > >> >I
>>>>>>>>>         > >> >> > >> was
>>>>>>>>>         > >> >> > >> >not the only persons raising
>>>>concerns about the
>>>>>>>>>document.
>>>>>>>>>         > >> >> > >> >That was probably the reason why you
>>>>>>>agreed to limit
>>>>>>>>>the
>>>>>>>>>         > >> >> > >scope of the
>>>>>>>>>         > >> >> > >> >document (which you didn't later do) to
>>>>>>>get folks to
>>>>>>>>>agree
>>>>>>>>>         > >> >> > >to make it
>>>>>>>>>         > >> >> > >> a WG
>>>>>>>>>         > >> >> > >> >item.
>>>>>>>>>         > >> >> > >>
>>>>>>>>>         > >> >> > >> re-listen to the audio please
>>>>>>>>>         > >> >> > >>
>>>>>>>>>         > >> >> > >> Ted's concerns were consistent with most
>>>>>>>>>(all?) other
>>>>>>>>>         > >> >> concerns --
>>>>>>>>>         > >> >> > >> which were based on the premise 
>of whether
>>>>>>>or not the
>>>>>>>>>         > >> >> UAC should be
>>>>>>>>>         > >> >> > >> trusted to initiate the marking on the
>>>>>>>INVITE.  The
>>>>>>>>>most
>>>>>>>>>         > >> >> > >> recent version has backed off this
>>>>to a "can" --
>>>>>>>>>meaning not
>>>>>>>>>         > >> >prohibited
>>>>>>>>>         > >> >> > >> (i.e., no 2119 text).  I also backed off
>>>>>>>the text in
>>>>>>>>>the
>>>>>>>>>         > >> >> SP domain
>>>>>>>>>         > >> >> > >> part to "can", such that there is
>>>>no 2119 text
>>>>>>>>>         > >> >mandating or even
>>>>>>>>>         > >> >> > >> recommending its usage there. I also do
>>>>>>>not prohibit
>>>>>>>>>its
>>>>>>>>>         > >> >> > >use, based on
>>>>>>>>>         > >> >> > >> local policy.  Keith has come 
>forward with
>>>>>>>the specific
>>>>>>>>>
>>>>>>>>>         > >> >> > >> request that non-ESInet networks be
>>>>>>>allowed to mark and
>>>>>>>>>pay
>>>>>>>>>         > >> >attention to
>>>>>>>>>         > >> >> > >> this priority indication -- with IMS as
>>>>>>>the specific
>>>>>>>>>example
>>>>>>>>>         > >> >> > >> he wishes to have this valid for.
>>>>>>>>>         > >> >> > >>
>>>>>>>>>         > >> >> > >> Where there is no disagreement, save for
>>>>>>>your recent
>>>>>>>>>         > >> >> > >pushback - is in
>>>>>>>>>         > >> >> > >> the ESInet, which is where Brian
>>>>has requested it's
>>>>>>>>>         > >> >> > >definition in the
>>>>>>>>>         > >> >> > >> IETF on behalf of NENA.  He's the i3 WG
>>>>>>>chair within
>>>>>>>>>         > >> >> NENA, and if
>>>>>>>>>         > >> >> > >> he asks for it, are you going to say you
>>>>>>>know better
>>>>>>>>>than he?
>>>>>>>>>         > >> >> > >>
>>>>>>>>>         > >> >> > >>
>>>>>>>>>         > >> >> > >> >Btw, I not disagreeing with the document
>>>>>>>as such. I
>>>>>>>>>         > >> >just want to
>>>>>>>>>         > >> >> > the
>>>>>>>>>         > >> >> > >> scope
>>>>>>>>>         > >> >> > >> >to change. The usage of RPH
>>>>within the emergency
>>>>>>>>>         > >> >> services network
>>>>>>>>>         > >> >> > is
>>>>>>>>>         > >> >> > >> fine
>>>>>>>>>         > >> >> > >> >for me. I may get convinced to start the
>>>>>>>RPH marking
>>>>>>>>>from
>>>>>>>>>         > >> >> > >the the VSP
>>>>>>>>>         > >> >> > >> >towards the PSAP. I feel uneasy 
>about the
>>>>>>>end host
>>>>>>>>>doing
>>>>>>>>>         > >> >> > >the marking.
>>>>>>>>>         > >> >> > >>
>>>>>>>>>         > >> >> > >> please read what I wrote above, and then
>>>>>>>re-read the
>>>>>>>>>         > >> >most recent
>>>>>>>>>         > >> >> > >> version of the ID. I don't have endpoints
>>>>>>>that SHOULD
>>>>>>>>>or
>>>>>>>>>         > >> >> MUST mark
>>>>>>>>>         > >> >> > >> anything wrt RPH.  I also don't want to
>>>>>>>prohibit it,
>>>>>>>>>         > >> >> because there
>>>>>>>>>         > >> >> > >> might be cases (that I don't know
>>>>of) of valid uses
>>>>>>>>>         > >> >> under certain
>>>>>>>>>         > >> >> > >> circumstances.  Figure 1 is very clear
>>>>>>>that there are 3
>>>>>>>>>         > >> >> networking
>>>>>>>>>         > >> >> > >> parts to consider
>>>>>>>>>         > >> >> > >>
>>>>>>>>>         > >> >> > >> #1 - from the endpoint
>>>>>>>>>         > >> >> > >> #2 - within the VSP
>>>>>>>>>         > >> >> > >> #3 - within the ESInet
>>>>>>>>>         > >> >> > >>
>>>>>>>>>         > >> >> > >> the most recent ID version has "can" for
>>>>>>>#s 1 and 2,
>>>>>>>>>and
>>>>>>>>>         > >> >> > >2119 language
>>>>>>>>>         > >> >> > >> offering those supporting this
>>>>>>>specification will have
>>>>>>>>>RPH
>>>>>>>>>         > >> >> > >> adherence within #3 (the ESInet).
>>>>>>>>>         > >> >> > >>
>>>>>>>>>         > >> >> > >> What other scope changes do you want,
>>>>>>>because I haven't
>>>>>>>>>         > >> >> heard them.
>>>>>>>>>         > >> >> > >>
>>>>>>>>>         > >> >> > >> I only heard you claim in email 
>during the
>>>>>>>last IETF
>>>>>>>>>and in
>>>>>>>>>         > >> >> > >the ECRIT
>>>>>>>>>         > >> >> > >> session that RPH should not be
>>>>used for priority
>>>>>>>>>marking
>>>>>>>>>         > >> >> requests.
>>>>>>>>>         > >> >> > >> This is something Keith (SIP WG
>>>>chair) voiced his
>>>>>>>>>opposition
>>>>>>>>>         > >> >> > >> to your views regarding creating a second
>>>>>>>means for SIP
>>>>>>>>>to
>>>>>>>>>         > >> >priority
>>>>>>>>>         > >> >> > >> mark request "when SIP already has one
>>>>>>>interoperable
>>>>>>>>>way to
>>>>>>>>>         > >> >> > >> accomplish this... it's call the 
>RP header
>>>>>>>mechanism".
>>>>>>>>>         > >> >> > >>
>>>>>>>>>         > >> >> > >> >I don't see advantages -- only
>>>>disadvantages.
>>>>>>>>>         > >> >> > >> >
>>>>>>>>>         > >> >> > >> >Ciao
>>>>>>>>>         > >> >> > >> >Hannes
>>>>>>>>>         > >> >> > >>
>>>>>>>>>         > >> >> > >>
>>>>_______________________________________________
>>>>>>>>>         > >> >> > >> Ecrit mailing list
>>>>>>>>>         > >> >> > >> [email-masked]
>>>>>>>>>         > >> >> > >> 
>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>         > >> >> > >
>>>>>>>>>         > >> >>
>>>>>>>>>         > >> >> 
>_______________________________________________
>>>>>>>>>         > >> >> Ecrit mailing list
>>>>>>>>>         > >> >> [email-masked]
>>>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>         > >> >>
>>>>>>>>>         > >> >
>>>>>>>>>         > >
>>>>>>>>>         >
>>>>>>>>>         > _______________________________________________
>>>>>>>>>         > Ecrit mailing list
>>>>>>>>>         > [email-masked]
>>>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>_______________________________________________
>>>>>>>>>Ecrit mailing list
>>>>>>>>>[email-masked]
>>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>
>>>>>>>>_______________________________________________
>>>>>>>>Ecrit mailing list
>>>>>>>>[email-masked]
>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>
>>>>>>_______________________________________________
>>>>>>Ecrit mailing list
>>>>>>[email-masked]
>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>>_______________________________________________
>>>Ecrit mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>>
>>>-------------------------------------------------------------
>-----------------------------------
>>>This message is for the designated recipient only and may
>>>contain privileged, proprietary, or otherwise private information.
>>>If you have received it in error, please notify the sender
>>>immediately and delete the original.  Any unauthorized use of
>>>this email is prohibited.
>>>-------------------------------------------------------------
>-----------------------------------
>>>[mf2]
>>>
>>
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/ecrit
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>

From: Henning Schulzrinne <[email-masked]>
To: "James M. Polk" <[email-masked]>
Date: Fri, 6 Feb 2009 17:52:33 -0500
Cc: ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

Discussing the use of RPH for UAs is out of scope for the document. I  
have no objection to adding a sentence to that effect, e.g., to the  
security consideration section.

On Feb 6, 2009, at 5:37 PM, James M. Polk wrote:

> Henning
>
> I agree with your statement
>
>        "This document does not prevent the use of this
>        mechanism somewhere else." in documents.
>
> I just want to avoid having to write in (something like)
>
>        'UAs are prevented from including RP namespace esnet"
>
> That was pretty much suggested by one person on the list.
>
> Is this agreeable?
>
> Taking this statement further
>
>        "I will object to any text mentioning use of ESNET in UAs."
>
> Does that mean you do _not_ want UA insertion of esnet to be added  
> to the security considerations section?
>
> James

Date: Fri, 06 Feb 2009 17:09:21 -0600
To: "Hannes Tschofenig" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)

At 04:46 PM 2/6/2009, Hannes Tschofenig wrote:
>Good that you agree that GETS usage of RPH and the one we discuss in ECRIT
>is different.
>So far, some folks have been saying "what works for GETS works for the ECRIT
>case as well".

I don't know who "those people" are but they are wrong.

Now, did you mean "what works for MLPP works for the ECRIT case as well"?

This is closer to the truth, but since we do not have any plans (that 
I know of) to allow preemption when calling sos -- the last P in MLPP 
doesn't apply at this time.

>I argued that the environment is different and hence just referencing RFC
>4412 isn't good enough.

I agree that the environment (for GETS and for MLPP when compared to 
ECRIT) is different, but the header is just a header. It's how one 
uses it in any environment that creates the security 
considerations.  The same authentication and authorization 
considerations text applies to all 3 environments, and this new ID 
only identifies a namespace to be used within local emergency calling.

I fully expect there will need to be a BCP or Framework type doc 
written providing more guidelines (or NENA will write it), once we 
have implementation experience to write such a doc -- but we do not 
at this time.

> >-----Original Message-----
> >From: James M. Polk [mailto:[email-masked]]
> >Sent: 07 February, 2009 00:02
> >To: Hannes Tschofenig
> >Cc: 'DRAGE, Keith (Keith)'; 'Brian Rosen'; Tschofenig, Hannes
> >(NSN - FI/Espoo); 'ECRIT'
> >Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
> >
> >At 03:21 AM 2/6/2009, Hannes Tschofenig wrote:
> >>Hi James,
> >>
> >>I have read RFC 4412 and also the GETS/MLPP IETF documents. What I
> >>would like to point out is that there is more than just a header and
> >>values within the header that have to be considered in order
> >to make a
> >>judgement of what is appropriate and what isn't. There is an
> >>architectural question and whether the environment we are using the
> >>stuff is indeed providing the properties you need for the
> >solution to be appropriate.
> >>
> >>Let me describe in more detail what I meant (and please
> >correct me if I
> >>am wrong).
> >>
> >>Getting priority for SIP requests when using a GETS alike scenario
> >>means that the entity that issues the request is specially authorized
> >>since otherwise you introduce a nice denial of service attack.
> >
> >You are missing a step in GETS here.  The endpoint, who sends
> >the GETS set-up as an INVITE is not already authorized (not
> >the device, not the user).  In North America, there is a 10
> >digit GETS number that is dialed (that I won't give out right
> >now on an open list) - and there literally is only 1 number
> >available to dial for this service.  Literally anyone can dial
> >this number today in North America (no matter where the phone
> >is - as long as it is in North America -- and I might be too
> >limiting in that it is dialable from anywhere, because it is
> >going to a North American destination).
> >
> >Once this number is dialed, it is answered by an
> >authentication and authorization IVR.  This IVR challenges
> >each caller for their authentication passcode, and a
> >password). Once this has been successfully entered, then call
> >is NOW authorized to proceed towards its destination number -
> >this step is only known to the authorizing system because the
> >destination 10 digit number is NOT entered until after the
> >authentication and authorization step has completed.
> >
> >The authorized caller is prompted with a new dial tone - in
> >which they can enter any number on the planet and receive
> >preferential treatment through as many carriers (in IP, it's
> >SPs) that have implemented this GETS service (which is an SLA
> >with the Department of Homeland Security now).
> >
> >Merely entering the GETS RP namespace is never intended,
> >alone, to gain any preferential treatment -- other than
> >towards this authentication & authorization IVR.
> >
> >I hope you can see that this is a completely separate type of
> >service and implementation type than ECRIT based emergency
> >calling will use.
> >
> >BTW - to your comment below about me not calling your name out
> >when you are incorrect because I have been equally incorrect
> >-- I'm not sure I've been spared as much as you think, given
> >that many have called me out by name when they've felt I've
> >been wrong over the years.
> >
> >>This authorization
> >>is tied to the entity that makes the request. For example, the person
> >>is working for the government and has special rights. James Bond as a
> >>(not so) secret agent might have these rights.
> >>
> >>The emergency services case (citizen-to-authority) is a bit different
> >>as there aren't really special rights with respect to authorization
> >>tied to individuals. Instead, the fact that something is an emergency
> >>is purely a judgement of the human that dials a special
> >number. To deal
> >>with fraud, we discussed in the group on what we can actually do to
> >>ensure that end users do not bypass security procedures (such as
> >>authorization checks, charging and so on). Part of this investigation
> >>was the publication of http://www.ietf.org/rfc/rfc5069.txt
> >that also describes this issue.
> >>
> >>So, imagine the implementation of a SIP proxy (and we implemented that
> >>stuff) that receives a call that contains a Service URN. The code
> >>branches into a special mode where everything is done so that
> >the call
> >>receives appropriate treatment and does not get dropped on the floor.
> >>The way how the Service URN is placed in the message ensures that the
> >>call cannot go to my friend (instead of the PSAP) unless the end host
> >>ran LoST already. In the latter case, we discussed this also on the
> >>list for a while and Richard even wrote a draft about it in
> >the context
> >>of the location hiding topic, we said that the proxy would
> >have to run
> >>LoST if he cares about a potential fraudulent usage.
> >>
> >>So, what do we need todo in order to provide secure RFC 4412
> >>functionality in our context?
> >>
> >>Do you think that the current text in
> >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-eme
> >rgency-rp
> >>h-nam espace-00.txt reflects any of the above-described issues:
> >>"
> >>    The Security considerations that apply to RFC 4412 [RFC4412] apply
> >>    here.  This document introduces no new security issues relative to
> >>    RFC 4412.
> >>"
> >>
> >> From various discussions in GEOPRIV I recall that you are
> >>super-sensitive regarding security and privacy. For some reasons you
> >>don't seem to have the same concerns here. I would like to
> >understand your reasoning.
> >>
> >>Please also do me another favor: Don't always say that I don't
> >>understand the subject. Even if that would be the case it isn't
> >>particular fair given that different folks had to educate you
> >on other topics in the past as well.
> >>Additionally, if you listen to the audio recordings then you will
> >>notice that Henning, Ted, and Jon do not seem to understand the issue
> >>either as they have raised similar issues during the F2F meetings.
> >>
> >>Ciao
> >>Hannes
> >>
> >>
> >> >Hannes - I believe it is you who do not understand RFC 4412 -- and
> >> >many of us are trying to get that through to you, but you
> >don't seem
> >> >to want to listen/read.
> >> >
> >> >RFC 4412 is *for* priority marking SIP requests,
> >> >
> >> >One use is GETS.
> >> >
> >> >One use is MLPP.
> >> >
> >> >These examples are in RFC 4412 because there were specific
> >namespaces
> >> >being created for the IANA section of that document.
> >> >
> >> >Reading the whole document, you will see that RPH can be specified
> >> >for other uses than GETS or MLPP specifically.
> >> >
> >> >I knew when I wrote RFC 4412 that one day we would specify a
> >> >namespace for ECRIT (the "esnet" namespace now) -- but I
> >also knew it
> >> >was premature for RFC 4412 to incorporate that namespace, that a
> >> >future doc to RFC 4412 would have to be written to do this.
> >Brian and
> >> >I talked about this at the original NENA meeting that
> >created the IP
> >> >WGs there (in August of 03).  We both agreed we should wait
> >until it
> >> >was appropriate to the work in the IETF to submit this
> >document that
> >> >is now
> >> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >> >gency-rph-namespace-00.txt
> >> >
> >> >Yet, you seem to want to use some additional mechanism to indicate
> >> >priority of a call in SIP.  That means you want to
> >introduce a second
> >> >way to accomplish this in SIP.  Why do you want to promote
> >a separate
> >> >way to do something SIP has already defined? That will cause
> >> >interoperability issues and we both know that.
> >> >
> >> >You've said to me (and others) that you believe RPH is just another
> >> >way to accomplish what sos or a URI can indicate - and
> >you're wrong.
> >> >Your way would be _the_second_way_to_do_it, because SIP already
> >> >considers RPH to be *the*way* to priority mark SIP requests.
> >> >
> >> >If you don't believe me (no comment), then why do you not
> >believe the
> >> >SIP WG chair (who knows more about SIP than both of us) - who, on
> >> >this thread, has again said to you "RFC 4412
> >> >(RPH) is the SIP mechanism to priority mark SIP requests"?
> >> >
> >> >Further, I believe it is inappropriate to prohibit endpoints from
> >> >being able to set the esnet namespace.  I absolutely
> >believe it will
> >> >not be needed most of the time, but I believe if someone
> >does find a
> >> >valid use for endpoints to mark priority in SIP, this ID - once it
> >> >has become an RFC -- will have to be obsoleted with a new
> >RFC saying
> >> >the exact opposite.
> >> >
> >> >(color me confused ... over and over again)
> >> >
> >> >James
> >> >
> >> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >> >>Keith, please understand that the usage of RFC 4412 for
> >GETS and for
> >> >>the type of emergency call we discuss here is different. Just
> >> >>looking at the header and the name of the namespace is a bit
> >> >artificial. I hope
> >> >>you understand that.
> >> >>
> >> >> >-----Original Message-----
> >> >> >From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> >> >> >Sent: 05 February, 2009 14:55
> >> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk';
> >> >> >'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >> >mistake)
> >> >> >
> >> >> >Which is exactly what RFC 4412 specifies for all namespaces.
> >> >> >
> >> >> >regards
> >> >> >
> >> >> >Keith
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> From: [email-masked] [mailto:[email-masked]]
> >> >> >On Behalf
> >> >> >> Of Brian Rosen
> >> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
> >> >Hannes (NSN
> >> >> >> - FI/Espoo)'; 'ECRIT'
> >> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >> >> mistake)
> >> >> >>
> >> >> >> The value is that in some networks where priority for
> >> >> >emergency calls
> >> >> >> is appropriate, and appropriate policing of marking is
> >> >implemented,
> >> >> >> emergency calls will receive resource priority.
> >> >> >>
> >> >> >> Not all networks would need policing.  Some will.  Policing
> >> >> >> could be to Route header/R-URI content, but other
> >criteria are possible.
> >> >> >>
> >> >> >> Not all networks will need resource priority for
> >emergency calls.
> >> >> >> Fine, ignore this marking/namespace.
> >> >> >>
> >> >> >> Brian
> >> >> >> > -----Original Message-----
> >> >> >> > From: Hannes Tschofenig [mailto:[email-masked]]
> >> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >> >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig,
> >Hannes (NSN -
> >> >> >> > FI/Espoo); 'ECRIT'
> >> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting:
> >Agenda (my
> >> >> >> > mistake)
> >> >> >> >
> >> >> >> > I don't even see the value in permitting the
> >endpoint todo the
> >> >> >> > RPH marking.
> >> >> >> > In addition to the security concerns there is also the
> >> >> >problem that
> >> >> >> > there are more options to implement without an
> >additional value.
> >> >> >> >
> >> >> >> > >-----Original Message-----
> >> >> >> > >From: Brian Rosen [mailto:[email-masked]]
> >> >> >> > >Sent: 05 February, 2009 00:03
> >> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,
> >> >> >> Hannes (NSN -
> >> >> >> > >FI/Espoo)'; 'ECRIT'
> >> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda
> >> >> >> > >(my
> >> >> >> > mistake)
> >> >> >> > >
> >> >> >> > >Hannes
> >> >> >> > >
> >> >> >> > >This matches my understanding precisely.  We wish to
> >> >> >> permit endpoints
> >> >> >> > >to mark. We do not require it, and don't necessarily expect
> >> >> >> > >it in many (even
> >> >> >> > >most) cases.  We don't wish to see the document prohibit it.
> >> >> >> > >We all seem to agree it has value within the Emergency
> >> >> >Services IP
> >> >> >> > >Networks.
> >> >> >> > >
> >> >> >> > >Brian
> >> >> >> > >
> >> >> >> > >> -----Original Message-----
> >> >> >> > >> From: [email-masked]
> >> >> >> > >> [mailto:[email-masked]]
> >> >> >> > >On Behalf
> >> >> >> > >> Of James M. Polk
> >> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> >> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
> >> >> >> FI/Espoo); 'ECRIT'
> >> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
> >> >Agenda (my
> >> >> >> > >> mistake)
> >> >> >> > >>
> >> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> >> >> >> > >> > > James wrote:
> >> >> >> > >> > >> you are the _lone_ voice not supporting this ID,
> >> >> >> > >> >
> >> >> >> > >> >Listening to the audio recording of past meetings I have
> >> >> >> > >> >to
> >> >> >> > >say that
> >> >> >> > >> >I
> >> >> >> > >> was
> >> >> >> > >> >not the only persons raising concerns about the document.
> >> >> >> > >> >That was probably the reason why you agreed to limit the
> >> >> >> > >scope of the
> >> >> >> > >> >document (which you didn't later do) to get
> >folks to agree
> >> >> >> > >to make it
> >> >> >> > >> a WG
> >> >> >> > >> >item.
> >> >> >> > >>
> >> >> >> > >> re-listen to the audio please
> >> >> >> > >>
> >> >> >> > >> Ted's concerns were consistent with most (all?) other
> >> >> >> concerns --
> >> >> >> > >> which were based on the premise of whether or not the
> >> >> >> UAC should be
> >> >> >> > >> trusted to initiate the marking on the INVITE.  The most
> >> >> >> > >> recent version has backed off this to a "can" -- meaning
> >> >> >> > >> not
> >> >> >prohibited
> >> >> >> > >> (i.e., no 2119 text).  I also backed off the text in the
> >> >> >> SP domain
> >> >> >> > >> part to "can", such that there is no 2119 text
> >> >> >mandating or even
> >> >> >> > >> recommending its usage there. I also do not prohibit its
> >> >> >> > >use, based on
> >> >> >> > >> local policy.  Keith has come forward with the specific
> >> >> >> > >> request that non-ESInet networks be allowed to
> >mark and pay
> >> >> >attention to
> >> >> >> > >> this priority indication -- with IMS as the specific
> >> >> >> > >> example he wishes to have this valid for.
> >> >> >> > >>
> >> >> >> > >> Where there is no disagreement, save for your recent
> >> >> >> > >pushback - is in
> >> >> >> > >> the ESInet, which is where Brian has requested it's
> >> >> >> > >definition in the
> >> >> >> > >> IETF on behalf of NENA.  He's the i3 WG chair within
> >> >> >> NENA, and if
> >> >> >> > >> he asks for it, are you going to say you know
> >better than he?
> >> >> >> > >>
> >> >> >> > >>
> >> >> >> > >> >Btw, I not disagreeing with the document as such. I
> >> >> >just want to
> >> >> >> > the
> >> >> >> > >> scope
> >> >> >> > >> >to change. The usage of RPH within the emergency
> >> >> >> services network
> >> >> >> > is
> >> >> >> > >> fine
> >> >> >> > >> >for me. I may get convinced to start the RPH marking from
> >> >> >> > >the the VSP
> >> >> >> > >> >towards the PSAP. I feel uneasy about the end host doing
> >> >> >> > >the marking.
> >> >> >> > >>
> >> >> >> > >> please read what I wrote above, and then re-read the
> >> >> >most recent
> >> >> >> > >> version of the ID. I don't have endpoints that SHOULD or
> >> >> >> MUST mark
> >> >> >> > >> anything wrt RPH.  I also don't want to prohibit it,
> >> >> >> because there
> >> >> >> > >> might be cases (that I don't know of) of valid uses
> >> >> >> under certain
> >> >> >> > >> circumstances.  Figure 1 is very clear that there are 3
> >> >> >> networking
> >> >> >> > >> parts to consider
> >> >> >> > >>
> >> >> >> > >> #1 - from the endpoint
> >> >> >> > >> #2 - within the VSP
> >> >> >> > >> #3 - within the ESInet
> >> >> >> > >>
> >> >> >> > >> the most recent ID version has "can" for #s 1 and 2, and
> >> >> >> > >2119 language
> >> >> >> > >> offering those supporting this specification will
> >have RPH
> >> >> >> > >> adherence within #3 (the ESInet).
> >> >> >> > >>
> >> >> >> > >> What other scope changes do you want, because I haven't
> >> >> >> heard them.
> >> >> >> > >>
> >> >> >> > >> I only heard you claim in email during the last
> >IETF and in
> >> >> >> > >the ECRIT
> >> >> >> > >> session that RPH should not be used for priority marking
> >> >> >> requests.
> >> >> >> > >> This is something Keith (SIP WG chair) voiced his
> >> >> >> > >> opposition to your views regarding creating a
> >second means
> >> >> >> > >> for SIP to
> >> >> >priority
> >> >> >> > >> mark request "when SIP already has one
> >interoperable way to
> >> >> >> > >> accomplish this... it's call the RP header mechanism".
> >> >> >> > >>
> >> >> >> > >> >I don't see advantages -- only disadvantages.
> >> >> >> > >> >
> >> >> >> > >> >Ciao
> >> >> >> > >> >Hannes
> >> >> >> > >>
> >> >> >> > >> _______________________________________________
> >> >> >> > >> Ecrit mailing list
> >> >> >> > >> [email-masked]
> >> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >> > >
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> Ecrit mailing list
> >> >> >> [email-masked]
> >> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >>
> >> >> >
> >> >
> >

Date: Fri, 06 Feb 2009 17:32:02 -0600
To: "Hannes Tschofenig" <[email-masked]>, "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] RPH

At 04:52 PM 2/6/2009, Hannes Tschofenig wrote:
>Hi Martin,
>
>I am arguing that if the UE does mark the call with the ECRIT RPH (I call it
>that way to differentiate it from RFC 4412 RPH usage, which is very
>different

this statement doesn't make any sense -- just when I thought we were 
close to a common understanding...

RFC 4412 defines a new header - Resource-Priority in SIP.

This header has an identified set of header-values.  With these 
values is a namespace, which dictate which type of usage is expected 
a particular namespace is used.

RFC 4412 allows other documents to create new RP header-values (i.e., 
new namespaces with associated priority-values).

Have I yet said anything that is inconsistent with usage within ECRIT?

I don't think so.

Along comes a new ID that defines a new RP namespaces in SIP for 
ECRIT, called "esnet".

This new namespace is needed because the 5 header-values defined in 
RFC 4412 do not match the usage for the ECRIT effort, therefore a new 
one needs to be created.

RFCV 4412 is not tied to GETS and MLPP, it is tied to the creation of 
the idea of "RESOURCE-PRIORITY" in SIP, *and* - it happens to create 
5 IANA registered namespaces (and associated priority-values).

Consider draft-ietf-ecrit-local-emergency-rph-namespace-00 to be an 
extension to RFC 4412, because there was no reason why the esnet 
namespace (and associated priority-values) could not have been 
included in 4412; none whatsoever.

The only reason why this -00 ID is not an UPDATE to RFC 4412 is that 
no new behavior is introduced. If there was, thenit would have to be 
listed as an UPDATE to 4412.  This means that is is not defining 
anything new about the behavior of the RP header, therefore what's in 
this new ID (other than the definition of the new namespace) is the 
SAME as that in 4412 -- therefore it is inappropriate to consider one 
to be 4412 centric and the other to be ECRIT centric.

May I recommend in the future we just refer to this -00 effort as the 
"esnet" RP namespace, please?

>) then it should be ignored.

This is basic SIP rules -- i.e., if a header is not understood, it is 
to be ignored.

>Processing it will not help in any way (as I described in my pseudo code
>snippet).

I can't believe this will be true in every network, so this should 
not be repeated.

Perhaps based on the networks you know about, it will be ignored.

>Incorrectly processing it (which is a possibility when the
>implementer does not understand the security implications -- they will not
>get it from the current version of the draft) will lead to security problems
>(fraud & DoS potential).

this can be said about a lot of different headers in SIP too... PAI 
is but one example. Identity is another.

>While you cannot prevent someone from sending you, there is certainly the
>chance to document what the receiver should do with it.

I believe that is a local policy decision -- i.e., it is a 
configuration issue -- which is not within the scope of the IETF.

I believe, based on Henning's answer to my last question to him, that 
the security considerations section ought to have text saying what an 
implementer ought to be concerned about when this esnet namespace is 
received from a UA.

As Martin said -- ultimately it's all about trust relationships -- 
and a domain might trust the endpoints within its domain to send the 
right RP namespace. It also might have a viable means to verify the 
namespace as well.  This is certainly true between SIP servers where 
the recipient knows the upstream entity is another server within the 
same network.

James

>Ciao
>Hannes
>
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]
> >On Behalf Of DOLLY, MARTIN C, ATTLABS
> >Sent: 07 February, 2009 00:15
> >To: [email-masked]; [email-masked];
> >[email-masked]
> >Cc: [email-masked]; [email-masked]
> >Subject: Re: [Ecrit] RPH
> >
> >You can not disallow this from an UE. The trust relationship
> >will dictate whether it is accepted or not
> >
> >----- Original Message -----
> >From: [email-masked] <[email-masked]>
> >To: Henning Schulzrinne <[email-masked]>; Winterbottom,
> >James <[email-masked]>
> >Cc: Tschofenig, Hannes (NSN - FI/Espoo)
> ><[email-masked]>; ECRIT <[email-masked]>
> >Sent: Fri Feb 06 17:10:08 2009
> >Subject: Re: [Ecrit] RPH
> >
> >At 03:05 PM 2/6/2009, Henning Schulzrinne wrote:
> >>There's another problem with the "it doesn't hurt argument".
> >Assume for
> >>a moment we have a "UA MAY include RPH" wording. There are now two
> >>cases:
> >>
> >>(1) All UAs implement it.
> >>
> >>(2) Only some UAs implement it.
> >>
> >>(1) seems unlikely for a MAY. If (2) occurs, we have the
> >choice between
> >>two undesirable outcomes:
> >>
> >>(a) some UAs that are otherwise compliant get worse service just
> >>because they didn't include the RPH;
> >
> >am I reading this correctly - that unless all UAs implement
> >this capability this should never be implemented by any UAs?
> >
> >This flies in the face of vendors solving for their customer's
> >requirements.
> >
> >I will admit that at this time, I know of no Cisco customers
> >that want this capability, so I'm not angling for any of our
> >revenue here.  I'm saying that I think I hear you saying this
> >ID should say something like
> >
> >         UAs are prevented from implementing the RP namespace esnet
> >
> >I'm fighting against that, because customers are always coming
> >to every vendor with new requirements, some of them unique at
> >the time.  This prevention text would prevent a vendor from
> >complying with this specification and still meet the customer's needs.
> >
> >I believe that this ID needs to retain the endpoints MAY
> >insert esnet, and have appropriate security considerations
> >text that highlights the concerns expressed here.
> >
> >Some future ID can then update this current RFC (to-be) within the
> >2119 rules of the use of MAY here.
> >
> >
> >>OR
> >>
> >>(b) the proxy has to look for the service URN to give the call the
> >>appropriate treatment, thus obviating any advantage of having the
> >>header, yet incurring more complicated processing logic.
> >>
> >>
> >>I have no objection to whatever markings people want to apply to calls
> >>within an ESN - that's largely a private matter.
> >>
> >>Henning
> >>
> >>On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote:
> >>
> >>>Hi All,
> >>>
> >>>I have followed thi thread with some interest and I struggling to
> >>>see a use case for the
> >>>providing RPH for emergency calls from the end-point.
> >>>
> >>>The reference-model call in ECRIT, for better or worse, is for all
> >>>calls to go back through a home-VSP.
> >>>We placed quite a lot of emphasis, largely for traffing reasons, for
> >>>the VSP to be able to verify that
> >>>a call is in fact an emergency call. This is done by the proxy
> >>>taking the inband location, doing a LoST
> >>>query with the provided URN, and verifying that the resulting
> >>>destination URI is the same as the destination
> >>>URI provide in the SIP INVITE. My understanding was that VSPs would
> >>>always do this check so they could
> >>>tell if they could bill for the call or not, and because the VSP can
> >>>be use that the call is an emergency call
> >>>it can apply any special priorities that may be applicable. This
> >>>obviates the need for RPH from the end-point
> >>>to the network.
> >>>
> >>>This leaves us with the argument of "it doesn't hurt to it", which
> >>>is not a good reason to write a specification.
> >>>It was intimated on the geopriv mailing list last year that great
> >>>pains had been taken to keep SIP with in the
> >>>MTU limits of UDP over Ethernet
> >>>(http://www.ietf.org/mail-archive/web/geopriv/current/msg0612
> >0.html ). Assuming
> >>>that this is the case, perhaps there is harm in including
> >>>information that we know will be ignored.
> >>>
> >>>Cheers
> >>>James
> >>>
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: [email-masked] on behalf of Hannes Tschofenig
> >>>Sent: Fri 2/6/2009 12:33 PM
> >>>To: 'Brian Rosen'; 'Henning Schulzrinne'
> >>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
> >>>Subject: Re: [Ecrit] RPH
> >>>
> >>>To the story short here is the code for the proxy:
> >>>
> >>>---------------------
> >>>
> >>>IF emergency call was recognized THEN
> >>>    execute emergency call specific procedures (priority queuing,
> >>>preemption, fetch location, determine routing, do funny QoS things &
> >>>co)
> >>>ELSE
> >>>    normal call handling procedures.
> >>>
> >>>---------------------
> >>>
> >>>If you can make this differentiation between an emergency call and a
> >>>regular
> >>>call then you can also do everything that is necessary for emergency
> >>>call
> >>>handling.
> >>>
> >>>Brian + Keith: Please tell me that we cannot do the above with our
> >>>currently
> >>>specified mechanisms.
> >>>
> >>>Ciao
> >>>Hannes
> >>>
> >>>>-----Original Message-----
> >>>>From: Brian Rosen [mailto:[email-masked]]
> >>>>Sent: 06 February, 2009 17:49
> >>>>To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
> >>>>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >>>>Subject: RE: [Ecrit] RPH
> >>>>
> >>>>I agree that not all networks will permit (or pay attention
> >>>>to) a priority request from an end device.
> >>>>
> >>>>No one has asked for that.
> >>>>
> >>>>The namespace request has several uses, one of which is within
> >>>>an emergency services IP network, one of which is between
> >>>>elements within a public network controlled by the operator,
> >>>>and one of which is an endpoint request for resource priority.
> >>>>
> >>>>Those of us requesting this work proceed are happy if the
> >>>>endpoint part is simply left as possible (MAY), and, speaking
> >>>>for myself, having the draft discuss the security implications
> >>>>of endpoint marking is reasonable.
> >>>>
> >>>>Having discussed this issue with an implementation team who
> >>>>worked on MLPP systems, I am confident I know what I'm talking
> >>>>about, but YMMV.  The fact that you could, if you wanted to,
> >>>>give resource priority to a call you decided, however you
> >>>>decided, was an emergency call is an implementation decision,
> >>>>and not subject to standardization.
> >>>>
> >>>>RPH is the IETF standard way for one entity to request
> >>>>resource priority of another entity in a SIP system.  We're
> >>>>asking for a namespace to use that within the domain of
> >>>>emergency calls.  That is, I think, a VERY reasonable request.
> >>>>
> >>>>Brian
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Henning Schulzrinne [mailto:[email-masked]]
> >>>>>Sent: Friday, February 06, 2009 10:33 AM
> >>>>>To: Hannes Tschofenig
> >>>>>Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
> >>>>>Subject: Re: [Ecrit] RPH
> >>>>>
> >>>>>To chime in here:
> >>>>>
> >>>>>I don't think it's productive to simply state that 4412
> >>>>doesn't worry
> >>>>>about authorization, so we shouldn't either (simplifying a bit).
> >>>>>Authorization was discussed repeatedly, and the general
> >>>>assumption was
> >>>>>that there were two conditions: Either the user invoking resource-
> >>>>>priority was well known and had a set of permissions that could be
> >>>>>checked in real time or there are ways to deal with abuse after the
> >>>>>fact in ways that deter abuse (the court-martial kind of thing in a
> >>>>>military context).
> >>>>>
> >>>>>The RFC 4412 security consideration (11.2) call this out in pretty
> >>>>>strong language:
> >>>>>
> >>>>>  Prioritized access to network and end-system resources imposes
> >>>>>    particularly stringent requirements on authentication and
> >>>>>    authorization mechanisms, since access to prioritized
> >>>>resources may
> >>>>>    impact overall system stability and performance and not
> >>>>just result
> >>>>>    in theft of, say, a single phone call.
> >>>>>Thus, the question is whether we have such strong authentication in
> >>>>>emergency calling. In some cases, such as residential fixed line
> >>>>>deployments where ISP = VSP, we're probably pretty close,
> >in others,
> >>>>>such as prepaid cell phones or hot spots or VSP-only providers, we
> >>>>>aren't.
> >>>>>
> >>>>>The other point that I think Hannes is making is that the
> >>>>information
> >>>>>is either redundant or dangerous. If a processing element
> >recognizes
> >>>>>the call as being an emergency call, it can apply whatever
> >treatment
> >>>>>it deems appropriate and doesn't need additional information. If it
> >>>>>doesn't or can't, using just the RPH can be rather dangerous unless
> >>>>>that element can be reasonably certain that there is strong
> >>>>>authentication and recourse.
> >>>>>
> >>>>>I don't buy the argument that somehow finding the RPH is
> >faster than
> >>>>>just looking for the identifier. Thus, given that the
> >information is
> >>>>>either redundant or dangerous, I fail to see the advantage.
> >>>>>
> >>>>>Henning
> >>>>>
> >>>>>
> >>>>>On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
> >>>>>
> >>>>>>Don't get hung up on the details. There are ways to optimize it.
> >>>>>>That was
> >>>>>>not the point of the code example.
> >>>>>>
> >>>>>>The problem that my pseudo code should have shown you is that you
> >>>>>>* don't gain anything with RPH marking for the emergency call case
> >>>>>>from the SIP UA towards the outbound proxy since the functionality
> >>>>>>is already provide otherwise. How often does the proxy need to get
> >>>>>>told that this is an emergency call todo whatever emergency call
> >>>>>>handling procedures are necessary?
> >>>>>>* you only introduce fraud problems (if you are not
> >>>>careful and you
> >>>>>>understand the security stuff well enough)
> >>>>>>
> >>>>>>If you can point me to people who implement the RPH emergency call
> >>>>>>case please do so. I would love to talk to them.
> >>>>>>
> >>>>>>Ciao
> >>>>>>Hannes
> >>>>>>
> >>>>>>PS: You need to parse incoming messages to some extend so that you
> >>>>>>know what it contains :-) Only looking for the emergency
> >>>>RPH header
> >>>>>>(and not for the Service URN/dial
> >>>>>>string) would exactly be the DoS/fraud attack I am worried about.
> >>>>>>That's the thing Henning was worried about (go and listen to the
> >>>>>>past meeting minutes).
> >>>>>>
> >>>>>>
> >>>>>>>Hannes
> >>>>>>>
> >>>>>>>You need to talk to people who really implement this kind
> >>>>of thing.
> >>>>>>>You are way off.
> >>>>>>>
> >>>>>>>When you implement a resource priority system, the point of doing
> >>>>>>>that is to look though the queue of work and pick out the
> >>>>ones with
> >>>>>>>priority, handling them first.  You don't do all the parsing, you
> >>>>>>>don't do a lot of decision tree.
> >>>>>>>
> >>>>>>>Typically:
> >>>>>>>Check for DoS things, like too big messages, etc Do a quick scan
> >>>>>>>for the RPH message header If found:
> >>>>>>>Parse the message
> >>>>>>>Determine validity
> >>>>>>>Determine priority
> >>>>>>>Queue on the correct work queue
> >>>>>>>
> >>>>>>>The first two actions have to be very fast.  Anyone who builds a
> >>>>>>>SIP thingie will tell you that parsing is one of the big cycle
> >>>>>>>consumers: if you have to parse every message BEFORE you
> >>>>determine
> >>>>>>>priority, you can't give much resource priority.
> >>>>>>>Once you get the whole message parsed, you might as well finish
> >>>>>>>working on it, because you've done so much of the work.
> >>>>>>>OTHOH, finding the end-of-message delimiter and doing a quick
> >>>>>>>string search for RPH is fast.  If you are doing
> >>>>priority, you need
> >>>>>>>to keep all the priority processing pretty uniform, and pretty
> >>>>>>>simple, or you tend to spend too much time futzing around
> >>>>figuring
> >>>>>>>out what to do.  You put all the priority related stuff together,
> >>>>>>>and use as much common code as possible.
> >>>>>>>
> >>>>>>>Brian
> >>>>>>>
> >>>>>>>>-----Original Message-----
> >>>>>>>>From: [email-masked] [mailto:[email-masked]]
> >>>>>>>On Behalf
> >>>>>>>>Of Hannes Tschofenig
> >>>>>>>>Sent: Friday, February 06, 2009 8:41 AM
> >>>>>>>>To: 'Hannes Tschofenig'; 'Janet P Gunn'
> >>>>>>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-
> >>>>>>>>[email-masked]
> >>>>>>>>Subject: [Ecrit] RPH
> >>>>>>>>
> >>>>>>>>Over lunch I was also thinking how an outbound proxy would
> >>>>>implement
> >>>>>>>>some of the emergency procedures. Here are some thoughts:
> >>>>>>>>
> >>>>>>>>---------------------------------------------------
> >>>>>>>>
> >>>>>>>>// Process incoming message
> >>>>>>>>Parse(msg);
> >>>>>>>>
> >>>>>>>>// SIP INVITE without Service URN
> >>>>>>>>// legacy devices
> >>>>>>>>If (recognize-dialstring(msg)==TRUE) {  // we got an emergency
> >>>>>>>>call going on  emergency=TRUE;  if (dialstring(msg) == 911)
> >>>>>>>>serviceURN=urn:service:sos; } else if
> >>>>>>>>(recognize-serviceURN(msg)==TRUE) {  // oh. A updated
> >>>>device that
> >>>>>>>>has a service URN attached to the
> >>>>>call
> >>>>>>>>serviceURN=retrieve_ServiceURN(msg);
> >>>>>>>>emergency=TRUE;
> >>>>>>>>} else {
> >>>>>>>>// standard SIP message
> >>>>>>>>// regular processing
> >>>>>>>>process(msg);
> >>>>>>>>emergency=FALSE;
> >>>>>>>>}
> >>>>>>>>
> >>>>>>>>If (emergency == TRUE) {
> >>>>>>>>  // make sure that the emergency call does not get
> >>>>dropped on the
> >>>>>>>>floor
> >>>>>>>>  // skip authorization failures
> >>>>>>>>  // give the call a special treatment
> >>>>>>>>  lots-of-code-here();
> >>>>>>>>
> >>>>>>>>  // trigger all the QoS signaling you have in the
> >>>>network to make
> >>>>>>>>James happy
> >>>>>>>>  trigger-qos();
> >>>>>>>>
> >>>>>>>>  // query location
> >>>>>>>>  location=retrieve-location();
> >>>>>>>>
> >>>>>>>>  // determine next hop
> >>>>>>>>  next-hop=lost(location, serviceURN)
> >>>>>>>>
> >>>>>>>>  // attach RPH marking to outgoing msg to make James and
> >>>>>>>Keith happy
> >>>>>>>>  msg=add(msg, RPH);
> >>>>>>>>
> >>>>>>>>  send(msg, next-hop);
> >>>>>>>>}
> >>>>>>>>
> >>>>>>>>If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
> >>>>>>>>  // all the emergency related processing done already upfront
> >>>>>>>>  // hence I log something.
> >>>>>>>>  log(RPH_WAS_PRESENT_JUHU);
> >>>>>>>>} else if ((rph-present(msg) == TRUE) && (emergency ==
> >>>>FALSE)) {
> >>>>>>>>// this is not an emergency call  // this is something
> >>>>like GETS
> >>>>>>>>result=special-authorization-procedure(user);
> >>>>>>>>
> >>>>>>>>if (result == AUTHORIZED) {
> >>>>>>>>   // do some priority & preemption thing here.
> >>>>>>>>   // trigger all the QoS you have
> >>>>>>>>   lots-of-code-here();
> >>>>>>>>} else {
> >>>>>>>>   log("NOT AUTHORIZED; don't DoS my network");  } } else {  //
> >>>>>>>>don't need todo any RPH processing  // this includes the case
> >>>>>>>>where the call was an emergency call but the RPH
> >>>>>>>>
> >>>>>>>>// marking was not there.
> >>>>>>>>nothing();
> >>>>>>>>}
> >>>>>>>>
> >>>>>>>>---------------------------------------------------
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>Ciao
> >>>>>>>>Hannes
> >>>>>>>>
> >>>>>>>>>-----Original Message-----
> >>>>>>>>>From: [email-masked] [mailto:[email-masked]] On
> >>>>>>>>>Behalf Of Hannes Tschofenig
> >>>>>>>>>Sent: 06 February, 2009 15:07
> >>>>>>>>>To: 'Janet P Gunn'
> >>>>>>>>>Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
> >>>>>>>>FI/Espoo)
> >>>>>>>>>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
> >Agenda (RPH)
> >>>>>>>>>
> >>>>>>>>>Who would define something that could prevent DoS problems?
> >>>>>>>>>
> >>>>>>>>>________________________________
> >>>>>>>>>
> >>>>>>>>>         From: Janet P Gunn [mailto:[email-masked]]
> >>>>>>>>>         Sent: 06 February, 2009 14:11
> >>>>>>>>>         To: Hannes Tschofenig
> >>>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >>>>>>>>>[email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
> >>>>>'James
> >>>>>>>>>M. Polk'
> >>>>>>>>>         Subject: Re: [Ecrit] ECRIT Virtual Interim
> >>>>Meeting: Agenda (RPH)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>         But there is nothing IN RFC4412 that specifically
> >>>>>>>addresses how to
> >>>>>>>>>prevent any particular namespace being used for DoS.
> >Anyone/any
> >>>>>UA
> >>>>>>>>>can ATTEMPT to invoke priority treatment by attaching RPH.  For
> >>>>>all
> >>>>>>>>>of the 4412 namespaces, as with the new proposed namespace, the
> >>>>>>>>>mechanisms for preventing DoS are not specified in the
> >>>>>>>document that
> >>>>>>>>>defines the namespace.
> >>>>>>>>>They are/will be specified elsewhere.
> >>>>>>>>>
> >>>>>>>>>         Janet
> >>>>>>>>>
> >>>>>>>>>         This is a PRIVATE message. If you are not the intended
> >>>>>>>recipient,
> >>>>>>>>>please delete without copying and kindly advise us by e-mail of
> >>>>>the
> >>>>>>>>>mistake in delivery.
> >>>>>>>>>         NOTE: Regardless of content, this e-mail shall not
> >>>>>>>operate to bind
> >>>>>>>>>CSC to any order or other contract unless pursuant to explicit
> >>>>>>>>>written agreement or government initiative expressly permitting
> >>>>>the
> >>>>>>>>>use of e-mail for such purpose.
> >>>>>>>>>
> >>>>>>>>>         [email-masked] wrote on 02/06/2009
> >04:21:51 AM:
> >>>>>>>>>
> >>>>>>>>>         > Hi James,
> >>>>>>>>>         >
> >>>>>>>>>         > I have read RFC 4412 and also the GETS/MLPP IETF
> >>>>>>>documents. What I
> >>>>>>>>>would
> >>>>>>>>>         > like to point out is that there is more than just a
> >>>>>>>header and
> >>>>>>>>>values within
> >>>>>>>>>         > the header that have to be considered in order to
> >>>>>>>make a judgement
> >>>>>>>>>of what
> >>>>>>>>>         > is appropriate and what isn't. There is an
> >>>>>>>architectural question
> >>>>>>>>>and
> >>>>>>>>>         > whether the environment we are using the stuff is
> >>>>>>>indeed providing
> >>>>>>>>>the
> >>>>>>>>>         > properties you need for the solution to be
> >>>>appropriate.
> >>>>>>>>>         >
> >>>>>>>>>         > Let me describe in more detail what I meant (and
> >>>>>>>please correct me
> >>>>>>>>>if I am
> >>>>>>>>>         > wrong).
> >>>>>>>>>         >
> >>>>>>>>>         > Getting priority for SIP requests when using a GETS
> >>>>>>>alike scenario
> >>>>>>>>>means
> >>>>>>>>>         > that the entity that issues the request is specially
> >>>>>>>authorized
> >>>>>>>>>since
> >>>>>>>>>         > otherwise you introduce a nice denial of
> >>>>service attack. This
> >>>>>>>>>authorization
> >>>>>>>>>         > is tied to the entity that makes the request. For
> >>>>>>>example, the
> >>>>>>>>>person is
> >>>>>>>>>         > working for the government and has special rights.
> >>>>>>>>>James Bond as a (not so)
> >>>>>>>>>         > secret agent might have these rights.
> >>>>>>>>>         >
> >>>>>>>>>         > The emergency services case
> >>>>(citizen-to-authority) is a bit
> >>>>>>>>>different as
> >>>>>>>>>         > there aren't really special rights with respect to
> >>>>>>>authorization
> >>>>>>>>>tied to
> >>>>>>>>>         > individuals. Instead, the fact that something is an
> >>>>>>>emergency is
> >>>>>>>>>purely a
> >>>>>>>>>         > judgement of the human that dials a special number.
> >>>>>>>>>To deal with fraud, we
> >>>>>>>>>         > discussed in the group on what we can actually do to
> >>>>>>>ensure that
> >>>>>>>>>end users
> >>>>>>>>>         > do not bypass security procedures (such as
> >>>>>>>authorization checks,
> >>>>>>>>>charging
> >>>>>>>>>         > and so on). Part of this investigation was
> >>>>the publication of
> >>>>>>>>>         > http://www.ietf.org/rfc/rfc5069.txt that also
> >>>>describes this
> >>>>>>>>>issue.
> >>>>>>>>>         >
> >>>>>>>>>         > So, imagine the implementation of a SIP
> >proxy (and we
> >>>>>>>implemented
> >>>>>>>>>that
> >>>>>>>>>         > stuff) that receives a call that contains a Service
> >>>>>>>URN. The code
> >>>>>>>>>branches
> >>>>>>>>>         > into a special mode where everything is done
> >>>>so that the call
> >>>>>>>>>receives
> >>>>>>>>>         > appropriate treatment and does not get
> >dropped on the
> >>>>>>>floor. The
> >>>>>>>>>way how the
> >>>>>>>>>         > Service URN is placed in the message
> >ensures that the
> >>>>>>>call cannot
> >>>>>>>>>go to my
> >>>>>>>>>         > friend (instead of the PSAP) unless the end host ran
> >>>>>>>LoST already.
> >>>>>>>>>In the
> >>>>>>>>>         > latter case, we discussed this also on the
> >list for a
> >>>>>>>while and
> >>>>>>>>>Richard even
> >>>>>>>>>         > wrote a draft about it in the context of the
> >>>>location hiding
> >>>>>>>>>topic, we said
> >>>>>>>>>         > that the proxy would have to run LoST if he
> >>>>cares about a
> >>>>>>>>>potential
> >>>>>>>>>         > fraudulent usage.
> >>>>>>>>>         >
> >>>>>>>>>         > So, what do we need todo in order to provide
> >>>>secure RFC 4412
> >>>>>>>>>functionality
> >>>>>>>>>         > in our context?
> >>>>>>>>>         >
> >>>>>>>>>         > Do you think that the current text in
> >>>>>>>>>         >
> >>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >>>>>>>>>gency-rph-nam
> >>>>>>>>>         > espace-00.txt reflects any of the
> >>>>above-described issues:
> >>>>>>>>>         > "
> >>>>>>>>>         >    The Security considerations that apply
> >to RFC 4412
> >>>>>>>>>[RFC4412]
> >>>>>>>>>apply
> >>>>>>>>>         >    here.  This document introduces no new security
> >>>>>>>>>issues relative
> >>>>>>>>>to
> >>>>>>>>>         >    RFC 4412.
> >>>>>>>>>         > "
> >>>>>>>>>         >
> >>>>>>>>>         > From various discussions in GEOPRIV I recall
> >>>>that you are
> >>>>>>>>>super-sensitive
> >>>>>>>>>         > regarding security and privacy. For some reasons you
> >>>>>>>don't seem to
> >>>>>>>>>have the
> >>>>>>>>>         > same concerns here. I would like to
> >>>>understand your reasoning.
> >>>>>>>>>         >
> >>>>>>>>>         > Please also do me another favor: Don't always say
> >>>>>>>that I don't
> >>>>>>>>>understand
> >>>>>>>>>         > the subject. Even if that would be the case it isn't
> >>>>>>>particular
> >>>>>>>>>fair given
> >>>>>>>>>         > that different folks had to educate you on other
> >>>>>>>topics in the
> >>>>>>>>>past as well.
> >>>>>>>>>         > Additionally, if you listen to the audio recordings
> >>>>>>>then you will
> >>>>>>>>>notice
> >>>>>>>>>         > that Henning, Ted, and Jon do not seem to understand
> >>>>>>>the issue
> >>>>>>>>>either as
> >>>>>>>>>         > they have raised similar issues during the
> >>>>F2F meetings.
> >>>>>>>>>         >
> >>>>>>>>>         > Ciao
> >>>>>>>>>         > Hannes
> >>>>>>>>>         >
> >>>>>>>>>         >
> >>>>>>>>>         > >Hannes - I believe it is you who do not understand
> >>>>>>>RFC 4412 --
> >>>>>>>>>         > >and many of us are trying to get that
> >>>>through to you, but you
> >>>>>>>>>         > >don't seem to want to listen/read.
> >>>>>>>>>         > >
> >>>>>>>>>         > >RFC 4412 is *for* priority marking SIP requests,
> >>>>>>>>>         > >
> >>>>>>>>>         > >One use is GETS.
> >>>>>>>>>         > >
> >>>>>>>>>         > >One use is MLPP.
> >>>>>>>>>         > >
> >>>>>>>>>         > >These examples are in RFC 4412 because there
> >>>>were specific
> >>>>>>>>>         > >namespaces being created for the IANA section of
> >>>>>>>that document.
> >>>>>>>>>         > >
> >>>>>>>>>         > >Reading the whole document, you will see
> >>>>that RPH can be
> >>>>>>>>>         > >specified for other uses than GETS or MLPP
> >>>>specifically.
> >>>>>>>>>         > >
> >>>>>>>>>         > >I knew when I wrote RFC 4412 that one day we
> >>>>would specify a
> >>>>>>>>>         > >namespace for ECRIT (the "esnet" namespace
> >>>>now) -- but I also
> >>>>>>>>>         > >knew it was premature for RFC 4412 to
> >>>>incorporate that
> >>>>>>>>>         > >namespace, that a future doc to RFC 4412
> >>>>would have to be
> >>>>>>>>>         > >written to do this. Brian and I talked about
> >>>>this at the
> >>>>>>>>>         > >original NENA meeting that created the IP WGs there
> >>>>>>>(in August
> >>>>>>>>>         > >of 03).  We both agreed we should wait until it was
> >>>>>>>>>         > >appropriate to the work in the IETF to
> >>>>submit this document
> >>>>>>>>>         > >that is now
> >>>>>>>>>         >
> >>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-l
> >ocal-emer
> >>>>>>>>>         > >gency-rph-namespace-00.txt
> >>>>>>>>>         > >
> >>>>>>>>>         > >Yet, you seem to want to use some additional
> >>>>mechanism to
> >>>>>>>>>         > >indicate priority of a call in SIP.  That
> >>>>means you want to
> >>>>>>>>>         > >introduce a second way to accomplish this in SIP.
> >>>>>>>>>Why do you
> >>>>>>>>>         > >want to promote a separate way to do something SIP
> >>>>>>>has already
> >>>>>>>>>         > >defined? That will cause interoperability
> >issues and
> >>>>>>>we both know
> >>>>>>>>>that.
> >>>>>>>>>         > >
> >>>>>>>>>         > >You've said to me (and others) that you
> >>>>believe RPH is just
> >>>>>>>>>         > >another way to accomplish what sos or a URI can
> >>>>>>>indicate - and
> >>>>>>>>>         > >you're wrong.  Your way would be
> >>>>_the_second_way_to_do_it,
> >>>>>>>>>         > >because SIP already considers RPH to be
> >>>>*the*way* to priority
> >>>>>>>>>         > >mark SIP requests.
> >>>>>>>>>         > >
> >>>>>>>>>         > >If you don't believe me (no comment), then
> >>>>why do you not
> >>>>>>>>>         > >believe the SIP WG chair (who knows more
> >>>>about SIP than both
> >>>>>>>>>         > >of us) - who, on this thread, has again said
> >>>>to you "RFC 4412
> >>>>>>>>>         > >(RPH) is the SIP mechanism to priority mark
> >>>>SIP requests"?
> >>>>>>>>>         > >
> >>>>>>>>>         > >Further, I believe it is inappropriate to
> >>>>prohibit endpoints
> >>>>>>>>>         > >from being able to set the esnet namespace.
> >>>>I absolutely
> >>>>>>>>>         > >believe it will not be needed most of the
> >>>>time, but I believe
> >>>>>>>>>         > >if someone does find a valid use for
> >>>>endpoints to mark
> >>>>>>>>>         > >priority in SIP, this ID - once it has
> >>>>become an RFC -- will
> >>>>>>>>>         > >have to be obsoleted with a new RFC saying
> >the exact
> >>>>>>>opposite.
> >>>>>>>>>         > >
> >>>>>>>>>         > >(color me confused ... over and over again)
> >>>>>>>>>         > >
> >>>>>>>>>         > >James
> >>>>>>>>>         > >
> >>>>>>>>>         > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >>>>>>>>>         > >>Keith, please understand that the usage
> >of RFC 4412
> >>>>>>>for GETS and
> >>>>>>>>>for
> >>>>>>>>>         > >>the type of emergency call we discuss here is
> >>>>>>>different. Just
> >>>>>>>>>looking
> >>>>>>>>>         > >>at the header and the name of the
> >namespace is a bit
> >>>>>>>>>         > >artificial. I hope
> >>>>>>>>>         > >>you understand that.
> >>>>>>>>>         > >>
> >>>>>>>>>         > >> >-----Original Message-----
> >>>>>>>>>         > >> >From: DRAGE, Keith (Keith)
> >>>>>>>>>[mailto:[email-masked]]
> >>>>>>>>>         > >> >Sent: 05 February, 2009 14:55
> >>>>>>>>>         > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
> >>>>>>>>>Polk'; 'Tschofenig,
> >>>>>>>>>         > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >>>>>>>>>         > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
> >>>>>>>>>Meeting: Agenda (my
> >>>>>>>>>
> >>>>>>>>>         > >> >mistake)
> >>>>>>>>>         > >> >
> >>>>>>>>>         > >> >Which is exactly what RFC 4412 specifies for all
> >>>>>>>namespaces.
> >>>>>>>>>         > >> >
> >>>>>>>>>         > >> >regards
> >>>>>>>>>         > >> >
> >>>>>>>>>         > >> >Keith
> >>>>>>>>>         > >> >
> >>>>>>>>>         > >> >> -----Original Message-----
> >>>>>>>>>         > >> >> From: [email-masked]
> >>>>>>>[mailto:[email-masked]]
> >>>>>>>>>         > >> >On Behalf
> >>>>>>>>>         > >> >> Of Brian Rosen
> >>>>>>>>>         > >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >>>>>>>>>         > >> >> To: 'Hannes Tschofenig'; 'James M.
> >>>>Polk'; 'Tschofenig,
> >>>>>>>>>         > >Hannes (NSN
> >>>>>>>>>         > >> >> - FI/Espoo)'; 'ECRIT'
> >>>>>>>>>         > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >>>>>>>>>Meeting: Agenda (my
> >>>>>>>>>         > >> >> mistake)
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >> The value is that in some networks
> >>>>where priority for
> >>>>>>>>>         > >> >emergency calls
> >>>>>>>>>         > >> >> is appropriate, and appropriate
> >>>>policing of marking is
> >>>>>>>>>         > >implemented,
> >>>>>>>>>         > >> >> emergency calls will receive resource
> >priority.
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >> Not all networks would need policing.  Some
> >>>>>>>will.  Policing
> >>>>>>>>>could
> >>>>>>>>>         > >> >> be to Route header/R-URI content, but other
> >>>>>>>criteria are
> >>>>>>>>>possible.
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >> Not all networks will need resource priority
> >>>>>>>for emergency
> >>>>>>>>>calls.
> >>>>>>>>>         > >> >> Fine, ignore this marking/namespace.
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >> Brian
> >>>>>>>>>         > >> >> > -----Original Message-----
> >>>>>>>>>         > >> >> > From: Hannes Tschofenig
> >>>>>>>>>[mailto:[email-masked]]
> >>>>>>>>>         > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >>>>>>>>>         > >> >> > To: 'Brian Rosen'; 'James M. Polk';
> >>>>>>>Tschofenig, Hannes
> >>>>>>>>>(NSN -
> >>>>>>>>>         > >> >> > FI/Espoo); 'ECRIT'
> >>>>>>>>>         > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
> >>>>>>>>>Meeting: Agenda (my
> >>>>>>>>>         > >> >> > mistake)
> >>>>>>>>>         > >> >> >
> >>>>>>>>>         > >> >> > I don't even see the value in permitting the
> >>>>>>>endpoint todo
> >>>>>>>>>the
> >>>>>>>>>         > >> >> > RPH marking.
> >>>>>>>>>         > >> >> > In addition to the security concerns
> >>>>there is also the
> >>>>>>>>>         > >> >problem that
> >>>>>>>>>         > >> >> > there are more options to implement without
> >>>>>>>an additional
> >>>>>>>>>value.
> >>>>>>>>>         > >> >> >
> >>>>>>>>>         > >> >> > >-----Original Message-----
> >>>>>>>>>         > >> >> > >From: Brian Rosen
> >[mailto:[email-masked]]
> >>>>>>>>>         > >> >> > >Sent: 05 February, 2009 00:03
> >>>>>>>>>         > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
> >>>>>>>'Tschofenig,
> >>>>>>>>>         > >> >> Hannes (NSN -
> >>>>>>>>>         > >> >> > >FI/Espoo)'; 'ECRIT'
> >>>>>>>>>         > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual
> >>>>Interim Meeting:
> >>>>>>>>>Agenda (my
> >>>>>>>>>         > >> >> > mistake)
> >>>>>>>>>         > >> >> > >
> >>>>>>>>>         > >> >> > >Hannes
> >>>>>>>>>         > >> >> > >
> >>>>>>>>>         > >> >> > >This matches my understanding
> >>>>precisely.  We wish to
> >>>>>>>>>         > >> >> permit endpoints
> >>>>>>>>>         > >> >> > >to mark. We do not require it, and
> >>>>don't necessarily
> >>>>>>>>>expect it
> >>>>>>>>>         > >> >> > >in many (even
> >>>>>>>>>         > >> >> > >most) cases.  We don't wish to see the
> >>>>>>>document prohibit
> >>>>>>>>>it.
> >>>>>>>>>         > >> >> > >We all seem to agree it has value
> >within the
> >>>>>>>Emergency
> >>>>>>>>>         > >> >Services IP
> >>>>>>>>>         > >> >> > >Networks.
> >>>>>>>>>         > >> >> > >
> >>>>>>>>>         > >> >> > >Brian
> >>>>>>>>>         > >> >> > >
> >>>>>>>>>         > >> >> > >> -----Original Message-----
> >>>>>>>>>         > >> >> > >> From: [email-masked]
> >>>>>>>>>[mailto:[email-masked]]
> >>>>>>>>>         > >> >> > >On Behalf
> >>>>>>>>>         > >> >> > >> Of James M. Polk
> >>>>>>>>>         > >> >> > >> Sent: Wednesday, February 04,
> >2009 4:01 PM
> >>>>>>>>>         > >> >> > >> To: Hannes Tschofenig; Tschofenig,
> >>>>Hannes (NSN -
> >>>>>>>>>         > >> >> FI/Espoo); 'ECRIT'
> >>>>>>>>>         > >> >> > >> Subject: Re: [Ecrit] ECRIT
> >Virtual Interim
> >>>>>>>>>Meeting:
> >>>>>>>>>         > >Agenda (my
> >>>>>>>>>         > >> >> > >> mistake)
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> At 02:37 PM 2/4/2009, Hannes
> >>>>Tschofenig wrote:
> >>>>>>>>>         > >> >> > >> > > James wrote:
> >>>>>>>>>         > >> >> > >> > >> you are the _lone_ voice not
> >>>>>>>supporting this ID,
> >>>>>>>>>         > >> >> > >> >
> >>>>>>>>>         > >> >> > >> >Listening to the audio recording of past
> >>>>>>>meetings I
> >>>>>>>>>have to
> >>>>>>>>>         > >> >> > >say that
> >>>>>>>>>         > >> >> > >> >I
> >>>>>>>>>         > >> >> > >> was
> >>>>>>>>>         > >> >> > >> >not the only persons raising
> >>>>concerns about the
> >>>>>>>>>document.
> >>>>>>>>>         > >> >> > >> >That was probably the reason why you
> >>>>>>>agreed to limit
> >>>>>>>>>the
> >>>>>>>>>         > >> >> > >scope of the
> >>>>>>>>>         > >> >> > >> >document (which you didn't later do) to
> >>>>>>>get folks to
> >>>>>>>>>agree
> >>>>>>>>>         > >> >> > >to make it
> >>>>>>>>>         > >> >> > >> a WG
> >>>>>>>>>         > >> >> > >> >item.
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> re-listen to the audio please
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> Ted's concerns were consistent with most
> >>>>>>>>>(all?) other
> >>>>>>>>>         > >> >> concerns --
> >>>>>>>>>         > >> >> > >> which were based on the premise
> >of whether
> >>>>>>>or not the
> >>>>>>>>>         > >> >> UAC should be
> >>>>>>>>>         > >> >> > >> trusted to initiate the marking on the
> >>>>>>>INVITE.  The
> >>>>>>>>>most
> >>>>>>>>>         > >> >> > >> recent version has backed off this
> >>>>to a "can" --
> >>>>>>>>>meaning not
> >>>>>>>>>         > >> >prohibited
> >>>>>>>>>         > >> >> > >> (i.e., no 2119 text).  I also backed off
> >>>>>>>the text in
> >>>>>>>>>the
> >>>>>>>>>         > >> >> SP domain
> >>>>>>>>>         > >> >> > >> part to "can", such that there is
> >>>>no 2119 text
> >>>>>>>>>         > >> >mandating or even
> >>>>>>>>>         > >> >> > >> recommending its usage there. I also do
> >>>>>>>not prohibit
> >>>>>>>>>its
> >>>>>>>>>         > >> >> > >use, based on
> >>>>>>>>>         > >> >> > >> local policy.  Keith has come
> >forward with
> >>>>>>>the specific
> >>>>>>>>>
> >>>>>>>>>         > >> >> > >> request that non-ESInet networks be
> >>>>>>>allowed to mark and
> >>>>>>>>>pay
> >>>>>>>>>         > >> >attention to
> >>>>>>>>>         > >> >> > >> this priority indication -- with IMS as
> >>>>>>>the specific
> >>>>>>>>>example
> >>>>>>>>>         > >> >> > >> he wishes to have this valid for.
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> Where there is no disagreement, save for
> >>>>>>>your recent
> >>>>>>>>>         > >> >> > >pushback - is in
> >>>>>>>>>         > >> >> > >> the ESInet, which is where Brian
> >>>>has requested it's
> >>>>>>>>>         > >> >> > >definition in the
> >>>>>>>>>         > >> >> > >> IETF on behalf of NENA.  He's the i3 WG
> >>>>>>>chair within
> >>>>>>>>>         > >> >> NENA, and if
> >>>>>>>>>         > >> >> > >> he asks for it, are you going to say you
> >>>>>>>know better
> >>>>>>>>>than he?
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> >Btw, I not disagreeing with the document
> >>>>>>>as such. I
> >>>>>>>>>         > >> >just want to
> >>>>>>>>>         > >> >> > the
> >>>>>>>>>         > >> >> > >> scope
> >>>>>>>>>         > >> >> > >> >to change. The usage of RPH
> >>>>within the emergency
> >>>>>>>>>         > >> >> services network
> >>>>>>>>>         > >> >> > is
> >>>>>>>>>         > >> >> > >> fine
> >>>>>>>>>         > >> >> > >> >for me. I may get convinced to start the
> >>>>>>>RPH marking
> >>>>>>>>>from
> >>>>>>>>>         > >> >> > >the the VSP
> >>>>>>>>>         > >> >> > >> >towards the PSAP. I feel uneasy
> >about the
> >>>>>>>end host
> >>>>>>>>>doing
> >>>>>>>>>         > >> >> > >the marking.
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> please read what I wrote above, and then
> >>>>>>>re-read the
> >>>>>>>>>         > >> >most recent
> >>>>>>>>>         > >> >> > >> version of the ID. I don't have endpoints
> >>>>>>>that SHOULD
> >>>>>>>>>or
> >>>>>>>>>         > >> >> MUST mark
> >>>>>>>>>         > >> >> > >> anything wrt RPH.  I also don't want to
> >>>>>>>prohibit it,
> >>>>>>>>>         > >> >> because there
> >>>>>>>>>         > >> >> > >> might be cases (that I don't know
> >>>>of) of valid uses
> >>>>>>>>>         > >> >> under certain
> >>>>>>>>>         > >> >> > >> circumstances.  Figure 1 is very clear
> >>>>>>>that there are 3
> >>>>>>>>>         > >> >> networking
> >>>>>>>>>         > >> >> > >> parts to consider
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> #1 - from the endpoint
> >>>>>>>>>         > >> >> > >> #2 - within the VSP
> >>>>>>>>>         > >> >> > >> #3 - within the ESInet
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> the most recent ID version has "can" for
> >>>>>>>#s 1 and 2,
> >>>>>>>>>and
> >>>>>>>>>         > >> >> > >2119 language
> >>>>>>>>>         > >> >> > >> offering those supporting this
> >>>>>>>specification will have
> >>>>>>>>>RPH
> >>>>>>>>>         > >> >> > >> adherence within #3 (the ESInet).
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> What other scope changes do you want,
> >>>>>>>because I haven't
> >>>>>>>>>         > >> >> heard them.
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> I only heard you claim in email
> >during the
> >>>>>>>last IETF
> >>>>>>>>>and in
> >>>>>>>>>         > >> >> > >the ECRIT
> >>>>>>>>>         > >> >> > >> session that RPH should not be
> >>>>used for priority
> >>>>>>>>>marking
> >>>>>>>>>         > >> >> requests.
> >>>>>>>>>         > >> >> > >> This is something Keith (SIP WG
> >>>>chair) voiced his
> >>>>>>>>>opposition
> >>>>>>>>>         > >> >> > >> to your views regarding creating a second
> >>>>>>>means for SIP
> >>>>>>>>>to
> >>>>>>>>>         > >> >priority
> >>>>>>>>>         > >> >> > >> mark request "when SIP already has one
> >>>>>>>interoperable
> >>>>>>>>>way to
> >>>>>>>>>         > >> >> > >> accomplish this... it's call the
> >RP header
> >>>>>>>mechanism".
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> >I don't see advantages -- only
> >>>>disadvantages.
> >>>>>>>>>         > >> >> > >> >
> >>>>>>>>>         > >> >> > >> >Ciao
> >>>>>>>>>         > >> >> > >> >Hannes
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >>
> >>>>_______________________________________________
> >>>>>>>>>         > >> >> > >> Ecrit mailing list
> >>>>>>>>>         > >> >> > >> [email-masked]
> >>>>>>>>>         > >> >> > >>
> >https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>>         > >> >> > >
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >>
> >_______________________________________________
> >>>>>>>>>         > >> >> Ecrit mailing list
> >>>>>>>>>         > >> >> [email-masked]
> >>>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >
> >>>>>>>>>         > >
> >>>>>>>>>         >
> >>>>>>>>>         > _______________________________________________
> >>>>>>>>>         > Ecrit mailing list
> >>>>>>>>>         > [email-masked]
> >>>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>_______________________________________________
> >>>>>>>>>Ecrit mailing list
> >>>>>>>>>[email-masked]
> >>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>
> >>>>>>>>_______________________________________________
> >>>>>>>>Ecrit mailing list
> >>>>>>>>[email-masked]
> >>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>
> >>>>>>_______________________________________________
> >>>>>>Ecrit mailing list
> >>>>>>[email-masked]
> >>>>>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>
> >>>_______________________________________________
> >>>Ecrit mailing list
> >>>[email-masked]
> >>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>
> >>>
> >>>-------------------------------------------------------------
> >-----------------------------------
> >>>This message is for the designated recipient only and may
> >>>contain privileged, proprietary, or otherwise private information.
> >>>If you have received it in error, please notify the sender
> >>>immediately and delete the original.  Any unauthorized use of
> >>>this email is prohibited.
> >>>-------------------------------------------------------------
> >-----------------------------------
> >>>[mf2]
> >>>
> >>
> >>_______________________________________________
> >>Ecrit mailing list
> >>[email-masked]
> >>https://www.ietf.org/mailman/listinfo/ecrit
> >
> >_______________________________________________
> >Ecrit mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/ecrit
> >_______________________________________________
> >Ecrit mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/ecrit
> >

Content-class: urn:content-classes:message
Date: Fri, 6 Feb 2009 18:39:00 -0500
From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Ecrit] RPH

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: "Winterbottom, James" <[email-masked]>, Hannes Tschofenig <[email-masked]>, Brian Rosen <[email-masked]>, Henning Schulzrinne <[email-masked]>
Date: Sat, 7 Feb 2009 01:14:48 +0100
Accept-Language: en-US
acceptlanguage: en-US
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

It is a valid header for that usage. It carries exactly the semantics the u=
ser wishes to convey, i.e. that the requestor would like the call to be tre=
ated in processing by the network in a manner appropriate to emergency call=
s.

Yes the edge proxy may well review and make up its own mind, and either rem=
ove, verify or pass on the header, but that does not mean it is wrong from =
the UE.

You might just as well argue that the UE should not inserted a P-Preferred-=
ID if it knows that the value it contains will be the one inserted by the e=
dge proxy.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Winterbottom, James
> Sent: Friday, February 06, 2009 8:02 PM
> To: Hannes Tschofenig; Brian Rosen; Henning Schulzrinne
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
> Subject: Re: [Ecrit] RPH
>
> Hi All,
>
> I have followed thi thread with some interest and I
> struggling to see a use case for the providing RPH for
> emergency calls from the end-point.
>
> The reference-model call in ECRIT, for better or worse, is
> for all calls to go back through a home-VSP.
> We placed quite a lot of emphasis, largely for traffing
> reasons, for the VSP to be able to verify that a call is in
> fact an emergency call. This is done by the proxy taking the
> inband location, doing a LoST query with the provided URN,
> and verifying that the resulting destination URI is the same
> as the destination URI provide in the SIP INVITE. My
> understanding was that VSPs would always do this check so
> they could tell if they could bill for the call or not, and
> because the VSP can be use that the call is an emergency call
> it can apply any special priorities that may be applicable.
> This obviates the need for RPH from the end-point to the network.
>
> This leaves us with the argument of "it doesn't hurt to it",
> which is not a good reason to write a specification.
> It was intimated on the geopriv mailing list last year that
> great pains had been taken to keep SIP with in the MTU limits
> of UDP over Ethernet
> (http://www.ietf.org/mail-archive/web/geopriv/current/msg06120
> .html). Assuming that this is the case, perhaps there is harm
> in including information that we know will be ignored.
>
> Cheers
> James
>
>
>
> -----Original Message-----
> From: [email-masked] on behalf of Hannes Tschofenig
> Sent: Fri 2/6/2009 12:33 PM
> To: 'Brian Rosen'; 'Henning Schulzrinne'
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
> Subject: Re: [Ecrit] RPH
>
> To the story short here is the code for the proxy:
>
> ---------------------
>
> IF emergency call was recognized THEN
>     execute emergency call specific procedures (priority
> queuing, preemption, fetch location, determine routing, do
> funny QoS things & co) ELSE
>     normal call handling procedures.
>
> ---------------------
>
> If you can make this differentiation between an emergency
> call and a regular call then you can also do everything that
> is necessary for emergency call handling.
>
> Brian + Keith: Please tell me that we cannot do the above
> with our currently specified mechanisms.
>
> Ciao
> Hannes
>
> >-----Original Message-----
> >From: Brian Rosen [mailto:[email-masked]]
> >Sent: 06 February, 2009 17:49
> >To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
> >Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >Subject: RE: [Ecrit] RPH
> >
> >I agree that not all networks will permit (or pay attention
> >to) a priority request from an end device.
> >
> >No one has asked for that.
> >
> >The namespace request has several uses, one of which is within an
> >emergency services IP network, one of which is between
> elements within
> >a public network controlled by the operator, and one of which is an
> >endpoint request for resource priority.
> >
> >Those of us requesting this work proceed are happy if the
> endpoint part
> >is simply left as possible (MAY), and, speaking for myself,
> having the
> >draft discuss the security implications of endpoint marking is
> >reasonable.
> >
> >Having discussed this issue with an implementation team who
> worked on
> >MLPP systems, I am confident I know what I'm talking about,
> but YMMV.
> >The fact that you could, if you wanted to, give resource
> priority to a
> >call you decided, however you decided, was an emergency call is an
> >implementation decision, and not subject to standardization.
> >
> >RPH is the IETF standard way for one entity to request resource
> >priority of another entity in a SIP system.  We're asking for a
> >namespace to use that within the domain of emergency calls.
> That is, I
> >think, a VERY reasonable request.
> >
> >Brian
> >
> >> -----Original Message-----
> >> From: Henning Schulzrinne [mailto:[email-masked]]
> >> Sent: Friday, February 06, 2009 10:33 AM
> >> To: Hannes Tschofenig
> >> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
> >> Subject: Re: [Ecrit] RPH
> >>
> >> To chime in here:
> >>
> >> I don't think it's productive to simply state that 4412
> >doesn't worry
> >> about authorization, so we shouldn't either (simplifying a bit).
> >> Authorization was discussed repeatedly, and the general
> >assumption was
> >> that there were two conditions: Either the user invoking resource-
> >> priority was well known and had a set of permissions that could be
> >> checked in real time or there are ways to deal with abuse
> after the
> >> fact in ways that deter abuse (the court-martial kind of
> thing in a
> >> military context).
> >>
> >> The RFC 4412 security consideration (11.2) call this out in pretty
> >> strong language:
> >>
> >>   Prioritized access to network and end-system resources imposes
> >>     particularly stringent requirements on authentication and
> >>     authorization mechanisms, since access to prioritized
> >resources may
> >>     impact overall system stability and performance and not
> >just result
> >>     in theft of, say, a single phone call.
> >> Thus, the question is whether we have such strong
> authentication in
> >> emergency calling. In some cases, such as residential fixed line
> >> deployments where ISP =3D VSP, we're probably pretty close,
> in others,
> >> such as prepaid cell phones or hot spots or VSP-only providers, we
> >> aren't.
> >>
> >> The other point that I think Hannes is making is that the
> >information
> >> is either redundant or dangerous. If a processing element
> recognizes
> >> the call as being an emergency call, it can apply whatever
> treatment
> >> it deems appropriate and doesn't need additional
> information. If it
> >> doesn't or can't, using just the RPH can be rather
> dangerous unless
> >> that element can be reasonably certain that there is strong
> >> authentication and recourse.
> >>
> >> I don't buy the argument that somehow finding the RPH is
> faster than
> >> just looking for the identifier. Thus, given that the
> information is
> >> either redundant or dangerous, I fail to see the advantage.
> >>
> >> Henning
> >>
> >>
> >> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
> >>
> >> > Don't get hung up on the details. There are ways to optimize it.
> >> > That was
> >> > not the point of the code example.
> >> >
> >> > The problem that my pseudo code should have shown you is that you
> >> > * don't gain anything with RPH marking for the emergency
> call case
> >> > from the SIP UA towards the outbound proxy since the
> functionality
> >> > is already provide otherwise. How often does the proxy
> need to get
> >> > told that this is an emergency call todo whatever emergency call
> >> > handling procedures are necessary?
> >> > * you only introduce fraud problems (if you are not
> >careful and you
> >> > understand the security stuff well enough)
> >> >
> >> > If you can point me to people who implement the RPH
> emergency call
> >> > case please do so. I would love to talk to them.
> >> >
> >> > Ciao
> >> > Hannes
> >> >
> >> > PS: You need to parse incoming messages to some extend
> so that you
> >> > know what it contains :-) Only looking for the emergency
> >RPH header
> >> > (and not for the Service URN/dial
> >> > string) would exactly be the DoS/fraud attack I am worried about.
> >> > That's the thing Henning was worried about (go and listen to the
> >> > past meeting minutes).
> >> >
> >> >
> >> >> Hannes
> >> >>
> >> >> You need to talk to people who really implement this kind
> >of thing.
> >> >> You are way off.
> >> >>
> >> >> When you implement a resource priority system, the
> point of doing
> >> >> that is to look though the queue of work and pick out the
> >ones with
> >> >> priority, handling them first.  You don't do all the
> parsing, you
> >> >> don't do a lot of decision tree.
> >> >>
> >> >> Typically:
> >> >> Check for DoS things, like too big messages, etc Do a
> quick scan
> >> >> for the RPH message header If found:
> >> >> Parse the message
> >> >> Determine validity
> >> >> Determine priority
> >> >> Queue on the correct work queue
> >> >>
> >> >> The first two actions have to be very fast.  Anyone who
> builds a
> >> >> SIP thingie will tell you that parsing is one of the big cycle
> >> >> consumers: if you have to parse every message BEFORE you
> >determine
> >> >> priority, you can't give much resource priority.
> >> >> Once you get the whole message parsed, you might as well finish
> >> >> working on it, because you've done so much of the work.
> >> >> OTHOH, finding the end-of-message delimiter and doing a quick
> >> >> string search for RPH is fast.  If you are doing
> >priority, you need
> >> >> to keep all the priority processing pretty uniform, and pretty
> >> >> simple, or you tend to spend too much time futzing around
> >figuring
> >> >> out what to do.  You put all the priority related stuff
> together,
> >> >> and use as much common code as possible.
> >> >>
> >> >> Brian
> >> >>
> >> >>> -----Original Message-----
> >> >>> From: [email-masked] [mailto:[email-masked]]
> >> >> On Behalf
> >> >>> Of Hannes Tschofenig
> >> >>> Sent: Friday, February 06, 2009 8:41 AM
> >> >>> To: 'Hannes Tschofenig'; 'Janet P Gunn'
> >> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-
> >> >>> [email-masked]
> >> >>> Subject: [Ecrit] RPH
> >> >>>
> >> >>> Over lunch I was also thinking how an outbound proxy would
> >> implement
> >> >>> some of the emergency procedures. Here are some thoughts:
> >> >>>
> >> >>> ---------------------------------------------------
> >> >>>
> >> >>> // Process incoming message
> >> >>> Parse(msg);
> >> >>>
> >> >>> // SIP INVITE without Service URN // legacy devices If
> >> >>> (recognize-dialstring(msg)=3D=3DTRUE) {  // we got an
> emergency call
> >> >>> going on  emergency=3DTRUE;  if (dialstring(msg) =3D=3D 911)
> >> >>> serviceURN=3Durn:service:sos; } else if
> >> >>> (recognize-serviceURN(msg)=3D=3DTRUE) {  // oh. A updated
> >device that
> >> >>> has a service URN attached to the
> >> call
> >> >>>  serviceURN=3Dretrieve_ServiceURN(msg);
> >> >>>  emergency=3DTRUE;
> >> >>> } else {
> >> >>>  // standard SIP message
> >> >>>  // regular processing
> >> >>>  process(msg);
> >> >>>  emergency=3DFALSE;
> >> >>> }
> >> >>>
> >> >>> If (emergency =3D=3D TRUE) {
> >> >>>   // make sure that the emergency call does not get
> >dropped on the
> >> >>> floor
> >> >>>   // skip authorization failures
> >> >>>   // give the call a special treatment
> >> >>>   lots-of-code-here();
> >> >>>
> >> >>>   // trigger all the QoS signaling you have in the
> >network to make
> >> >>> James happy
> >> >>>   trigger-qos();
> >> >>>
> >> >>>   // query location
> >> >>>   location=3Dretrieve-location();
> >> >>>
> >> >>>   // determine next hop
> >> >>>   next-hop=3Dlost(location, serviceURN)
> >> >>>
> >> >>>   // attach RPH marking to outgoing msg to make James and
> >> >> Keith happy
> >> >>>   msg=3Dadd(msg, RPH);
> >> >>>
> >> >>>   send(msg, next-hop);
> >> >>> }
> >> >>>
> >> >>> If ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D TRUE)) {
> >> >>>   // all the emergency related processing done already upfront
> >> >>>   // hence I log something.
> >> >>>   log(RPH_WAS_PRESENT_JUHU);
> >> >>> } else if ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D
> >FALSE)) {
> >> >>> // this is not an emergency call  // this is something
> >like GETS
> >> >>> result=3Dspecial-authorization-procedure(user);
> >> >>>
> >> >>>  if (result =3D=3D AUTHORIZED) {
> >> >>>    // do some priority & preemption thing here.
> >> >>>    // trigger all the QoS you have
> >> >>>    lots-of-code-here();
> >> >>>  } else {
> >> >>>    log("NOT AUTHORIZED; don't DoS my network");  } }
> else {  //
> >> >>> don't need todo any RPH processing  // this includes the case
> >> >>> where the call was an emergency call but the RPH
> >> >>>
> >> >>>  // marking was not there.
> >> >>>  nothing();
> >> >>> }
> >> >>>
> >> >>> ---------------------------------------------------
> >> >>>
> >> >>>
> >> >>> Ciao
> >> >>> Hannes
> >> >>>
> >> >>>> -----Original Message-----
> >> >>>> From: [email-masked]
> [mailto:[email-masked]] On
> >> >>>> Behalf Of Hannes Tschofenig
> >> >>>> Sent: 06 February, 2009 15:07
> >> >>>> To: 'Janet P Gunn'
> >> >>>> Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
> >> >>> FI/Espoo)
> >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
> Agenda (RPH)
> >> >>>>
> >> >>>> Who would define something that could prevent DoS problems?
> >> >>>>
> >> >>>> ________________________________
> >> >>>>
> >> >>>>       From: Janet P Gunn [mailto:[email-masked]]
> >> >>>>       Sent: 06 February, 2009 14:11
> >> >>>>       To: Hannes Tschofenig
> >> >>>>       Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >> >>>> [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
> >> 'James
> >> >>>> M. Polk'
> >> >>>>       Subject: Re: [Ecrit] ECRIT Virtual Interim
> >Meeting: Agenda (RPH)
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>       But there is nothing IN RFC4412 that specifically
> >> >> addresses how to
> >> >>>> prevent any particular namespace being used for DoS.
> Anyone/any
> >> UA
> >> >>>> can ATTEMPT to invoke priority treatment by attaching
> RPH.  For
> >> all
> >> >>>> of the 4412 namespaces, as with the new proposed
> namespace, the
> >> >>>> mechanisms for preventing DoS are not specified in the
> >> >> document that
> >> >>>> defines the namespace.
> >> >>>> They are/will be specified elsewhere.
> >> >>>>
> >> >>>>       Janet
> >> >>>>
> >> >>>>       This is a PRIVATE message. If you are not the intended
> >> >> recipient,
> >> >>>> please delete without copying and kindly advise us by
> e-mail of
> >> the
> >> >>>> mistake in delivery.
> >> >>>>       NOTE: Regardless of content, this e-mail shall not
> >> >> operate to bind
> >> >>>> CSC to any order or other contract unless pursuant to
> explicit
> >> >>>> written agreement or government initiative expressly
> permitting
> >> the
> >> >>>> use of e-mail for such purpose.
> >> >>>>
> >> >>>>       [email-masked] wrote on 02/06/2009 04:21:51 AM:
> >> >>>>
> >> >>>>       > Hi James,
> >> >>>>       >
> >> >>>>       > I have read RFC 4412 and also the GETS/MLPP IETF
> >> >> documents. What I
> >> >>>> would
> >> >>>>       > like to point out is that there is more than just a
> >> >> header and
> >> >>>> values within
> >> >>>>       > the header that have to be considered in order to
> >> >> make a judgement
> >> >>>> of what
> >> >>>>       > is appropriate and what isn't. There is an
> >> >> architectural question
> >> >>>> and
> >> >>>>       > whether the environment we are using the stuff is
> >> >> indeed providing
> >> >>>> the
> >> >>>>       > properties you need for the solution to be
> >appropriate.
> >> >>>>       >
> >> >>>>       > Let me describe in more detail what I meant (and
> >> >> please correct me
> >> >>>> if I am
> >> >>>>       > wrong).
> >> >>>>       >
> >> >>>>       > Getting priority for SIP requests when using a GETS
> >> >> alike scenario
> >> >>>> means
> >> >>>>       > that the entity that issues the request is specially
> >> >> authorized
> >> >>>> since
> >> >>>>       > otherwise you introduce a nice denial of
> >service attack. This
> >> >>>> authorization
> >> >>>>       > is tied to the entity that makes the request. For
> >> >> example, the
> >> >>>> person is
> >> >>>>       > working for the government and has special rights.
> >> >>>> James Bond as a (not so)
> >> >>>>       > secret agent might have these rights.
> >> >>>>       >
> >> >>>>       > The emergency services case
> >(citizen-to-authority) is a bit
> >> >>>> different as
> >> >>>>       > there aren't really special rights with respect to
> >> >> authorization
> >> >>>> tied to
> >> >>>>       > individuals. Instead, the fact that something is an
> >> >> emergency is
> >> >>>> purely a
> >> >>>>       > judgement of the human that dials a special number.
> >> >>>> To deal with fraud, we
> >> >>>>       > discussed in the group on what we can actually do to
> >> >> ensure that
> >> >>>> end users
> >> >>>>       > do not bypass security procedures (such as
> >> >> authorization checks,
> >> >>>> charging
> >> >>>>       > and so on). Part of this investigation was
> >the publication of
> >> >>>>       > http://www.ietf.org/rfc/rfc5069.txt that also
> >describes this
> >> >>>> issue.
> >> >>>>       >
> >> >>>>       > So, imagine the implementation of a SIP proxy (and we
> >> >> implemented
> >> >>>> that
> >> >>>>       > stuff) that receives a call that contains a Service
> >> >> URN. The code
> >> >>>> branches
> >> >>>>       > into a special mode where everything is done
> >so that the call
> >> >>>> receives
> >> >>>>       > appropriate treatment and does not get dropped on the
> >> >> floor. The
> >> >>>> way how the
> >> >>>>       > Service URN is placed in the message ensures that the
> >> >> call cannot
> >> >>>> go to my
> >> >>>>       > friend (instead of the PSAP) unless the end host ran
> >> >> LoST already.
> >> >>>> In the
> >> >>>>       > latter case, we discussed this also on the list for a
> >> >> while and
> >> >>>> Richard even
> >> >>>>       > wrote a draft about it in the context of the
> >location hiding
> >> >>>> topic, we said
> >> >>>>       > that the proxy would have to run LoST if he
> >cares about a
> >> >>>> potential
> >> >>>>       > fraudulent usage.
> >> >>>>       >
> >> >>>>       > So, what do we need todo in order to provide
> >secure RFC 4412
> >> >>>> functionality
> >> >>>>       > in our context?
> >> >>>>       >
> >> >>>>       > Do you think that the current text in
> >> >>>>       >
> >> >>>>
> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >> >>>> gency-rph-nam
> >> >>>>       > espace-00.txt reflects any of the
> >above-described issues:
> >> >>>>       > "
> >> >>>>       >    The Security considerations that apply to RFC 4412
> >> >>>> [RFC4412]
> >> >>>> apply
> >> >>>>       >    here.  This document introduces no new security
> >> >>>> issues relative
> >> >>>> to
> >> >>>>       >    RFC 4412.
> >> >>>>       > "
> >> >>>>       >
> >> >>>>       > From various discussions in GEOPRIV I recall
> >that you are
> >> >>>> super-sensitive
> >> >>>>       > regarding security and privacy. For some reasons you
> >> >> don't seem to
> >> >>>> have the
> >> >>>>       > same concerns here. I would like to
> >understand your reasoning.
> >> >>>>       >
> >> >>>>       > Please also do me another favor: Don't always say
> >> >> that I don't
> >> >>>> understand
> >> >>>>       > the subject. Even if that would be the case it isn't
> >> >> particular
> >> >>>> fair given
> >> >>>>       > that different folks had to educate you on other
> >> >> topics in the
> >> >>>> past as well.
> >> >>>>       > Additionally, if you listen to the audio recordings
> >> >> then you will
> >> >>>> notice
> >> >>>>       > that Henning, Ted, and Jon do not seem to understand
> >> >> the issue
> >> >>>> either as
> >> >>>>       > they have raised similar issues during the
> >F2F meetings.
> >> >>>>       >
> >> >>>>       > Ciao
> >> >>>>       > Hannes
> >> >>>>       >
> >> >>>>       >
> >> >>>>       > >Hannes - I believe it is you who do not understand
> >> >> RFC 4412 --
> >> >>>>       > >and many of us are trying to get that
> >through to you, but you
> >> >>>>       > >don't seem to want to listen/read.
> >> >>>>       > >
> >> >>>>       > >RFC 4412 is *for* priority marking SIP requests,
> >> >>>>       > >
> >> >>>>       > >One use is GETS.
> >> >>>>       > >
> >> >>>>       > >One use is MLPP.
> >> >>>>       > >
> >> >>>>       > >These examples are in RFC 4412 because there
> >were specific
> >> >>>>       > >namespaces being created for the IANA section of
> >> >> that document.
> >> >>>>       > >
> >> >>>>       > >Reading the whole document, you will see
> >that RPH can be
> >> >>>>       > >specified for other uses than GETS or MLPP
> >specifically.
> >> >>>>       > >
> >> >>>>       > >I knew when I wrote RFC 4412 that one day we
> >would specify a
> >> >>>>       > >namespace for ECRIT (the "esnet" namespace
> >now) -- but I also
> >> >>>>       > >knew it was premature for RFC 4412 to
> >incorporate that
> >> >>>>       > >namespace, that a future doc to RFC 4412
> >would have to be
> >> >>>>       > >written to do this. Brian and I talked about
> >this at the
> >> >>>>       > >original NENA meeting that created the IP WGs there
> >> >> (in August
> >> >>>>       > >of 03).  We both agreed we should wait until it was
> >> >>>>       > >appropriate to the work in the IETF to
> >submit this document
> >> >>>>       > >that is now
> >> >>>>       >
> >> >>>>>
> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >> >>>>       > >gency-rph-namespace-00.txt
> >> >>>>       > >
> >> >>>>       > >Yet, you seem to want to use some additional
> >mechanism to
> >> >>>>       > >indicate priority of a call in SIP.  That
> >means you want to
> >> >>>>       > >introduce a second way to accomplish this in SIP.
> >> >>>> Why do you
> >> >>>>       > >want to promote a separate way to do something SIP
> >> >> has already
> >> >>>>       > >defined? That will cause interoperability issues and
> >> >> we both know
> >> >>>> that.
> >> >>>>       > >
> >> >>>>       > >You've said to me (and others) that you
> >believe RPH is just
> >> >>>>       > >another way to accomplish what sos or a URI can
> >> >> indicate - and
> >> >>>>       > >you're wrong.  Your way would be
> >_the_second_way_to_do_it,
> >> >>>>       > >because SIP already considers RPH to be
> >*the*way* to priority
> >> >>>>       > >mark SIP requests.
> >> >>>>       > >
> >> >>>>       > >If you don't believe me (no comment), then
> >why do you not
> >> >>>>       > >believe the SIP WG chair (who knows more
> >about SIP than both
> >> >>>>       > >of us) - who, on this thread, has again said
> >to you "RFC 4412
> >> >>>>       > >(RPH) is the SIP mechanism to priority mark
> >SIP requests"?
> >> >>>>       > >
> >> >>>>       > >Further, I believe it is inappropriate to
> >prohibit endpoints
> >> >>>>       > >from being able to set the esnet namespace.
> >I absolutely
> >> >>>>       > >believe it will not be needed most of the
> >time, but I believe
> >> >>>>       > >if someone does find a valid use for
> >endpoints to mark
> >> >>>>       > >priority in SIP, this ID - once it has
> >become an RFC -- will
> >> >>>>       > >have to be obsoleted with a new RFC saying the exact
> >> >> opposite.
> >> >>>>       > >
> >> >>>>       > >(color me confused ... over and over again)
> >> >>>>       > >
> >> >>>>       > >James
> >> >>>>       > >
> >> >>>>       > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >> >>>>       > >>Keith, please understand that the usage of RFC 4412
> >> >> for GETS and
> >> >>>> for
> >> >>>>       > >>the type of emergency call we discuss here is
> >> >> different. Just
> >> >>>> looking
> >> >>>>       > >>at the header and the name of the namespace is a bit
> >> >>>>       > >artificial. I hope
> >> >>>>       > >>you understand that.
> >> >>>>       > >>
> >> >>>>       > >> >-----Original Message-----
> >> >>>>       > >> >From: DRAGE, Keith (Keith)
> >> >>>> [mailto:[email-masked]]
> >> >>>>       > >> >Sent: 05 February, 2009 14:55
> >> >>>>       > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
> >> >>>> Polk'; 'Tschofenig,
> >> >>>>       > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >> >>>>       > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
> >> >>>> Meeting: Agenda (my
> >> >>>>
> >> >>>>       > >> >mistake)
> >> >>>>       > >> >
> >> >>>>       > >> >Which is exactly what RFC 4412 specifies for all
> >> >> namespaces.
> >> >>>>       > >> >
> >> >>>>       > >> >regards
> >> >>>>       > >> >
> >> >>>>       > >> >Keith
> >> >>>>       > >> >
> >> >>>>       > >> >> -----Original Message-----
> >> >>>>       > >> >> From: [email-masked]
> >> >> [mailto:[email-masked]]
> >> >>>>       > >> >On Behalf
> >> >>>>       > >> >> Of Brian Rosen
> >> >>>>       > >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >> >>>>       > >> >> To: 'Hannes Tschofenig'; 'James M.
> >Polk'; 'Tschofenig,
> >> >>>>       > >Hannes (NSN
> >> >>>>       > >> >> - FI/Espoo)'; 'ECRIT'
> >> >>>>       > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >> >>>> Meeting: Agenda (my
> >> >>>>       > >> >> mistake)
> >> >>>>       > >> >>
> >> >>>>       > >> >> The value is that in some networks
> >where priority for
> >> >>>>       > >> >emergency calls
> >> >>>>       > >> >> is appropriate, and appropriate
> >policing of marking is
> >> >>>>       > >implemented,
> >> >>>>       > >> >> emergency calls will receive resource priority.
> >> >>>>       > >> >>
> >> >>>>       > >> >> Not all networks would need policing.  Some
> >> >> will.  Policing
> >> >>>> could
> >> >>>>       > >> >> be to Route header/R-URI content, but other
> >> >> criteria are
> >> >>>> possible.
> >> >>>>       > >> >>
> >> >>>>       > >> >> Not all networks will need resource priority
> >> >> for emergency
> >> >>>> calls.
> >> >>>>       > >> >> Fine, ignore this marking/namespace.
> >> >>>>       > >> >>
> >> >>>>       > >> >> Brian
> >> >>>>       > >> >> > -----Original Message-----
> >> >>>>       > >> >> > From: Hannes Tschofenig
> >> >>>> [mailto:[email-masked]]
> >> >>>>       > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >> >>>>       > >> >> > To: 'Brian Rosen'; 'James M. Polk';
> >> >> Tschofenig, Hannes
> >> >>>> (NSN -
> >> >>>>       > >> >> > FI/Espoo); 'ECRIT'
> >> >>>>       > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
> >> >>>> Meeting: Agenda (my
> >> >>>>       > >> >> > mistake)
> >> >>>>       > >> >> >
> >> >>>>       > >> >> > I don't even see the value in permitting the
> >> >> endpoint todo
> >> >>>> the
> >> >>>>       > >> >> > RPH marking.
> >> >>>>       > >> >> > In addition to the security concerns
> >there is also the
> >> >>>>       > >> >problem that
> >> >>>>       > >> >> > there are more options to implement without
> >> >> an additional
> >> >>>> value.
> >> >>>>       > >> >> >
> >> >>>>       > >> >> > >-----Original Message-----
> >> >>>>       > >> >> > >From: Brian Rosen [mailto:[email-masked]]
> >> >>>>       > >> >> > >Sent: 05 February, 2009 00:03
> >> >>>>       > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
> >> >> 'Tschofenig,
> >> >>>>       > >> >> Hannes (NSN -
> >> >>>>       > >> >> > >FI/Espoo)'; 'ECRIT'
> >> >>>>       > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual
> >Interim Meeting:
> >> >>>> Agenda (my
> >> >>>>       > >> >> > mistake)
> >> >>>>       > >> >> > >
> >> >>>>       > >> >> > >Hannes
> >> >>>>       > >> >> > >
> >> >>>>       > >> >> > >This matches my understanding
> >precisely.  We wish to
> >> >>>>       > >> >> permit endpoints
> >> >>>>       > >> >> > >to mark. We do not require it, and
> >don't necessarily
> >> >>>> expect it
> >> >>>>       > >> >> > >in many (even
> >> >>>>       > >> >> > >most) cases.  We don't wish to see the
> >> >> document prohibit
> >> >>>> it.
> >> >>>>       > >> >> > >We all seem to agree it has value within the
> >> >> Emergency
> >> >>>>       > >> >Services IP
> >> >>>>       > >> >> > >Networks.
> >> >>>>       > >> >> > >
> >> >>>>       > >> >> > >Brian
> >> >>>>       > >> >> > >
> >> >>>>       > >> >> > >> -----Original Message-----
> >> >>>>       > >> >> > >> From: [email-masked]
> >> >>>> [mailto:[email-masked]]
> >> >>>>       > >> >> > >On Behalf
> >> >>>>       > >> >> > >> Of James M. Polk
> >> >>>>       > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> >> >>>>       > >> >> > >> To: Hannes Tschofenig; Tschofenig,
> >Hannes (NSN -
> >> >>>>       > >> >> FI/Espoo); 'ECRIT'
> >> >>>>       > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >> >>>> Meeting:
> >> >>>>       > >Agenda (my
> >> >>>>       > >> >> > >> mistake)
> >> >>>>       > >> >> > >>
> >> >>>>       > >> >> > >> At 02:37 PM 2/4/2009, Hannes
> >Tschofenig wrote:
> >> >>>>       > >> >> > >> > > James wrote:
> >> >>>>       > >> >> > >> > >> you are the _lone_ voice not
> >> >> supporting this ID,
> >> >>>>       > >> >> > >> >
> >> >>>>       > >> >> > >> >Listening to the audio recording of past
> >> >> meetings I
> >> >>>> have to
> >> >>>>       > >> >> > >say that
> >> >>>>       > >> >> > >> >I
> >> >>>>       > >> >> > >> was
> >> >>>>       > >> >> > >> >not the only persons raising
> >concerns about the
> >> >>>> document.
> >> >>>>       > >> >> > >> >That was probably the reason why you
> >> >> agreed to limit
> >> >>>> the
> >> >>>>       > >> >> > >scope of the
> >> >>>>       > >> >> > >> >document (which you didn't later do) to
> >> >> get folks to
> >> >>>> agree
> >> >>>>       > >> >> > >to make it
> >> >>>>       > >> >> > >> a WG
> >> >>>>       > >> >> > >> >item.
> >> >>>>       > >> >> > >>
> >> >>>>       > >> >> > >> re-listen to the audio please
> >> >>>>       > >> >> > >>
> >> >>>>       > >> >> > >> Ted's concerns were consistent with most
> >> >>>> (all?) other
> >> >>>>       > >> >> concerns --
> >> >>>>       > >> >> > >> which were based on the premise of whether
> >> >> or not the
> >> >>>>       > >> >> UAC should be
> >> >>>>       > >> >> > >> trusted to initiate the marking on the
> >> >> INVITE.  The
> >> >>>> most
> >> >>>>       > >> >> > >> recent version has backed off this
> >to a "can" --
> >> >>>> meaning not
> >> >>>>       > >> >prohibited
> >> >>>>       > >> >> > >> (i.e., no 2119 text).  I also backed off
> >> >> the text in
> >> >>>> the
> >> >>>>       > >> >> SP domain
> >> >>>>       > >> >> > >> part to "can", such that there is
> >no 2119 text
> >> >>>>       > >> >mandating or even
> >> >>>>       > >> >> > >> recommending its usage there. I also do
> >> >> not prohibit
> >> >>>> its
> >> >>>>       > >> >> > >use, based on
> >> >>>>       > >> >> > >> local policy.  Keith has come forward with
> >> >> the specific
> >> >>>>
> >> >>>>       > >> >> > >> request that non-ESInet networks be
> >> >> allowed to mark and
> >> >>>> pay
> >> >>>>       > >> >attention to
> >> >>>>       > >> >> > >> this priority indication -- with IMS as
> >> >> the specific
> >> >>>> example
> >> >>>>       > >> >> > >> he wishes to have this valid for.
> >> >>>>       > >> >> > >>
> >> >>>>       > >> >> > >> Where there is no disagreement, save for
> >> >> your recent
> >> >>>>       > >> >> > >pushback - is in
> >> >>>>       > >> >> > >> the ESInet, which is where Brian
> >has requested it's
> >> >>>>       > >> >> > >definition in the
> >> >>>>       > >> >> > >> IETF on behalf of NENA.  He's the i3 WG
> >> >> chair within
> >> >>>>       > >> >> NENA, and if
> >> >>>>       > >> >> > >> he asks for it, are you going to say you
> >> >> know better
> >> >>>> than he?
> >> >>>>       > >> >> > >>
> >> >>>>       > >> >> > >>
> >> >>>>       > >> >> > >> >Btw, I not disagreeing with the document
> >> >> as such. I
> >> >>>>       > >> >just want to
> >> >>>>       > >> >> > the
> >> >>>>       > >> >> > >> scope
> >> >>>>       > >> >> > >> >to change. The usage of RPH
> >within the emergency
> >> >>>>       > >> >> services network
> >> >>>>       > >> >> > is
> >> >>>>       > >> >> > >> fine
> >> >>>>       > >> >> > >> >for me. I may get convinced to start the
> >> >> RPH marking
> >> >>>> from
> >> >>>>       > >> >> > >the the VSP
> >> >>>>       > >> >> > >> >towards the PSAP. I feel uneasy about the
> >> >> end host
> >> >>>> doing
> >> >>>>       > >> >> > >the marking.
> >> >>>>       > >> >> > >>
> >> >>>>       > >> >> > >> please read what I wrote above, and then
> >> >> re-read the
> >> >>>>       > >> >most recent
> >> >>>>       > >> >> > >> version of the ID. I don't have endpoints
> >> >> that SHOULD
> >> >>>> or
> >> >>>>       > >> >> MUST mark
> >> >>>>       > >> >> > >> anything wrt RPH.  I also don't want to
> >> >> prohibit it,
> >> >>>>       > >> >> because there
> >> >>>>       > >> >> > >> might be cases (that I don't know
> >of) of valid uses
> >> >>>>       > >> >> under certain
> >> >>>>       > >> >> > >> circumstances.  Figure 1 is very clear
> >> >> that there are 3
> >> >>>>       > >> >> networking
> >> >>>>       > >> >> > >> parts to consider
> >> >>>>       > >> >> > >>
> >> >>>>       > >> >> > >> #1 - from the endpoint
> >> >>>>       > >> >> > >> #2 - within the VSP
> >> >>>>       > >> >> > >> #3 - within the ESInet
> >> >>>>       > >> >> > >>
> >> >>>>       > >> >> > >> the most recent ID version has "can" for
> >> >> #s 1 and 2,
> >> >>>> and
> >> >>>>       > >> >> > >2119 language
> >> >>>>       > >> >> > >> offering those supporting this
> >> >> specification will have
> >> >>>> RPH
> >> >>>>       > >> >> > >> adherence within #3 (the ESInet).
> >> >>>>       > >> >> > >>
> >> >>>>       > >> >> > >> What other scope changes do you want,
> >> >> because I haven't
> >> >>>>       > >> >> heard them.
> >> >>>>       > >> >> > >>
> >> >>>>       > >> >> > >> I only heard you claim in email during the
> >> >> last IETF
> >> >>>> and in
> >> >>>>       > >> >> > >the ECRIT
> >> >>>>       > >> >> > >> session that RPH should not be
> >used for priority
> >> >>>> marking
> >> >>>>       > >> >> requests.
> >> >>>>       > >> >> > >> This is something Keith (SIP WG
> >chair) voiced his
> >> >>>> opposition
> >> >>>>       > >> >> > >> to your views regarding creating a second
> >> >> means for SIP
> >> >>>> to
> >> >>>>       > >> >priority
> >> >>>>       > >> >> > >> mark request "when SIP already has one
> >> >> interoperable
> >> >>>> way to
> >> >>>>       > >> >> > >> accomplish this... it's call the RP header
> >> >> mechanism".
> >> >>>>       > >> >> > >>
> >> >>>>       > >> >> > >> >I don't see advantages -- only
> >disadvantages.
> >> >>>>       > >> >> > >> >
> >> >>>>       > >> >> > >> >Ciao
> >> >>>>       > >> >> > >> >Hannes
> >> >>>>       > >> >> > >>
> >> >>>>       > >> >> > >>
> >_______________________________________________
> >> >>>>       > >> >> > >> Ecrit mailing list
> >> >>>>       > >> >> > >> [email-masked]
> >> >>>>       > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>       > >> >> > >
> >> >>>>       > >> >>
> >> >>>>       > >> >> _______________________________________________
> >> >>>>       > >> >> Ecrit mailing list
> >> >>>>       > >> >> [email-masked]
> >> >>>>       > >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>       > >> >>
> >> >>>>       > >> >
> >> >>>>       > >
> >> >>>>       >
> >> >>>>       > _______________________________________________
> >> >>>>       > Ecrit mailing list
> >> >>>>       > [email-masked]
> >> >>>>       > https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> Ecrit mailing list
> >> >>>> [email-masked]
> >> >>>> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> Ecrit mailing list
> >> >>> [email-masked]
> >> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>
> >> >
> >> > _______________________________________________
> >> > Ecrit mailing list
> >> > [email-masked]
> >> > https://www.ietf.org/mailman/listinfo/ecrit
> >> >
> >
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>
>
> --------------------------------------------------------------
> ----------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------
> ----------------------------------
> [mf2]
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Henning Schulzrinne <[email-masked]>, "James M. Polk" <[email-masked]>
Date: Sat, 7 Feb 2009 01:21:40 +0100
Accept-Language: en-US
acceptlanguage: en-US
Cc: ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

Well to be honest, I thought RFC 4412 defined exactly the usage from the UA=
 of any RPH header, and noone appears to be seeking to change that. Any UE =
can insert an RPH header, and the outbound proxy that understands RPH can u=
se this as absolute, guidance, or completely ignore it and throw it away de=
pending on whatever rules it decides apply to its usage of that namespace. =
IETF does not write those rules, just defines the namespace.=20

So I disagree with the statement of "underspecified" in relation to this.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> On Behalf Of Henning Schulzrinne
> Sent: Friday, February 06, 2009 10:29 PM
> To: James M. Polk
> Cc: ECRIT
> Subject: Re: [Ecrit] RPH
>=20
> To restate: I will object to any text mentioning use of ESNET=20
> in UAs. =20
> It's useless (since under-specified), likely to be harmful to=20
> reliable network operation and just causes confusion. The=20
> text should describe when it is useful (within a "closed"=20
> ESNET, presumably) and what conditions need to be met in=20
> order to ensure reliable and secure usage. That something=20
> might be useful somewhere else is always true, in any=20
> specification, but we don't add a "This document does not=20
> prevent the use of this mechanism somewhere else." in documents.
>=20
> Henning
>=20
> On Feb 6, 2009, at 5:21 PM, James M. Polk wrote:
>=20
> > At 04:05 PM 2/6/2009, Henning Schulzrinne wrote:
> >> James,
> >>
> >> we don't go through every possible SIP header that might=20
> be inserted=20
> >> into emergency requests. Yes, somebody could add RPH, but this=20
> >> applies to PAI and dozens of other SIP headers as well. So far,=20
> >> nobody has provided, in my opinion, a compelling use case that is=20
> >> worth documenting. "It could be useful somewhere for something"=20
> >> doesn't cut it. I have provided multiple reasons why I=20
> think that it=20
> >> is a bad idea for (normal) UAs to do so, none of which you address.
> >
> >
> >> I see no need to  say "do not insert RPH",
> >
> > this is the only thing - right now - that I'm afraid one of us=20
> > believes should be the case. I'm glad you are not joining that=20
> > position.  I really do not want to highlight the idea fo=20
> UAs inserting=20
> > esnet, but I believe sometime down the road - some customer=20
> will come=20
> > up with a valid reason for this, and I don't want to state in text=20
> > that it is prevented from being inserted (and yet have the=20
> vendor who=20
> > wants to sell to that customer also want that vendor to=20
> adhere to this=20
> > spec as well).
> >
> > I'm just advocating we not have the text prevent its inclusion.
> >
> > As I've said, I will beef up the security considerations=20
> section wrt=20
> > UA insertion of esnet - unless others object to this...
>=20
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
> =

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 7 Feb 2009 01:26:02 +0100
Accept-Language: en-US
acceptlanguage: en-US
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ecrit] RPH

It appears you want to develop an entirely separate codepath for the usage =
of RPH in emergency calls, where the appropriate thing is to apply the test=
ed usage of RPH that many networks will have to deploy anyway. So there wil=
l be a standard RPH usage which is then configured to handle the emergency =
namespace.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Hannes Tschofenig
> Sent: Friday, February 06, 2009 10:52 PM
> To: 'DOLLY, MARTIN C, ATTLABS'; [email-masked];
> [email-masked]; [email-masked]
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
> Subject: Re: [Ecrit] RPH
>
> Hi Martin,
>
> I am arguing that if the UE does mark the call with the ECRIT
> RPH (I call it that way to differentiate it from RFC 4412 RPH
> usage, which is very
> different) then it should be ignored.
> Processing it will not help in any way (as I described in my
> pseudo code snippet). Incorrectly processing it (which is a
> possibility when the implementer does not understand the
> security implications -- they will not get it from the
> current version of the draft) will lead to security problems
> (fraud & DoS potential).
>
> While you cannot prevent someone from sending you, there is
> certainly the chance to document what the receiver should do with it.
>
> Ciao
> Hannes
>
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]
> On Behalf
> >Of DOLLY, MARTIN C, ATTLABS
> >Sent: 07 February, 2009 00:15
> >To: [email-masked]; [email-masked];
> >[email-masked]
> >Cc: [email-masked]; [email-masked]
> >Subject: Re: [Ecrit] RPH
> >
> >You can not disallow this from an UE. The trust relationship will
> >dictate whether it is accepted or not
> >
> >----- Original Message -----
> >From: [email-masked] <[email-masked]>
> >To: Henning Schulzrinne <[email-masked]>; Winterbottom, James
> ><[email-masked]>
> >Cc: Tschofenig, Hannes (NSN - FI/Espoo) <[email-masked]>;
> >ECRIT <[email-masked]>
> >Sent: Fri Feb 06 17:10:08 2009
> >Subject: Re: [Ecrit] RPH
> >
> >At 03:05 PM 2/6/2009, Henning Schulzrinne wrote:
> >>There's another problem with the "it doesn't hurt argument".
> >Assume for
> >>a moment we have a "UA MAY include RPH" wording. There are now two
> >>cases:
> >>
> >>(1) All UAs implement it.
> >>
> >>(2) Only some UAs implement it.
> >>
> >>(1) seems unlikely for a MAY. If (2) occurs, we have the
> >choice between
> >>two undesirable outcomes:
> >>
> >>(a) some UAs that are otherwise compliant get worse service just
> >>because they didn't include the RPH;
> >
> >am I reading this correctly - that unless all UAs implement this
> >capability this should never be implemented by any UAs?
> >
> >This flies in the face of vendors solving for their customer's
> >requirements.
> >
> >I will admit that at this time, I know of no Cisco customers
> that want
> >this capability, so I'm not angling for any of our revenue
> here.  I'm
> >saying that I think I hear you saying this ID should say
> something like
> >
> >         UAs are prevented from implementing the RP namespace esnet
> >
> >I'm fighting against that, because customers are always
> coming to every
> >vendor with new requirements, some of them unique at the time.  This
> >prevention text would prevent a vendor from complying with this
> >specification and still meet the customer's needs.
> >
> >I believe that this ID needs to retain the endpoints MAY
> insert esnet,
> >and have appropriate security considerations text that
> highlights the
> >concerns expressed here.
> >
> >Some future ID can then update this current RFC (to-be) within the
> >2119 rules of the use of MAY here.
> >
> >
> >>OR
> >>
> >>(b) the proxy has to look for the service URN to give the call the
> >>appropriate treatment, thus obviating any advantage of having the
> >>header, yet incurring more complicated processing logic.
> >>
> >>
> >>I have no objection to whatever markings people want to
> apply to calls
> >>within an ESN - that's largely a private matter.
> >>
> >>Henning
> >>
> >>On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote:
> >>
> >>>Hi All,
> >>>
> >>>I have followed thi thread with some interest and I
> struggling to see
> >>>a use case for the providing RPH for emergency calls from the
> >>>end-point.
> >>>
> >>>The reference-model call in ECRIT, for better or worse, is for all
> >>>calls to go back through a home-VSP.
> >>>We placed quite a lot of emphasis, largely for traffing
> reasons, for
> >>>the VSP to be able to verify that a call is in fact an emergency
> >>>call. This is done by the proxy taking the inband
> location, doing a
> >>>LoST query with the provided URN, and verifying that the resulting
> >>>destination URI is the same as the destination URI provide
> in the SIP
> >>>INVITE. My understanding was that VSPs would always do
> this check so
> >>>they could tell if they could bill for the call or not,
> and because
> >>>the VSP can be use that the call is an emergency call it can apply
> >>>any special priorities that may be applicable. This
> obviates the need
> >>>for RPH from the end-point to the network.
> >>>
> >>>This leaves us with the argument of "it doesn't hurt to
> it", which is
> >>>not a good reason to write a specification.
> >>>It was intimated on the geopriv mailing list last year that great
> >>>pains had been taken to keep SIP with in the MTU limits of
> UDP over
> >>>Ethernet
> >>>(http://www.ietf.org/mail-archive/web/geopriv/current/msg0612
> >0.html ). Assuming
> >>>that this is the case, perhaps there is harm in including
> information
> >>>that we know will be ignored.
> >>>
> >>>Cheers
> >>>James
> >>>
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: [email-masked] on behalf of Hannes Tschofenig
> >>>Sent: Fri 2/6/2009 12:33 PM
> >>>To: 'Brian Rosen'; 'Henning Schulzrinne'
> >>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
> >>>Subject: Re: [Ecrit] RPH
> >>>
> >>>To the story short here is the code for the proxy:
> >>>
> >>>---------------------
> >>>
> >>>IF emergency call was recognized THEN
> >>>    execute emergency call specific procedures (priority queuing,
> >>>preemption, fetch location, determine routing, do funny
> QoS things &
> >>>co)
> >>>ELSE
> >>>    normal call handling procedures.
> >>>
> >>>---------------------
> >>>
> >>>If you can make this differentiation between an emergency
> call and a
> >>>regular call then you can also do everything that is necessary for
> >>>emergency call handling.
> >>>
> >>>Brian + Keith: Please tell me that we cannot do the above with our
> >>>currently specified mechanisms.
> >>>
> >>>Ciao
> >>>Hannes
> >>>
> >>>>-----Original Message-----
> >>>>From: Brian Rosen [mailto:[email-masked]]
> >>>>Sent: 06 February, 2009 17:49
> >>>>To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
> >>>>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >>>>Subject: RE: [Ecrit] RPH
> >>>>
> >>>>I agree that not all networks will permit (or pay attention
> >>>>to) a priority request from an end device.
> >>>>
> >>>>No one has asked for that.
> >>>>
> >>>>The namespace request has several uses, one of which is within an
> >>>>emergency services IP network, one of which is between elements
> >>>>within a public network controlled by the operator, and
> one of which
> >>>>is an endpoint request for resource priority.
> >>>>
> >>>>Those of us requesting this work proceed are happy if the
> endpoint
> >>>>part is simply left as possible (MAY), and, speaking for myself,
> >>>>having the draft discuss the security implications of endpoint
> >>>>marking is reasonable.
> >>>>
> >>>>Having discussed this issue with an implementation team
> who worked
> >>>>on MLPP systems, I am confident I know what I'm talking
> about, but
> >>>>YMMV.  The fact that you could, if you wanted to, give resource
> >>>>priority to a call you decided, however you decided, was an
> >>>>emergency call is an implementation decision, and not subject to
> >>>>standardization.
> >>>>
> >>>>RPH is the IETF standard way for one entity to request resource
> >>>>priority of another entity in a SIP system.  We're asking for a
> >>>>namespace to use that within the domain of emergency calls.  That
> >>>>is, I think, a VERY reasonable request.
> >>>>
> >>>>Brian
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Henning Schulzrinne [mailto:[email-masked]]
> >>>>>Sent: Friday, February 06, 2009 10:33 AM
> >>>>>To: Hannes Tschofenig
> >>>>>Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
> >>>>>Subject: Re: [Ecrit] RPH
> >>>>>
> >>>>>To chime in here:
> >>>>>
> >>>>>I don't think it's productive to simply state that 4412
> >>>>doesn't worry
> >>>>>about authorization, so we shouldn't either (simplifying a bit).
> >>>>>Authorization was discussed repeatedly, and the general
> >>>>assumption was
> >>>>>that there were two conditions: Either the user invoking
> resource-
> >>>>>priority was well known and had a set of permissions
> that could be
> >>>>>checked in real time or there are ways to deal with
> abuse after the
> >>>>>fact in ways that deter abuse (the court-martial kind of
> thing in a
> >>>>>military context).
> >>>>>
> >>>>>The RFC 4412 security consideration (11.2) call this out
> in pretty
> >>>>>strong language:
> >>>>>
> >>>>>  Prioritized access to network and end-system resources imposes
> >>>>>    particularly stringent requirements on authentication and
> >>>>>    authorization mechanisms, since access to prioritized
> >>>>resources may
> >>>>>    impact overall system stability and performance and not
> >>>>just result
> >>>>>    in theft of, say, a single phone call.
> >>>>>Thus, the question is whether we have such strong
> authentication in
> >>>>>emergency calling. In some cases, such as residential fixed line
> >>>>>deployments where ISP =3D VSP, we're probably pretty close,
> >in others,
> >>>>>such as prepaid cell phones or hot spots or VSP-only
> providers, we
> >>>>>aren't.
> >>>>>
> >>>>>The other point that I think Hannes is making is that the
> >>>>information
> >>>>>is either redundant or dangerous. If a processing element
> >recognizes
> >>>>>the call as being an emergency call, it can apply whatever
> >treatment
> >>>>>it deems appropriate and doesn't need additional
> information. If it
> >>>>>doesn't or can't, using just the RPH can be rather
> dangerous unless
> >>>>>that element can be reasonably certain that there is strong
> >>>>>authentication and recourse.
> >>>>>
> >>>>>I don't buy the argument that somehow finding the RPH is
> >faster than
> >>>>>just looking for the identifier. Thus, given that the
> >information is
> >>>>>either redundant or dangerous, I fail to see the advantage.
> >>>>>
> >>>>>Henning
> >>>>>
> >>>>>
> >>>>>On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
> >>>>>
> >>>>>>Don't get hung up on the details. There are ways to optimize it.
> >>>>>>That was
> >>>>>>not the point of the code example.
> >>>>>>
> >>>>>>The problem that my pseudo code should have shown you
> is that you
> >>>>>>* don't gain anything with RPH marking for the
> emergency call case
> >>>>>>from the SIP UA towards the outbound proxy since the
> functionality
> >>>>>>is already provide otherwise. How often does the proxy
> need to get
> >>>>>>told that this is an emergency call todo whatever
> emergency call
> >>>>>>handling procedures are necessary?
> >>>>>>* you only introduce fraud problems (if you are not
> >>>>careful and you
> >>>>>>understand the security stuff well enough)
> >>>>>>
> >>>>>>If you can point me to people who implement the RPH
> emergency call
> >>>>>>case please do so. I would love to talk to them.
> >>>>>>
> >>>>>>Ciao
> >>>>>>Hannes
> >>>>>>
> >>>>>>PS: You need to parse incoming messages to some extend
> so that you
> >>>>>>know what it contains :-) Only looking for the emergency
> >>>>RPH header
> >>>>>>(and not for the Service URN/dial
> >>>>>>string) would exactly be the DoS/fraud attack I am
> worried about.
> >>>>>>That's the thing Henning was worried about (go and
> listen to the
> >>>>>>past meeting minutes).
> >>>>>>
> >>>>>>
> >>>>>>>Hannes
> >>>>>>>
> >>>>>>>You need to talk to people who really implement this kind
> >>>>of thing.
> >>>>>>>You are way off.
> >>>>>>>
> >>>>>>>When you implement a resource priority system, the
> point of doing
> >>>>>>>that is to look though the queue of work and pick out the
> >>>>ones with
> >>>>>>>priority, handling them first.  You don't do all the
> parsing, you
> >>>>>>>don't do a lot of decision tree.
> >>>>>>>
> >>>>>>>Typically:
> >>>>>>>Check for DoS things, like too big messages, etc Do a
> quick scan
> >>>>>>>for the RPH message header If found:
> >>>>>>>Parse the message
> >>>>>>>Determine validity
> >>>>>>>Determine priority
> >>>>>>>Queue on the correct work queue
> >>>>>>>
> >>>>>>>The first two actions have to be very fast.  Anyone
> who builds a
> >>>>>>>SIP thingie will tell you that parsing is one of the big cycle
> >>>>>>>consumers: if you have to parse every message BEFORE you
> >>>>determine
> >>>>>>>priority, you can't give much resource priority.
> >>>>>>>Once you get the whole message parsed, you might as
> well finish
> >>>>>>>working on it, because you've done so much of the work.
> >>>>>>>OTHOH, finding the end-of-message delimiter and doing a quick
> >>>>>>>string search for RPH is fast.  If you are doing
> >>>>priority, you need
> >>>>>>>to keep all the priority processing pretty uniform, and pretty
> >>>>>>>simple, or you tend to spend too much time futzing around
> >>>>figuring
> >>>>>>>out what to do.  You put all the priority related
> stuff together,
> >>>>>>>and use as much common code as possible.
> >>>>>>>
> >>>>>>>Brian
> >>>>>>>
> >>>>>>>>-----Original Message-----
> >>>>>>>>From: [email-masked] [mailto:[email-masked]]
> >>>>>>>On Behalf
> >>>>>>>>Of Hannes Tschofenig
> >>>>>>>>Sent: Friday, February 06, 2009 8:41 AM
> >>>>>>>>To: 'Hannes Tschofenig'; 'Janet P Gunn'
> >>>>>>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-
> >>>>>>>>[email-masked]
> >>>>>>>>Subject: [Ecrit] RPH
> >>>>>>>>
> >>>>>>>>Over lunch I was also thinking how an outbound proxy would
> >>>>>implement
> >>>>>>>>some of the emergency procedures. Here are some thoughts:
> >>>>>>>>
> >>>>>>>>---------------------------------------------------
> >>>>>>>>
> >>>>>>>>// Process incoming message
> >>>>>>>>Parse(msg);
> >>>>>>>>
> >>>>>>>>// SIP INVITE without Service URN // legacy devices If
> >>>>>>>>(recognize-dialstring(msg)=3D=3DTRUE) {  // we got an
> emergency call
> >>>>>>>>going on  emergency=3DTRUE;  if (dialstring(msg) =3D=3D 911)
> >>>>>>>>serviceURN=3Durn:service:sos; } else if
> >>>>>>>>(recognize-serviceURN(msg)=3D=3DTRUE) {  // oh. A updated
> >>>>device that
> >>>>>>>>has a service URN attached to the
> >>>>>call
> >>>>>>>>serviceURN=3Dretrieve_ServiceURN(msg);
> >>>>>>>>emergency=3DTRUE;
> >>>>>>>>} else {
> >>>>>>>>// standard SIP message
> >>>>>>>>// regular processing
> >>>>>>>>process(msg);
> >>>>>>>>emergency=3DFALSE;
> >>>>>>>>}
> >>>>>>>>
> >>>>>>>>If (emergency =3D=3D TRUE) {
> >>>>>>>>  // make sure that the emergency call does not get
> >>>>dropped on the
> >>>>>>>>floor
> >>>>>>>>  // skip authorization failures
> >>>>>>>>  // give the call a special treatment
> >>>>>>>>  lots-of-code-here();
> >>>>>>>>
> >>>>>>>>  // trigger all the QoS signaling you have in the
> >>>>network to make
> >>>>>>>>James happy
> >>>>>>>>  trigger-qos();
> >>>>>>>>
> >>>>>>>>  // query location
> >>>>>>>>  location=3Dretrieve-location();
> >>>>>>>>
> >>>>>>>>  // determine next hop
> >>>>>>>>  next-hop=3Dlost(location, serviceURN)
> >>>>>>>>
> >>>>>>>>  // attach RPH marking to outgoing msg to make James and
> >>>>>>>Keith happy
> >>>>>>>>  msg=3Dadd(msg, RPH);
> >>>>>>>>
> >>>>>>>>  send(msg, next-hop);
> >>>>>>>>}
> >>>>>>>>
> >>>>>>>>If ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D TRUE)) {
> >>>>>>>>  // all the emergency related processing done already upfront
> >>>>>>>>  // hence I log something.
> >>>>>>>>  log(RPH_WAS_PRESENT_JUHU);
> >>>>>>>>} else if ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D
> >>>>FALSE)) {
> >>>>>>>>// this is not an emergency call  // this is something
> >>>>like GETS
> >>>>>>>>result=3Dspecial-authorization-procedure(user);
> >>>>>>>>
> >>>>>>>>if (result =3D=3D AUTHORIZED) {
> >>>>>>>>   // do some priority & preemption thing here.
> >>>>>>>>   // trigger all the QoS you have
> >>>>>>>>   lots-of-code-here();
> >>>>>>>>} else {
> >>>>>>>>   log("NOT AUTHORIZED; don't DoS my network");  } }
> else {  //
> >>>>>>>>don't need todo any RPH processing  // this includes the case
> >>>>>>>>where the call was an emergency call but the RPH
> >>>>>>>>
> >>>>>>>>// marking was not there.
> >>>>>>>>nothing();
> >>>>>>>>}
> >>>>>>>>
> >>>>>>>>---------------------------------------------------
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>Ciao
> >>>>>>>>Hannes
> >>>>>>>>
> >>>>>>>>>-----Original Message-----
> >>>>>>>>>From: [email-masked]
> [mailto:[email-masked]] On
> >>>>>>>>>Behalf Of Hannes Tschofenig
> >>>>>>>>>Sent: 06 February, 2009 15:07
> >>>>>>>>>To: 'Janet P Gunn'
> >>>>>>>>>Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
> >>>>>>>>FI/Espoo)
> >>>>>>>>>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
> >Agenda (RPH)
> >>>>>>>>>
> >>>>>>>>>Who would define something that could prevent DoS problems?
> >>>>>>>>>
> >>>>>>>>>________________________________
> >>>>>>>>>
> >>>>>>>>>         From: Janet P Gunn [mailto:[email-masked]]
> >>>>>>>>>         Sent: 06 February, 2009 14:11
> >>>>>>>>>         To: Hannes Tschofenig
> >>>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >>>>>>>>>[email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
> >>>>>'James
> >>>>>>>>>M. Polk'
> >>>>>>>>>         Subject: Re: [Ecrit] ECRIT Virtual Interim
> >>>>Meeting: Agenda (RPH)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>         But there is nothing IN RFC4412 that specifically
> >>>>>>>addresses how to
> >>>>>>>>>prevent any particular namespace being used for DoS.
> >Anyone/any
> >>>>>UA
> >>>>>>>>>can ATTEMPT to invoke priority treatment by
> attaching RPH.  For
> >>>>>all
> >>>>>>>>>of the 4412 namespaces, as with the new proposed
> namespace, the
> >>>>>>>>>mechanisms for preventing DoS are not specified in the
> >>>>>>>document that
> >>>>>>>>>defines the namespace.
> >>>>>>>>>They are/will be specified elsewhere.
> >>>>>>>>>
> >>>>>>>>>         Janet
> >>>>>>>>>
> >>>>>>>>>         This is a PRIVATE message. If you are not
> the intended
> >>>>>>>recipient,
> >>>>>>>>>please delete without copying and kindly advise us
> by e-mail of
> >>>>>the
> >>>>>>>>>mistake in delivery.
> >>>>>>>>>         NOTE: Regardless of content, this e-mail shall not
> >>>>>>>operate to bind
> >>>>>>>>>CSC to any order or other contract unless pursuant
> to explicit
> >>>>>>>>>written agreement or government initiative expressly
> permitting
> >>>>>the
> >>>>>>>>>use of e-mail for such purpose.
> >>>>>>>>>
> >>>>>>>>>         [email-masked] wrote on 02/06/2009
> >04:21:51 AM:
> >>>>>>>>>
> >>>>>>>>>         > Hi James,
> >>>>>>>>>         >
> >>>>>>>>>         > I have read RFC 4412 and also the GETS/MLPP IETF
> >>>>>>>documents. What I
> >>>>>>>>>would
> >>>>>>>>>         > like to point out is that there is more
> than just a
> >>>>>>>header and
> >>>>>>>>>values within
> >>>>>>>>>         > the header that have to be considered in order to
> >>>>>>>make a judgement
> >>>>>>>>>of what
> >>>>>>>>>         > is appropriate and what isn't. There is an
> >>>>>>>architectural question
> >>>>>>>>>and
> >>>>>>>>>         > whether the environment we are using the stuff is
> >>>>>>>indeed providing
> >>>>>>>>>the
> >>>>>>>>>         > properties you need for the solution to be
> >>>>appropriate.
> >>>>>>>>>         >
> >>>>>>>>>         > Let me describe in more detail what I meant (and
> >>>>>>>please correct me
> >>>>>>>>>if I am
> >>>>>>>>>         > wrong).
> >>>>>>>>>         >
> >>>>>>>>>         > Getting priority for SIP requests when
> using a GETS
> >>>>>>>alike scenario
> >>>>>>>>>means
> >>>>>>>>>         > that the entity that issues the request
> is specially
> >>>>>>>authorized
> >>>>>>>>>since
> >>>>>>>>>         > otherwise you introduce a nice denial of
> >>>>service attack. This
> >>>>>>>>>authorization
> >>>>>>>>>         > is tied to the entity that makes the request. For
> >>>>>>>example, the
> >>>>>>>>>person is
> >>>>>>>>>         > working for the government and has special rights.
> >>>>>>>>>James Bond as a (not so)
> >>>>>>>>>         > secret agent might have these rights.
> >>>>>>>>>         >
> >>>>>>>>>         > The emergency services case
> >>>>(citizen-to-authority) is a bit
> >>>>>>>>>different as
> >>>>>>>>>         > there aren't really special rights with respect to
> >>>>>>>authorization
> >>>>>>>>>tied to
> >>>>>>>>>         > individuals. Instead, the fact that
> something is an
> >>>>>>>emergency is
> >>>>>>>>>purely a
> >>>>>>>>>         > judgement of the human that dials a
> special number.
> >>>>>>>>>To deal with fraud, we
> >>>>>>>>>         > discussed in the group on what we can
> actually do to
> >>>>>>>ensure that
> >>>>>>>>>end users
> >>>>>>>>>         > do not bypass security procedures (such as
> >>>>>>>authorization checks,
> >>>>>>>>>charging
> >>>>>>>>>         > and so on). Part of this investigation was
> >>>>the publication of
> >>>>>>>>>         > http://www.ietf.org/rfc/rfc5069.txt that also
> >>>>describes this
> >>>>>>>>>issue.
> >>>>>>>>>         >
> >>>>>>>>>         > So, imagine the implementation of a SIP
> >proxy (and we
> >>>>>>>implemented
> >>>>>>>>>that
> >>>>>>>>>         > stuff) that receives a call that contains
> a Service
> >>>>>>>URN. The code
> >>>>>>>>>branches
> >>>>>>>>>         > into a special mode where everything is done
> >>>>so that the call
> >>>>>>>>>receives
> >>>>>>>>>         > appropriate treatment and does not get
> >dropped on the
> >>>>>>>floor. The
> >>>>>>>>>way how the
> >>>>>>>>>         > Service URN is placed in the message
> >ensures that the
> >>>>>>>call cannot
> >>>>>>>>>go to my
> >>>>>>>>>         > friend (instead of the PSAP) unless the
> end host ran
> >>>>>>>LoST already.
> >>>>>>>>>In the
> >>>>>>>>>         > latter case, we discussed this also on the
> >list for a
> >>>>>>>while and
> >>>>>>>>>Richard even
> >>>>>>>>>         > wrote a draft about it in the context of the
> >>>>location hiding
> >>>>>>>>>topic, we said
> >>>>>>>>>         > that the proxy would have to run LoST if he
> >>>>cares about a
> >>>>>>>>>potential
> >>>>>>>>>         > fraudulent usage.
> >>>>>>>>>         >
> >>>>>>>>>         > So, what do we need todo in order to provide
> >>>>secure RFC 4412
> >>>>>>>>>functionality
> >>>>>>>>>         > in our context?
> >>>>>>>>>         >
> >>>>>>>>>         > Do you think that the current text in
> >>>>>>>>>         >
> >>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-
> local-emer
> >>>>>>>>>gency-rph-nam
> >>>>>>>>>         > espace-00.txt reflects any of the
> >>>>above-described issues:
> >>>>>>>>>         > "
> >>>>>>>>>         >    The Security considerations that apply
> >to RFC 4412
> >>>>>>>>>[RFC4412]
> >>>>>>>>>apply
> >>>>>>>>>         >    here.  This document introduces no new security
> >>>>>>>>>issues relative
> >>>>>>>>>to
> >>>>>>>>>         >    RFC 4412.
> >>>>>>>>>         > "
> >>>>>>>>>         >
> >>>>>>>>>         > From various discussions in GEOPRIV I recall
> >>>>that you are
> >>>>>>>>>super-sensitive
> >>>>>>>>>         > regarding security and privacy. For some
> reasons you
> >>>>>>>don't seem to
> >>>>>>>>>have the
> >>>>>>>>>         > same concerns here. I would like to
> >>>>understand your reasoning.
> >>>>>>>>>         >
> >>>>>>>>>         > Please also do me another favor: Don't always say
> >>>>>>>that I don't
> >>>>>>>>>understand
> >>>>>>>>>         > the subject. Even if that would be the
> case it isn't
> >>>>>>>particular
> >>>>>>>>>fair given
> >>>>>>>>>         > that different folks had to educate you on other
> >>>>>>>topics in the
> >>>>>>>>>past as well.
> >>>>>>>>>         > Additionally, if you listen to the audio
> recordings
> >>>>>>>then you will
> >>>>>>>>>notice
> >>>>>>>>>         > that Henning, Ted, and Jon do not seem to
> understand
> >>>>>>>the issue
> >>>>>>>>>either as
> >>>>>>>>>         > they have raised similar issues during the
> >>>>F2F meetings.
> >>>>>>>>>         >
> >>>>>>>>>         > Ciao
> >>>>>>>>>         > Hannes
> >>>>>>>>>         >
> >>>>>>>>>         >
> >>>>>>>>>         > >Hannes - I believe it is you who do not
> understand
> >>>>>>>RFC 4412 --
> >>>>>>>>>         > >and many of us are trying to get that
> >>>>through to you, but you
> >>>>>>>>>         > >don't seem to want to listen/read.
> >>>>>>>>>         > >
> >>>>>>>>>         > >RFC 4412 is *for* priority marking SIP requests,
> >>>>>>>>>         > >
> >>>>>>>>>         > >One use is GETS.
> >>>>>>>>>         > >
> >>>>>>>>>         > >One use is MLPP.
> >>>>>>>>>         > >
> >>>>>>>>>         > >These examples are in RFC 4412 because there
> >>>>were specific
> >>>>>>>>>         > >namespaces being created for the IANA section of
> >>>>>>>that document.
> >>>>>>>>>         > >
> >>>>>>>>>         > >Reading the whole document, you will see
> >>>>that RPH can be
> >>>>>>>>>         > >specified for other uses than GETS or MLPP
> >>>>specifically.
> >>>>>>>>>         > >
> >>>>>>>>>         > >I knew when I wrote RFC 4412 that one day we
> >>>>would specify a
> >>>>>>>>>         > >namespace for ECRIT (the "esnet" namespace
> >>>>now) -- but I also
> >>>>>>>>>         > >knew it was premature for RFC 4412 to
> >>>>incorporate that
> >>>>>>>>>         > >namespace, that a future doc to RFC 4412
> >>>>would have to be
> >>>>>>>>>         > >written to do this. Brian and I talked about
> >>>>this at the
> >>>>>>>>>         > >original NENA meeting that created the
> IP WGs there
> >>>>>>>(in August
> >>>>>>>>>         > >of 03).  We both agreed we should wait
> until it was
> >>>>>>>>>         > >appropriate to the work in the IETF to
> >>>>submit this document
> >>>>>>>>>         > >that is now
> >>>>>>>>>         >
> >>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-l
> >ocal-emer
> >>>>>>>>>         > >gency-rph-namespace-00.txt
> >>>>>>>>>         > >
> >>>>>>>>>         > >Yet, you seem to want to use some additional
> >>>>mechanism to
> >>>>>>>>>         > >indicate priority of a call in SIP.  That
> >>>>means you want to
> >>>>>>>>>         > >introduce a second way to accomplish this in SIP.
> >>>>>>>>>Why do you
> >>>>>>>>>         > >want to promote a separate way to do
> something SIP
> >>>>>>>has already
> >>>>>>>>>         > >defined? That will cause interoperability
> >issues and
> >>>>>>>we both know
> >>>>>>>>>that.
> >>>>>>>>>         > >
> >>>>>>>>>         > >You've said to me (and others) that you
> >>>>believe RPH is just
> >>>>>>>>>         > >another way to accomplish what sos or a URI can
> >>>>>>>indicate - and
> >>>>>>>>>         > >you're wrong.  Your way would be
> >>>>_the_second_way_to_do_it,
> >>>>>>>>>         > >because SIP already considers RPH to be
> >>>>*the*way* to priority
> >>>>>>>>>         > >mark SIP requests.
> >>>>>>>>>         > >
> >>>>>>>>>         > >If you don't believe me (no comment), then
> >>>>why do you not
> >>>>>>>>>         > >believe the SIP WG chair (who knows more
> >>>>about SIP than both
> >>>>>>>>>         > >of us) - who, on this thread, has again said
> >>>>to you "RFC 4412
> >>>>>>>>>         > >(RPH) is the SIP mechanism to priority mark
> >>>>SIP requests"?
> >>>>>>>>>         > >
> >>>>>>>>>         > >Further, I believe it is inappropriate to
> >>>>prohibit endpoints
> >>>>>>>>>         > >from being able to set the esnet namespace.
> >>>>I absolutely
> >>>>>>>>>         > >believe it will not be needed most of the
> >>>>time, but I believe
> >>>>>>>>>         > >if someone does find a valid use for
> >>>>endpoints to mark
> >>>>>>>>>         > >priority in SIP, this ID - once it has
> >>>>become an RFC -- will
> >>>>>>>>>         > >have to be obsoleted with a new RFC saying
> >the exact
> >>>>>>>opposite.
> >>>>>>>>>         > >
> >>>>>>>>>         > >(color me confused ... over and over again)
> >>>>>>>>>         > >
> >>>>>>>>>         > >James
> >>>>>>>>>         > >
> >>>>>>>>>         > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >>>>>>>>>         > >>Keith, please understand that the usage
> >of RFC 4412
> >>>>>>>for GETS and
> >>>>>>>>>for
> >>>>>>>>>         > >>the type of emergency call we discuss here is
> >>>>>>>different. Just
> >>>>>>>>>looking
> >>>>>>>>>         > >>at the header and the name of the
> >namespace is a bit
> >>>>>>>>>         > >artificial. I hope
> >>>>>>>>>         > >>you understand that.
> >>>>>>>>>         > >>
> >>>>>>>>>         > >> >-----Original Message-----
> >>>>>>>>>         > >> >From: DRAGE, Keith (Keith)
> >>>>>>>>>[mailto:[email-masked]]
> >>>>>>>>>         > >> >Sent: 05 February, 2009 14:55
> >>>>>>>>>         > >> >To: Brian Rosen; 'Hannes Tschofenig';
> 'James M.
> >>>>>>>>>Polk'; 'Tschofenig,
> >>>>>>>>>         > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >>>>>>>>>         > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
> >>>>>>>>>Meeting: Agenda (my
> >>>>>>>>>
> >>>>>>>>>         > >> >mistake)
> >>>>>>>>>         > >> >
> >>>>>>>>>         > >> >Which is exactly what RFC 4412
> specifies for all
> >>>>>>>namespaces.
> >>>>>>>>>         > >> >
> >>>>>>>>>         > >> >regards
> >>>>>>>>>         > >> >
> >>>>>>>>>         > >> >Keith
> >>>>>>>>>         > >> >
> >>>>>>>>>         > >> >> -----Original Message-----
> >>>>>>>>>         > >> >> From: [email-masked]
> >>>>>>>[mailto:[email-masked]]
> >>>>>>>>>         > >> >On Behalf
> >>>>>>>>>         > >> >> Of Brian Rosen
> >>>>>>>>>         > >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >>>>>>>>>         > >> >> To: 'Hannes Tschofenig'; 'James M.
> >>>>Polk'; 'Tschofenig,
> >>>>>>>>>         > >Hannes (NSN
> >>>>>>>>>         > >> >> - FI/Espoo)'; 'ECRIT'
> >>>>>>>>>         > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >>>>>>>>>Meeting: Agenda (my
> >>>>>>>>>         > >> >> mistake)
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >> The value is that in some networks
> >>>>where priority for
> >>>>>>>>>         > >> >emergency calls
> >>>>>>>>>         > >> >> is appropriate, and appropriate
> >>>>policing of marking is
> >>>>>>>>>         > >implemented,
> >>>>>>>>>         > >> >> emergency calls will receive resource
> >priority.
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >> Not all networks would need policing.  Some
> >>>>>>>will.  Policing
> >>>>>>>>>could
> >>>>>>>>>         > >> >> be to Route header/R-URI content, but other
> >>>>>>>criteria are
> >>>>>>>>>possible.
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >> Not all networks will need resource priority
> >>>>>>>for emergency
> >>>>>>>>>calls.
> >>>>>>>>>         > >> >> Fine, ignore this marking/namespace.
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >> Brian
> >>>>>>>>>         > >> >> > -----Original Message-----
> >>>>>>>>>         > >> >> > From: Hannes Tschofenig
> >>>>>>>>>[mailto:[email-masked]]
> >>>>>>>>>         > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >>>>>>>>>         > >> >> > To: 'Brian Rosen'; 'James M. Polk';
> >>>>>>>Tschofenig, Hannes
> >>>>>>>>>(NSN -
> >>>>>>>>>         > >> >> > FI/Espoo); 'ECRIT'
> >>>>>>>>>         > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
> >>>>>>>>>Meeting: Agenda (my
> >>>>>>>>>         > >> >> > mistake)
> >>>>>>>>>         > >> >> >
> >>>>>>>>>         > >> >> > I don't even see the value in
> permitting the
> >>>>>>>endpoint todo
> >>>>>>>>>the
> >>>>>>>>>         > >> >> > RPH marking.
> >>>>>>>>>         > >> >> > In addition to the security concerns
> >>>>there is also the
> >>>>>>>>>         > >> >problem that
> >>>>>>>>>         > >> >> > there are more options to
> implement without
> >>>>>>>an additional
> >>>>>>>>>value.
> >>>>>>>>>         > >> >> >
> >>>>>>>>>         > >> >> > >-----Original Message-----
> >>>>>>>>>         > >> >> > >From: Brian Rosen
> >[mailto:[email-masked]]
> >>>>>>>>>         > >> >> > >Sent: 05 February, 2009 00:03
> >>>>>>>>>         > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
> >>>>>>>'Tschofenig,
> >>>>>>>>>         > >> >> Hannes (NSN -
> >>>>>>>>>         > >> >> > >FI/Espoo)'; 'ECRIT'
> >>>>>>>>>         > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual
> >>>>Interim Meeting:
> >>>>>>>>>Agenda (my
> >>>>>>>>>         > >> >> > mistake)
> >>>>>>>>>         > >> >> > >
> >>>>>>>>>         > >> >> > >Hannes
> >>>>>>>>>         > >> >> > >
> >>>>>>>>>         > >> >> > >This matches my understanding
> >>>>precisely.  We wish to
> >>>>>>>>>         > >> >> permit endpoints
> >>>>>>>>>         > >> >> > >to mark. We do not require it, and
> >>>>don't necessarily
> >>>>>>>>>expect it
> >>>>>>>>>         > >> >> > >in many (even
> >>>>>>>>>         > >> >> > >most) cases.  We don't wish to see the
> >>>>>>>document prohibit
> >>>>>>>>>it.
> >>>>>>>>>         > >> >> > >We all seem to agree it has value
> >within the
> >>>>>>>Emergency
> >>>>>>>>>         > >> >Services IP
> >>>>>>>>>         > >> >> > >Networks.
> >>>>>>>>>         > >> >> > >
> >>>>>>>>>         > >> >> > >Brian
> >>>>>>>>>         > >> >> > >
> >>>>>>>>>         > >> >> > >> -----Original Message-----
> >>>>>>>>>         > >> >> > >> From: [email-masked]
> >>>>>>>>>[mailto:[email-masked]]
> >>>>>>>>>         > >> >> > >On Behalf
> >>>>>>>>>         > >> >> > >> Of James M. Polk
> >>>>>>>>>         > >> >> > >> Sent: Wednesday, February 04,
> >2009 4:01 PM
> >>>>>>>>>         > >> >> > >> To: Hannes Tschofenig; Tschofenig,
> >>>>Hannes (NSN -
> >>>>>>>>>         > >> >> FI/Espoo); 'ECRIT'
> >>>>>>>>>         > >> >> > >> Subject: Re: [Ecrit] ECRIT
> >Virtual Interim
> >>>>>>>>>Meeting:
> >>>>>>>>>         > >Agenda (my
> >>>>>>>>>         > >> >> > >> mistake)
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> At 02:37 PM 2/4/2009, Hannes
> >>>>Tschofenig wrote:
> >>>>>>>>>         > >> >> > >> > > James wrote:
> >>>>>>>>>         > >> >> > >> > >> you are the _lone_ voice not
> >>>>>>>supporting this ID,
> >>>>>>>>>         > >> >> > >> >
> >>>>>>>>>         > >> >> > >> >Listening to the audio
> recording of past
> >>>>>>>meetings I
> >>>>>>>>>have to
> >>>>>>>>>         > >> >> > >say that
> >>>>>>>>>         > >> >> > >> >I
> >>>>>>>>>         > >> >> > >> was
> >>>>>>>>>         > >> >> > >> >not the only persons raising
> >>>>concerns about the
> >>>>>>>>>document.
> >>>>>>>>>         > >> >> > >> >That was probably the reason why you
> >>>>>>>agreed to limit
> >>>>>>>>>the
> >>>>>>>>>         > >> >> > >scope of the
> >>>>>>>>>         > >> >> > >> >document (which you didn't
> later do) to
> >>>>>>>get folks to
> >>>>>>>>>agree
> >>>>>>>>>         > >> >> > >to make it
> >>>>>>>>>         > >> >> > >> a WG
> >>>>>>>>>         > >> >> > >> >item.
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> re-listen to the audio please
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> Ted's concerns were consistent
> with most
> >>>>>>>>>(all?) other
> >>>>>>>>>         > >> >> concerns --
> >>>>>>>>>         > >> >> > >> which were based on the premise
> >of whether
> >>>>>>>or not the
> >>>>>>>>>         > >> >> UAC should be
> >>>>>>>>>         > >> >> > >> trusted to initiate the marking on the
> >>>>>>>INVITE.  The
> >>>>>>>>>most
> >>>>>>>>>         > >> >> > >> recent version has backed off this
> >>>>to a "can" --
> >>>>>>>>>meaning not
> >>>>>>>>>         > >> >prohibited
> >>>>>>>>>         > >> >> > >> (i.e., no 2119 text).  I also
> backed off
> >>>>>>>the text in
> >>>>>>>>>the
> >>>>>>>>>         > >> >> SP domain
> >>>>>>>>>         > >> >> > >> part to "can", such that there is
> >>>>no 2119 text
> >>>>>>>>>         > >> >mandating or even
> >>>>>>>>>         > >> >> > >> recommending its usage there. I also do
> >>>>>>>not prohibit
> >>>>>>>>>its
> >>>>>>>>>         > >> >> > >use, based on
> >>>>>>>>>         > >> >> > >> local policy.  Keith has come
> >forward with
> >>>>>>>the specific
> >>>>>>>>>
> >>>>>>>>>         > >> >> > >> request that non-ESInet networks be
> >>>>>>>allowed to mark and
> >>>>>>>>>pay
> >>>>>>>>>         > >> >attention to
> >>>>>>>>>         > >> >> > >> this priority indication -- with IMS as
> >>>>>>>the specific
> >>>>>>>>>example
> >>>>>>>>>         > >> >> > >> he wishes to have this valid for.
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> Where there is no
> disagreement, save for
> >>>>>>>your recent
> >>>>>>>>>         > >> >> > >pushback - is in
> >>>>>>>>>         > >> >> > >> the ESInet, which is where Brian
> >>>>has requested it's
> >>>>>>>>>         > >> >> > >definition in the
> >>>>>>>>>         > >> >> > >> IETF on behalf of NENA.  He's the i3 WG
> >>>>>>>chair within
> >>>>>>>>>         > >> >> NENA, and if
> >>>>>>>>>         > >> >> > >> he asks for it, are you going
> to say you
> >>>>>>>know better
> >>>>>>>>>than he?
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> >Btw, I not disagreeing with
> the document
> >>>>>>>as such. I
> >>>>>>>>>         > >> >just want to
> >>>>>>>>>         > >> >> > the
> >>>>>>>>>         > >> >> > >> scope
> >>>>>>>>>         > >> >> > >> >to change. The usage of RPH
> >>>>within the emergency
> >>>>>>>>>         > >> >> services network
> >>>>>>>>>         > >> >> > is
> >>>>>>>>>         > >> >> > >> fine
> >>>>>>>>>         > >> >> > >> >for me. I may get convinced
> to start the
> >>>>>>>RPH marking
> >>>>>>>>>from
> >>>>>>>>>         > >> >> > >the the VSP
> >>>>>>>>>         > >> >> > >> >towards the PSAP. I feel uneasy
> >about the
> >>>>>>>end host
> >>>>>>>>>doing
> >>>>>>>>>         > >> >> > >the marking.
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> please read what I wrote
> above, and then
> >>>>>>>re-read the
> >>>>>>>>>         > >> >most recent
> >>>>>>>>>         > >> >> > >> version of the ID. I don't
> have endpoints
> >>>>>>>that SHOULD
> >>>>>>>>>or
> >>>>>>>>>         > >> >> MUST mark
> >>>>>>>>>         > >> >> > >> anything wrt RPH.  I also don't want to
> >>>>>>>prohibit it,
> >>>>>>>>>         > >> >> because there
> >>>>>>>>>         > >> >> > >> might be cases (that I don't know
> >>>>of) of valid uses
> >>>>>>>>>         > >> >> under certain
> >>>>>>>>>         > >> >> > >> circumstances.  Figure 1 is very clear
> >>>>>>>that there are 3
> >>>>>>>>>         > >> >> networking
> >>>>>>>>>         > >> >> > >> parts to consider
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> #1 - from the endpoint
> >>>>>>>>>         > >> >> > >> #2 - within the VSP
> >>>>>>>>>         > >> >> > >> #3 - within the ESInet
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> the most recent ID version has
> "can" for
> >>>>>>>#s 1 and 2,
> >>>>>>>>>and
> >>>>>>>>>         > >> >> > >2119 language
> >>>>>>>>>         > >> >> > >> offering those supporting this
> >>>>>>>specification will have
> >>>>>>>>>RPH
> >>>>>>>>>         > >> >> > >> adherence within #3 (the ESInet).
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> What other scope changes do you want,
> >>>>>>>because I haven't
> >>>>>>>>>         > >> >> heard them.
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> I only heard you claim in email
> >during the
> >>>>>>>last IETF
> >>>>>>>>>and in
> >>>>>>>>>         > >> >> > >the ECRIT
> >>>>>>>>>         > >> >> > >> session that RPH should not be
> >>>>used for priority
> >>>>>>>>>marking
> >>>>>>>>>         > >> >> requests.
> >>>>>>>>>         > >> >> > >> This is something Keith (SIP WG
> >>>>chair) voiced his
> >>>>>>>>>opposition
> >>>>>>>>>         > >> >> > >> to your views regarding
> creating a second
> >>>>>>>means for SIP
> >>>>>>>>>to
> >>>>>>>>>         > >> >priority
> >>>>>>>>>         > >> >> > >> mark request "when SIP already has one
> >>>>>>>interoperable
> >>>>>>>>>way to
> >>>>>>>>>         > >> >> > >> accomplish this... it's call the
> >RP header
> >>>>>>>mechanism".
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >> >I don't see advantages -- only
> >>>>disadvantages.
> >>>>>>>>>         > >> >> > >> >
> >>>>>>>>>         > >> >> > >> >Ciao
> >>>>>>>>>         > >> >> > >> >Hannes
> >>>>>>>>>         > >> >> > >>
> >>>>>>>>>         > >> >> > >>
> >>>>_______________________________________________
> >>>>>>>>>         > >> >> > >> Ecrit mailing list
> >>>>>>>>>         > >> >> > >> [email-masked]
> >>>>>>>>>         > >> >> > >>
> >https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>>         > >> >> > >
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >>
> >_______________________________________________
> >>>>>>>>>         > >> >> Ecrit mailing list
> >>>>>>>>>         > >> >> [email-masked]
> >>>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >
> >>>>>>>>>         > >
> >>>>>>>>>         >
> >>>>>>>>>         > _______________________________________________
> >>>>>>>>>         > Ecrit mailing list
> >>>>>>>>>         > [email-masked]
> >>>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>_______________________________________________
> >>>>>>>>>Ecrit mailing list
> >>>>>>>>>[email-masked]
> >>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>
> >>>>>>>>_______________________________________________
> >>>>>>>>Ecrit mailing list
> >>>>>>>>[email-masked]
> >>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>
> >>>>>>_______________________________________________
> >>>>>>Ecrit mailing list
> >>>>>>[email-masked]
> >>>>>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>
> >>>_______________________________________________
> >>>Ecrit mailing list
> >>>[email-masked]
> >>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>
> >>>
> >>>-------------------------------------------------------------
> >-----------------------------------
> >>>This message is for the designated recipient only and may contain
> >>>privileged, proprietary, or otherwise private information.
> >>>If you have received it in error, please notify the sender
> >>>immediately and delete the original.  Any unauthorized use of this
> >>>email is prohibited.
> >>>-------------------------------------------------------------
> >-----------------------------------
> >>>[mf2]
> >>>
> >>
> >>_______________________________________________
> >>Ecrit mailing list
> >>[email-masked]
> >>https://www.ietf.org/mailman/listinfo/ecrit
> >
> >_______________________________________________
> >Ecrit mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/ecrit
> >_______________________________________________
> >Ecrit mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/ecrit
> >
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "'James M. Polk'" <[email-masked]>
Date: Sat, 7 Feb 2009 01:47:57 +0100
Accept-Language: en-US
acceptlanguage: en-US
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)

I don't believe anyone has been saying that. GETS and emergency are two dif=
ferent namespaces that work within the overvall framework of RPH.

You implement RPH, and then configure or tailor it to the namespaces you ne=
ed to support, not provide a separate implementation for every namespace yo=
u are called upon to support.

Go that way and every request will take hours to traverse end to end.

regards

Keith

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Friday, February 06, 2009 10:47 PM
> To: 'James M. Polk'
> Cc: DRAGE, Keith (Keith); 'Brian Rosen'; Tschofenig, Hannes
> (NSN - FI/Espoo); 'ECRIT'
> Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
>
> Good that you agree that GETS usage of RPH and the one we
> discuss in ECRIT is different.
> So far, some folks have been saying "what works for GETS
> works for the ECRIT case as well".
>
> I argued that the environment is different and hence just
> referencing RFC
> 4412 isn't good enough.
>
> >-----Original Message-----
> >From: James M. Polk [mailto:[email-masked]]
> >Sent: 07 February, 2009 00:02
> >To: Hannes Tschofenig
> >Cc: 'DRAGE, Keith (Keith)'; 'Brian Rosen'; Tschofenig, Hannes (NSN -
> >FI/Espoo); 'ECRIT'
> >Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
> >
> >At 03:21 AM 2/6/2009, Hannes Tschofenig wrote:
> >>Hi James,
> >>
> >>I have read RFC 4412 and also the GETS/MLPP IETF documents. What I
> >>would like to point out is that there is more than just a
> header and
> >>values within the header that have to be considered in order
> >to make a
> >>judgement of what is appropriate and what isn't. There is an
> >>architectural question and whether the environment we are using the
> >>stuff is indeed providing the properties you need for the
> >solution to be appropriate.
> >>
> >>Let me describe in more detail what I meant (and please
> >correct me if I
> >>am wrong).
> >>
> >>Getting priority for SIP requests when using a GETS alike scenario
> >>means that the entity that issues the request is specially
> authorized
> >>since otherwise you introduce a nice denial of service attack.
> >
> >You are missing a step in GETS here.  The endpoint, who
> sends the GETS
> >set-up as an INVITE is not already authorized (not the
> device, not the
> >user).  In North America, there is a 10 digit GETS number that is
> >dialed (that I won't give out right now on an open list) - and there
> >literally is only 1 number available to dial for this service.
> >Literally anyone can dial this number today in North America
> (no matter
> >where the phone is - as long as it is in North America --
> and I might
> >be too limiting in that it is dialable from anywhere, because it is
> >going to a North American destination).
> >
> >Once this number is dialed, it is answered by an authentication and
> >authorization IVR.  This IVR challenges each caller for their
> >authentication passcode, and a password). Once this has been
> >successfully entered, then call is NOW authorized to proceed towards
> >its destination number - this step is only known to the authorizing
> >system because the destination 10 digit number is NOT entered until
> >after the authentication and authorization step has completed.
> >
> >The authorized caller is prompted with a new dial tone - in
> which they
> >can enter any number on the planet and receive preferential
> treatment
> >through as many carriers (in IP, it's
> >SPs) that have implemented this GETS service (which is an
> SLA with the
> >Department of Homeland Security now).
> >
> >Merely entering the GETS RP namespace is never intended,
> alone, to gain
> >any preferential treatment -- other than towards this
> authentication &
> >authorization IVR.
> >
> >I hope you can see that this is a completely separate type
> of service
> >and implementation type than ECRIT based emergency calling will use.
> >
> >BTW - to your comment below about me not calling your name
> out when you
> >are incorrect because I have been equally incorrect
> >-- I'm not sure I've been spared as much as you think, given
> that many
> >have called me out by name when they've felt I've been wrong
> over the
> >years.
> >
> >>This authorization
> >>is tied to the entity that makes the request. For example,
> the person
> >>is working for the government and has special rights. James
> Bond as a
> >>(not so) secret agent might have these rights.
> >>
> >>The emergency services case (citizen-to-authority) is a bit
> different
> >>as there aren't really special rights with respect to authorization
> >>tied to individuals. Instead, the fact that something is an
> emergency
> >>is purely a judgement of the human that dials a special
> >number. To deal
> >>with fraud, we discussed in the group on what we can actually do to
> >>ensure that end users do not bypass security procedures (such as
> >>authorization checks, charging and so on). Part of this
> investigation
> >>was the publication of http://www.ietf.org/rfc/rfc5069.txt
> >that also describes this issue.
> >>
> >>So, imagine the implementation of a SIP proxy (and we
> implemented that
> >>stuff) that receives a call that contains a Service URN. The code
> >>branches into a special mode where everything is done so that
> >the call
> >>receives appropriate treatment and does not get dropped on
> the floor.
> >>The way how the Service URN is placed in the message
> ensures that the
> >>call cannot go to my friend (instead of the PSAP) unless
> the end host
> >>ran LoST already. In the latter case, we discussed this also on the
> >>list for a while and Richard even wrote a draft about it in
> >the context
> >>of the location hiding topic, we said that the proxy would
> >have to run
> >>LoST if he cares about a potential fraudulent usage.
> >>
> >>So, what do we need todo in order to provide secure RFC 4412
> >>functionality in our context?
> >>
> >>Do you think that the current text in
> >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-eme
> >rgency-rp
> >>h-nam espace-00.txt reflects any of the above-described issues:
> >>"
> >>    The Security considerations that apply to RFC 4412
> [RFC4412] apply
> >>    here.  This document introduces no new security issues
> relative to
> >>    RFC 4412.
> >>"
> >>
> >> From various discussions in GEOPRIV I recall that you are
> >>super-sensitive regarding security and privacy. For some
> reasons you
> >>don't seem to have the same concerns here. I would like to
> >understand your reasoning.
> >>
> >>Please also do me another favor: Don't always say that I don't
> >>understand the subject. Even if that would be the case it isn't
> >>particular fair given that different folks had to educate you
> >on other topics in the past as well.
> >>Additionally, if you listen to the audio recordings then you will
> >>notice that Henning, Ted, and Jon do not seem to understand
> the issue
> >>either as they have raised similar issues during the F2F meetings.
> >>
> >>Ciao
> >>Hannes
> >>
> >>
> >> >Hannes - I believe it is you who do not understand RFC
> 4412 -- and
> >> >many of us are trying to get that through to you, but you
> >don't seem
> >> >to want to listen/read.
> >> >
> >> >RFC 4412 is *for* priority marking SIP requests,
> >> >
> >> >One use is GETS.
> >> >
> >> >One use is MLPP.
> >> >
> >> >These examples are in RFC 4412 because there were specific
> >namespaces
> >> >being created for the IANA section of that document.
> >> >
> >> >Reading the whole document, you will see that RPH can be
> specified
> >> >for other uses than GETS or MLPP specifically.
> >> >
> >> >I knew when I wrote RFC 4412 that one day we would specify a
> >> >namespace for ECRIT (the "esnet" namespace now) -- but I
> >also knew it
> >> >was premature for RFC 4412 to incorporate that namespace, that a
> >> >future doc to RFC 4412 would have to be written to do this.
> >Brian and
> >> >I talked about this at the original NENA meeting that
> >created the IP
> >> >WGs there (in August of 03).  We both agreed we should wait
> >until it
> >> >was appropriate to the work in the IETF to submit this
> >document that
> >> >is now
> >> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >> >gency-rph-namespace-00.txt
> >> >
> >> >Yet, you seem to want to use some additional mechanism to
> indicate
> >> >priority of a call in SIP.  That means you want to
> >introduce a second
> >> >way to accomplish this in SIP.  Why do you want to promote
> >a separate
> >> >way to do something SIP has already defined? That will cause
> >> >interoperability issues and we both know that.
> >> >
> >> >You've said to me (and others) that you believe RPH is
> just another
> >> >way to accomplish what sos or a URI can indicate - and
> >you're wrong.
> >> >Your way would be _the_second_way_to_do_it, because SIP already
> >> >considers RPH to be *the*way* to priority mark SIP requests.
> >> >
> >> >If you don't believe me (no comment), then why do you not
> >believe the
> >> >SIP WG chair (who knows more about SIP than both of us) - who, on
> >> >this thread, has again said to you "RFC 4412
> >> >(RPH) is the SIP mechanism to priority mark SIP requests"?
> >> >
> >> >Further, I believe it is inappropriate to prohibit endpoints from
> >> >being able to set the esnet namespace.  I absolutely
> >believe it will
> >> >not be needed most of the time, but I believe if someone
> >does find a
> >> >valid use for endpoints to mark priority in SIP, this ID
> - once it
> >> >has become an RFC -- will have to be obsoleted with a new
> >RFC saying
> >> >the exact opposite.
> >> >
> >> >(color me confused ... over and over again)
> >> >
> >> >James
> >> >
> >> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >> >>Keith, please understand that the usage of RFC 4412 for
> >GETS and for
> >> >>the type of emergency call we discuss here is different. Just
> >> >>looking at the header and the name of the namespace is a bit
> >> >artificial. I hope
> >> >>you understand that.
> >> >>
> >> >> >-----Original Message-----
> >> >> >From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> >> >> >Sent: 05 February, 2009 14:55
> >> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk';
> >> >> >'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >> >mistake)
> >> >> >
> >> >> >Which is exactly what RFC 4412 specifies for all namespaces.
> >> >> >
> >> >> >regards
> >> >> >
> >> >> >Keith
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> From: [email-masked] [mailto:[email-masked]]
> >> >> >On Behalf
> >> >> >> Of Brian Rosen
> >> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
> >> >Hannes (NSN
> >> >> >> - FI/Espoo)'; 'ECRIT'
> >> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
> Agenda (my
> >> >> >> mistake)
> >> >> >>
> >> >> >> The value is that in some networks where priority for
> >> >> >emergency calls
> >> >> >> is appropriate, and appropriate policing of marking is
> >> >implemented,
> >> >> >> emergency calls will receive resource priority.
> >> >> >>
> >> >> >> Not all networks would need policing.  Some will.  Policing
> >> >> >> could be to Route header/R-URI content, but other
> >criteria are possible.
> >> >> >>
> >> >> >> Not all networks will need resource priority for
> >emergency calls.
> >> >> >> Fine, ignore this marking/namespace.
> >> >> >>
> >> >> >> Brian
> >> >> >> > -----Original Message-----
> >> >> >> > From: Hannes Tschofenig [mailto:[email-masked]]
> >> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >> >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig,
> >Hannes (NSN -
> >> >> >> > FI/Espoo); 'ECRIT'
> >> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting:
> >Agenda (my
> >> >> >> > mistake)
> >> >> >> >
> >> >> >> > I don't even see the value in permitting the
> >endpoint todo the
> >> >> >> > RPH marking.
> >> >> >> > In addition to the security concerns there is also the
> >> >> >problem that
> >> >> >> > there are more options to implement without an
> >additional value.
> >> >> >> >
> >> >> >> > >-----Original Message-----
> >> >> >> > >From: Brian Rosen [mailto:[email-masked]]
> >> >> >> > >Sent: 05 February, 2009 00:03
> >> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,
> >> >> >> Hannes (NSN -
> >> >> >> > >FI/Espoo)'; 'ECRIT'
> >> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim
> Meeting: Agenda
> >> >> >> > >(my
> >> >> >> > mistake)
> >> >> >> > >
> >> >> >> > >Hannes
> >> >> >> > >
> >> >> >> > >This matches my understanding precisely.  We wish to
> >> >> >> permit endpoints
> >> >> >> > >to mark. We do not require it, and don't
> necessarily expect
> >> >> >> > >it in many (even
> >> >> >> > >most) cases.  We don't wish to see the document
> prohibit it.
> >> >> >> > >We all seem to agree it has value within the Emergency
> >> >> >Services IP
> >> >> >> > >Networks.
> >> >> >> > >
> >> >> >> > >Brian
> >> >> >> > >
> >> >> >> > >> -----Original Message-----
> >> >> >> > >> From: [email-masked]
> >> >> >> > >> [mailto:[email-masked]]
> >> >> >> > >On Behalf
> >> >> >> > >> Of James M. Polk
> >> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> >> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
> >> >> >> FI/Espoo); 'ECRIT'
> >> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
> >> >Agenda (my
> >> >> >> > >> mistake)
> >> >> >> > >>
> >> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> >> >> >> > >> > > James wrote:
> >> >> >> > >> > >> you are the _lone_ voice not supporting this ID,
> >> >> >> > >> >
> >> >> >> > >> >Listening to the audio recording of past
> meetings I have
> >> >> >> > >> >to
> >> >> >> > >say that
> >> >> >> > >> >I
> >> >> >> > >> was
> >> >> >> > >> >not the only persons raising concerns about
> the document.
> >> >> >> > >> >That was probably the reason why you agreed to
> limit the
> >> >> >> > >scope of the
> >> >> >> > >> >document (which you didn't later do) to get
> >folks to agree
> >> >> >> > >to make it
> >> >> >> > >> a WG
> >> >> >> > >> >item.
> >> >> >> > >>
> >> >> >> > >> re-listen to the audio please
> >> >> >> > >>
> >> >> >> > >> Ted's concerns were consistent with most (all?) other
> >> >> >> concerns --
> >> >> >> > >> which were based on the premise of whether or not the
> >> >> >> UAC should be
> >> >> >> > >> trusted to initiate the marking on the INVITE.
> The most
> >> >> >> > >> recent version has backed off this to a "can"
> -- meaning
> >> >> >> > >> not
> >> >> >prohibited
> >> >> >> > >> (i.e., no 2119 text).  I also backed off the text in the
> >> >> >> SP domain
> >> >> >> > >> part to "can", such that there is no 2119 text
> >> >> >mandating or even
> >> >> >> > >> recommending its usage there. I also do not prohibit its
> >> >> >> > >use, based on
> >> >> >> > >> local policy.  Keith has come forward with the specific
> >> >> >> > >> request that non-ESInet networks be allowed to
> >mark and pay
> >> >> >attention to
> >> >> >> > >> this priority indication -- with IMS as the specific
> >> >> >> > >> example he wishes to have this valid for.
> >> >> >> > >>
> >> >> >> > >> Where there is no disagreement, save for your recent
> >> >> >> > >pushback - is in
> >> >> >> > >> the ESInet, which is where Brian has requested it's
> >> >> >> > >definition in the
> >> >> >> > >> IETF on behalf of NENA.  He's the i3 WG chair within
> >> >> >> NENA, and if
> >> >> >> > >> he asks for it, are you going to say you know
> >better than he?
> >> >> >> > >>
> >> >> >> > >>
> >> >> >> > >> >Btw, I not disagreeing with the document as such. I
> >> >> >just want to
> >> >> >> > the
> >> >> >> > >> scope
> >> >> >> > >> >to change. The usage of RPH within the emergency
> >> >> >> services network
> >> >> >> > is
> >> >> >> > >> fine
> >> >> >> > >> >for me. I may get convinced to start the RPH
> marking from
> >> >> >> > >the the VSP
> >> >> >> > >> >towards the PSAP. I feel uneasy about the end
> host doing
> >> >> >> > >the marking.
> >> >> >> > >>
> >> >> >> > >> please read what I wrote above, and then re-read the
> >> >> >most recent
> >> >> >> > >> version of the ID. I don't have endpoints that SHOULD or
> >> >> >> MUST mark
> >> >> >> > >> anything wrt RPH.  I also don't want to prohibit it,
> >> >> >> because there
> >> >> >> > >> might be cases (that I don't know of) of valid uses
> >> >> >> under certain
> >> >> >> > >> circumstances.  Figure 1 is very clear that there are 3
> >> >> >> networking
> >> >> >> > >> parts to consider
> >> >> >> > >>
> >> >> >> > >> #1 - from the endpoint
> >> >> >> > >> #2 - within the VSP
> >> >> >> > >> #3 - within the ESInet
> >> >> >> > >>
> >> >> >> > >> the most recent ID version has "can" for #s 1 and 2, and
> >> >> >> > >2119 language
> >> >> >> > >> offering those supporting this specification will
> >have RPH
> >> >> >> > >> adherence within #3 (the ESInet).
> >> >> >> > >>
> >> >> >> > >> What other scope changes do you want, because I haven't
> >> >> >> heard them.
> >> >> >> > >>
> >> >> >> > >> I only heard you claim in email during the last
> >IETF and in
> >> >> >> > >the ECRIT
> >> >> >> > >> session that RPH should not be used for priority marking
> >> >> >> requests.
> >> >> >> > >> This is something Keith (SIP WG chair) voiced his
> >> >> >> > >> opposition to your views regarding creating a
> >second means
> >> >> >> > >> for SIP to
> >> >> >priority
> >> >> >> > >> mark request "when SIP already has one
> >interoperable way to
> >> >> >> > >> accomplish this... it's call the RP header mechanism".
> >> >> >> > >>
> >> >> >> > >> >I don't see advantages -- only disadvantages.
> >> >> >> > >> >
> >> >> >> > >> >Ciao
> >> >> >> > >> >Hannes
> >> >> >> > >>
> >> >> >> > >> _______________________________________________
> >> >> >> > >> Ecrit mailing list
> >> >> >> > >> [email-masked]
> >> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >> > >
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> Ecrit mailing list
> >> >> >> [email-masked]
> >> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >>
> >> >> >
> >> >
> >
>
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sat, 7 Feb 2009 10:12:40 +0200
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] RPH

Security policies are an important part. 

If a VSP does not trust the UA regarding the marking of the ECRIT RPH then
it gets ignored. 
If a VSP trusts it then it is irrelevant as my pseudo code example shows. 

Not a particular useful mechanism, I would argue. 

I understand the excitement for RPH but the case for RPH usage in ECRIT is a
bit different since we already have ways to different an emergency call from
a regular call. 

>-----Original Message-----
>From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
>Sent: 07 February, 2009 01:39
>To: [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: [Ecrit] RPH
>
>Wrong, everything is based on security policies
>
>----- Original Message -----
>From: Hannes Tschofenig <[email-masked]>
>To: DOLLY, MARTIN C, ATTLABS; [email-masked] 
><[email-masked]>; [email-masked] <[email-masked]>; 
>[email-masked] <[email-masked]>
>Cc: Tschofenig, Hannes (NSN - FI/Espoo) 
><[email-masked]>; [email-masked] <[email-masked]>
>Sent: Fri Feb 06 17:52:07 2009
>Subject: RE: [Ecrit] RPH
>
>Hi Martin, 
>
>I am arguing that if the UE does mark the call with the ECRIT 
>RPH (I call it that way to differentiate it from RFC 4412 RPH 
>usage, which is very
>different) then it should be ignored. 
>Processing it will not help in any way (as I described in my 
>pseudo code snippet). Incorrectly processing it (which is a 
>possibility when the implementer does not understand the 
>security implications -- they will not get it from the current 
>version of the draft) will lead to security problems (fraud & 
>DoS potential). 
>
>While you cannot prevent someone from sending you, there is 
>certainly the chance to document what the receiver should do with it.
>
>Ciao
>Hannes 
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>>Of DOLLY, MARTIN C, ATTLABS
>>Sent: 07 February, 2009 00:15
>>To: [email-masked]; [email-masked]; 
>>[email-masked]
>>Cc: [email-masked]; [email-masked]
>>Subject: Re: [Ecrit] RPH
>>
>>You can not disallow this from an UE. The trust relationship will 
>>dictate whether it is accepted or not
>>
>>----- Original Message -----
>>From: [email-masked] <[email-masked]>
>>To: Henning Schulzrinne <[email-masked]>; Winterbottom, James 
>><[email-masked]>
>>Cc: Tschofenig, Hannes (NSN - FI/Espoo) <[email-masked]>; 
>>ECRIT <[email-masked]>
>>Sent: Fri Feb 06 17:10:08 2009
>>Subject: Re: [Ecrit] RPH
>>
>>At 03:05 PM 2/6/2009, Henning Schulzrinne wrote:
>>>There's another problem with the "it doesn't hurt argument". 
>>Assume for
>>>a moment we have a "UA MAY include RPH" wording. There are now two
>>>cases:
>>>
>>>(1) All UAs implement it.
>>>
>>>(2) Only some UAs implement it.
>>>
>>>(1) seems unlikely for a MAY. If (2) occurs, we have the
>>choice between
>>>two undesirable outcomes:
>>>
>>>(a) some UAs that are otherwise compliant get worse service just 
>>>because they didn't include the RPH;
>>
>>am I reading this correctly - that unless all UAs implement this 
>>capability this should never be implemented by any UAs?
>>
>>This flies in the face of vendors solving for their customer's 
>>requirements.
>>
>>I will admit that at this time, I know of no Cisco customers 
>that want 
>>this capability, so I'm not angling for any of our revenue here.  I'm 
>>saying that I think I hear you saying this ID should say 
>something like
>>
>>         UAs are prevented from implementing the RP namespace esnet
>>
>>I'm fighting against that, because customers are always 
>coming to every 
>>vendor with new requirements, some of them unique at the time.  This 
>>prevention text would prevent a vendor from complying with this 
>>specification and still meet the customer's needs.
>>
>>I believe that this ID needs to retain the endpoints MAY 
>insert esnet, 
>>and have appropriate security considerations text that highlights the 
>>concerns expressed here.
>>
>>Some future ID can then update this current RFC (to-be) within the
>>2119 rules of the use of MAY here.
>>
>>
>>>OR
>>>
>>>(b) the proxy has to look for the service URN to give the call the 
>>>appropriate treatment, thus obviating any advantage of having the 
>>>header, yet incurring more complicated processing logic.
>>>
>>>
>>>I have no objection to whatever markings people want to 
>apply to calls 
>>>within an ESN - that's largely a private matter.
>>>
>>>Henning
>>>
>>>On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote:
>>>
>>>>Hi All,
>>>>
>>>>I have followed thi thread with some interest and I 
>struggling to see 
>>>>a use case for the providing RPH for emergency calls from the 
>>>>end-point.
>>>>
>>>>The reference-model call in ECRIT, for better or worse, is for all 
>>>>calls to go back through a home-VSP.
>>>>We placed quite a lot of emphasis, largely for traffing 
>reasons, for 
>>>>the VSP to be able to verify that a call is in fact an emergency 
>>>>call. This is done by the proxy taking the inband location, doing a 
>>>>LoST query with the provided URN, and verifying that the resulting 
>>>>destination URI is the same as the destination URI provide 
>in the SIP 
>>>>INVITE. My understanding was that VSPs would always do this 
>check so 
>>>>they could tell if they could bill for the call or not, and because 
>>>>the VSP can be use that the call is an emergency call it can apply 
>>>>any special priorities that may be applicable. This 
>obviates the need 
>>>>for RPH from the end-point to the network.
>>>>
>>>>This leaves us with the argument of "it doesn't hurt to 
>it", which is 
>>>>not a good reason to write a specification.
>>>>It was intimated on the geopriv mailing list last year that great 
>>>>pains had been taken to keep SIP with in the MTU limits of UDP over 
>>>>Ethernet
>>>>(http://www.ietf.org/mail-archive/web/geopriv/current/msg0612
>>0.html ). Assuming
>>>>that this is the case, perhaps there is harm in including 
>information 
>>>>that we know will be ignored.
>>>>
>>>>Cheers
>>>>James
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: [email-masked] on behalf of Hannes Tschofenig
>>>>Sent: Fri 2/6/2009 12:33 PM
>>>>To: 'Brian Rosen'; 'Henning Schulzrinne'
>>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
>>>>Subject: Re: [Ecrit] RPH
>>>>
>>>>To the story short here is the code for the proxy:
>>>>
>>>>---------------------
>>>>
>>>>IF emergency call was recognized THEN
>>>>    execute emergency call specific procedures (priority queuing, 
>>>>preemption, fetch location, determine routing, do funny QoS things &
>>>>co)
>>>>ELSE
>>>>    normal call handling procedures.
>>>>
>>>>---------------------
>>>>
>>>>If you can make this differentiation between an emergency 
>call and a 
>>>>regular call then you can also do everything that is necessary for 
>>>>emergency call handling.
>>>>
>>>>Brian + Keith: Please tell me that we cannot do the above with our 
>>>>currently specified mechanisms.
>>>>
>>>>Ciao
>>>>Hannes
>>>>
>>>>>-----Original Message-----
>>>>>From: Brian Rosen [mailto:[email-masked]]
>>>>>Sent: 06 February, 2009 17:49
>>>>>To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
>>>>>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
>>>>>Subject: RE: [Ecrit] RPH
>>>>>
>>>>>I agree that not all networks will permit (or pay attention
>>>>>to) a priority request from an end device.
>>>>>
>>>>>No one has asked for that.
>>>>>
>>>>>The namespace request has several uses, one of which is within an 
>>>>>emergency services IP network, one of which is between elements 
>>>>>within a public network controlled by the operator, and 
>one of which 
>>>>>is an endpoint request for resource priority.
>>>>>
>>>>>Those of us requesting this work proceed are happy if the endpoint 
>>>>>part is simply left as possible (MAY), and, speaking for myself, 
>>>>>having the draft discuss the security implications of endpoint 
>>>>>marking is reasonable.
>>>>>
>>>>>Having discussed this issue with an implementation team who worked 
>>>>>on MLPP systems, I am confident I know what I'm talking about, but 
>>>>>YMMV.  The fact that you could, if you wanted to, give resource 
>>>>>priority to a call you decided, however you decided, was an 
>>>>>emergency call is an implementation decision, and not subject to 
>>>>>standardization.
>>>>>
>>>>>RPH is the IETF standard way for one entity to request resource 
>>>>>priority of another entity in a SIP system.  We're asking for a 
>>>>>namespace to use that within the domain of emergency calls.  That 
>>>>>is, I think, a VERY reasonable request.
>>>>>
>>>>>Brian
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Henning Schulzrinne [mailto:[email-masked]]
>>>>>>Sent: Friday, February 06, 2009 10:33 AM
>>>>>>To: Hannes Tschofenig
>>>>>>Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>>>>>>Subject: Re: [Ecrit] RPH
>>>>>>
>>>>>>To chime in here:
>>>>>>
>>>>>>I don't think it's productive to simply state that 4412
>>>>>doesn't worry
>>>>>>about authorization, so we shouldn't either (simplifying a bit).
>>>>>>Authorization was discussed repeatedly, and the general
>>>>>assumption was
>>>>>>that there were two conditions: Either the user invoking 
>resource- 
>>>>>>priority was well known and had a set of permissions that 
>could be 
>>>>>>checked in real time or there are ways to deal with abuse 
>after the 
>>>>>>fact in ways that deter abuse (the court-martial kind of 
>thing in a 
>>>>>>military context).
>>>>>>
>>>>>>The RFC 4412 security consideration (11.2) call this out 
>in pretty 
>>>>>>strong language:
>>>>>>
>>>>>>  Prioritized access to network and end-system resources imposes
>>>>>>    particularly stringent requirements on authentication and
>>>>>>    authorization mechanisms, since access to prioritized
>>>>>resources may
>>>>>>    impact overall system stability and performance and not
>>>>>just result
>>>>>>    in theft of, say, a single phone call.
>>>>>>Thus, the question is whether we have such strong 
>authentication in 
>>>>>>emergency calling. In some cases, such as residential fixed line 
>>>>>>deployments where ISP = VSP, we're probably pretty close,
>>in others,
>>>>>>such as prepaid cell phones or hot spots or VSP-only 
>providers, we 
>>>>>>aren't.
>>>>>>
>>>>>>The other point that I think Hannes is making is that the
>>>>>information
>>>>>>is either redundant or dangerous. If a processing element
>>recognizes
>>>>>>the call as being an emergency call, it can apply whatever
>>treatment
>>>>>>it deems appropriate and doesn't need additional 
>information. If it 
>>>>>>doesn't or can't, using just the RPH can be rather 
>dangerous unless 
>>>>>>that element can be reasonably certain that there is strong 
>>>>>>authentication and recourse.
>>>>>>
>>>>>>I don't buy the argument that somehow finding the RPH is
>>faster than
>>>>>>just looking for the identifier. Thus, given that the
>>information is
>>>>>>either redundant or dangerous, I fail to see the advantage.
>>>>>>
>>>>>>Henning
>>>>>>
>>>>>>
>>>>>>On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
>>>>>>
>>>>>>>Don't get hung up on the details. There are ways to optimize it.
>>>>>>>That was
>>>>>>>not the point of the code example.
>>>>>>>
>>>>>>>The problem that my pseudo code should have shown you is that you
>>>>>>>* don't gain anything with RPH marking for the emergency 
>call case 
>>>>>>>from the SIP UA towards the outbound proxy since the 
>functionality 
>>>>>>>is already provide otherwise. How often does the proxy 
>need to get 
>>>>>>>told that this is an emergency call todo whatever emergency call 
>>>>>>>handling procedures are necessary?
>>>>>>>* you only introduce fraud problems (if you are not
>>>>>careful and you
>>>>>>>understand the security stuff well enough)
>>>>>>>
>>>>>>>If you can point me to people who implement the RPH 
>emergency call 
>>>>>>>case please do so. I would love to talk to them.
>>>>>>>
>>>>>>>Ciao
>>>>>>>Hannes
>>>>>>>
>>>>>>>PS: You need to parse incoming messages to some extend 
>so that you 
>>>>>>>know what it contains :-) Only looking for the emergency
>>>>>RPH header
>>>>>>>(and not for the Service URN/dial
>>>>>>>string) would exactly be the DoS/fraud attack I am worried about.
>>>>>>>That's the thing Henning was worried about (go and listen to the 
>>>>>>>past meeting minutes).
>>>>>>>
>>>>>>>
>>>>>>>>Hannes
>>>>>>>>
>>>>>>>>You need to talk to people who really implement this kind
>>>>>of thing.
>>>>>>>>You are way off.
>>>>>>>>
>>>>>>>>When you implement a resource priority system, the 
>point of doing 
>>>>>>>>that is to look though the queue of work and pick out the
>>>>>ones with
>>>>>>>>priority, handling them first.  You don't do all the 
>parsing, you 
>>>>>>>>don't do a lot of decision tree.
>>>>>>>>
>>>>>>>>Typically:
>>>>>>>>Check for DoS things, like too big messages, etc Do a 
>quick scan 
>>>>>>>>for the RPH message header If found:
>>>>>>>>Parse the message
>>>>>>>>Determine validity
>>>>>>>>Determine priority
>>>>>>>>Queue on the correct work queue
>>>>>>>>
>>>>>>>>The first two actions have to be very fast.  Anyone who 
>builds a 
>>>>>>>>SIP thingie will tell you that parsing is one of the big cycle
>>>>>>>>consumers: if you have to parse every message BEFORE you
>>>>>determine
>>>>>>>>priority, you can't give much resource priority.
>>>>>>>>Once you get the whole message parsed, you might as well finish 
>>>>>>>>working on it, because you've done so much of the work.
>>>>>>>>OTHOH, finding the end-of-message delimiter and doing a quick 
>>>>>>>>string search for RPH is fast.  If you are doing
>>>>>priority, you need
>>>>>>>>to keep all the priority processing pretty uniform, and pretty 
>>>>>>>>simple, or you tend to spend too much time futzing around
>>>>>figuring
>>>>>>>>out what to do.  You put all the priority related stuff 
>together, 
>>>>>>>>and use as much common code as possible.
>>>>>>>>
>>>>>>>>Brian
>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: [email-masked] [mailto:[email-masked]]
>>>>>>>>On Behalf
>>>>>>>>>Of Hannes Tschofenig
>>>>>>>>>Sent: Friday, February 06, 2009 8:41 AM
>>>>>>>>>To: 'Hannes Tschofenig'; 'Janet P Gunn'
>>>>>>>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- 
>>>>>>>>>[email-masked]
>>>>>>>>>Subject: [Ecrit] RPH
>>>>>>>>>
>>>>>>>>>Over lunch I was also thinking how an outbound proxy would
>>>>>>implement
>>>>>>>>>some of the emergency procedures. Here are some thoughts:
>>>>>>>>>
>>>>>>>>>---------------------------------------------------
>>>>>>>>>
>>>>>>>>>// Process incoming message
>>>>>>>>>Parse(msg);
>>>>>>>>>
>>>>>>>>>// SIP INVITE without Service URN // legacy devices If 
>>>>>>>>>(recognize-dialstring(msg)==TRUE) {  // we got an 
>emergency call 
>>>>>>>>>going on  emergency=TRUE;  if (dialstring(msg) == 911) 
>>>>>>>>>serviceURN=urn:service:sos; } else if
>>>>>>>>>(recognize-serviceURN(msg)==TRUE) {  // oh. A updated
>>>>>device that
>>>>>>>>>has a service URN attached to the
>>>>>>call
>>>>>>>>>serviceURN=retrieve_ServiceURN(msg);
>>>>>>>>>emergency=TRUE;
>>>>>>>>>} else {
>>>>>>>>>// standard SIP message
>>>>>>>>>// regular processing
>>>>>>>>>process(msg);
>>>>>>>>>emergency=FALSE;
>>>>>>>>>}
>>>>>>>>>
>>>>>>>>>If (emergency == TRUE) {
>>>>>>>>>  // make sure that the emergency call does not get
>>>>>dropped on the
>>>>>>>>>floor
>>>>>>>>>  // skip authorization failures
>>>>>>>>>  // give the call a special treatment
>>>>>>>>>  lots-of-code-here();
>>>>>>>>>
>>>>>>>>>  // trigger all the QoS signaling you have in the
>>>>>network to make
>>>>>>>>>James happy
>>>>>>>>>  trigger-qos();
>>>>>>>>>
>>>>>>>>>  // query location
>>>>>>>>>  location=retrieve-location();
>>>>>>>>>
>>>>>>>>>  // determine next hop
>>>>>>>>>  next-hop=lost(location, serviceURN)
>>>>>>>>>
>>>>>>>>>  // attach RPH marking to outgoing msg to make James and
>>>>>>>>Keith happy
>>>>>>>>>  msg=add(msg, RPH);
>>>>>>>>>
>>>>>>>>>  send(msg, next-hop);
>>>>>>>>>}
>>>>>>>>>
>>>>>>>>>If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
>>>>>>>>>  // all the emergency related processing done already upfront
>>>>>>>>>  // hence I log something.
>>>>>>>>>  log(RPH_WAS_PRESENT_JUHU);
>>>>>>>>>} else if ((rph-present(msg) == TRUE) && (emergency ==
>>>>>FALSE)) {
>>>>>>>>>// this is not an emergency call  // this is something
>>>>>like GETS
>>>>>>>>>result=special-authorization-procedure(user);
>>>>>>>>>
>>>>>>>>>if (result == AUTHORIZED) {
>>>>>>>>>   // do some priority & preemption thing here.
>>>>>>>>>   // trigger all the QoS you have
>>>>>>>>>   lots-of-code-here();
>>>>>>>>>} else {
>>>>>>>>>   log("NOT AUTHORIZED; don't DoS my network");  } } 
>else {  // 
>>>>>>>>>don't need todo any RPH processing  // this includes the case 
>>>>>>>>>where the call was an emergency call but the RPH
>>>>>>>>>
>>>>>>>>>// marking was not there.
>>>>>>>>>nothing();
>>>>>>>>>}
>>>>>>>>>
>>>>>>>>>---------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Ciao
>>>>>>>>>Hannes
>>>>>>>>>
>>>>>>>>>>-----Original Message-----
>>>>>>>>>>From: [email-masked] 
>[mailto:[email-masked]] On 
>>>>>>>>>>Behalf Of Hannes Tschofenig
>>>>>>>>>>Sent: 06 February, 2009 15:07
>>>>>>>>>>To: 'Janet P Gunn'
>>>>>>>>>>Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
>>>>>>>>>FI/Espoo)
>>>>>>>>>>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: 
>>Agenda (RPH)
>>>>>>>>>>
>>>>>>>>>>Who would define something that could prevent DoS problems?
>>>>>>>>>>
>>>>>>>>>>________________________________
>>>>>>>>>>
>>>>>>>>>>         From: Janet P Gunn [mailto:[email-masked]]
>>>>>>>>>>         Sent: 06 February, 2009 14:11
>>>>>>>>>>         To: Hannes Tschofenig
>>>>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; 
>>>>>>>>>>[email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
>>>>>>'James
>>>>>>>>>>M. Polk'
>>>>>>>>>>         Subject: Re: [Ecrit] ECRIT Virtual Interim
>>>>>Meeting: Agenda (RPH)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>         But there is nothing IN RFC4412 that specifically
>>>>>>>>addresses how to
>>>>>>>>>>prevent any particular namespace being used for DoS.  
>>Anyone/any
>>>>>>UA
>>>>>>>>>>can ATTEMPT to invoke priority treatment by attaching 
>RPH.  For
>>>>>>all
>>>>>>>>>>of the 4412 namespaces, as with the new proposed 
>namespace, the 
>>>>>>>>>>mechanisms for preventing DoS are not specified in the
>>>>>>>>document that
>>>>>>>>>>defines the namespace.
>>>>>>>>>>They are/will be specified elsewhere.
>>>>>>>>>>
>>>>>>>>>>         Janet
>>>>>>>>>>
>>>>>>>>>>         This is a PRIVATE message. If you are not 
>the intended
>>>>>>>>recipient,
>>>>>>>>>>please delete without copying and kindly advise us by 
>e-mail of
>>>>>>the
>>>>>>>>>>mistake in delivery.
>>>>>>>>>>         NOTE: Regardless of content, this e-mail shall not
>>>>>>>>operate to bind
>>>>>>>>>>CSC to any order or other contract unless pursuant to 
>explicit 
>>>>>>>>>>written agreement or government initiative expressly 
>permitting
>>>>>>the
>>>>>>>>>>use of e-mail for such purpose.
>>>>>>>>>>
>>>>>>>>>>         [email-masked] wrote on 02/06/2009
>>04:21:51 AM:
>>>>>>>>>>
>>>>>>>>>>         > Hi James,
>>>>>>>>>>         >
>>>>>>>>>>         > I have read RFC 4412 and also the GETS/MLPP IETF
>>>>>>>>documents. What I
>>>>>>>>>>would
>>>>>>>>>>         > like to point out is that there is more than just a
>>>>>>>>header and
>>>>>>>>>>values within
>>>>>>>>>>         > the header that have to be considered in order to
>>>>>>>>make a judgement
>>>>>>>>>>of what
>>>>>>>>>>         > is appropriate and what isn't. There is an
>>>>>>>>architectural question
>>>>>>>>>>and
>>>>>>>>>>         > whether the environment we are using the stuff is
>>>>>>>>indeed providing
>>>>>>>>>>the
>>>>>>>>>>         > properties you need for the solution to be
>>>>>appropriate.
>>>>>>>>>>         >
>>>>>>>>>>         > Let me describe in more detail what I meant (and
>>>>>>>>please correct me
>>>>>>>>>>if I am
>>>>>>>>>>         > wrong).
>>>>>>>>>>         >
>>>>>>>>>>         > Getting priority for SIP requests when using a GETS
>>>>>>>>alike scenario
>>>>>>>>>>means
>>>>>>>>>>         > that the entity that issues the request is 
>specially
>>>>>>>>authorized
>>>>>>>>>>since
>>>>>>>>>>         > otherwise you introduce a nice denial of
>>>>>service attack. This
>>>>>>>>>>authorization
>>>>>>>>>>         > is tied to the entity that makes the request. For
>>>>>>>>example, the
>>>>>>>>>>person is
>>>>>>>>>>         > working for the government and has special rights.
>>>>>>>>>>James Bond as a (not so)
>>>>>>>>>>         > secret agent might have these rights.
>>>>>>>>>>         >
>>>>>>>>>>         > The emergency services case
>>>>>(citizen-to-authority) is a bit
>>>>>>>>>>different as
>>>>>>>>>>         > there aren't really special rights with respect to
>>>>>>>>authorization
>>>>>>>>>>tied to
>>>>>>>>>>         > individuals. Instead, the fact that something is an
>>>>>>>>emergency is
>>>>>>>>>>purely a
>>>>>>>>>>         > judgement of the human that dials a special number.
>>>>>>>>>>To deal with fraud, we
>>>>>>>>>>         > discussed in the group on what we can 
>actually do to
>>>>>>>>ensure that
>>>>>>>>>>end users
>>>>>>>>>>         > do not bypass security procedures (such as
>>>>>>>>authorization checks,
>>>>>>>>>>charging
>>>>>>>>>>         > and so on). Part of this investigation was
>>>>>the publication of
>>>>>>>>>>         > http://www.ietf.org/rfc/rfc5069.txt that also
>>>>>describes this
>>>>>>>>>>issue.
>>>>>>>>>>         >
>>>>>>>>>>         > So, imagine the implementation of a SIP
>>proxy (and we
>>>>>>>>implemented
>>>>>>>>>>that
>>>>>>>>>>         > stuff) that receives a call that contains a Service
>>>>>>>>URN. The code
>>>>>>>>>>branches
>>>>>>>>>>         > into a special mode where everything is done
>>>>>so that the call
>>>>>>>>>>receives
>>>>>>>>>>         > appropriate treatment and does not get
>>dropped on the
>>>>>>>>floor. The
>>>>>>>>>>way how the
>>>>>>>>>>         > Service URN is placed in the message
>>ensures that the
>>>>>>>>call cannot
>>>>>>>>>>go to my
>>>>>>>>>>         > friend (instead of the PSAP) unless the 
>end host ran
>>>>>>>>LoST already.
>>>>>>>>>>In the
>>>>>>>>>>         > latter case, we discussed this also on the
>>list for a
>>>>>>>>while and
>>>>>>>>>>Richard even
>>>>>>>>>>         > wrote a draft about it in the context of the
>>>>>location hiding
>>>>>>>>>>topic, we said
>>>>>>>>>>         > that the proxy would have to run LoST if he
>>>>>cares about a
>>>>>>>>>>potential
>>>>>>>>>>         > fraudulent usage.
>>>>>>>>>>         >
>>>>>>>>>>         > So, what do we need todo in order to provide
>>>>>secure RFC 4412
>>>>>>>>>>functionality
>>>>>>>>>>         > in our context?
>>>>>>>>>>         >
>>>>>>>>>>         > Do you think that the current text in
>>>>>>>>>>         >
>>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-l
>ocal-emer
>>>>>>>>>>gency-rph-nam
>>>>>>>>>>         > espace-00.txt reflects any of the
>>>>>above-described issues:
>>>>>>>>>>         > "
>>>>>>>>>>         >    The Security considerations that apply 
>>to RFC 4412
>>>>>>>>>>[RFC4412]
>>>>>>>>>>apply
>>>>>>>>>>         >    here.  This document introduces no new security
>>>>>>>>>>issues relative
>>>>>>>>>>to
>>>>>>>>>>         >    RFC 4412.
>>>>>>>>>>         > "
>>>>>>>>>>         >
>>>>>>>>>>         > From various discussions in GEOPRIV I recall
>>>>>that you are
>>>>>>>>>>super-sensitive
>>>>>>>>>>         > regarding security and privacy. For some 
>reasons you
>>>>>>>>don't seem to
>>>>>>>>>>have the
>>>>>>>>>>         > same concerns here. I would like to
>>>>>understand your reasoning.
>>>>>>>>>>         >
>>>>>>>>>>         > Please also do me another favor: Don't always say
>>>>>>>>that I don't
>>>>>>>>>>understand
>>>>>>>>>>         > the subject. Even if that would be the 
>case it isn't
>>>>>>>>particular
>>>>>>>>>>fair given
>>>>>>>>>>         > that different folks had to educate you on other
>>>>>>>>topics in the
>>>>>>>>>>past as well.
>>>>>>>>>>         > Additionally, if you listen to the audio recordings
>>>>>>>>then you will
>>>>>>>>>>notice
>>>>>>>>>>         > that Henning, Ted, and Jon do not seem to 
>understand
>>>>>>>>the issue
>>>>>>>>>>either as
>>>>>>>>>>         > they have raised similar issues during the
>>>>>F2F meetings.
>>>>>>>>>>         >
>>>>>>>>>>         > Ciao
>>>>>>>>>>         > Hannes
>>>>>>>>>>         >
>>>>>>>>>>         >
>>>>>>>>>>         > >Hannes - I believe it is you who do not understand
>>>>>>>>RFC 4412 --
>>>>>>>>>>         > >and many of us are trying to get that
>>>>>through to you, but you
>>>>>>>>>>         > >don't seem to want to listen/read.
>>>>>>>>>>         > >
>>>>>>>>>>         > >RFC 4412 is *for* priority marking SIP requests,
>>>>>>>>>>         > >
>>>>>>>>>>         > >One use is GETS.
>>>>>>>>>>         > >
>>>>>>>>>>         > >One use is MLPP.
>>>>>>>>>>         > >
>>>>>>>>>>         > >These examples are in RFC 4412 because there
>>>>>were specific
>>>>>>>>>>         > >namespaces being created for the IANA section of
>>>>>>>>that document.
>>>>>>>>>>         > >
>>>>>>>>>>         > >Reading the whole document, you will see
>>>>>that RPH can be
>>>>>>>>>>         > >specified for other uses than GETS or MLPP
>>>>>specifically.
>>>>>>>>>>         > >
>>>>>>>>>>         > >I knew when I wrote RFC 4412 that one day we
>>>>>would specify a
>>>>>>>>>>         > >namespace for ECRIT (the "esnet" namespace
>>>>>now) -- but I also
>>>>>>>>>>         > >knew it was premature for RFC 4412 to
>>>>>incorporate that
>>>>>>>>>>         > >namespace, that a future doc to RFC 4412
>>>>>would have to be
>>>>>>>>>>         > >written to do this. Brian and I talked about
>>>>>this at the
>>>>>>>>>>         > >original NENA meeting that created the IP 
>WGs there
>>>>>>>>(in August
>>>>>>>>>>         > >of 03).  We both agreed we should wait 
>until it was
>>>>>>>>>>         > >appropriate to the work in the IETF to
>>>>>submit this document
>>>>>>>>>>         > >that is now
>>>>>>>>>>         >
>>>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-l
>>ocal-emer
>>>>>>>>>>         > >gency-rph-namespace-00.txt
>>>>>>>>>>         > >
>>>>>>>>>>         > >Yet, you seem to want to use some additional
>>>>>mechanism to
>>>>>>>>>>         > >indicate priority of a call in SIP.  That
>>>>>means you want to
>>>>>>>>>>         > >introduce a second way to accomplish this in SIP.
>>>>>>>>>>Why do you
>>>>>>>>>>         > >want to promote a separate way to do something SIP
>>>>>>>>has already
>>>>>>>>>>         > >defined? That will cause interoperability
>>issues and
>>>>>>>>we both know
>>>>>>>>>>that.
>>>>>>>>>>         > >
>>>>>>>>>>         > >You've said to me (and others) that you
>>>>>believe RPH is just
>>>>>>>>>>         > >another way to accomplish what sos or a URI can
>>>>>>>>indicate - and
>>>>>>>>>>         > >you're wrong.  Your way would be
>>>>>_the_second_way_to_do_it,
>>>>>>>>>>         > >because SIP already considers RPH to be
>>>>>*the*way* to priority
>>>>>>>>>>         > >mark SIP requests.
>>>>>>>>>>         > >
>>>>>>>>>>         > >If you don't believe me (no comment), then
>>>>>why do you not
>>>>>>>>>>         > >believe the SIP WG chair (who knows more
>>>>>about SIP than both
>>>>>>>>>>         > >of us) - who, on this thread, has again said
>>>>>to you "RFC 4412
>>>>>>>>>>         > >(RPH) is the SIP mechanism to priority mark
>>>>>SIP requests"?
>>>>>>>>>>         > >
>>>>>>>>>>         > >Further, I believe it is inappropriate to
>>>>>prohibit endpoints
>>>>>>>>>>         > >from being able to set the esnet namespace.
>>>>>I absolutely
>>>>>>>>>>         > >believe it will not be needed most of the
>>>>>time, but I believe
>>>>>>>>>>         > >if someone does find a valid use for
>>>>>endpoints to mark
>>>>>>>>>>         > >priority in SIP, this ID - once it has
>>>>>become an RFC -- will
>>>>>>>>>>         > >have to be obsoleted with a new RFC saying
>>the exact
>>>>>>>>opposite.
>>>>>>>>>>         > >
>>>>>>>>>>         > >(color me confused ... over and over again)
>>>>>>>>>>         > >
>>>>>>>>>>         > >James
>>>>>>>>>>         > >
>>>>>>>>>>         > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>>>>>>>>>>         > >>Keith, please understand that the usage
>>of RFC 4412
>>>>>>>>for GETS and
>>>>>>>>>>for
>>>>>>>>>>         > >>the type of emergency call we discuss here is
>>>>>>>>different. Just
>>>>>>>>>>looking
>>>>>>>>>>         > >>at the header and the name of the
>>namespace is a bit
>>>>>>>>>>         > >artificial. I hope
>>>>>>>>>>         > >>you understand that.
>>>>>>>>>>         > >>
>>>>>>>>>>         > >> >-----Original Message-----
>>>>>>>>>>         > >> >From: DRAGE, Keith (Keith) 
>>>>>>>>>>[mailto:[email-masked]]
>>>>>>>>>>         > >> >Sent: 05 February, 2009 14:55
>>>>>>>>>>         > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
>>>>>>>>>>Polk'; 'Tschofenig,
>>>>>>>>>>         > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
>>>>>>>>>>         > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
>>>>>>>>>>Meeting: Agenda (my
>>>>>>>>>>
>>>>>>>>>>         > >> >mistake)
>>>>>>>>>>         > >> >
>>>>>>>>>>         > >> >Which is exactly what RFC 4412 
>specifies for all
>>>>>>>>namespaces.
>>>>>>>>>>         > >> >
>>>>>>>>>>         > >> >regards
>>>>>>>>>>         > >> >
>>>>>>>>>>         > >> >Keith
>>>>>>>>>>         > >> >
>>>>>>>>>>         > >> >> -----Original Message-----
>>>>>>>>>>         > >> >> From: [email-masked]
>>>>>>>>[mailto:[email-masked]]
>>>>>>>>>>         > >> >On Behalf
>>>>>>>>>>         > >> >> Of Brian Rosen
>>>>>>>>>>         > >> >> Sent: Wednesday, February 04, 2009 10:19 PM
>>>>>>>>>>         > >> >> To: 'Hannes Tschofenig'; 'James M.
>>>>>Polk'; 'Tschofenig,
>>>>>>>>>>         > >Hannes (NSN
>>>>>>>>>>         > >> >> - FI/Espoo)'; 'ECRIT'
>>>>>>>>>>         > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>>>>>>>>>>Meeting: Agenda (my
>>>>>>>>>>         > >> >> mistake)
>>>>>>>>>>         > >> >>
>>>>>>>>>>         > >> >> The value is that in some networks
>>>>>where priority for
>>>>>>>>>>         > >> >emergency calls
>>>>>>>>>>         > >> >> is appropriate, and appropriate
>>>>>policing of marking is
>>>>>>>>>>         > >implemented,
>>>>>>>>>>         > >> >> emergency calls will receive resource
>>priority.
>>>>>>>>>>         > >> >>
>>>>>>>>>>         > >> >> Not all networks would need policing.  Some
>>>>>>>>will.  Policing
>>>>>>>>>>could
>>>>>>>>>>         > >> >> be to Route header/R-URI content, but other
>>>>>>>>criteria are
>>>>>>>>>>possible.
>>>>>>>>>>         > >> >>
>>>>>>>>>>         > >> >> Not all networks will need resource priority
>>>>>>>>for emergency
>>>>>>>>>>calls.
>>>>>>>>>>         > >> >> Fine, ignore this marking/namespace.
>>>>>>>>>>         > >> >>
>>>>>>>>>>         > >> >> Brian
>>>>>>>>>>         > >> >> > -----Original Message-----
>>>>>>>>>>         > >> >> > From: Hannes Tschofenig 
>>>>>>>>>>[mailto:[email-masked]]
>>>>>>>>>>         > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>>>>>>>>>>         > >> >> > To: 'Brian Rosen'; 'James M. Polk';
>>>>>>>>Tschofenig, Hannes
>>>>>>>>>>(NSN -
>>>>>>>>>>         > >> >> > FI/Espoo); 'ECRIT'
>>>>>>>>>>         > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
>>>>>>>>>>Meeting: Agenda (my
>>>>>>>>>>         > >> >> > mistake)
>>>>>>>>>>         > >> >> >
>>>>>>>>>>         > >> >> > I don't even see the value in 
>permitting the
>>>>>>>>endpoint todo
>>>>>>>>>>the
>>>>>>>>>>         > >> >> > RPH marking.
>>>>>>>>>>         > >> >> > In addition to the security concerns
>>>>>there is also the
>>>>>>>>>>         > >> >problem that
>>>>>>>>>>         > >> >> > there are more options to implement without
>>>>>>>>an additional
>>>>>>>>>>value.
>>>>>>>>>>         > >> >> >
>>>>>>>>>>         > >> >> > >-----Original Message-----
>>>>>>>>>>         > >> >> > >From: Brian Rosen
>>[mailto:[email-masked]]
>>>>>>>>>>         > >> >> > >Sent: 05 February, 2009 00:03
>>>>>>>>>>         > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
>>>>>>>>'Tschofenig,
>>>>>>>>>>         > >> >> Hannes (NSN -
>>>>>>>>>>         > >> >> > >FI/Espoo)'; 'ECRIT'
>>>>>>>>>>         > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual
>>>>>Interim Meeting:
>>>>>>>>>>Agenda (my
>>>>>>>>>>         > >> >> > mistake)
>>>>>>>>>>         > >> >> > >
>>>>>>>>>>         > >> >> > >Hannes
>>>>>>>>>>         > >> >> > >
>>>>>>>>>>         > >> >> > >This matches my understanding
>>>>>precisely.  We wish to
>>>>>>>>>>         > >> >> permit endpoints
>>>>>>>>>>         > >> >> > >to mark. We do not require it, and
>>>>>don't necessarily
>>>>>>>>>>expect it
>>>>>>>>>>         > >> >> > >in many (even
>>>>>>>>>>         > >> >> > >most) cases.  We don't wish to see the
>>>>>>>>document prohibit
>>>>>>>>>>it.
>>>>>>>>>>         > >> >> > >We all seem to agree it has value
>>within the
>>>>>>>>Emergency
>>>>>>>>>>         > >> >Services IP
>>>>>>>>>>         > >> >> > >Networks.
>>>>>>>>>>         > >> >> > >
>>>>>>>>>>         > >> >> > >Brian
>>>>>>>>>>         > >> >> > >
>>>>>>>>>>         > >> >> > >> -----Original Message-----
>>>>>>>>>>         > >> >> > >> From: [email-masked] 
>>>>>>>>>>[mailto:[email-masked]]
>>>>>>>>>>         > >> >> > >On Behalf
>>>>>>>>>>         > >> >> > >> Of James M. Polk
>>>>>>>>>>         > >> >> > >> Sent: Wednesday, February 04,
>>2009 4:01 PM
>>>>>>>>>>         > >> >> > >> To: Hannes Tschofenig; Tschofenig,
>>>>>Hannes (NSN -
>>>>>>>>>>         > >> >> FI/Espoo); 'ECRIT'
>>>>>>>>>>         > >> >> > >> Subject: Re: [Ecrit] ECRIT
>>Virtual Interim
>>>>>>>>>>Meeting:
>>>>>>>>>>         > >Agenda (my
>>>>>>>>>>         > >> >> > >> mistake)
>>>>>>>>>>         > >> >> > >>
>>>>>>>>>>         > >> >> > >> At 02:37 PM 2/4/2009, Hannes
>>>>>Tschofenig wrote:
>>>>>>>>>>         > >> >> > >> > > James wrote:
>>>>>>>>>>         > >> >> > >> > >> you are the _lone_ voice not
>>>>>>>>supporting this ID,
>>>>>>>>>>         > >> >> > >> >
>>>>>>>>>>         > >> >> > >> >Listening to the audio 
>recording of past
>>>>>>>>meetings I
>>>>>>>>>>have to
>>>>>>>>>>         > >> >> > >say that
>>>>>>>>>>         > >> >> > >> >I
>>>>>>>>>>         > >> >> > >> was
>>>>>>>>>>         > >> >> > >> >not the only persons raising
>>>>>concerns about the
>>>>>>>>>>document.
>>>>>>>>>>         > >> >> > >> >That was probably the reason why you
>>>>>>>>agreed to limit
>>>>>>>>>>the
>>>>>>>>>>         > >> >> > >scope of the
>>>>>>>>>>         > >> >> > >> >document (which you didn't later do) to
>>>>>>>>get folks to
>>>>>>>>>>agree
>>>>>>>>>>         > >> >> > >to make it
>>>>>>>>>>         > >> >> > >> a WG
>>>>>>>>>>         > >> >> > >> >item.
>>>>>>>>>>         > >> >> > >>
>>>>>>>>>>         > >> >> > >> re-listen to the audio please
>>>>>>>>>>         > >> >> > >>
>>>>>>>>>>         > >> >> > >> Ted's concerns were consistent with most
>>>>>>>>>>(all?) other
>>>>>>>>>>         > >> >> concerns --
>>>>>>>>>>         > >> >> > >> which were based on the premise
>>of whether
>>>>>>>>or not the
>>>>>>>>>>         > >> >> UAC should be
>>>>>>>>>>         > >> >> > >> trusted to initiate the marking on the
>>>>>>>>INVITE.  The
>>>>>>>>>>most
>>>>>>>>>>         > >> >> > >> recent version has backed off this
>>>>>to a "can" --
>>>>>>>>>>meaning not
>>>>>>>>>>         > >> >prohibited
>>>>>>>>>>         > >> >> > >> (i.e., no 2119 text).  I also backed off
>>>>>>>>the text in
>>>>>>>>>>the
>>>>>>>>>>         > >> >> SP domain
>>>>>>>>>>         > >> >> > >> part to "can", such that there is
>>>>>no 2119 text
>>>>>>>>>>         > >> >mandating or even
>>>>>>>>>>         > >> >> > >> recommending its usage there. I also do
>>>>>>>>not prohibit
>>>>>>>>>>its
>>>>>>>>>>         > >> >> > >use, based on
>>>>>>>>>>         > >> >> > >> local policy.  Keith has come
>>forward with
>>>>>>>>the specific
>>>>>>>>>>
>>>>>>>>>>         > >> >> > >> request that non-ESInet networks be
>>>>>>>>allowed to mark and
>>>>>>>>>>pay
>>>>>>>>>>         > >> >attention to
>>>>>>>>>>         > >> >> > >> this priority indication -- with IMS as
>>>>>>>>the specific
>>>>>>>>>>example
>>>>>>>>>>         > >> >> > >> he wishes to have this valid for.
>>>>>>>>>>         > >> >> > >>
>>>>>>>>>>         > >> >> > >> Where there is no disagreement, save for
>>>>>>>>your recent
>>>>>>>>>>         > >> >> > >pushback - is in
>>>>>>>>>>         > >> >> > >> the ESInet, which is where Brian
>>>>>has requested it's
>>>>>>>>>>         > >> >> > >definition in the
>>>>>>>>>>         > >> >> > >> IETF on behalf of NENA.  He's the i3 WG
>>>>>>>>chair within
>>>>>>>>>>         > >> >> NENA, and if
>>>>>>>>>>         > >> >> > >> he asks for it, are you going to say you
>>>>>>>>know better
>>>>>>>>>>than he?
>>>>>>>>>>         > >> >> > >>
>>>>>>>>>>         > >> >> > >>
>>>>>>>>>>         > >> >> > >> >Btw, I not disagreeing with 
>the document
>>>>>>>>as such. I
>>>>>>>>>>         > >> >just want to
>>>>>>>>>>         > >> >> > the
>>>>>>>>>>         > >> >> > >> scope
>>>>>>>>>>         > >> >> > >> >to change. The usage of RPH
>>>>>within the emergency
>>>>>>>>>>         > >> >> services network
>>>>>>>>>>         > >> >> > is
>>>>>>>>>>         > >> >> > >> fine
>>>>>>>>>>         > >> >> > >> >for me. I may get convinced to 
>start the
>>>>>>>>RPH marking
>>>>>>>>>>from
>>>>>>>>>>         > >> >> > >the the VSP
>>>>>>>>>>         > >> >> > >> >towards the PSAP. I feel uneasy
>>about the
>>>>>>>>end host
>>>>>>>>>>doing
>>>>>>>>>>         > >> >> > >the marking.
>>>>>>>>>>         > >> >> > >>
>>>>>>>>>>         > >> >> > >> please read what I wrote above, and then
>>>>>>>>re-read the
>>>>>>>>>>         > >> >most recent
>>>>>>>>>>         > >> >> > >> version of the ID. I don't have 
>endpoints
>>>>>>>>that SHOULD
>>>>>>>>>>or
>>>>>>>>>>         > >> >> MUST mark
>>>>>>>>>>         > >> >> > >> anything wrt RPH.  I also don't want to
>>>>>>>>prohibit it,
>>>>>>>>>>         > >> >> because there
>>>>>>>>>>         > >> >> > >> might be cases (that I don't know
>>>>>of) of valid uses
>>>>>>>>>>         > >> >> under certain
>>>>>>>>>>         > >> >> > >> circumstances.  Figure 1 is very clear
>>>>>>>>that there are 3
>>>>>>>>>>         > >> >> networking
>>>>>>>>>>         > >> >> > >> parts to consider
>>>>>>>>>>         > >> >> > >>
>>>>>>>>>>         > >> >> > >> #1 - from the endpoint
>>>>>>>>>>         > >> >> > >> #2 - within the VSP
>>>>>>>>>>         > >> >> > >> #3 - within the ESInet
>>>>>>>>>>         > >> >> > >>
>>>>>>>>>>         > >> >> > >> the most recent ID version has "can" for
>>>>>>>>#s 1 and 2,
>>>>>>>>>>and
>>>>>>>>>>         > >> >> > >2119 language
>>>>>>>>>>         > >> >> > >> offering those supporting this
>>>>>>>>specification will have
>>>>>>>>>>RPH
>>>>>>>>>>         > >> >> > >> adherence within #3 (the ESInet).
>>>>>>>>>>         > >> >> > >>
>>>>>>>>>>         > >> >> > >> What other scope changes do you want,
>>>>>>>>because I haven't
>>>>>>>>>>         > >> >> heard them.
>>>>>>>>>>         > >> >> > >>
>>>>>>>>>>         > >> >> > >> I only heard you claim in email
>>during the
>>>>>>>>last IETF
>>>>>>>>>>and in
>>>>>>>>>>         > >> >> > >the ECRIT
>>>>>>>>>>         > >> >> > >> session that RPH should not be
>>>>>used for priority
>>>>>>>>>>marking
>>>>>>>>>>         > >> >> requests.
>>>>>>>>>>         > >> >> > >> This is something Keith (SIP WG
>>>>>chair) voiced his
>>>>>>>>>>opposition
>>>>>>>>>>         > >> >> > >> to your views regarding 
>creating a second
>>>>>>>>means for SIP
>>>>>>>>>>to
>>>>>>>>>>         > >> >priority
>>>>>>>>>>         > >> >> > >> mark request "when SIP already has one
>>>>>>>>interoperable
>>>>>>>>>>way to
>>>>>>>>>>         > >> >> > >> accomplish this... it's call the
>>RP header
>>>>>>>>mechanism".
>>>>>>>>>>         > >> >> > >>
>>>>>>>>>>         > >> >> > >> >I don't see advantages -- only
>>>>>disadvantages.
>>>>>>>>>>         > >> >> > >> >
>>>>>>>>>>         > >> >> > >> >Ciao
>>>>>>>>>>         > >> >> > >> >Hannes
>>>>>>>>>>         > >> >> > >>
>>>>>>>>>>         > >> >> > >>
>>>>>_______________________________________________
>>>>>>>>>>         > >> >> > >> Ecrit mailing list
>>>>>>>>>>         > >> >> > >> [email-masked]
>>>>>>>>>>         > >> >> > >>
>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>         > >> >> > >
>>>>>>>>>>         > >> >>
>>>>>>>>>>         > >> >>
>>_______________________________________________
>>>>>>>>>>         > >> >> Ecrit mailing list
>>>>>>>>>>         > >> >> [email-masked]
>>>>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>         > >> >>
>>>>>>>>>>         > >> >
>>>>>>>>>>         > >
>>>>>>>>>>         >
>>>>>>>>>>         > _______________________________________________
>>>>>>>>>>         > Ecrit mailing list
>>>>>>>>>>         > [email-masked]
>>>>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>_______________________________________________
>>>>>>>>>>Ecrit mailing list
>>>>>>>>>>[email-masked]
>>>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>
>>>>>>>>>_______________________________________________
>>>>>>>>>Ecrit mailing list
>>>>>>>>>[email-masked]
>>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>Ecrit mailing list
>>>>>>>[email-masked]
>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>>_______________________________________________
>>>>Ecrit mailing list
>>>>[email-masked]
>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>>
>>>>-------------------------------------------------------------
>>-----------------------------------
>>>>This message is for the designated recipient only and may contain 
>>>>privileged, proprietary, or otherwise private information.
>>>>If you have received it in error, please notify the sender 
>>>>immediately and delete the original.  Any unauthorized use of this 
>>>>email is prohibited.
>>>>-------------------------------------------------------------
>>-----------------------------------
>>>>[mf2]
>>>>
>>>
>>>_______________________________________________
>>>Ecrit mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/ecrit
>>
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/ecrit
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/ecrit
>>
>
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'DRAGE, Keith \(Keith\)'" <[email-masked]>, "'Henning Schulzrinne'" <[email-masked]>, "'James M. Polk'" <[email-masked]>
Date: Sat, 7 Feb 2009 10:14:57 +0200
Cc: 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] RPH

PLEASE try to understand that the syntax is similar (header, new namespace,
new values) 
BUT the semantic is different. 
 
For all message it is true that the sender can add whatever they want. The
big question is what does it mean for the recipient. 

This is what the discussion is about. 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of DRAGE, Keith (Keith)
>Sent: 07 February, 2009 02:22
>To: Henning Schulzrinne; James M. Polk
>Cc: ECRIT
>Subject: Re: [Ecrit] RPH
>
>Well to be honest, I thought RFC 4412 defined exactly the 
>usage from the UA of any RPH header, and noone appears to be 
>seeking to change that. Any UE can insert an RPH header, and 
>the outbound proxy that understands RPH can use this as 
>absolute, guidance, or completely ignore it and throw it away 
>depending on whatever rules it decides apply to its usage of 
>that namespace. IETF does not write those rules, just defines 
>the namespace. 
>
>So I disagree with the statement of "underspecified" in 
>relation to this.
>
>regards
>
>Keith
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>> Of Henning Schulzrinne
>> Sent: Friday, February 06, 2009 10:29 PM
>> To: James M. Polk
>> Cc: ECRIT
>> Subject: Re: [Ecrit] RPH
>> 
>> To restate: I will object to any text mentioning use of ESNET in UAs.
>> It's useless (since under-specified), likely to be harmful 
>to reliable 
>> network operation and just causes confusion. The text should 
>describe 
>> when it is useful (within a "closed"
>> ESNET, presumably) and what conditions need to be met in order to 
>> ensure reliable and secure usage. That something might be useful 
>> somewhere else is always true, in any specification, but we 
>don't add 
>> a "This document does not prevent the use of this mechanism 
>somewhere 
>> else." in documents.
>> 
>> Henning
>> 
>> On Feb 6, 2009, at 5:21 PM, James M. Polk wrote:
>> 
>> > At 04:05 PM 2/6/2009, Henning Schulzrinne wrote:
>> >> James,
>> >>
>> >> we don't go through every possible SIP header that might
>> be inserted
>> >> into emergency requests. Yes, somebody could add RPH, but this 
>> >> applies to PAI and dozens of other SIP headers as well. So far, 
>> >> nobody has provided, in my opinion, a compelling use case that is 
>> >> worth documenting. "It could be useful somewhere for something"
>> >> doesn't cut it. I have provided multiple reasons why I
>> think that it
>> >> is a bad idea for (normal) UAs to do so, none of which 
>you address.
>> >
>> >
>> >> I see no need to  say "do not insert RPH",
>> >
>> > this is the only thing - right now - that I'm afraid one of us 
>> > believes should be the case. I'm glad you are not joining that 
>> > position.  I really do not want to highlight the idea fo
>> UAs inserting
>> > esnet, but I believe sometime down the road - some customer
>> will come
>> > up with a valid reason for this, and I don't want to state in text 
>> > that it is prevented from being inserted (and yet have the
>> vendor who
>> > wants to sell to that customer also want that vendor to
>> adhere to this
>> > spec as well).
>> >
>> > I'm just advocating we not have the text prevent its inclusion.
>> >
>> > As I've said, I will beef up the security considerations
>> section wrt
>> > UA insertion of esnet - unless others object to this...
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'DRAGE, Keith \(Keith\)'" <[email-masked]>, "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sat, 7 Feb 2009 10:22:58 +0200
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] RPH

Hi Keith, 

>It appears you want to develop an entirely separate codepath 
>for the usage of RPH in emergency calls, where the appropriate 
>thing is to apply the tested usage of RPH that many networks 
>will have to deploy anyway. So there will be a standard RPH 
>usage which is then configured to handle the emergency namespace.

IF you don't add any additional branch for the case where the call is an
emergency call (Service URN or respective dial string present) AND the ECRIT
RPH is set (in addition that the case where the call is detected as an
emergency call) THEN 
the ECRIT RPH thing does not add any value.

With the same argument we could also add another header
"IGNORE_AUTHORIZATION_FAILURE" that can be set by the UA and 
1) let the proxy decide whether it wants to trust it (a security policy, as
folks argue)
2) if it does then there is a code branch that ignores authorization
failures. 

Now, one would argue that (2) might be a bit risky from a security point of
view when the call is not an emergency call. Hence, you have to make sure
that the call is an emergency call (by checking Service URN and specific
dial string presence). 

Then, someone who thinks about it might then argue: "Wait, we already have
this code already in there for the case that the call is an emergency call
anyway. There wouldn't be any additional value of sending such a header."

This is exactly what is happening here with the ECRIT RPH case. 

Convincing? 

Ciao
Hannes

>regards
>
>Keith
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>> Of Hannes Tschofenig
>> Sent: Friday, February 06, 2009 10:52 PM
>> To: 'DOLLY, MARTIN C, ATTLABS'; [email-masked]; 
>[email-masked]; 
>> [email-masked]
>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
>> Subject: Re: [Ecrit] RPH
>>
>> Hi Martin,
>>
>> I am arguing that if the UE does mark the call with the ECRIT RPH (I 
>> call it that way to differentiate it from RFC 4412 RPH 
>usage, which is 
>> very
>> different) then it should be ignored.
>> Processing it will not help in any way (as I described in my pseudo 
>> code snippet). Incorrectly processing it (which is a 
>possibility when 
>> the implementer does not understand the security 
>implications -- they 
>> will not get it from the current version of the draft) will lead to 
>> security problems (fraud & DoS potential).
>>
>> While you cannot prevent someone from sending you, there is 
>certainly 
>> the chance to document what the receiver should do with it.
>>
>> Ciao
>> Hannes
>>
>> >-----Original Message-----
>> >From: [email-masked] [mailto:[email-masked]]
>> On Behalf
>> >Of DOLLY, MARTIN C, ATTLABS
>> >Sent: 07 February, 2009 00:15
>> >To: [email-masked]; [email-masked]; 
>> >[email-masked]
>> >Cc: [email-masked]; [email-masked]
>> >Subject: Re: [Ecrit] RPH
>> >
>> >You can not disallow this from an UE. The trust relationship will 
>> >dictate whether it is accepted or not
>> >
>> >----- Original Message -----
>> >From: [email-masked] <[email-masked]>
>> >To: Henning Schulzrinne <[email-masked]>; Winterbottom, James 
>> ><[email-masked]>
>> >Cc: Tschofenig, Hannes (NSN - FI/Espoo) 
><[email-masked]>; 
>> >ECRIT <[email-masked]>
>> >Sent: Fri Feb 06 17:10:08 2009
>> >Subject: Re: [Ecrit] RPH
>> >
>> >At 03:05 PM 2/6/2009, Henning Schulzrinne wrote:
>> >>There's another problem with the "it doesn't hurt argument".
>> >Assume for
>> >>a moment we have a "UA MAY include RPH" wording. There are now two
>> >>cases:
>> >>
>> >>(1) All UAs implement it.
>> >>
>> >>(2) Only some UAs implement it.
>> >>
>> >>(1) seems unlikely for a MAY. If (2) occurs, we have the
>> >choice between
>> >>two undesirable outcomes:
>> >>
>> >>(a) some UAs that are otherwise compliant get worse service just 
>> >>because they didn't include the RPH;
>> >
>> >am I reading this correctly - that unless all UAs implement this 
>> >capability this should never be implemented by any UAs?
>> >
>> >This flies in the face of vendors solving for their customer's 
>> >requirements.
>> >
>> >I will admit that at this time, I know of no Cisco customers
>> that want
>> >this capability, so I'm not angling for any of our revenue
>> here.  I'm
>> >saying that I think I hear you saying this ID should say
>> something like
>> >
>> >         UAs are prevented from implementing the RP namespace esnet
>> >
>> >I'm fighting against that, because customers are always
>> coming to every
>> >vendor with new requirements, some of them unique at the 
>time.  This 
>> >prevention text would prevent a vendor from complying with this 
>> >specification and still meet the customer's needs.
>> >
>> >I believe that this ID needs to retain the endpoints MAY
>> insert esnet,
>> >and have appropriate security considerations text that
>> highlights the
>> >concerns expressed here.
>> >
>> >Some future ID can then update this current RFC (to-be) within the
>> >2119 rules of the use of MAY here.
>> >
>> >
>> >>OR
>> >>
>> >>(b) the proxy has to look for the service URN to give the call the 
>> >>appropriate treatment, thus obviating any advantage of having the 
>> >>header, yet incurring more complicated processing logic.
>> >>
>> >>
>> >>I have no objection to whatever markings people want to
>> apply to calls
>> >>within an ESN - that's largely a private matter.
>> >>
>> >>Henning
>> >>
>> >>On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote:
>> >>
>> >>>Hi All,
>> >>>
>> >>>I have followed thi thread with some interest and I
>> struggling to see
>> >>>a use case for the providing RPH for emergency calls from the 
>> >>>end-point.
>> >>>
>> >>>The reference-model call in ECRIT, for better or worse, 
>is for all 
>> >>>calls to go back through a home-VSP.
>> >>>We placed quite a lot of emphasis, largely for traffing
>> reasons, for
>> >>>the VSP to be able to verify that a call is in fact an emergency 
>> >>>call. This is done by the proxy taking the inband
>> location, doing a
>> >>>LoST query with the provided URN, and verifying that the 
>resulting 
>> >>>destination URI is the same as the destination URI provide
>> in the SIP
>> >>>INVITE. My understanding was that VSPs would always do
>> this check so
>> >>>they could tell if they could bill for the call or not,
>> and because
>> >>>the VSP can be use that the call is an emergency call it 
>can apply 
>> >>>any special priorities that may be applicable. This
>> obviates the need
>> >>>for RPH from the end-point to the network.
>> >>>
>> >>>This leaves us with the argument of "it doesn't hurt to
>> it", which is
>> >>>not a good reason to write a specification.
>> >>>It was intimated on the geopriv mailing list last year that great 
>> >>>pains had been taken to keep SIP with in the MTU limits of
>> UDP over
>> >>>Ethernet
>> >>>(http://www.ietf.org/mail-archive/web/geopriv/current/msg0612
>> >0.html ). Assuming
>> >>>that this is the case, perhaps there is harm in including
>> information
>> >>>that we know will be ignored.
>> >>>
>> >>>Cheers
>> >>>James
>> >>>
>> >>>
>> >>>
>> >>>-----Original Message-----
>> >>>From: [email-masked] on behalf of Hannes Tschofenig
>> >>>Sent: Fri 2/6/2009 12:33 PM
>> >>>To: 'Brian Rosen'; 'Henning Schulzrinne'
>> >>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
>> >>>Subject: Re: [Ecrit] RPH
>> >>>
>> >>>To the story short here is the code for the proxy:
>> >>>
>> >>>---------------------
>> >>>
>> >>>IF emergency call was recognized THEN
>> >>>    execute emergency call specific procedures (priority queuing, 
>> >>>preemption, fetch location, determine routing, do funny
>> QoS things &
>> >>>co)
>> >>>ELSE
>> >>>    normal call handling procedures.
>> >>>
>> >>>---------------------
>> >>>
>> >>>If you can make this differentiation between an emergency
>> call and a
>> >>>regular call then you can also do everything that is 
>necessary for 
>> >>>emergency call handling.
>> >>>
>> >>>Brian + Keith: Please tell me that we cannot do the above 
>with our 
>> >>>currently specified mechanisms.
>> >>>
>> >>>Ciao
>> >>>Hannes
>> >>>
>> >>>>-----Original Message-----
>> >>>>From: Brian Rosen [mailto:[email-masked]]
>> >>>>Sent: 06 February, 2009 17:49
>> >>>>To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
>> >>>>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
>> >>>>Subject: RE: [Ecrit] RPH
>> >>>>
>> >>>>I agree that not all networks will permit (or pay attention
>> >>>>to) a priority request from an end device.
>> >>>>
>> >>>>No one has asked for that.
>> >>>>
>> >>>>The namespace request has several uses, one of which is 
>within an 
>> >>>>emergency services IP network, one of which is between elements 
>> >>>>within a public network controlled by the operator, and
>> one of which
>> >>>>is an endpoint request for resource priority.
>> >>>>
>> >>>>Those of us requesting this work proceed are happy if the
>> endpoint
>> >>>>part is simply left as possible (MAY), and, speaking for myself, 
>> >>>>having the draft discuss the security implications of endpoint 
>> >>>>marking is reasonable.
>> >>>>
>> >>>>Having discussed this issue with an implementation team
>> who worked
>> >>>>on MLPP systems, I am confident I know what I'm talking
>> about, but
>> >>>>YMMV.  The fact that you could, if you wanted to, give resource 
>> >>>>priority to a call you decided, however you decided, was an 
>> >>>>emergency call is an implementation decision, and not subject to 
>> >>>>standardization.
>> >>>>
>> >>>>RPH is the IETF standard way for one entity to request resource 
>> >>>>priority of another entity in a SIP system.  We're asking for a 
>> >>>>namespace to use that within the domain of emergency 
>calls.  That 
>> >>>>is, I think, a VERY reasonable request.
>> >>>>
>> >>>>Brian
>> >>>>
>> >>>>>-----Original Message-----
>> >>>>>From: Henning Schulzrinne [mailto:[email-masked]]
>> >>>>>Sent: Friday, February 06, 2009 10:33 AM
>> >>>>>To: Hannes Tschofenig
>> >>>>>Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>> >>>>>Subject: Re: [Ecrit] RPH
>> >>>>>
>> >>>>>To chime in here:
>> >>>>>
>> >>>>>I don't think it's productive to simply state that 4412
>> >>>>doesn't worry
>> >>>>>about authorization, so we shouldn't either (simplifying a bit).
>> >>>>>Authorization was discussed repeatedly, and the general
>> >>>>assumption was
>> >>>>>that there were two conditions: Either the user invoking
>> resource-
>> >>>>>priority was well known and had a set of permissions
>> that could be
>> >>>>>checked in real time or there are ways to deal with
>> abuse after the
>> >>>>>fact in ways that deter abuse (the court-martial kind of
>> thing in a
>> >>>>>military context).
>> >>>>>
>> >>>>>The RFC 4412 security consideration (11.2) call this out
>> in pretty
>> >>>>>strong language:
>> >>>>>
>> >>>>>  Prioritized access to network and end-system resources imposes
>> >>>>>    particularly stringent requirements on authentication and
>> >>>>>    authorization mechanisms, since access to prioritized
>> >>>>resources may
>> >>>>>    impact overall system stability and performance and not
>> >>>>just result
>> >>>>>    in theft of, say, a single phone call.
>> >>>>>Thus, the question is whether we have such strong
>> authentication in
>> >>>>>emergency calling. In some cases, such as residential 
>fixed line 
>> >>>>>deployments where ISP = VSP, we're probably pretty close,
>> >in others,
>> >>>>>such as prepaid cell phones or hot spots or VSP-only
>> providers, we
>> >>>>>aren't.
>> >>>>>
>> >>>>>The other point that I think Hannes is making is that the
>> >>>>information
>> >>>>>is either redundant or dangerous. If a processing element
>> >recognizes
>> >>>>>the call as being an emergency call, it can apply whatever
>> >treatment
>> >>>>>it deems appropriate and doesn't need additional
>> information. If it
>> >>>>>doesn't or can't, using just the RPH can be rather
>> dangerous unless
>> >>>>>that element can be reasonably certain that there is strong 
>> >>>>>authentication and recourse.
>> >>>>>
>> >>>>>I don't buy the argument that somehow finding the RPH is
>> >faster than
>> >>>>>just looking for the identifier. Thus, given that the
>> >information is
>> >>>>>either redundant or dangerous, I fail to see the advantage.
>> >>>>>
>> >>>>>Henning
>> >>>>>
>> >>>>>
>> >>>>>On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
>> >>>>>
>> >>>>>>Don't get hung up on the details. There are ways to 
>optimize it.
>> >>>>>>That was
>> >>>>>>not the point of the code example.
>> >>>>>>
>> >>>>>>The problem that my pseudo code should have shown you
>> is that you
>> >>>>>>* don't gain anything with RPH marking for the
>> emergency call case
>> >>>>>>from the SIP UA towards the outbound proxy since the
>> functionality
>> >>>>>>is already provide otherwise. How often does the proxy
>> need to get
>> >>>>>>told that this is an emergency call todo whatever
>> emergency call
>> >>>>>>handling procedures are necessary?
>> >>>>>>* you only introduce fraud problems (if you are not
>> >>>>careful and you
>> >>>>>>understand the security stuff well enough)
>> >>>>>>
>> >>>>>>If you can point me to people who implement the RPH
>> emergency call
>> >>>>>>case please do so. I would love to talk to them.
>> >>>>>>
>> >>>>>>Ciao
>> >>>>>>Hannes
>> >>>>>>
>> >>>>>>PS: You need to parse incoming messages to some extend
>> so that you
>> >>>>>>know what it contains :-) Only looking for the emergency
>> >>>>RPH header
>> >>>>>>(and not for the Service URN/dial
>> >>>>>>string) would exactly be the DoS/fraud attack I am
>> worried about.
>> >>>>>>That's the thing Henning was worried about (go and
>> listen to the
>> >>>>>>past meeting minutes).
>> >>>>>>
>> >>>>>>
>> >>>>>>>Hannes
>> >>>>>>>
>> >>>>>>>You need to talk to people who really implement this kind
>> >>>>of thing.
>> >>>>>>>You are way off.
>> >>>>>>>
>> >>>>>>>When you implement a resource priority system, the
>> point of doing
>> >>>>>>>that is to look though the queue of work and pick out the
>> >>>>ones with
>> >>>>>>>priority, handling them first.  You don't do all the
>> parsing, you
>> >>>>>>>don't do a lot of decision tree.
>> >>>>>>>
>> >>>>>>>Typically:
>> >>>>>>>Check for DoS things, like too big messages, etc Do a
>> quick scan
>> >>>>>>>for the RPH message header If found:
>> >>>>>>>Parse the message
>> >>>>>>>Determine validity
>> >>>>>>>Determine priority
>> >>>>>>>Queue on the correct work queue
>> >>>>>>>
>> >>>>>>>The first two actions have to be very fast.  Anyone
>> who builds a
>> >>>>>>>SIP thingie will tell you that parsing is one of the big cycle
>> >>>>>>>consumers: if you have to parse every message BEFORE you
>> >>>>determine
>> >>>>>>>priority, you can't give much resource priority.
>> >>>>>>>Once you get the whole message parsed, you might as
>> well finish
>> >>>>>>>working on it, because you've done so much of the work.
>> >>>>>>>OTHOH, finding the end-of-message delimiter and doing a quick 
>> >>>>>>>string search for RPH is fast.  If you are doing
>> >>>>priority, you need
>> >>>>>>>to keep all the priority processing pretty uniform, 
>and pretty 
>> >>>>>>>simple, or you tend to spend too much time futzing around
>> >>>>figuring
>> >>>>>>>out what to do.  You put all the priority related
>> stuff together,
>> >>>>>>>and use as much common code as possible.
>> >>>>>>>
>> >>>>>>>Brian
>> >>>>>>>
>> >>>>>>>>-----Original Message-----
>> >>>>>>>>From: [email-masked] [mailto:[email-masked]]
>> >>>>>>>On Behalf
>> >>>>>>>>Of Hannes Tschofenig
>> >>>>>>>>Sent: Friday, February 06, 2009 8:41 AM
>> >>>>>>>>To: 'Hannes Tschofenig'; 'Janet P Gunn'
>> >>>>>>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- 
>> >>>>>>>>[email-masked]
>> >>>>>>>>Subject: [Ecrit] RPH
>> >>>>>>>>
>> >>>>>>>>Over lunch I was also thinking how an outbound proxy would
>> >>>>>implement
>> >>>>>>>>some of the emergency procedures. Here are some thoughts:
>> >>>>>>>>
>> >>>>>>>>---------------------------------------------------
>> >>>>>>>>
>> >>>>>>>>// Process incoming message
>> >>>>>>>>Parse(msg);
>> >>>>>>>>
>> >>>>>>>>// SIP INVITE without Service URN // legacy devices If
>> >>>>>>>>(recognize-dialstring(msg)==TRUE) {  // we got an
>> emergency call
>> >>>>>>>>going on  emergency=TRUE;  if (dialstring(msg) == 911) 
>> >>>>>>>>serviceURN=urn:service:sos; } else if
>> >>>>>>>>(recognize-serviceURN(msg)==TRUE) {  // oh. A updated
>> >>>>device that
>> >>>>>>>>has a service URN attached to the
>> >>>>>call
>> >>>>>>>>serviceURN=retrieve_ServiceURN(msg);
>> >>>>>>>>emergency=TRUE;
>> >>>>>>>>} else {
>> >>>>>>>>// standard SIP message
>> >>>>>>>>// regular processing
>> >>>>>>>>process(msg);
>> >>>>>>>>emergency=FALSE;
>> >>>>>>>>}
>> >>>>>>>>
>> >>>>>>>>If (emergency == TRUE) {
>> >>>>>>>>  // make sure that the emergency call does not get
>> >>>>dropped on the
>> >>>>>>>>floor
>> >>>>>>>>  // skip authorization failures
>> >>>>>>>>  // give the call a special treatment
>> >>>>>>>>  lots-of-code-here();
>> >>>>>>>>
>> >>>>>>>>  // trigger all the QoS signaling you have in the
>> >>>>network to make
>> >>>>>>>>James happy
>> >>>>>>>>  trigger-qos();
>> >>>>>>>>
>> >>>>>>>>  // query location
>> >>>>>>>>  location=retrieve-location();
>> >>>>>>>>
>> >>>>>>>>  // determine next hop
>> >>>>>>>>  next-hop=lost(location, serviceURN)
>> >>>>>>>>
>> >>>>>>>>  // attach RPH marking to outgoing msg to make James and
>> >>>>>>>Keith happy
>> >>>>>>>>  msg=add(msg, RPH);
>> >>>>>>>>
>> >>>>>>>>  send(msg, next-hop);
>> >>>>>>>>}
>> >>>>>>>>
>> >>>>>>>>If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
>> >>>>>>>>  // all the emergency related processing done 
>already upfront
>> >>>>>>>>  // hence I log something.
>> >>>>>>>>  log(RPH_WAS_PRESENT_JUHU);
>> >>>>>>>>} else if ((rph-present(msg) == TRUE) && (emergency ==
>> >>>>FALSE)) {
>> >>>>>>>>// this is not an emergency call  // this is something
>> >>>>like GETS
>> >>>>>>>>result=special-authorization-procedure(user);
>> >>>>>>>>
>> >>>>>>>>if (result == AUTHORIZED) {
>> >>>>>>>>   // do some priority & preemption thing here.
>> >>>>>>>>   // trigger all the QoS you have
>> >>>>>>>>   lots-of-code-here();
>> >>>>>>>>} else {
>> >>>>>>>>   log("NOT AUTHORIZED; don't DoS my network");  } }
>> else {  //
>> >>>>>>>>don't need todo any RPH processing  // this includes 
>the case 
>> >>>>>>>>where the call was an emergency call but the RPH
>> >>>>>>>>
>> >>>>>>>>// marking was not there.
>> >>>>>>>>nothing();
>> >>>>>>>>}
>> >>>>>>>>
>> >>>>>>>>---------------------------------------------------
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>Ciao
>> >>>>>>>>Hannes
>> >>>>>>>>
>> >>>>>>>>>-----Original Message-----
>> >>>>>>>>>From: [email-masked]
>> [mailto:[email-masked]] On
>> >>>>>>>>>Behalf Of Hannes Tschofenig
>> >>>>>>>>>Sent: 06 February, 2009 15:07
>> >>>>>>>>>To: 'Janet P Gunn'
>> >>>>>>>>>Cc: 'ECRIT'; [email-masked]; 
>Tschofenig,Hannes (NSN -
>> >>>>>>>>FI/Espoo)
>> >>>>>>>>>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
>> >Agenda (RPH)
>> >>>>>>>>>
>> >>>>>>>>>Who would define something that could prevent DoS problems?
>> >>>>>>>>>
>> >>>>>>>>>________________________________
>> >>>>>>>>>
>> >>>>>>>>>         From: Janet P Gunn [mailto:[email-masked]]
>> >>>>>>>>>         Sent: 06 February, 2009 14:11
>> >>>>>>>>>         To: Hannes Tschofenig
>> >>>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 
>'ECRIT'; 
>> >>>>>>>>>[email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
>> >>>>>'James
>> >>>>>>>>>M. Polk'
>> >>>>>>>>>         Subject: Re: [Ecrit] ECRIT Virtual Interim
>> >>>>Meeting: Agenda (RPH)
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>         But there is nothing IN RFC4412 that specifically
>> >>>>>>>addresses how to
>> >>>>>>>>>prevent any particular namespace being used for DoS.
>> >Anyone/any
>> >>>>>UA
>> >>>>>>>>>can ATTEMPT to invoke priority treatment by
>> attaching RPH.  For
>> >>>>>all
>> >>>>>>>>>of the 4412 namespaces, as with the new proposed
>> namespace, the
>> >>>>>>>>>mechanisms for preventing DoS are not specified in the
>> >>>>>>>document that
>> >>>>>>>>>defines the namespace.
>> >>>>>>>>>They are/will be specified elsewhere.
>> >>>>>>>>>
>> >>>>>>>>>         Janet
>> >>>>>>>>>
>> >>>>>>>>>         This is a PRIVATE message. If you are not
>> the intended
>> >>>>>>>recipient,
>> >>>>>>>>>please delete without copying and kindly advise us
>> by e-mail of
>> >>>>>the
>> >>>>>>>>>mistake in delivery.
>> >>>>>>>>>         NOTE: Regardless of content, this e-mail shall not
>> >>>>>>>operate to bind
>> >>>>>>>>>CSC to any order or other contract unless pursuant
>> to explicit
>> >>>>>>>>>written agreement or government initiative expressly
>> permitting
>> >>>>>the
>> >>>>>>>>>use of e-mail for such purpose.
>> >>>>>>>>>
>> >>>>>>>>>         [email-masked] wrote on 02/06/2009
>> >04:21:51 AM:
>> >>>>>>>>>
>> >>>>>>>>>         > Hi James,
>> >>>>>>>>>         >
>> >>>>>>>>>         > I have read RFC 4412 and also the GETS/MLPP IETF
>> >>>>>>>documents. What I
>> >>>>>>>>>would
>> >>>>>>>>>         > like to point out is that there is more
>> than just a
>> >>>>>>>header and
>> >>>>>>>>>values within
>> >>>>>>>>>         > the header that have to be considered in order to
>> >>>>>>>make a judgement
>> >>>>>>>>>of what
>> >>>>>>>>>         > is appropriate and what isn't. There is an
>> >>>>>>>architectural question
>> >>>>>>>>>and
>> >>>>>>>>>         > whether the environment we are using the stuff is
>> >>>>>>>indeed providing
>> >>>>>>>>>the
>> >>>>>>>>>         > properties you need for the solution to be
>> >>>>appropriate.
>> >>>>>>>>>         >
>> >>>>>>>>>         > Let me describe in more detail what I meant (and
>> >>>>>>>please correct me
>> >>>>>>>>>if I am
>> >>>>>>>>>         > wrong).
>> >>>>>>>>>         >
>> >>>>>>>>>         > Getting priority for SIP requests when
>> using a GETS
>> >>>>>>>alike scenario
>> >>>>>>>>>means
>> >>>>>>>>>         > that the entity that issues the request
>> is specially
>> >>>>>>>authorized
>> >>>>>>>>>since
>> >>>>>>>>>         > otherwise you introduce a nice denial of
>> >>>>service attack. This
>> >>>>>>>>>authorization
>> >>>>>>>>>         > is tied to the entity that makes the request. For
>> >>>>>>>example, the
>> >>>>>>>>>person is
>> >>>>>>>>>         > working for the government and has 
>special rights.
>> >>>>>>>>>James Bond as a (not so)
>> >>>>>>>>>         > secret agent might have these rights.
>> >>>>>>>>>         >
>> >>>>>>>>>         > The emergency services case
>> >>>>(citizen-to-authority) is a bit
>> >>>>>>>>>different as
>> >>>>>>>>>         > there aren't really special rights with 
>respect to
>> >>>>>>>authorization
>> >>>>>>>>>tied to
>> >>>>>>>>>         > individuals. Instead, the fact that
>> something is an
>> >>>>>>>emergency is
>> >>>>>>>>>purely a
>> >>>>>>>>>         > judgement of the human that dials a
>> special number.
>> >>>>>>>>>To deal with fraud, we
>> >>>>>>>>>         > discussed in the group on what we can
>> actually do to
>> >>>>>>>ensure that
>> >>>>>>>>>end users
>> >>>>>>>>>         > do not bypass security procedures (such as
>> >>>>>>>authorization checks,
>> >>>>>>>>>charging
>> >>>>>>>>>         > and so on). Part of this investigation was
>> >>>>the publication of
>> >>>>>>>>>         > http://www.ietf.org/rfc/rfc5069.txt that also
>> >>>>describes this
>> >>>>>>>>>issue.
>> >>>>>>>>>         >
>> >>>>>>>>>         > So, imagine the implementation of a SIP
>> >proxy (and we
>> >>>>>>>implemented
>> >>>>>>>>>that
>> >>>>>>>>>         > stuff) that receives a call that contains
>> a Service
>> >>>>>>>URN. The code
>> >>>>>>>>>branches
>> >>>>>>>>>         > into a special mode where everything is done
>> >>>>so that the call
>> >>>>>>>>>receives
>> >>>>>>>>>         > appropriate treatment and does not get
>> >dropped on the
>> >>>>>>>floor. The
>> >>>>>>>>>way how the
>> >>>>>>>>>         > Service URN is placed in the message
>> >ensures that the
>> >>>>>>>call cannot
>> >>>>>>>>>go to my
>> >>>>>>>>>         > friend (instead of the PSAP) unless the
>> end host ran
>> >>>>>>>LoST already.
>> >>>>>>>>>In the
>> >>>>>>>>>         > latter case, we discussed this also on the
>> >list for a
>> >>>>>>>while and
>> >>>>>>>>>Richard even
>> >>>>>>>>>         > wrote a draft about it in the context of the
>> >>>>location hiding
>> >>>>>>>>>topic, we said
>> >>>>>>>>>         > that the proxy would have to run LoST if he
>> >>>>cares about a
>> >>>>>>>>>potential
>> >>>>>>>>>         > fraudulent usage.
>> >>>>>>>>>         >
>> >>>>>>>>>         > So, what do we need todo in order to provide
>> >>>>secure RFC 4412
>> >>>>>>>>>functionality
>> >>>>>>>>>         > in our context?
>> >>>>>>>>>         >
>> >>>>>>>>>         > Do you think that the current text in
>> >>>>>>>>>         >
>> >>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-
>> local-emer
>> >>>>>>>>>gency-rph-nam
>> >>>>>>>>>         > espace-00.txt reflects any of the
>> >>>>above-described issues:
>> >>>>>>>>>         > "
>> >>>>>>>>>         >    The Security considerations that apply
>> >to RFC 4412
>> >>>>>>>>>[RFC4412]
>> >>>>>>>>>apply
>> >>>>>>>>>         >    here.  This document introduces no 
>new security
>> >>>>>>>>>issues relative
>> >>>>>>>>>to
>> >>>>>>>>>         >    RFC 4412.
>> >>>>>>>>>         > "
>> >>>>>>>>>         >
>> >>>>>>>>>         > From various discussions in GEOPRIV I recall
>> >>>>that you are
>> >>>>>>>>>super-sensitive
>> >>>>>>>>>         > regarding security and privacy. For some
>> reasons you
>> >>>>>>>don't seem to
>> >>>>>>>>>have the
>> >>>>>>>>>         > same concerns here. I would like to
>> >>>>understand your reasoning.
>> >>>>>>>>>         >
>> >>>>>>>>>         > Please also do me another favor: Don't always say
>> >>>>>>>that I don't
>> >>>>>>>>>understand
>> >>>>>>>>>         > the subject. Even if that would be the
>> case it isn't
>> >>>>>>>particular
>> >>>>>>>>>fair given
>> >>>>>>>>>         > that different folks had to educate you on other
>> >>>>>>>topics in the
>> >>>>>>>>>past as well.
>> >>>>>>>>>         > Additionally, if you listen to the audio
>> recordings
>> >>>>>>>then you will
>> >>>>>>>>>notice
>> >>>>>>>>>         > that Henning, Ted, and Jon do not seem to
>> understand
>> >>>>>>>the issue
>> >>>>>>>>>either as
>> >>>>>>>>>         > they have raised similar issues during the
>> >>>>F2F meetings.
>> >>>>>>>>>         >
>> >>>>>>>>>         > Ciao
>> >>>>>>>>>         > Hannes
>> >>>>>>>>>         >
>> >>>>>>>>>         >
>> >>>>>>>>>         > >Hannes - I believe it is you who do not
>> understand
>> >>>>>>>RFC 4412 --
>> >>>>>>>>>         > >and many of us are trying to get that
>> >>>>through to you, but you
>> >>>>>>>>>         > >don't seem to want to listen/read.
>> >>>>>>>>>         > >
>> >>>>>>>>>         > >RFC 4412 is *for* priority marking SIP requests,
>> >>>>>>>>>         > >
>> >>>>>>>>>         > >One use is GETS.
>> >>>>>>>>>         > >
>> >>>>>>>>>         > >One use is MLPP.
>> >>>>>>>>>         > >
>> >>>>>>>>>         > >These examples are in RFC 4412 because there
>> >>>>were specific
>> >>>>>>>>>         > >namespaces being created for the IANA section of
>> >>>>>>>that document.
>> >>>>>>>>>         > >
>> >>>>>>>>>         > >Reading the whole document, you will see
>> >>>>that RPH can be
>> >>>>>>>>>         > >specified for other uses than GETS or MLPP
>> >>>>specifically.
>> >>>>>>>>>         > >
>> >>>>>>>>>         > >I knew when I wrote RFC 4412 that one day we
>> >>>>would specify a
>> >>>>>>>>>         > >namespace for ECRIT (the "esnet" namespace
>> >>>>now) -- but I also
>> >>>>>>>>>         > >knew it was premature for RFC 4412 to
>> >>>>incorporate that
>> >>>>>>>>>         > >namespace, that a future doc to RFC 4412
>> >>>>would have to be
>> >>>>>>>>>         > >written to do this. Brian and I talked about
>> >>>>this at the
>> >>>>>>>>>         > >original NENA meeting that created the
>> IP WGs there
>> >>>>>>>(in August
>> >>>>>>>>>         > >of 03).  We both agreed we should wait
>> until it was
>> >>>>>>>>>         > >appropriate to the work in the IETF to
>> >>>>submit this document
>> >>>>>>>>>         > >that is now
>> >>>>>>>>>         >
>> >>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-l
>> >ocal-emer
>> >>>>>>>>>         > >gency-rph-namespace-00.txt
>> >>>>>>>>>         > >
>> >>>>>>>>>         > >Yet, you seem to want to use some additional
>> >>>>mechanism to
>> >>>>>>>>>         > >indicate priority of a call in SIP.  That
>> >>>>means you want to
>> >>>>>>>>>         > >introduce a second way to accomplish 
>this in SIP.
>> >>>>>>>>>Why do you
>> >>>>>>>>>         > >want to promote a separate way to do
>> something SIP
>> >>>>>>>has already
>> >>>>>>>>>         > >defined? That will cause interoperability
>> >issues and
>> >>>>>>>we both know
>> >>>>>>>>>that.
>> >>>>>>>>>         > >
>> >>>>>>>>>         > >You've said to me (and others) that you
>> >>>>believe RPH is just
>> >>>>>>>>>         > >another way to accomplish what sos or a URI can
>> >>>>>>>indicate - and
>> >>>>>>>>>         > >you're wrong.  Your way would be
>> >>>>_the_second_way_to_do_it,
>> >>>>>>>>>         > >because SIP already considers RPH to be
>> >>>>*the*way* to priority
>> >>>>>>>>>         > >mark SIP requests.
>> >>>>>>>>>         > >
>> >>>>>>>>>         > >If you don't believe me (no comment), then
>> >>>>why do you not
>> >>>>>>>>>         > >believe the SIP WG chair (who knows more
>> >>>>about SIP than both
>> >>>>>>>>>         > >of us) - who, on this thread, has again said
>> >>>>to you "RFC 4412
>> >>>>>>>>>         > >(RPH) is the SIP mechanism to priority mark
>> >>>>SIP requests"?
>> >>>>>>>>>         > >
>> >>>>>>>>>         > >Further, I believe it is inappropriate to
>> >>>>prohibit endpoints
>> >>>>>>>>>         > >from being able to set the esnet namespace.
>> >>>>I absolutely
>> >>>>>>>>>         > >believe it will not be needed most of the
>> >>>>time, but I believe
>> >>>>>>>>>         > >if someone does find a valid use for
>> >>>>endpoints to mark
>> >>>>>>>>>         > >priority in SIP, this ID - once it has
>> >>>>become an RFC -- will
>> >>>>>>>>>         > >have to be obsoleted with a new RFC saying
>> >the exact
>> >>>>>>>opposite.
>> >>>>>>>>>         > >
>> >>>>>>>>>         > >(color me confused ... over and over again)
>> >>>>>>>>>         > >
>> >>>>>>>>>         > >James
>> >>>>>>>>>         > >
>> >>>>>>>>>         > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>> >>>>>>>>>         > >>Keith, please understand that the usage
>> >of RFC 4412
>> >>>>>>>for GETS and
>> >>>>>>>>>for
>> >>>>>>>>>         > >>the type of emergency call we discuss here is
>> >>>>>>>different. Just
>> >>>>>>>>>looking
>> >>>>>>>>>         > >>at the header and the name of the
>> >namespace is a bit
>> >>>>>>>>>         > >artificial. I hope
>> >>>>>>>>>         > >>you understand that.
>> >>>>>>>>>         > >>
>> >>>>>>>>>         > >> >-----Original Message-----
>> >>>>>>>>>         > >> >From: DRAGE, Keith (Keith) 
>> >>>>>>>>>[mailto:[email-masked]]
>> >>>>>>>>>         > >> >Sent: 05 February, 2009 14:55
>> >>>>>>>>>         > >> >To: Brian Rosen; 'Hannes Tschofenig';
>> 'James M.
>> >>>>>>>>>Polk'; 'Tschofenig,
>> >>>>>>>>>         > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
>> >>>>>>>>>         > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
>> >>>>>>>>>Meeting: Agenda (my
>> >>>>>>>>>
>> >>>>>>>>>         > >> >mistake)
>> >>>>>>>>>         > >> >
>> >>>>>>>>>         > >> >Which is exactly what RFC 4412
>> specifies for all
>> >>>>>>>namespaces.
>> >>>>>>>>>         > >> >
>> >>>>>>>>>         > >> >regards
>> >>>>>>>>>         > >> >
>> >>>>>>>>>         > >> >Keith
>> >>>>>>>>>         > >> >
>> >>>>>>>>>         > >> >> -----Original Message-----
>> >>>>>>>>>         > >> >> From: [email-masked]
>> >>>>>>>[mailto:[email-masked]]
>> >>>>>>>>>         > >> >On Behalf
>> >>>>>>>>>         > >> >> Of Brian Rosen
>> >>>>>>>>>         > >> >> Sent: Wednesday, February 04, 2009 10:19 PM
>> >>>>>>>>>         > >> >> To: 'Hannes Tschofenig'; 'James M.
>> >>>>Polk'; 'Tschofenig,
>> >>>>>>>>>         > >Hannes (NSN
>> >>>>>>>>>         > >> >> - FI/Espoo)'; 'ECRIT'
>> >>>>>>>>>         > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>> >>>>>>>>>Meeting: Agenda (my
>> >>>>>>>>>         > >> >> mistake)
>> >>>>>>>>>         > >> >>
>> >>>>>>>>>         > >> >> The value is that in some networks
>> >>>>where priority for
>> >>>>>>>>>         > >> >emergency calls
>> >>>>>>>>>         > >> >> is appropriate, and appropriate
>> >>>>policing of marking is
>> >>>>>>>>>         > >implemented,
>> >>>>>>>>>         > >> >> emergency calls will receive resource
>> >priority.
>> >>>>>>>>>         > >> >>
>> >>>>>>>>>         > >> >> Not all networks would need policing.  Some
>> >>>>>>>will.  Policing
>> >>>>>>>>>could
>> >>>>>>>>>         > >> >> be to Route header/R-URI content, but other
>> >>>>>>>criteria are
>> >>>>>>>>>possible.
>> >>>>>>>>>         > >> >>
>> >>>>>>>>>         > >> >> Not all networks will need 
>resource priority
>> >>>>>>>for emergency
>> >>>>>>>>>calls.
>> >>>>>>>>>         > >> >> Fine, ignore this marking/namespace.
>> >>>>>>>>>         > >> >>
>> >>>>>>>>>         > >> >> Brian
>> >>>>>>>>>         > >> >> > -----Original Message-----
>> >>>>>>>>>         > >> >> > From: Hannes Tschofenig 
>> >>>>>>>>>[mailto:[email-masked]]
>> >>>>>>>>>         > >> >> > Sent: Wednesday, February 04, 
>2009 5:09 PM
>> >>>>>>>>>         > >> >> > To: 'Brian Rosen'; 'James M. Polk';
>> >>>>>>>Tschofenig, Hannes
>> >>>>>>>>>(NSN -
>> >>>>>>>>>         > >> >> > FI/Espoo); 'ECRIT'
>> >>>>>>>>>         > >> >> > Subject: RE: [Ecrit] ECRIT 
>Virtual Interim
>> >>>>>>>>>Meeting: Agenda (my
>> >>>>>>>>>         > >> >> > mistake)
>> >>>>>>>>>         > >> >> >
>> >>>>>>>>>         > >> >> > I don't even see the value in
>> permitting the
>> >>>>>>>endpoint todo
>> >>>>>>>>>the
>> >>>>>>>>>         > >> >> > RPH marking.
>> >>>>>>>>>         > >> >> > In addition to the security concerns
>> >>>>there is also the
>> >>>>>>>>>         > >> >problem that
>> >>>>>>>>>         > >> >> > there are more options to
>> implement without
>> >>>>>>>an additional
>> >>>>>>>>>value.
>> >>>>>>>>>         > >> >> >
>> >>>>>>>>>         > >> >> > >-----Original Message-----
>> >>>>>>>>>         > >> >> > >From: Brian Rosen
>> >[mailto:[email-masked]]
>> >>>>>>>>>         > >> >> > >Sent: 05 February, 2009 00:03
>> >>>>>>>>>         > >> >> > >To: 'James M. Polk'; 'Hannes 
>Tschofenig';
>> >>>>>>>'Tschofenig,
>> >>>>>>>>>         > >> >> Hannes (NSN -
>> >>>>>>>>>         > >> >> > >FI/Espoo)'; 'ECRIT'
>> >>>>>>>>>         > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual
>> >>>>Interim Meeting:
>> >>>>>>>>>Agenda (my
>> >>>>>>>>>         > >> >> > mistake)
>> >>>>>>>>>         > >> >> > >
>> >>>>>>>>>         > >> >> > >Hannes
>> >>>>>>>>>         > >> >> > >
>> >>>>>>>>>         > >> >> > >This matches my understanding
>> >>>>precisely.  We wish to
>> >>>>>>>>>         > >> >> permit endpoints
>> >>>>>>>>>         > >> >> > >to mark. We do not require it, and
>> >>>>don't necessarily
>> >>>>>>>>>expect it
>> >>>>>>>>>         > >> >> > >in many (even
>> >>>>>>>>>         > >> >> > >most) cases.  We don't wish to see the
>> >>>>>>>document prohibit
>> >>>>>>>>>it.
>> >>>>>>>>>         > >> >> > >We all seem to agree it has value
>> >within the
>> >>>>>>>Emergency
>> >>>>>>>>>         > >> >Services IP
>> >>>>>>>>>         > >> >> > >Networks.
>> >>>>>>>>>         > >> >> > >
>> >>>>>>>>>         > >> >> > >Brian
>> >>>>>>>>>         > >> >> > >
>> >>>>>>>>>         > >> >> > >> -----Original Message-----
>> >>>>>>>>>         > >> >> > >> From: [email-masked] 
>> >>>>>>>>>[mailto:[email-masked]]
>> >>>>>>>>>         > >> >> > >On Behalf
>> >>>>>>>>>         > >> >> > >> Of James M. Polk
>> >>>>>>>>>         > >> >> > >> Sent: Wednesday, February 04,
>> >2009 4:01 PM
>> >>>>>>>>>         > >> >> > >> To: Hannes Tschofenig; Tschofenig,
>> >>>>Hannes (NSN -
>> >>>>>>>>>         > >> >> FI/Espoo); 'ECRIT'
>> >>>>>>>>>         > >> >> > >> Subject: Re: [Ecrit] ECRIT
>> >Virtual Interim
>> >>>>>>>>>Meeting:
>> >>>>>>>>>         > >Agenda (my
>> >>>>>>>>>         > >> >> > >> mistake)
>> >>>>>>>>>         > >> >> > >>
>> >>>>>>>>>         > >> >> > >> At 02:37 PM 2/4/2009, Hannes
>> >>>>Tschofenig wrote:
>> >>>>>>>>>         > >> >> > >> > > James wrote:
>> >>>>>>>>>         > >> >> > >> > >> you are the _lone_ voice not
>> >>>>>>>supporting this ID,
>> >>>>>>>>>         > >> >> > >> >
>> >>>>>>>>>         > >> >> > >> >Listening to the audio
>> recording of past
>> >>>>>>>meetings I
>> >>>>>>>>>have to
>> >>>>>>>>>         > >> >> > >say that
>> >>>>>>>>>         > >> >> > >> >I
>> >>>>>>>>>         > >> >> > >> was
>> >>>>>>>>>         > >> >> > >> >not the only persons raising
>> >>>>concerns about the
>> >>>>>>>>>document.
>> >>>>>>>>>         > >> >> > >> >That was probably the reason why you
>> >>>>>>>agreed to limit
>> >>>>>>>>>the
>> >>>>>>>>>         > >> >> > >scope of the
>> >>>>>>>>>         > >> >> > >> >document (which you didn't
>> later do) to
>> >>>>>>>get folks to
>> >>>>>>>>>agree
>> >>>>>>>>>         > >> >> > >to make it
>> >>>>>>>>>         > >> >> > >> a WG
>> >>>>>>>>>         > >> >> > >> >item.
>> >>>>>>>>>         > >> >> > >>
>> >>>>>>>>>         > >> >> > >> re-listen to the audio please
>> >>>>>>>>>         > >> >> > >>
>> >>>>>>>>>         > >> >> > >> Ted's concerns were consistent
>> with most
>> >>>>>>>>>(all?) other
>> >>>>>>>>>         > >> >> concerns --
>> >>>>>>>>>         > >> >> > >> which were based on the premise
>> >of whether
>> >>>>>>>or not the
>> >>>>>>>>>         > >> >> UAC should be
>> >>>>>>>>>         > >> >> > >> trusted to initiate the marking on the
>> >>>>>>>INVITE.  The
>> >>>>>>>>>most
>> >>>>>>>>>         > >> >> > >> recent version has backed off this
>> >>>>to a "can" --
>> >>>>>>>>>meaning not
>> >>>>>>>>>         > >> >prohibited
>> >>>>>>>>>         > >> >> > >> (i.e., no 2119 text).  I also
>> backed off
>> >>>>>>>the text in
>> >>>>>>>>>the
>> >>>>>>>>>         > >> >> SP domain
>> >>>>>>>>>         > >> >> > >> part to "can", such that there is
>> >>>>no 2119 text
>> >>>>>>>>>         > >> >mandating or even
>> >>>>>>>>>         > >> >> > >> recommending its usage there. 
>I also do
>> >>>>>>>not prohibit
>> >>>>>>>>>its
>> >>>>>>>>>         > >> >> > >use, based on
>> >>>>>>>>>         > >> >> > >> local policy.  Keith has come
>> >forward with
>> >>>>>>>the specific
>> >>>>>>>>>
>> >>>>>>>>>         > >> >> > >> request that non-ESInet networks be
>> >>>>>>>allowed to mark and
>> >>>>>>>>>pay
>> >>>>>>>>>         > >> >attention to
>> >>>>>>>>>         > >> >> > >> this priority indication -- 
>with IMS as
>> >>>>>>>the specific
>> >>>>>>>>>example
>> >>>>>>>>>         > >> >> > >> he wishes to have this valid for.
>> >>>>>>>>>         > >> >> > >>
>> >>>>>>>>>         > >> >> > >> Where there is no
>> disagreement, save for
>> >>>>>>>your recent
>> >>>>>>>>>         > >> >> > >pushback - is in
>> >>>>>>>>>         > >> >> > >> the ESInet, which is where Brian
>> >>>>has requested it's
>> >>>>>>>>>         > >> >> > >definition in the
>> >>>>>>>>>         > >> >> > >> IETF on behalf of NENA.  He's 
>the i3 WG
>> >>>>>>>chair within
>> >>>>>>>>>         > >> >> NENA, and if
>> >>>>>>>>>         > >> >> > >> he asks for it, are you going
>> to say you
>> >>>>>>>know better
>> >>>>>>>>>than he?
>> >>>>>>>>>         > >> >> > >>
>> >>>>>>>>>         > >> >> > >>
>> >>>>>>>>>         > >> >> > >> >Btw, I not disagreeing with
>> the document
>> >>>>>>>as such. I
>> >>>>>>>>>         > >> >just want to
>> >>>>>>>>>         > >> >> > the
>> >>>>>>>>>         > >> >> > >> scope
>> >>>>>>>>>         > >> >> > >> >to change. The usage of RPH
>> >>>>within the emergency
>> >>>>>>>>>         > >> >> services network
>> >>>>>>>>>         > >> >> > is
>> >>>>>>>>>         > >> >> > >> fine
>> >>>>>>>>>         > >> >> > >> >for me. I may get convinced
>> to start the
>> >>>>>>>RPH marking
>> >>>>>>>>>from
>> >>>>>>>>>         > >> >> > >the the VSP
>> >>>>>>>>>         > >> >> > >> >towards the PSAP. I feel uneasy
>> >about the
>> >>>>>>>end host
>> >>>>>>>>>doing
>> >>>>>>>>>         > >> >> > >the marking.
>> >>>>>>>>>         > >> >> > >>
>> >>>>>>>>>         > >> >> > >> please read what I wrote
>> above, and then
>> >>>>>>>re-read the
>> >>>>>>>>>         > >> >most recent
>> >>>>>>>>>         > >> >> > >> version of the ID. I don't
>> have endpoints
>> >>>>>>>that SHOULD
>> >>>>>>>>>or
>> >>>>>>>>>         > >> >> MUST mark
>> >>>>>>>>>         > >> >> > >> anything wrt RPH.  I also 
>don't want to
>> >>>>>>>prohibit it,
>> >>>>>>>>>         > >> >> because there
>> >>>>>>>>>         > >> >> > >> might be cases (that I don't know
>> >>>>of) of valid uses
>> >>>>>>>>>         > >> >> under certain
>> >>>>>>>>>         > >> >> > >> circumstances.  Figure 1 is very clear
>> >>>>>>>that there are 3
>> >>>>>>>>>         > >> >> networking
>> >>>>>>>>>         > >> >> > >> parts to consider
>> >>>>>>>>>         > >> >> > >>
>> >>>>>>>>>         > >> >> > >> #1 - from the endpoint
>> >>>>>>>>>         > >> >> > >> #2 - within the VSP
>> >>>>>>>>>         > >> >> > >> #3 - within the ESInet
>> >>>>>>>>>         > >> >> > >>
>> >>>>>>>>>         > >> >> > >> the most recent ID version has
>> "can" for
>> >>>>>>>#s 1 and 2,
>> >>>>>>>>>and
>> >>>>>>>>>         > >> >> > >2119 language
>> >>>>>>>>>         > >> >> > >> offering those supporting this
>> >>>>>>>specification will have
>> >>>>>>>>>RPH
>> >>>>>>>>>         > >> >> > >> adherence within #3 (the ESInet).
>> >>>>>>>>>         > >> >> > >>
>> >>>>>>>>>         > >> >> > >> What other scope changes do you want,
>> >>>>>>>because I haven't
>> >>>>>>>>>         > >> >> heard them.
>> >>>>>>>>>         > >> >> > >>
>> >>>>>>>>>         > >> >> > >> I only heard you claim in email
>> >during the
>> >>>>>>>last IETF
>> >>>>>>>>>and in
>> >>>>>>>>>         > >> >> > >the ECRIT
>> >>>>>>>>>         > >> >> > >> session that RPH should not be
>> >>>>used for priority
>> >>>>>>>>>marking
>> >>>>>>>>>         > >> >> requests.
>> >>>>>>>>>         > >> >> > >> This is something Keith (SIP WG
>> >>>>chair) voiced his
>> >>>>>>>>>opposition
>> >>>>>>>>>         > >> >> > >> to your views regarding
>> creating a second
>> >>>>>>>means for SIP
>> >>>>>>>>>to
>> >>>>>>>>>         > >> >priority
>> >>>>>>>>>         > >> >> > >> mark request "when SIP already has one
>> >>>>>>>interoperable
>> >>>>>>>>>way to
>> >>>>>>>>>         > >> >> > >> accomplish this... it's call the
>> >RP header
>> >>>>>>>mechanism".
>> >>>>>>>>>         > >> >> > >>
>> >>>>>>>>>         > >> >> > >> >I don't see advantages -- only
>> >>>>disadvantages.
>> >>>>>>>>>         > >> >> > >> >
>> >>>>>>>>>         > >> >> > >> >Ciao
>> >>>>>>>>>         > >> >> > >> >Hannes
>> >>>>>>>>>         > >> >> > >>
>> >>>>>>>>>         > >> >> > >>
>> >>>>_______________________________________________
>> >>>>>>>>>         > >> >> > >> Ecrit mailing list
>> >>>>>>>>>         > >> >> > >> [email-masked]
>> >>>>>>>>>         > >> >> > >>
>> >https://www.ietf.org/mailman/listinfo/ecrit
>> >>>>>>>>>         > >> >> > >
>> >>>>>>>>>         > >> >>
>> >>>>>>>>>         > >> >>
>> >_______________________________________________
>> >>>>>>>>>         > >> >> Ecrit mailing list
>> >>>>>>>>>         > >> >> [email-masked]
>> >>>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >>>>>>>>>         > >> >>
>> >>>>>>>>>         > >> >
>> >>>>>>>>>         > >
>> >>>>>>>>>         >
>> >>>>>>>>>         > _______________________________________________
>> >>>>>>>>>         > Ecrit mailing list
>> >>>>>>>>>         > [email-masked]
>> >>>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>_______________________________________________
>> >>>>>>>>>Ecrit mailing list
>> >>>>>>>>>[email-masked]
>> >>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>> >>>>>>>>
>> >>>>>>>>_______________________________________________
>> >>>>>>>>Ecrit mailing list
>> >>>>>>>>[email-masked]
>> >>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>> >>>>>>
>> >>>>>>_______________________________________________
>> >>>>>>Ecrit mailing list
>> >>>>>>[email-masked]
>> >>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>> >>>
>> >>>_______________________________________________
>> >>>Ecrit mailing list
>> >>>[email-masked]
>> >>>https://www.ietf.org/mailman/listinfo/ecrit
>> >>>
>> >>>
>> >>>-------------------------------------------------------------
>> >-----------------------------------
>> >>>This message is for the designated recipient only and may contain 
>> >>>privileged, proprietary, or otherwise private information.
>> >>>If you have received it in error, please notify the sender 
>> >>>immediately and delete the original.  Any unauthorized 
>use of this 
>> >>>email is prohibited.
>> >>>-------------------------------------------------------------
>> >-----------------------------------
>> >>>[mf2]
>> >>>
>> >>
>> >>_______________________________________________
>> >>Ecrit mailing list
>> >>[email-masked]
>> >>https://www.ietf.org/mailman/listinfo/ecrit
>> >
>> >_______________________________________________
>> >Ecrit mailing list
>> >[email-masked]
>> >https://www.ietf.org/mailman/listinfo/ecrit
>> >_______________________________________________
>> >Ecrit mailing list
>> >[email-masked]
>> >https://www.ietf.org/mailman/listinfo/ecrit
>> >
>>
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'DRAGE, Keith \(Keith\)'" <[email-masked]>, "'Winterbottom, James'" <[email-masked]>, "'Brian Rosen'" <[email-masked]>, "'Henning Schulzrinne'" <[email-masked]>
Date: Sat, 7 Feb 2009 10:28:40 +0200
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] RPH

What do you think is the semantic of the Service URN (or the respective dial
string)?  
Emergency call with special processing needed? Do everything so that the
call gets through? 

How often do you want to say that the call is really important to you? 

We could invent a few more headers say "Yes, it is really important. Believe
me -- really, really important. Also add location because that it could be
needed to locate me.". See my other mail where I invented such a new header
that from a philosophical point of view (not from a practical) makes a lot
of sense.

Code just needs to know it is important and can do all the necessary steps. 
I doubt that someone would write code that does not treat the emergency call
as less important when an emergency call comes in that does not have the
ECRIT RPH header present. Would you think so? 

Ciao
Hannes
 
>-----Original Message-----
>From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
>Sent: 07 February, 2009 02:15
>To: Winterbottom, James; Hannes Tschofenig; Brian Rosen; 
>Henning Schulzrinne
>Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>Subject: RE: [Ecrit] RPH
>
>It is a valid header for that usage. It carries exactly the 
>semantics the user wishes to convey, i.e. that the requestor 
>would like the call to be treated in processing by the network 
>in a manner appropriate to emergency calls.
>
>Yes the edge proxy may well review and make up its own mind, 
>and either remove, verify or pass on the header, but that does 
>not mean it is wrong from the UE.
>
>You might just as well argue that the UE should not inserted a 
>P-Preferred-ID if it knows that the value it contains will be 
>the one inserted by the edge proxy.
>
>regards
>
>Keith
>
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>> Of Winterbottom, James
>> Sent: Friday, February 06, 2009 8:02 PM
>> To: Hannes Tschofenig; Brian Rosen; Henning Schulzrinne
>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>> Subject: Re: [Ecrit] RPH
>>
>> Hi All,
>>
>> I have followed thi thread with some interest and I 
>struggling to see 
>> a use case for the providing RPH for emergency calls from the 
>> end-point.
>>
>> The reference-model call in ECRIT, for better or worse, is for all 
>> calls to go back through a home-VSP.
>> We placed quite a lot of emphasis, largely for traffing reasons, for 
>> the VSP to be able to verify that a call is in fact an 
>emergency call. 
>> This is done by the proxy taking the inband location, doing a LoST 
>> query with the provided URN, and verifying that the resulting 
>> destination URI is the same as the destination URI provide 
>in the SIP 
>> INVITE. My understanding was that VSPs would always do this check so 
>> they could tell if they could bill for the call or not, and because 
>> the VSP can be use that the call is an emergency call it can 
>apply any 
>> special priorities that may be applicable.
>> This obviates the need for RPH from the end-point to the network.
>>
>> This leaves us with the argument of "it doesn't hurt to it", 
>which is 
>> not a good reason to write a specification.
>> It was intimated on the geopriv mailing list last year that great 
>> pains had been taken to keep SIP with in the MTU limits of UDP over 
>> Ethernet 
>> (http://www.ietf.org/mail-archive/web/geopriv/current/msg06120
>> .html). Assuming that this is the case, perhaps there is harm in 
>> including information that we know will be ignored.
>>
>> Cheers
>> James
>>
>>
>>
>> -----Original Message-----
>> From: [email-masked] on behalf of Hannes Tschofenig
>> Sent: Fri 2/6/2009 12:33 PM
>> To: 'Brian Rosen'; 'Henning Schulzrinne'
>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
>> Subject: Re: [Ecrit] RPH
>>
>> To the story short here is the code for the proxy:
>>
>> ---------------------
>>
>> IF emergency call was recognized THEN
>>     execute emergency call specific procedures (priority queuing, 
>> preemption, fetch location, determine routing, do funny QoS things & 
>> co) ELSE
>>     normal call handling procedures.
>>
>> ---------------------
>>
>> If you can make this differentiation between an emergency call and a 
>> regular call then you can also do everything that is necessary for 
>> emergency call handling.
>>
>> Brian + Keith: Please tell me that we cannot do the above with our 
>> currently specified mechanisms.
>>
>> Ciao
>> Hannes
>>
>> >-----Original Message-----
>> >From: Brian Rosen [mailto:[email-masked]]
>> >Sent: 06 February, 2009 17:49
>> >To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
>> >Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
>> >Subject: RE: [Ecrit] RPH
>> >
>> >I agree that not all networks will permit (or pay attention
>> >to) a priority request from an end device.
>> >
>> >No one has asked for that.
>> >
>> >The namespace request has several uses, one of which is within an 
>> >emergency services IP network, one of which is between
>> elements within
>> >a public network controlled by the operator, and one of which is an 
>> >endpoint request for resource priority.
>> >
>> >Those of us requesting this work proceed are happy if the
>> endpoint part
>> >is simply left as possible (MAY), and, speaking for myself,
>> having the
>> >draft discuss the security implications of endpoint marking is 
>> >reasonable.
>> >
>> >Having discussed this issue with an implementation team who
>> worked on
>> >MLPP systems, I am confident I know what I'm talking about,
>> but YMMV.
>> >The fact that you could, if you wanted to, give resource
>> priority to a
>> >call you decided, however you decided, was an emergency call is an 
>> >implementation decision, and not subject to standardization.
>> >
>> >RPH is the IETF standard way for one entity to request resource 
>> >priority of another entity in a SIP system.  We're asking for a 
>> >namespace to use that within the domain of emergency calls.
>> That is, I
>> >think, a VERY reasonable request.
>> >
>> >Brian
>> >
>> >> -----Original Message-----
>> >> From: Henning Schulzrinne [mailto:[email-masked]]
>> >> Sent: Friday, February 06, 2009 10:33 AM
>> >> To: Hannes Tschofenig
>> >> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>> >> Subject: Re: [Ecrit] RPH
>> >>
>> >> To chime in here:
>> >>
>> >> I don't think it's productive to simply state that 4412
>> >doesn't worry
>> >> about authorization, so we shouldn't either (simplifying a bit).
>> >> Authorization was discussed repeatedly, and the general
>> >assumption was
>> >> that there were two conditions: Either the user invoking 
>resource- 
>> >> priority was well known and had a set of permissions that 
>could be 
>> >> checked in real time or there are ways to deal with abuse
>> after the
>> >> fact in ways that deter abuse (the court-martial kind of
>> thing in a
>> >> military context).
>> >>
>> >> The RFC 4412 security consideration (11.2) call this out 
>in pretty 
>> >> strong language:
>> >>
>> >>   Prioritized access to network and end-system resources imposes
>> >>     particularly stringent requirements on authentication and
>> >>     authorization mechanisms, since access to prioritized
>> >resources may
>> >>     impact overall system stability and performance and not
>> >just result
>> >>     in theft of, say, a single phone call.
>> >> Thus, the question is whether we have such strong
>> authentication in
>> >> emergency calling. In some cases, such as residential fixed line 
>> >> deployments where ISP = VSP, we're probably pretty close,
>> in others,
>> >> such as prepaid cell phones or hot spots or VSP-only 
>providers, we 
>> >> aren't.
>> >>
>> >> The other point that I think Hannes is making is that the
>> >information
>> >> is either redundant or dangerous. If a processing element
>> recognizes
>> >> the call as being an emergency call, it can apply whatever
>> treatment
>> >> it deems appropriate and doesn't need additional
>> information. If it
>> >> doesn't or can't, using just the RPH can be rather
>> dangerous unless
>> >> that element can be reasonably certain that there is strong 
>> >> authentication and recourse.
>> >>
>> >> I don't buy the argument that somehow finding the RPH is
>> faster than
>> >> just looking for the identifier. Thus, given that the
>> information is
>> >> either redundant or dangerous, I fail to see the advantage.
>> >>
>> >> Henning
>> >>
>> >>
>> >> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
>> >>
>> >> > Don't get hung up on the details. There are ways to optimize it.
>> >> > That was
>> >> > not the point of the code example.
>> >> >
>> >> > The problem that my pseudo code should have shown you 
>is that you
>> >> > * don't gain anything with RPH marking for the emergency
>> call case
>> >> > from the SIP UA towards the outbound proxy since the
>> functionality
>> >> > is already provide otherwise. How often does the proxy
>> need to get
>> >> > told that this is an emergency call todo whatever 
>emergency call 
>> >> > handling procedures are necessary?
>> >> > * you only introduce fraud problems (if you are not
>> >careful and you
>> >> > understand the security stuff well enough)
>> >> >
>> >> > If you can point me to people who implement the RPH
>> emergency call
>> >> > case please do so. I would love to talk to them.
>> >> >
>> >> > Ciao
>> >> > Hannes
>> >> >
>> >> > PS: You need to parse incoming messages to some extend
>> so that you
>> >> > know what it contains :-) Only looking for the emergency
>> >RPH header
>> >> > (and not for the Service URN/dial
>> >> > string) would exactly be the DoS/fraud attack I am 
>worried about.
>> >> > That's the thing Henning was worried about (go and 
>listen to the 
>> >> > past meeting minutes).
>> >> >
>> >> >
>> >> >> Hannes
>> >> >>
>> >> >> You need to talk to people who really implement this kind
>> >of thing.
>> >> >> You are way off.
>> >> >>
>> >> >> When you implement a resource priority system, the
>> point of doing
>> >> >> that is to look though the queue of work and pick out the
>> >ones with
>> >> >> priority, handling them first.  You don't do all the
>> parsing, you
>> >> >> don't do a lot of decision tree.
>> >> >>
>> >> >> Typically:
>> >> >> Check for DoS things, like too big messages, etc Do a
>> quick scan
>> >> >> for the RPH message header If found:
>> >> >> Parse the message
>> >> >> Determine validity
>> >> >> Determine priority
>> >> >> Queue on the correct work queue
>> >> >>
>> >> >> The first two actions have to be very fast.  Anyone who
>> builds a
>> >> >> SIP thingie will tell you that parsing is one of the big cycle
>> >> >> consumers: if you have to parse every message BEFORE you
>> >determine
>> >> >> priority, you can't give much resource priority.
>> >> >> Once you get the whole message parsed, you might as 
>well finish 
>> >> >> working on it, because you've done so much of the work.
>> >> >> OTHOH, finding the end-of-message delimiter and doing a quick 
>> >> >> string search for RPH is fast.  If you are doing
>> >priority, you need
>> >> >> to keep all the priority processing pretty uniform, and pretty 
>> >> >> simple, or you tend to spend too much time futzing around
>> >figuring
>> >> >> out what to do.  You put all the priority related stuff
>> together,
>> >> >> and use as much common code as possible.
>> >> >>
>> >> >> Brian
>> >> >>
>> >> >>> -----Original Message-----
>> >> >>> From: [email-masked] [mailto:[email-masked]]
>> >> >> On Behalf
>> >> >>> Of Hannes Tschofenig
>> >> >>> Sent: Friday, February 06, 2009 8:41 AM
>> >> >>> To: 'Hannes Tschofenig'; 'Janet P Gunn'
>> >> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- 
>> >> >>> [email-masked]
>> >> >>> Subject: [Ecrit] RPH
>> >> >>>
>> >> >>> Over lunch I was also thinking how an outbound proxy would
>> >> implement
>> >> >>> some of the emergency procedures. Here are some thoughts:
>> >> >>>
>> >> >>> ---------------------------------------------------
>> >> >>>
>> >> >>> // Process incoming message
>> >> >>> Parse(msg);
>> >> >>>
>> >> >>> // SIP INVITE without Service URN // legacy devices If
>> >> >>> (recognize-dialstring(msg)==TRUE) {  // we got an
>> emergency call
>> >> >>> going on  emergency=TRUE;  if (dialstring(msg) == 911) 
>> >> >>> serviceURN=urn:service:sos; } else if
>> >> >>> (recognize-serviceURN(msg)==TRUE) {  // oh. A updated
>> >device that
>> >> >>> has a service URN attached to the
>> >> call
>> >> >>>  serviceURN=retrieve_ServiceURN(msg);
>> >> >>>  emergency=TRUE;
>> >> >>> } else {
>> >> >>>  // standard SIP message
>> >> >>>  // regular processing
>> >> >>>  process(msg);
>> >> >>>  emergency=FALSE;
>> >> >>> }
>> >> >>>
>> >> >>> If (emergency == TRUE) {
>> >> >>>   // make sure that the emergency call does not get
>> >dropped on the
>> >> >>> floor
>> >> >>>   // skip authorization failures
>> >> >>>   // give the call a special treatment
>> >> >>>   lots-of-code-here();
>> >> >>>
>> >> >>>   // trigger all the QoS signaling you have in the
>> >network to make
>> >> >>> James happy
>> >> >>>   trigger-qos();
>> >> >>>
>> >> >>>   // query location
>> >> >>>   location=retrieve-location();
>> >> >>>
>> >> >>>   // determine next hop
>> >> >>>   next-hop=lost(location, serviceURN)
>> >> >>>
>> >> >>>   // attach RPH marking to outgoing msg to make James and
>> >> >> Keith happy
>> >> >>>   msg=add(msg, RPH);
>> >> >>>
>> >> >>>   send(msg, next-hop);
>> >> >>> }
>> >> >>>
>> >> >>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
>> >> >>>   // all the emergency related processing done already upfront
>> >> >>>   // hence I log something.
>> >> >>>   log(RPH_WAS_PRESENT_JUHU);
>> >> >>> } else if ((rph-present(msg) == TRUE) && (emergency ==
>> >FALSE)) {
>> >> >>> // this is not an emergency call  // this is something
>> >like GETS
>> >> >>> result=special-authorization-procedure(user);
>> >> >>>
>> >> >>>  if (result == AUTHORIZED) {
>> >> >>>    // do some priority & preemption thing here.
>> >> >>>    // trigger all the QoS you have
>> >> >>>    lots-of-code-here();
>> >> >>>  } else {
>> >> >>>    log("NOT AUTHORIZED; don't DoS my network");  } }
>> else {  //
>> >> >>> don't need todo any RPH processing  // this includes the case 
>> >> >>> where the call was an emergency call but the RPH
>> >> >>>
>> >> >>>  // marking was not there.
>> >> >>>  nothing();
>> >> >>> }
>> >> >>>
>> >> >>> ---------------------------------------------------
>> >> >>>
>> >> >>>
>> >> >>> Ciao
>> >> >>> Hannes
>> >> >>>
>> >> >>>> -----Original Message-----
>> >> >>>> From: [email-masked]
>> [mailto:[email-masked]] On
>> >> >>>> Behalf Of Hannes Tschofenig
>> >> >>>> Sent: 06 February, 2009 15:07
>> >> >>>> To: 'Janet P Gunn'
>> >> >>>> Cc: 'ECRIT'; [email-masked]; Tschofenig,Hannes (NSN -
>> >> >>> FI/Espoo)
>> >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
>> Agenda (RPH)
>> >> >>>>
>> >> >>>> Who would define something that could prevent DoS problems?
>> >> >>>>
>> >> >>>> ________________________________
>> >> >>>>
>> >> >>>>       From: Janet P Gunn [mailto:[email-masked]]
>> >> >>>>       Sent: 06 February, 2009 14:11
>> >> >>>>       To: Hannes Tschofenig
>> >> >>>>       Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; 
>> >> >>>> [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo);
>> >> 'James
>> >> >>>> M. Polk'
>> >> >>>>       Subject: Re: [Ecrit] ECRIT Virtual Interim
>> >Meeting: Agenda (RPH)
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>       But there is nothing IN RFC4412 that specifically
>> >> >> addresses how to
>> >> >>>> prevent any particular namespace being used for DoS.
>> Anyone/any
>> >> UA
>> >> >>>> can ATTEMPT to invoke priority treatment by attaching
>> RPH.  For
>> >> all
>> >> >>>> of the 4412 namespaces, as with the new proposed
>> namespace, the
>> >> >>>> mechanisms for preventing DoS are not specified in the
>> >> >> document that
>> >> >>>> defines the namespace.
>> >> >>>> They are/will be specified elsewhere.
>> >> >>>>
>> >> >>>>       Janet
>> >> >>>>
>> >> >>>>       This is a PRIVATE message. If you are not the intended
>> >> >> recipient,
>> >> >>>> please delete without copying and kindly advise us by
>> e-mail of
>> >> the
>> >> >>>> mistake in delivery.
>> >> >>>>       NOTE: Regardless of content, this e-mail shall not
>> >> >> operate to bind
>> >> >>>> CSC to any order or other contract unless pursuant to
>> explicit
>> >> >>>> written agreement or government initiative expressly
>> permitting
>> >> the
>> >> >>>> use of e-mail for such purpose.
>> >> >>>>
>> >> >>>>       [email-masked] wrote on 02/06/2009 04:21:51 AM:
>> >> >>>>
>> >> >>>>       > Hi James,
>> >> >>>>       >
>> >> >>>>       > I have read RFC 4412 and also the GETS/MLPP IETF
>> >> >> documents. What I
>> >> >>>> would
>> >> >>>>       > like to point out is that there is more than just a
>> >> >> header and
>> >> >>>> values within
>> >> >>>>       > the header that have to be considered in order to
>> >> >> make a judgement
>> >> >>>> of what
>> >> >>>>       > is appropriate and what isn't. There is an
>> >> >> architectural question
>> >> >>>> and
>> >> >>>>       > whether the environment we are using the stuff is
>> >> >> indeed providing
>> >> >>>> the
>> >> >>>>       > properties you need for the solution to be
>> >appropriate.
>> >> >>>>       >
>> >> >>>>       > Let me describe in more detail what I meant (and
>> >> >> please correct me
>> >> >>>> if I am
>> >> >>>>       > wrong).
>> >> >>>>       >
>> >> >>>>       > Getting priority for SIP requests when using a GETS
>> >> >> alike scenario
>> >> >>>> means
>> >> >>>>       > that the entity that issues the request is specially
>> >> >> authorized
>> >> >>>> since
>> >> >>>>       > otherwise you introduce a nice denial of
>> >service attack. This
>> >> >>>> authorization
>> >> >>>>       > is tied to the entity that makes the request. For
>> >> >> example, the
>> >> >>>> person is
>> >> >>>>       > working for the government and has special rights.
>> >> >>>> James Bond as a (not so)
>> >> >>>>       > secret agent might have these rights.
>> >> >>>>       >
>> >> >>>>       > The emergency services case
>> >(citizen-to-authority) is a bit
>> >> >>>> different as
>> >> >>>>       > there aren't really special rights with respect to
>> >> >> authorization
>> >> >>>> tied to
>> >> >>>>       > individuals. Instead, the fact that something is an
>> >> >> emergency is
>> >> >>>> purely a
>> >> >>>>       > judgement of the human that dials a special number.
>> >> >>>> To deal with fraud, we
>> >> >>>>       > discussed in the group on what we can actually do to
>> >> >> ensure that
>> >> >>>> end users
>> >> >>>>       > do not bypass security procedures (such as
>> >> >> authorization checks,
>> >> >>>> charging
>> >> >>>>       > and so on). Part of this investigation was
>> >the publication of
>> >> >>>>       > http://www.ietf.org/rfc/rfc5069.txt that also
>> >describes this
>> >> >>>> issue.
>> >> >>>>       >
>> >> >>>>       > So, imagine the implementation of a SIP proxy (and we
>> >> >> implemented
>> >> >>>> that
>> >> >>>>       > stuff) that receives a call that contains a Service
>> >> >> URN. The code
>> >> >>>> branches
>> >> >>>>       > into a special mode where everything is done
>> >so that the call
>> >> >>>> receives
>> >> >>>>       > appropriate treatment and does not get dropped on the
>> >> >> floor. The
>> >> >>>> way how the
>> >> >>>>       > Service URN is placed in the message ensures that the
>> >> >> call cannot
>> >> >>>> go to my
>> >> >>>>       > friend (instead of the PSAP) unless the end host ran
>> >> >> LoST already.
>> >> >>>> In the
>> >> >>>>       > latter case, we discussed this also on the list for a
>> >> >> while and
>> >> >>>> Richard even
>> >> >>>>       > wrote a draft about it in the context of the
>> >location hiding
>> >> >>>> topic, we said
>> >> >>>>       > that the proxy would have to run LoST if he
>> >cares about a
>> >> >>>> potential
>> >> >>>>       > fraudulent usage.
>> >> >>>>       >
>> >> >>>>       > So, what do we need todo in order to provide
>> >secure RFC 4412
>> >> >>>> functionality
>> >> >>>>       > in our context?
>> >> >>>>       >
>> >> >>>>       > Do you think that the current text in
>> >> >>>>       >
>> >> >>>>
>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>> >> >>>> gency-rph-nam
>> >> >>>>       > espace-00.txt reflects any of the
>> >above-described issues:
>> >> >>>>       > "
>> >> >>>>       >    The Security considerations that apply to RFC 4412
>> >> >>>> [RFC4412]
>> >> >>>> apply
>> >> >>>>       >    here.  This document introduces no new security
>> >> >>>> issues relative
>> >> >>>> to
>> >> >>>>       >    RFC 4412.
>> >> >>>>       > "
>> >> >>>>       >
>> >> >>>>       > From various discussions in GEOPRIV I recall
>> >that you are
>> >> >>>> super-sensitive
>> >> >>>>       > regarding security and privacy. For some reasons you
>> >> >> don't seem to
>> >> >>>> have the
>> >> >>>>       > same concerns here. I would like to
>> >understand your reasoning.
>> >> >>>>       >
>> >> >>>>       > Please also do me another favor: Don't always say
>> >> >> that I don't
>> >> >>>> understand
>> >> >>>>       > the subject. Even if that would be the case it isn't
>> >> >> particular
>> >> >>>> fair given
>> >> >>>>       > that different folks had to educate you on other
>> >> >> topics in the
>> >> >>>> past as well.
>> >> >>>>       > Additionally, if you listen to the audio recordings
>> >> >> then you will
>> >> >>>> notice
>> >> >>>>       > that Henning, Ted, and Jon do not seem to understand
>> >> >> the issue
>> >> >>>> either as
>> >> >>>>       > they have raised similar issues during the
>> >F2F meetings.
>> >> >>>>       >
>> >> >>>>       > Ciao
>> >> >>>>       > Hannes
>> >> >>>>       >
>> >> >>>>       >
>> >> >>>>       > >Hannes - I believe it is you who do not understand
>> >> >> RFC 4412 --
>> >> >>>>       > >and many of us are trying to get that
>> >through to you, but you
>> >> >>>>       > >don't seem to want to listen/read.
>> >> >>>>       > >
>> >> >>>>       > >RFC 4412 is *for* priority marking SIP requests,
>> >> >>>>       > >
>> >> >>>>       > >One use is GETS.
>> >> >>>>       > >
>> >> >>>>       > >One use is MLPP.
>> >> >>>>       > >
>> >> >>>>       > >These examples are in RFC 4412 because there
>> >were specific
>> >> >>>>       > >namespaces being created for the IANA section of
>> >> >> that document.
>> >> >>>>       > >
>> >> >>>>       > >Reading the whole document, you will see
>> >that RPH can be
>> >> >>>>       > >specified for other uses than GETS or MLPP
>> >specifically.
>> >> >>>>       > >
>> >> >>>>       > >I knew when I wrote RFC 4412 that one day we
>> >would specify a
>> >> >>>>       > >namespace for ECRIT (the "esnet" namespace
>> >now) -- but I also
>> >> >>>>       > >knew it was premature for RFC 4412 to
>> >incorporate that
>> >> >>>>       > >namespace, that a future doc to RFC 4412
>> >would have to be
>> >> >>>>       > >written to do this. Brian and I talked about
>> >this at the
>> >> >>>>       > >original NENA meeting that created the IP WGs there
>> >> >> (in August
>> >> >>>>       > >of 03).  We both agreed we should wait until it was
>> >> >>>>       > >appropriate to the work in the IETF to
>> >submit this document
>> >> >>>>       > >that is now
>> >> >>>>       >
>> >> >>>>>
>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>> >> >>>>       > >gency-rph-namespace-00.txt
>> >> >>>>       > >
>> >> >>>>       > >Yet, you seem to want to use some additional
>> >mechanism to
>> >> >>>>       > >indicate priority of a call in SIP.  That
>> >means you want to
>> >> >>>>       > >introduce a second way to accomplish this in SIP.
>> >> >>>> Why do you
>> >> >>>>       > >want to promote a separate way to do something SIP
>> >> >> has already
>> >> >>>>       > >defined? That will cause interoperability issues and
>> >> >> we both know
>> >> >>>> that.
>> >> >>>>       > >
>> >> >>>>       > >You've said to me (and others) that you
>> >believe RPH is just
>> >> >>>>       > >another way to accomplish what sos or a URI can
>> >> >> indicate - and
>> >> >>>>       > >you're wrong.  Your way would be
>> >_the_second_way_to_do_it,
>> >> >>>>       > >because SIP already considers RPH to be
>> >*the*way* to priority
>> >> >>>>       > >mark SIP requests.
>> >> >>>>       > >
>> >> >>>>       > >If you don't believe me (no comment), then
>> >why do you not
>> >> >>>>       > >believe the SIP WG chair (who knows more
>> >about SIP than both
>> >> >>>>       > >of us) - who, on this thread, has again said
>> >to you "RFC 4412
>> >> >>>>       > >(RPH) is the SIP mechanism to priority mark
>> >SIP requests"?
>> >> >>>>       > >
>> >> >>>>       > >Further, I believe it is inappropriate to
>> >prohibit endpoints
>> >> >>>>       > >from being able to set the esnet namespace.
>> >I absolutely
>> >> >>>>       > >believe it will not be needed most of the
>> >time, but I believe
>> >> >>>>       > >if someone does find a valid use for
>> >endpoints to mark
>> >> >>>>       > >priority in SIP, this ID - once it has
>> >become an RFC -- will
>> >> >>>>       > >have to be obsoleted with a new RFC saying the exact
>> >> >> opposite.
>> >> >>>>       > >
>> >> >>>>       > >(color me confused ... over and over again)
>> >> >>>>       > >
>> >> >>>>       > >James
>> >> >>>>       > >
>> >> >>>>       > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>> >> >>>>       > >>Keith, please understand that the usage of RFC 4412
>> >> >> for GETS and
>> >> >>>> for
>> >> >>>>       > >>the type of emergency call we discuss here is
>> >> >> different. Just
>> >> >>>> looking
>> >> >>>>       > >>at the header and the name of the 
>namespace is a bit
>> >> >>>>       > >artificial. I hope
>> >> >>>>       > >>you understand that.
>> >> >>>>       > >>
>> >> >>>>       > >> >-----Original Message-----
>> >> >>>>       > >> >From: DRAGE, Keith (Keith) 
>> >> >>>> [mailto:[email-masked]]
>> >> >>>>       > >> >Sent: 05 February, 2009 14:55
>> >> >>>>       > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
>> >> >>>> Polk'; 'Tschofenig,
>> >> >>>>       > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
>> >> >>>>       > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
>> >> >>>> Meeting: Agenda (my
>> >> >>>>
>> >> >>>>       > >> >mistake)
>> >> >>>>       > >> >
>> >> >>>>       > >> >Which is exactly what RFC 4412 specifies for all
>> >> >> namespaces.
>> >> >>>>       > >> >
>> >> >>>>       > >> >regards
>> >> >>>>       > >> >
>> >> >>>>       > >> >Keith
>> >> >>>>       > >> >
>> >> >>>>       > >> >> -----Original Message-----
>> >> >>>>       > >> >> From: [email-masked]
>> >> >> [mailto:[email-masked]]
>> >> >>>>       > >> >On Behalf
>> >> >>>>       > >> >> Of Brian Rosen
>> >> >>>>       > >> >> Sent: Wednesday, February 04, 2009 10:19 PM
>> >> >>>>       > >> >> To: 'Hannes Tschofenig'; 'James M.
>> >Polk'; 'Tschofenig,
>> >> >>>>       > >Hannes (NSN
>> >> >>>>       > >> >> - FI/Espoo)'; 'ECRIT'
>> >> >>>>       > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>> >> >>>> Meeting: Agenda (my
>> >> >>>>       > >> >> mistake)
>> >> >>>>       > >> >>
>> >> >>>>       > >> >> The value is that in some networks
>> >where priority for
>> >> >>>>       > >> >emergency calls
>> >> >>>>       > >> >> is appropriate, and appropriate
>> >policing of marking is
>> >> >>>>       > >implemented,
>> >> >>>>       > >> >> emergency calls will receive resource priority.
>> >> >>>>       > >> >>
>> >> >>>>       > >> >> Not all networks would need policing.  Some
>> >> >> will.  Policing
>> >> >>>> could
>> >> >>>>       > >> >> be to Route header/R-URI content, but other
>> >> >> criteria are
>> >> >>>> possible.
>> >> >>>>       > >> >>
>> >> >>>>       > >> >> Not all networks will need resource priority
>> >> >> for emergency
>> >> >>>> calls.
>> >> >>>>       > >> >> Fine, ignore this marking/namespace.
>> >> >>>>       > >> >>
>> >> >>>>       > >> >> Brian
>> >> >>>>       > >> >> > -----Original Message-----
>> >> >>>>       > >> >> > From: Hannes Tschofenig 
>> >> >>>> [mailto:[email-masked]]
>> >> >>>>       > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>> >> >>>>       > >> >> > To: 'Brian Rosen'; 'James M. Polk';
>> >> >> Tschofenig, Hannes
>> >> >>>> (NSN -
>> >> >>>>       > >> >> > FI/Espoo); 'ECRIT'
>> >> >>>>       > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
>> >> >>>> Meeting: Agenda (my
>> >> >>>>       > >> >> > mistake)
>> >> >>>>       > >> >> >
>> >> >>>>       > >> >> > I don't even see the value in permitting the
>> >> >> endpoint todo
>> >> >>>> the
>> >> >>>>       > >> >> > RPH marking.
>> >> >>>>       > >> >> > In addition to the security concerns
>> >there is also the
>> >> >>>>       > >> >problem that
>> >> >>>>       > >> >> > there are more options to implement without
>> >> >> an additional
>> >> >>>> value.
>> >> >>>>       > >> >> >
>> >> >>>>       > >> >> > >-----Original Message-----
>> >> >>>>       > >> >> > >From: Brian Rosen [mailto:[email-masked]]
>> >> >>>>       > >> >> > >Sent: 05 February, 2009 00:03
>> >> >>>>       > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
>> >> >> 'Tschofenig,
>> >> >>>>       > >> >> Hannes (NSN -
>> >> >>>>       > >> >> > >FI/Espoo)'; 'ECRIT'
>> >> >>>>       > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual
>> >Interim Meeting:
>> >> >>>> Agenda (my
>> >> >>>>       > >> >> > mistake)
>> >> >>>>       > >> >> > >
>> >> >>>>       > >> >> > >Hannes
>> >> >>>>       > >> >> > >
>> >> >>>>       > >> >> > >This matches my understanding
>> >precisely.  We wish to
>> >> >>>>       > >> >> permit endpoints
>> >> >>>>       > >> >> > >to mark. We do not require it, and
>> >don't necessarily
>> >> >>>> expect it
>> >> >>>>       > >> >> > >in many (even
>> >> >>>>       > >> >> > >most) cases.  We don't wish to see the
>> >> >> document prohibit
>> >> >>>> it.
>> >> >>>>       > >> >> > >We all seem to agree it has value within the
>> >> >> Emergency
>> >> >>>>       > >> >Services IP
>> >> >>>>       > >> >> > >Networks.
>> >> >>>>       > >> >> > >
>> >> >>>>       > >> >> > >Brian
>> >> >>>>       > >> >> > >
>> >> >>>>       > >> >> > >> -----Original Message-----
>> >> >>>>       > >> >> > >> From: [email-masked] 
>> >> >>>> [mailto:[email-masked]]
>> >> >>>>       > >> >> > >On Behalf
>> >> >>>>       > >> >> > >> Of James M. Polk
>> >> >>>>       > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
>> >> >>>>       > >> >> > >> To: Hannes Tschofenig; Tschofenig,
>> >Hannes (NSN -
>> >> >>>>       > >> >> FI/Espoo); 'ECRIT'
>> >> >>>>       > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>> >> >>>> Meeting:
>> >> >>>>       > >Agenda (my
>> >> >>>>       > >> >> > >> mistake)
>> >> >>>>       > >> >> > >>
>> >> >>>>       > >> >> > >> At 02:37 PM 2/4/2009, Hannes
>> >Tschofenig wrote:
>> >> >>>>       > >> >> > >> > > James wrote:
>> >> >>>>       > >> >> > >> > >> you are the _lone_ voice not
>> >> >> supporting this ID,
>> >> >>>>       > >> >> > >> >
>> >> >>>>       > >> >> > >> >Listening to the audio recording of past
>> >> >> meetings I
>> >> >>>> have to
>> >> >>>>       > >> >> > >say that
>> >> >>>>       > >> >> > >> >I
>> >> >>>>       > >> >> > >> was
>> >> >>>>       > >> >> > >> >not the only persons raising
>> >concerns about the
>> >> >>>> document.
>> >> >>>>       > >> >> > >> >That was probably the reason why you
>> >> >> agreed to limit
>> >> >>>> the
>> >> >>>>       > >> >> > >scope of the
>> >> >>>>       > >> >> > >> >document (which you didn't later do) to
>> >> >> get folks to
>> >> >>>> agree
>> >> >>>>       > >> >> > >to make it
>> >> >>>>       > >> >> > >> a WG
>> >> >>>>       > >> >> > >> >item.
>> >> >>>>       > >> >> > >>
>> >> >>>>       > >> >> > >> re-listen to the audio please
>> >> >>>>       > >> >> > >>
>> >> >>>>       > >> >> > >> Ted's concerns were consistent with most
>> >> >>>> (all?) other
>> >> >>>>       > >> >> concerns --
>> >> >>>>       > >> >> > >> which were based on the premise of whether
>> >> >> or not the
>> >> >>>>       > >> >> UAC should be
>> >> >>>>       > >> >> > >> trusted to initiate the marking on the
>> >> >> INVITE.  The
>> >> >>>> most
>> >> >>>>       > >> >> > >> recent version has backed off this
>> >to a "can" --
>> >> >>>> meaning not
>> >> >>>>       > >> >prohibited
>> >> >>>>       > >> >> > >> (i.e., no 2119 text).  I also backed off
>> >> >> the text in
>> >> >>>> the
>> >> >>>>       > >> >> SP domain
>> >> >>>>       > >> >> > >> part to "can", such that there is
>> >no 2119 text
>> >> >>>>       > >> >mandating or even
>> >> >>>>       > >> >> > >> recommending its usage there. I also do
>> >> >> not prohibit
>> >> >>>> its
>> >> >>>>       > >> >> > >use, based on
>> >> >>>>       > >> >> > >> local policy.  Keith has come forward with
>> >> >> the specific
>> >> >>>>
>> >> >>>>       > >> >> > >> request that non-ESInet networks be
>> >> >> allowed to mark and
>> >> >>>> pay
>> >> >>>>       > >> >attention to
>> >> >>>>       > >> >> > >> this priority indication -- with IMS as
>> >> >> the specific
>> >> >>>> example
>> >> >>>>       > >> >> > >> he wishes to have this valid for.
>> >> >>>>       > >> >> > >>
>> >> >>>>       > >> >> > >> Where there is no disagreement, save for
>> >> >> your recent
>> >> >>>>       > >> >> > >pushback - is in
>> >> >>>>       > >> >> > >> the ESInet, which is where Brian
>> >has requested it's
>> >> >>>>       > >> >> > >definition in the
>> >> >>>>       > >> >> > >> IETF on behalf of NENA.  He's the i3 WG
>> >> >> chair within
>> >> >>>>       > >> >> NENA, and if
>> >> >>>>       > >> >> > >> he asks for it, are you going to say you
>> >> >> know better
>> >> >>>> than he?
>> >> >>>>       > >> >> > >>
>> >> >>>>       > >> >> > >>
>> >> >>>>       > >> >> > >> >Btw, I not disagreeing with the document
>> >> >> as such. I
>> >> >>>>       > >> >just want to
>> >> >>>>       > >> >> > the
>> >> >>>>       > >> >> > >> scope
>> >> >>>>       > >> >> > >> >to change. The usage of RPH
>> >within the emergency
>> >> >>>>       > >> >> services network
>> >> >>>>       > >> >> > is
>> >> >>>>       > >> >> > >> fine
>> >> >>>>       > >> >> > >> >for me. I may get convinced to start the
>> >> >> RPH marking
>> >> >>>> from
>> >> >>>>       > >> >> > >the the VSP
>> >> >>>>       > >> >> > >> >towards the PSAP. I feel uneasy about the
>> >> >> end host
>> >> >>>> doing
>> >> >>>>       > >> >> > >the marking.
>> >> >>>>       > >> >> > >>
>> >> >>>>       > >> >> > >> please read what I wrote above, and then
>> >> >> re-read the
>> >> >>>>       > >> >most recent
>> >> >>>>       > >> >> > >> version of the ID. I don't have endpoints
>> >> >> that SHOULD
>> >> >>>> or
>> >> >>>>       > >> >> MUST mark
>> >> >>>>       > >> >> > >> anything wrt RPH.  I also don't want to
>> >> >> prohibit it,
>> >> >>>>       > >> >> because there
>> >> >>>>       > >> >> > >> might be cases (that I don't know
>> >of) of valid uses
>> >> >>>>       > >> >> under certain
>> >> >>>>       > >> >> > >> circumstances.  Figure 1 is very clear
>> >> >> that there are 3
>> >> >>>>       > >> >> networking
>> >> >>>>       > >> >> > >> parts to consider
>> >> >>>>       > >> >> > >>
>> >> >>>>       > >> >> > >> #1 - from the endpoint
>> >> >>>>       > >> >> > >> #2 - within the VSP
>> >> >>>>       > >> >> > >> #3 - within the ESInet
>> >> >>>>       > >> >> > >>
>> >> >>>>       > >> >> > >> the most recent ID version has "can" for
>> >> >> #s 1 and 2,
>> >> >>>> and
>> >> >>>>       > >> >> > >2119 language
>> >> >>>>       > >> >> > >> offering those supporting this
>> >> >> specification will have
>> >> >>>> RPH
>> >> >>>>       > >> >> > >> adherence within #3 (the ESInet).
>> >> >>>>       > >> >> > >>
>> >> >>>>       > >> >> > >> What other scope changes do you want,
>> >> >> because I haven't
>> >> >>>>       > >> >> heard them.
>> >> >>>>       > >> >> > >>
>> >> >>>>       > >> >> > >> I only heard you claim in email during the
>> >> >> last IETF
>> >> >>>> and in
>> >> >>>>       > >> >> > >the ECRIT
>> >> >>>>       > >> >> > >> session that RPH should not be
>> >used for priority
>> >> >>>> marking
>> >> >>>>       > >> >> requests.
>> >> >>>>       > >> >> > >> This is something Keith (SIP WG
>> >chair) voiced his
>> >> >>>> opposition
>> >> >>>>       > >> >> > >> to your views regarding creating a second
>> >> >> means for SIP
>> >> >>>> to
>> >> >>>>       > >> >priority
>> >> >>>>       > >> >> > >> mark request "when SIP already has one
>> >> >> interoperable
>> >> >>>> way to
>> >> >>>>       > >> >> > >> accomplish this... it's call the RP header
>> >> >> mechanism".
>> >> >>>>       > >> >> > >>
>> >> >>>>       > >> >> > >> >I don't see advantages -- only
>> >disadvantages.
>> >> >>>>       > >> >> > >> >
>> >> >>>>       > >> >> > >> >Ciao
>> >> >>>>       > >> >> > >> >Hannes
>> >> >>>>       > >> >> > >>
>> >> >>>>       > >> >> > >>
>> >_______________________________________________
>> >> >>>>       > >> >> > >> Ecrit mailing list
>> >> >>>>       > >> >> > >> [email-masked]
>> >> >>>>       > >> >> > >> 
>https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>>>       > >> >> > >
>> >> >>>>       > >> >>
>> >> >>>>       > >> >> _______________________________________________
>> >> >>>>       > >> >> Ecrit mailing list
>> >> >>>>       > >> >> [email-masked]
>> >> >>>>       > >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>>>       > >> >>
>> >> >>>>       > >> >
>> >> >>>>       > >
>> >> >>>>       >
>> >> >>>>       > _______________________________________________
>> >> >>>>       > Ecrit mailing list
>> >> >>>>       > [email-masked]
>> >> >>>>       > https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> _______________________________________________
>> >> >>>> Ecrit mailing list
>> >> >>>> [email-masked]
>> >> >>>> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>>>
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> Ecrit mailing list
>> >> >>> [email-masked]
>> >> >>> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>
>> >> >
>> >> > _______________________________________________
>> >> > Ecrit mailing list
>> >> > [email-masked]
>> >> > https://www.ietf.org/mailman/listinfo/ecrit
>> >> >
>> >
>>
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>>
>> --------------------------------------------------------------
>> ----------------------------------
>> This message is for the designated recipient only and may contain 
>> privileged, proprietary, or otherwise private information.
>> If you have received it in error, please notify the sender 
>immediately 
>> and delete the original.  Any unauthorized use of this email is 
>> prohibited.
>> --------------------------------------------------------------
>> ----------------------------------
>> [mf2]
>>
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'DRAGE, Keith \(Keith\)'" <[email-masked]>, "'James M. Polk'" <[email-masked]>
Date: Sat, 7 Feb 2009 10:32:30 +0200
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)

>I don't believe anyone has been saying that. GETS and 
>emergency are two different namespaces that work within the 
>overvall framework of RPH.
>
>You implement RPH, and then configure or tailor it to the 
>namespaces you need to support, not provide a separate 
>implementation for every namespace you are called upon to support.

This is exactly the trap Henning warned us during the last meeting. 
Because the authorization handling is totally different (because of the
different context) you need to write different code. If you don't then you
introduce these security problems. 

The draft at least needs to contain a super big SECURITY WARNING so that
implements don't make that mistake. Currently it says "no security issues
beyond the initial RPH document". This is clearly wrong and even leads
experts like you to go along the wrong track. 

>
>Go that way and every request will take hours to traverse end to end.
Not sure what you mean. 

Ciao
Hannes

>
>regards
>
>Keith
>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[email-masked]]
>> Sent: Friday, February 06, 2009 10:47 PM
>> To: 'James M. Polk'
>> Cc: DRAGE, Keith (Keith); 'Brian Rosen'; Tschofenig, Hannes (NSN - 
>> FI/Espoo); 'ECRIT'
>> Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
>>
>> Good that you agree that GETS usage of RPH and the one we discuss in 
>> ECRIT is different.
>> So far, some folks have been saying "what works for GETS 
>works for the 
>> ECRIT case as well".
>>
>> I argued that the environment is different and hence just 
>referencing 
>> RFC
>> 4412 isn't good enough.
>>
>> >-----Original Message-----
>> >From: James M. Polk [mailto:[email-masked]]
>> >Sent: 07 February, 2009 00:02
>> >To: Hannes Tschofenig
>> >Cc: 'DRAGE, Keith (Keith)'; 'Brian Rosen'; Tschofenig, 
>Hannes (NSN - 
>> >FI/Espoo); 'ECRIT'
>> >Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
>> >
>> >At 03:21 AM 2/6/2009, Hannes Tschofenig wrote:
>> >>Hi James,
>> >>
>> >>I have read RFC 4412 and also the GETS/MLPP IETF documents. What I 
>> >>would like to point out is that there is more than just a
>> header and
>> >>values within the header that have to be considered in order
>> >to make a
>> >>judgement of what is appropriate and what isn't. There is an 
>> >>architectural question and whether the environment we are 
>using the 
>> >>stuff is indeed providing the properties you need for the
>> >solution to be appropriate.
>> >>
>> >>Let me describe in more detail what I meant (and please
>> >correct me if I
>> >>am wrong).
>> >>
>> >>Getting priority for SIP requests when using a GETS alike scenario 
>> >>means that the entity that issues the request is specially
>> authorized
>> >>since otherwise you introduce a nice denial of service attack.
>> >
>> >You are missing a step in GETS here.  The endpoint, who
>> sends the GETS
>> >set-up as an INVITE is not already authorized (not the
>> device, not the
>> >user).  In North America, there is a 10 digit GETS number that is 
>> >dialed (that I won't give out right now on an open list) - 
>and there 
>> >literally is only 1 number available to dial for this service.
>> >Literally anyone can dial this number today in North America
>> (no matter
>> >where the phone is - as long as it is in North America --
>> and I might
>> >be too limiting in that it is dialable from anywhere, because it is 
>> >going to a North American destination).
>> >
>> >Once this number is dialed, it is answered by an authentication and 
>> >authorization IVR.  This IVR challenges each caller for their 
>> >authentication passcode, and a password). Once this has been 
>> >successfully entered, then call is NOW authorized to 
>proceed towards 
>> >its destination number - this step is only known to the authorizing 
>> >system because the destination 10 digit number is NOT entered until 
>> >after the authentication and authorization step has completed.
>> >
>> >The authorized caller is prompted with a new dial tone - in
>> which they
>> >can enter any number on the planet and receive preferential
>> treatment
>> >through as many carriers (in IP, it's
>> >SPs) that have implemented this GETS service (which is an
>> SLA with the
>> >Department of Homeland Security now).
>> >
>> >Merely entering the GETS RP namespace is never intended,
>> alone, to gain
>> >any preferential treatment -- other than towards this
>> authentication &
>> >authorization IVR.
>> >
>> >I hope you can see that this is a completely separate type
>> of service
>> >and implementation type than ECRIT based emergency calling will use.
>> >
>> >BTW - to your comment below about me not calling your name
>> out when you
>> >are incorrect because I have been equally incorrect
>> >-- I'm not sure I've been spared as much as you think, given
>> that many
>> >have called me out by name when they've felt I've been wrong
>> over the
>> >years.
>> >
>> >>This authorization
>> >>is tied to the entity that makes the request. For example,
>> the person
>> >>is working for the government and has special rights. James
>> Bond as a
>> >>(not so) secret agent might have these rights.
>> >>
>> >>The emergency services case (citizen-to-authority) is a bit
>> different
>> >>as there aren't really special rights with respect to 
>authorization 
>> >>tied to individuals. Instead, the fact that something is an
>> emergency
>> >>is purely a judgement of the human that dials a special
>> >number. To deal
>> >>with fraud, we discussed in the group on what we can 
>actually do to 
>> >>ensure that end users do not bypass security procedures (such as 
>> >>authorization checks, charging and so on). Part of this
>> investigation
>> >>was the publication of http://www.ietf.org/rfc/rfc5069.txt
>> >that also describes this issue.
>> >>
>> >>So, imagine the implementation of a SIP proxy (and we
>> implemented that
>> >>stuff) that receives a call that contains a Service URN. The code 
>> >>branches into a special mode where everything is done so that
>> >the call
>> >>receives appropriate treatment and does not get dropped on
>> the floor.
>> >>The way how the Service URN is placed in the message
>> ensures that the
>> >>call cannot go to my friend (instead of the PSAP) unless
>> the end host
>> >>ran LoST already. In the latter case, we discussed this 
>also on the 
>> >>list for a while and Richard even wrote a draft about it in
>> >the context
>> >>of the location hiding topic, we said that the proxy would
>> >have to run
>> >>LoST if he cares about a potential fraudulent usage.
>> >>
>> >>So, what do we need todo in order to provide secure RFC 4412 
>> >>functionality in our context?
>> >>
>> >>Do you think that the current text in 
>> >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-eme
>> >rgency-rp
>> >>h-nam espace-00.txt reflects any of the above-described issues:
>> >>"
>> >>    The Security considerations that apply to RFC 4412
>> [RFC4412] apply
>> >>    here.  This document introduces no new security issues
>> relative to
>> >>    RFC 4412.
>> >>"
>> >>
>> >> From various discussions in GEOPRIV I recall that you are 
>> >>super-sensitive regarding security and privacy. For some
>> reasons you
>> >>don't seem to have the same concerns here. I would like to
>> >understand your reasoning.
>> >>
>> >>Please also do me another favor: Don't always say that I don't 
>> >>understand the subject. Even if that would be the case it isn't 
>> >>particular fair given that different folks had to educate you
>> >on other topics in the past as well.
>> >>Additionally, if you listen to the audio recordings then you will 
>> >>notice that Henning, Ted, and Jon do not seem to understand
>> the issue
>> >>either as they have raised similar issues during the F2F meetings.
>> >>
>> >>Ciao
>> >>Hannes
>> >>
>> >>
>> >> >Hannes - I believe it is you who do not understand RFC
>> 4412 -- and
>> >> >many of us are trying to get that through to you, but you
>> >don't seem
>> >> >to want to listen/read.
>> >> >
>> >> >RFC 4412 is *for* priority marking SIP requests,
>> >> >
>> >> >One use is GETS.
>> >> >
>> >> >One use is MLPP.
>> >> >
>> >> >These examples are in RFC 4412 because there were specific
>> >namespaces
>> >> >being created for the IANA section of that document.
>> >> >
>> >> >Reading the whole document, you will see that RPH can be
>> specified
>> >> >for other uses than GETS or MLPP specifically.
>> >> >
>> >> >I knew when I wrote RFC 4412 that one day we would specify a 
>> >> >namespace for ECRIT (the "esnet" namespace now) -- but I
>> >also knew it
>> >> >was premature for RFC 4412 to incorporate that namespace, that a 
>> >> >future doc to RFC 4412 would have to be written to do this.
>> >Brian and
>> >> >I talked about this at the original NENA meeting that
>> >created the IP
>> >> >WGs there (in August of 03).  We both agreed we should wait
>> >until it
>> >> >was appropriate to the work in the IETF to submit this
>> >document that
>> >> >is now
>> >> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>> >> >gency-rph-namespace-00.txt
>> >> >
>> >> >Yet, you seem to want to use some additional mechanism to
>> indicate
>> >> >priority of a call in SIP.  That means you want to
>> >introduce a second
>> >> >way to accomplish this in SIP.  Why do you want to promote
>> >a separate
>> >> >way to do something SIP has already defined? That will cause 
>> >> >interoperability issues and we both know that.
>> >> >
>> >> >You've said to me (and others) that you believe RPH is
>> just another
>> >> >way to accomplish what sos or a URI can indicate - and
>> >you're wrong.
>> >> >Your way would be _the_second_way_to_do_it, because SIP already 
>> >> >considers RPH to be *the*way* to priority mark SIP requests.
>> >> >
>> >> >If you don't believe me (no comment), then why do you not
>> >believe the
>> >> >SIP WG chair (who knows more about SIP than both of us) 
>- who, on 
>> >> >this thread, has again said to you "RFC 4412
>> >> >(RPH) is the SIP mechanism to priority mark SIP requests"?
>> >> >
>> >> >Further, I believe it is inappropriate to prohibit 
>endpoints from 
>> >> >being able to set the esnet namespace.  I absolutely
>> >believe it will
>> >> >not be needed most of the time, but I believe if someone
>> >does find a
>> >> >valid use for endpoints to mark priority in SIP, this ID
>> - once it
>> >> >has become an RFC -- will have to be obsoleted with a new
>> >RFC saying
>> >> >the exact opposite.
>> >> >
>> >> >(color me confused ... over and over again)
>> >> >
>> >> >James
>> >> >
>> >> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>> >> >>Keith, please understand that the usage of RFC 4412 for
>> >GETS and for
>> >> >>the type of emergency call we discuss here is different. Just 
>> >> >>looking at the header and the name of the namespace is a bit
>> >> >artificial. I hope
>> >> >>you understand that.
>> >> >>
>> >> >> >-----Original Message-----
>> >> >> >From: DRAGE, Keith (Keith) [mailto:[email-masked]]
>> >> >> >Sent: 05 February, 2009 14:55
>> >> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 
>> >> >> >'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
>> >> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
>> >> >> >mistake)
>> >> >> >
>> >> >> >Which is exactly what RFC 4412 specifies for all namespaces.
>> >> >> >
>> >> >> >regards
>> >> >> >
>> >> >> >Keith
>> >> >> >
>> >> >> >> -----Original Message-----
>> >> >> >> From: [email-masked] [mailto:[email-masked]]
>> >> >> >On Behalf
>> >> >> >> Of Brian Rosen
>> >> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
>> >> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
>> >> >Hannes (NSN
>> >> >> >> - FI/Espoo)'; 'ECRIT'
>> >> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
>> Agenda (my
>> >> >> >> mistake)
>> >> >> >>
>> >> >> >> The value is that in some networks where priority for
>> >> >> >emergency calls
>> >> >> >> is appropriate, and appropriate policing of marking is
>> >> >implemented,
>> >> >> >> emergency calls will receive resource priority.
>> >> >> >>
>> >> >> >> Not all networks would need policing.  Some will.  Policing 
>> >> >> >> could be to Route header/R-URI content, but other
>> >criteria are possible.
>> >> >> >>
>> >> >> >> Not all networks will need resource priority for
>> >emergency calls.
>> >> >> >> Fine, ignore this marking/namespace.
>> >> >> >>
>> >> >> >> Brian
>> >> >> >> > -----Original Message-----
>> >> >> >> > From: Hannes Tschofenig [mailto:[email-masked]]
>> >> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>> >> >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig,
>> >Hannes (NSN -
>> >> >> >> > FI/Espoo); 'ECRIT'
>> >> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting:
>> >Agenda (my
>> >> >> >> > mistake)
>> >> >> >> >
>> >> >> >> > I don't even see the value in permitting the
>> >endpoint todo the
>> >> >> >> > RPH marking.
>> >> >> >> > In addition to the security concerns there is also the
>> >> >> >problem that
>> >> >> >> > there are more options to implement without an
>> >additional value.
>> >> >> >> >
>> >> >> >> > >-----Original Message-----
>> >> >> >> > >From: Brian Rosen [mailto:[email-masked]]
>> >> >> >> > >Sent: 05 February, 2009 00:03
>> >> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,
>> >> >> >> Hannes (NSN -
>> >> >> >> > >FI/Espoo)'; 'ECRIT'
>> >> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim
>> Meeting: Agenda
>> >> >> >> > >(my
>> >> >> >> > mistake)
>> >> >> >> > >
>> >> >> >> > >Hannes
>> >> >> >> > >
>> >> >> >> > >This matches my understanding precisely.  We wish to
>> >> >> >> permit endpoints
>> >> >> >> > >to mark. We do not require it, and don't
>> necessarily expect
>> >> >> >> > >it in many (even
>> >> >> >> > >most) cases.  We don't wish to see the document
>> prohibit it.
>> >> >> >> > >We all seem to agree it has value within the Emergency
>> >> >> >Services IP
>> >> >> >> > >Networks.
>> >> >> >> > >
>> >> >> >> > >Brian
>> >> >> >> > >
>> >> >> >> > >> -----Original Message-----
>> >> >> >> > >> From: [email-masked] 
>> >> >> >> > >> [mailto:[email-masked]]
>> >> >> >> > >On Behalf
>> >> >> >> > >> Of James M. Polk
>> >> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
>> >> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
>> >> >> >> FI/Espoo); 'ECRIT'
>> >> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
>> >> >Agenda (my
>> >> >> >> > >> mistake)
>> >> >> >> > >>
>> >> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
>> >> >> >> > >> > > James wrote:
>> >> >> >> > >> > >> you are the _lone_ voice not supporting this ID,
>> >> >> >> > >> >
>> >> >> >> > >> >Listening to the audio recording of past
>> meetings I have
>> >> >> >> > >> >to
>> >> >> >> > >say that
>> >> >> >> > >> >I
>> >> >> >> > >> was
>> >> >> >> > >> >not the only persons raising concerns about
>> the document.
>> >> >> >> > >> >That was probably the reason why you agreed to
>> limit the
>> >> >> >> > >scope of the
>> >> >> >> > >> >document (which you didn't later do) to get
>> >folks to agree
>> >> >> >> > >to make it
>> >> >> >> > >> a WG
>> >> >> >> > >> >item.
>> >> >> >> > >>
>> >> >> >> > >> re-listen to the audio please
>> >> >> >> > >>
>> >> >> >> > >> Ted's concerns were consistent with most (all?) other
>> >> >> >> concerns --
>> >> >> >> > >> which were based on the premise of whether or not the
>> >> >> >> UAC should be
>> >> >> >> > >> trusted to initiate the marking on the INVITE.
>> The most
>> >> >> >> > >> recent version has backed off this to a "can"
>> -- meaning
>> >> >> >> > >> not
>> >> >> >prohibited
>> >> >> >> > >> (i.e., no 2119 text).  I also backed off the 
>text in the
>> >> >> >> SP domain
>> >> >> >> > >> part to "can", such that there is no 2119 text
>> >> >> >mandating or even
>> >> >> >> > >> recommending its usage there. I also do not 
>prohibit its
>> >> >> >> > >use, based on
>> >> >> >> > >> local policy.  Keith has come forward with the 
>specific 
>> >> >> >> > >> request that non-ESInet networks be allowed to
>> >mark and pay
>> >> >> >attention to
>> >> >> >> > >> this priority indication -- with IMS as the specific 
>> >> >> >> > >> example he wishes to have this valid for.
>> >> >> >> > >>
>> >> >> >> > >> Where there is no disagreement, save for your recent
>> >> >> >> > >pushback - is in
>> >> >> >> > >> the ESInet, which is where Brian has requested it's
>> >> >> >> > >definition in the
>> >> >> >> > >> IETF on behalf of NENA.  He's the i3 WG chair within
>> >> >> >> NENA, and if
>> >> >> >> > >> he asks for it, are you going to say you know
>> >better than he?
>> >> >> >> > >>
>> >> >> >> > >>
>> >> >> >> > >> >Btw, I not disagreeing with the document as such. I
>> >> >> >just want to
>> >> >> >> > the
>> >> >> >> > >> scope
>> >> >> >> > >> >to change. The usage of RPH within the emergency
>> >> >> >> services network
>> >> >> >> > is
>> >> >> >> > >> fine
>> >> >> >> > >> >for me. I may get convinced to start the RPH
>> marking from
>> >> >> >> > >the the VSP
>> >> >> >> > >> >towards the PSAP. I feel uneasy about the end
>> host doing
>> >> >> >> > >the marking.
>> >> >> >> > >>
>> >> >> >> > >> please read what I wrote above, and then re-read the
>> >> >> >most recent
>> >> >> >> > >> version of the ID. I don't have endpoints that 
>SHOULD or
>> >> >> >> MUST mark
>> >> >> >> > >> anything wrt RPH.  I also don't want to prohibit it,
>> >> >> >> because there
>> >> >> >> > >> might be cases (that I don't know of) of valid uses
>> >> >> >> under certain
>> >> >> >> > >> circumstances.  Figure 1 is very clear that there are 3
>> >> >> >> networking
>> >> >> >> > >> parts to consider
>> >> >> >> > >>
>> >> >> >> > >> #1 - from the endpoint
>> >> >> >> > >> #2 - within the VSP
>> >> >> >> > >> #3 - within the ESInet
>> >> >> >> > >>
>> >> >> >> > >> the most recent ID version has "can" for #s 1 
>and 2, and
>> >> >> >> > >2119 language
>> >> >> >> > >> offering those supporting this specification will
>> >have RPH
>> >> >> >> > >> adherence within #3 (the ESInet).
>> >> >> >> > >>
>> >> >> >> > >> What other scope changes do you want, because I haven't
>> >> >> >> heard them.
>> >> >> >> > >>
>> >> >> >> > >> I only heard you claim in email during the last
>> >IETF and in
>> >> >> >> > >the ECRIT
>> >> >> >> > >> session that RPH should not be used for 
>priority marking
>> >> >> >> requests.
>> >> >> >> > >> This is something Keith (SIP WG chair) voiced his 
>> >> >> >> > >> opposition to your views regarding creating a
>> >second means
>> >> >> >> > >> for SIP to
>> >> >> >priority
>> >> >> >> > >> mark request "when SIP already has one
>> >interoperable way to
>> >> >> >> > >> accomplish this... it's call the RP header mechanism".
>> >> >> >> > >>
>> >> >> >> > >> >I don't see advantages -- only disadvantages.
>> >> >> >> > >> >
>> >> >> >> > >> >Ciao
>> >> >> >> > >> >Hannes
>> >> >> >> > >>
>> >> >> >> > >> _______________________________________________
>> >> >> >> > >> Ecrit mailing list
>> >> >> >> > >> [email-masked]
>> >> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >> > >
>> >> >> >>
>> >> >> >> _______________________________________________
>> >> >> >> Ecrit mailing list
>> >> >> >> [email-masked]
>> >> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >>
>> >> >> >
>> >> >
>> >
>>
>>
>

To: "Hannes Tschofenig" <[email-masked]>
From: Janet P Gunn <[email-masked]>
Date: Sat, 7 Feb 2009 11:27:14 -0500
Cc: 'ECRIT' <[email-masked]>, [email-masked]
Subject: [Ecrit] Semantics  Re:  RPH

This is a multipart message in MIME format.
--=_alternative 005A5FB785257556_=
Content-Type: text/plain; charset="US-ASCII"

.

[email-masked] wrote on 02/07/2009 03:14:57 AM:

> PLEASE try to understand that the syntax is similar (header, new 
namespace,
> new values) 
> BUT the semantic is different. 
> 
> For all message it is true that the sender can add whatever they want. 
The
> big question is what does it mean for the recipient. 
> 
> This is what the discussion is about. 
> 
On the contrary, the semantic is, or at least can be, very similar.

Consider the hypothetical, but plausible, case of a network with an 
explicit call/capacity admission process, in which both 911-type-emergency 
calls and GETS calls get preferential admission treatment.  By the time 
the INVITE gets to this Functional Module/ block of code, all 
authentication, authorization, and changes/confirmation of the destination 
have already taken place.  All this block of code deals with is 
call/capacity admission.

For the sake of argument, suppose this is the nature of the preference.

1) For INVITEs without RPH, or with an RPH this network does not 
use/understand, if the admission process fails, the INVITE fails

2) For INVITEs with RPH with the ets namespace, if the admission process 
initially fails, the INVITE is put in queue until the resources become 
available so it can be admitted.

3) For INVITEs with RPH with the esnet namespace, if the admission process 
initially fails, the INVITE is put in queue, but at lower priority than 
the calls with the ets namespace.

With the esnet namespace, this block of code only needs to deal with the 
RPH in determining which INVITEs to reject, and which to queue, and how.

But if there is no esnet namespace for RPH, then this block of code would 
need to deal with BOTH the RPH and the URN.  That would be a completely 
unnecessary complication.

Janet

--=_alternative 005A5FB785257556_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif"><br>
.</font>
<br>
<br><font size=2><tt>[email-masked] wrote on 02/07/2009 03:14:57
AM:<br>
<br>
&gt; PLEASE try to understand that the syntax is similar (header, new namespace,<br>
&gt; new values) <br>
&gt; BUT the semantic is different. <br>
&gt; &nbsp;<br>
&gt; For all message it is true that the sender can add whatever they want.
The<br>
&gt; big question is what does it mean for the recipient. <br>
&gt; <br>
&gt; This is what the discussion is about. <br>
&gt; <br>
On the contrary, the semantic is, or at least can be, very similar.</tt></font>
<br>
<br><font size=2><tt>Consider the hypothetical, but plausible, case of
a network with an explicit call/capacity admission process, in which both
911-type-emergency calls and GETS calls get preferential admission treatment.
&nbsp;By the time the INVITE gets to this Functional Module/ block of code,
all authentication, authorization, and changes/confirmation of the destination
have already taken place. &nbsp;All this block of code deals with is call/capacity
admission.</tt></font>
<br>
<br><font size=2><tt>For the sake of argument, suppose this is the nature
of the preference.</tt></font>
<br>
<br><font size=2><tt>1) For INVITEs without RPH, or with an RPH this network
does not use/understand, if the admission process fails, the INVITE fails</tt></font>
<br>
<br><font size=2><tt>2) For INVITEs with RPH with the ets namespace, if
the admission process initially fails, the INVITE is put in queue until
the resources become available so it can be admitted.</tt></font>
<br>
<br><font size=2><tt>3) For INVITEs with RPH with the esnet namespace,
if the admission process initially fails, the INVITE is put in queue, but
at lower priority than the calls with the ets namespace.</tt></font>
<br>
<br><font size=2><tt>With the esnet namespace, this block of code only
needs to deal with the RPH in determining which INVITEs to reject, and
which to queue, and how.</tt></font>
<br>
<br><font size=2><tt>But if there is no esnet namespace for RPH, then this
block of code would need to deal with BOTH the RPH and the URN. &nbsp;That
would be a completely unnecessary complication.</tt></font>
<br>
<br><font size=2><tt>Janet<br>
</tt></font>
--=_alternative 005A5FB785257556_=--

From: Henning Schulzrinne <[email-masked]>
To: Janet P Gunn <[email-masked]>
Date: Sat, 7 Feb 2009 11:56:42 -0500
Cc: ECRIT <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

Please see my earlier message as to why your approach fails for the UA- 
inserted case where not all emergency calls have RPH markings. I think  
it would be a really bad idea if emergency calls with RPH are treated  
differently than emergency calls without it. (Again, I'm talking about  
the user-initiated calls. An ESNET can do whatever it wants and can  
assign extra priority to calls from citizens that have bought PBA  
stickers or zip codes that pay more taxes, but that's a separate  
problem.)

I also don't believe your implementation logic. A much better approach  
is to semantically declare the class of call early on (e.g., based on  
the URN or after authentication/authorization), and make that part of  
the call state record, rather than hunt for headers each time a  
handling decision needs to be made. Given the authorization  
requirements, just looking at "has header X" is never going to be  
sufficient anyway.

Henning

On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:

>
>
> .
>
> [email-masked] wrote on 02/07/2009 03:14:57 AM:
>
> > PLEASE try to understand that the syntax is similar (header, new  
> namespace,
> > new values)
> > BUT the semantic is different.
> >
> > For all message it is true that the sender can add whatever they  
> want. The
> > big question is what does it mean for the recipient.
> >
> > This is what the discussion is about.
> >
> On the contrary, the semantic is, or at least can be, very similar.
>
> Consider the hypothetical, but plausible, case of a network with an  
> explicit call/capacity admission process, in which both 911-type- 
> emergency calls and GETS calls get preferential admission  
> treatment.  By the time the INVITE gets to this Functional Module/  
> block of code, all authentication, authorization, and changes/ 
> confirmation of the destination have already taken place.  All this  
> block of code deals with is call/capacity admission.
>
> For the sake of argument, suppose this is the nature of the  
> preference.
>
> 1) For INVITEs without RPH, or with an RPH this network does not use/ 
> understand, if the admission process fails, the INVITE fails
>
> 2) For INVITEs with RPH with the ets namespace, if the admission  
> process initially fails, the INVITE is put in queue until the  
> resources become available so it can be admitted.
>
> 3) For INVITEs with RPH with the esnet namespace, if the admission  
> process initially fails, the INVITE is put in queue, but at lower  
> priority than the calls with the ets namespace.
>
> With the esnet namespace, this block of code only needs to deal with  
> the RPH in determining which INVITEs to reject, and which to queue,  
> and how.
>
> But if there is no esnet namespace for RPH, then this block of code  
> would need to deal with BOTH the RPH and the URN.  That would be a  
> completely unnecessary complication.
>
> Janet

To: Henning Schulzrinne <[email-masked]>
From: Janet P Gunn <[email-masked]>
Date: Sat, 7 Feb 2009 12:17:12 -0500
Cc: ECRIT <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

This is a multipart message in MIME format.
--=_alternative 005EF2FA85257556_=
Content-Type: text/plain; charset="US-ASCII"

To clarify,
My example has NOTHING to do with when the RPH is inserted.  In particular 
I said "after the authentication and authorization", so it is NOT about 
user generated RPH (which I agree is "problematic")

It is intended to show that the SEMANTICS of providing priority based on 
the RPH can be the SAME for different namespaces, even if many other 
aspects are quite different.

It is intended to counter the argument that "you don't gain anything by 
having the RPH namespace esnet because  you already have the URN"

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.

Henning Schulzrinne <[email-masked]> wrote on 02/07/2009 11:56:42 AM:

> Please see my earlier message as to why your approach fails for the UA- 
> inserted case where not all emergency calls have RPH markings. I think 
> it would be a really bad idea if emergency calls with RPH are treated 
> differently than emergency calls without it. (Again, I'm talking about 
> the user-initiated calls. An ESNET can do whatever it wants and can 
> assign extra priority to calls from citizens that have bought PBA 
> stickers or zip codes that pay more taxes, but that's a separate 
> problem.)
> 
> I also don't believe your implementation logic. A much better approach 
> is to semantically declare the class of call early on (e.g., based on 
> the URN or after authentication/authorization), and make that part of 
> the call state record, rather than hunt for headers each time a 
> handling decision needs to be made. Given the authorization 
> requirements, just looking at "has header X" is never going to be 
> sufficient anyway.
> 
> Henning
> 
> On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:
> 
> >
> >
> > .
> >
> > [email-masked] wrote on 02/07/2009 03:14:57 AM:
> >
> > > PLEASE try to understand that the syntax is similar (header, new 
> > namespace,
> > > new values)
> > > BUT the semantic is different.
> > >
> > > For all message it is true that the sender can add whatever they 
> > want. The
> > > big question is what does it mean for the recipient.
> > >
> > > This is what the discussion is about.
> > >
> > On the contrary, the semantic is, or at least can be, very similar.
> >
> > Consider the hypothetical, but plausible, case of a network with an 
> > explicit call/capacity admission process, in which both 911-type- 
> > emergency calls and GETS calls get preferential admission 
> > treatment.  By the time the INVITE gets to this Functional Module/ 
> > block of code, all authentication, authorization, and changes/ 
> > confirmation of the destination have already taken place.  All this 
> > block of code deals with is call/capacity admission.
> >
> > For the sake of argument, suppose this is the nature of the 
> > preference.
> >
> > 1) For INVITEs without RPH, or with an RPH this network does not use/ 
> > understand, if the admission process fails, the INVITE fails
> >
> > 2) For INVITEs with RPH with the ets namespace, if the admission 
> > process initially fails, the INVITE is put in queue until the 
> > resources become available so it can be admitted.
> >
> > 3) For INVITEs with RPH with the esnet namespace, if the admission 
> > process initially fails, the INVITE is put in queue, but at lower 
> > priority than the calls with the ets namespace.
> >
> > With the esnet namespace, this block of code only needs to deal with 
> > the RPH in determining which INVITEs to reject, and which to queue, 
> > and how.
> >
> > But if there is no esnet namespace for RPH, then this block of code 
> > would need to deal with BOTH the RPH and the URN.  That would be a 
> > completely unnecessary complication.
> >
> > Janet
> 

--=_alternative 005EF2FA85257556_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">To clarify,</font>
<br><font size=2 face="sans-serif">My example has NOTHING to do with when
the RPH is inserted. &nbsp;In particular I said &quot;after the authentication
and authorization&quot;, so it is NOT about user generated RPH (which I
agree is &quot;problematic&quot;)</font>
<br>
<br><font size=2 face="sans-serif">It is intended to show that the SEMANTICS
of providing priority based on the RPH can be the SAME for different namespaces,
even if many other aspects are quite different.</font>
<br>
<br><font size=2 face="sans-serif">It is intended to counter the argument
that &quot;you don't gain anything by having the RPH namespace esnet because
&nbsp;you already have the URN&quot;</font>
<br>
<br><font size=2 face="sans-serif">Janet<br>
<br>
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. <br>
NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.</font>
<br>
<br><font size=2><tt>Henning Schulzrinne &lt;[email-masked]&gt; wrote
on 02/07/2009 11:56:42 AM:<br>
<br>
&gt; Please see my earlier message as to why your approach fails for the
UA- <br>
&gt; inserted case where not all emergency calls have RPH markings. I think
&nbsp;<br>
&gt; it would be a really bad idea if emergency calls with RPH are treated
&nbsp;<br>
&gt; differently than emergency calls without it. (Again, I'm talking about
&nbsp;<br>
&gt; the user-initiated calls. An ESNET can do whatever it wants and can
&nbsp;<br>
&gt; assign extra priority to calls from citizens that have bought PBA
&nbsp;<br>
&gt; stickers or zip codes that pay more taxes, but that's a separate &nbsp;<br>
&gt; problem.)<br>
&gt; <br>
&gt; I also don't believe your implementation logic. A much better approach
&nbsp;<br>
&gt; is to semantically declare the class of call early on (e.g., based
on &nbsp;<br>
&gt; the URN or after authentication/authorization), and make that part
of &nbsp;<br>
&gt; the call state record, rather than hunt for headers each time a &nbsp;<br>
&gt; handling decision needs to be made. Given the authorization &nbsp;<br>
&gt; requirements, just looking at &quot;has header X&quot; is never going
to be &nbsp;<br>
&gt; sufficient anyway.<br>
&gt; <br>
&gt; Henning<br>
&gt; <br>
&gt; On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:<br>
&gt; <br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; .<br>
&gt; &gt;<br>
&gt; &gt; [email-masked] wrote on 02/07/2009 03:14:57 AM:<br>
&gt; &gt;<br>
&gt; &gt; &gt; PLEASE try to understand that the syntax is similar (header,
new &nbsp;<br>
&gt; &gt; namespace,<br>
&gt; &gt; &gt; new values)<br>
&gt; &gt; &gt; BUT the semantic is different.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; For all message it is true that the sender can add whatever
they &nbsp;<br>
&gt; &gt; want. The<br>
&gt; &gt; &gt; big question is what does it mean for the recipient.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; This is what the discussion is about.<br>
&gt; &gt; &gt;<br>
&gt; &gt; On the contrary, the semantic is, or at least can be, very similar.<br>
&gt; &gt;<br>
&gt; &gt; Consider the hypothetical, but plausible, case of a network with
an &nbsp;<br>
&gt; &gt; explicit call/capacity admission process, in which both 911-type-
<br>
&gt; &gt; emergency calls and GETS calls get preferential admission &nbsp;<br>
&gt; &gt; treatment. &nbsp;By the time the INVITE gets to this Functional
Module/ &nbsp;<br>
&gt; &gt; block of code, all authentication, authorization, and changes/
<br>
&gt; &gt; confirmation of the destination have already taken place. &nbsp;All
this &nbsp;<br>
&gt; &gt; block of code deals with is call/capacity admission.<br>
&gt; &gt;<br>
&gt; &gt; For the sake of argument, suppose this is the nature of the &nbsp;<br>
&gt; &gt; preference.<br>
&gt; &gt;<br>
&gt; &gt; 1) For INVITEs without RPH, or with an RPH this network does
not use/ <br>
&gt; &gt; understand, if the admission process fails, the INVITE fails<br>
&gt; &gt;<br>
&gt; &gt; 2) For INVITEs with RPH with the ets namespace, if the admission
&nbsp;<br>
&gt; &gt; process initially fails, the INVITE is put in queue until the
&nbsp;<br>
&gt; &gt; resources become available so it can be admitted.<br>
&gt; &gt;<br>
&gt; &gt; 3) For INVITEs with RPH with the esnet namespace, if the admission
&nbsp;<br>
&gt; &gt; process initially fails, the INVITE is put in queue, but at lower
&nbsp;<br>
&gt; &gt; priority than the calls with the ets namespace.<br>
&gt; &gt;<br>
&gt; &gt; With the esnet namespace, this block of code only needs to deal
with &nbsp;<br>
&gt; &gt; the RPH in determining which INVITEs to reject, and which to
queue, &nbsp;<br>
&gt; &gt; and how.<br>
&gt; &gt;<br>
&gt; &gt; But if there is no esnet namespace for RPH, then this block of
code &nbsp;<br>
&gt; &gt; would need to deal with BOTH the RPH and the URN. &nbsp;That
would be a &nbsp;<br>
&gt; &gt; completely unnecessary complication.<br>
&gt; &gt;<br>
&gt; &gt; Janet<br>
&gt; <br>
</tt></font>
--=_alternative 005EF2FA85257556_=--

Content-class: urn:content-classes:message
Date: Sat, 7 Feb 2009 12:29:35 -0500
From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "'Winterbottom, James'" <[email-masked]>, "'Brian Rosen'" <[email-masked]>, "'Henning Schulzrinne'" <[email-masked]>
Date: Sun, 8 Feb 2009 01:59:10 +0100
Accept-Language: en-US
acceptlanguage: en-US
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] RPH

We go round and round in circles.

We had this discussion on the mail list before the last IETF meeting.

Different headers have different semantics. The service urn appears in a pa=
rt of the SIP message where RFC 3261 defines exactly the semantics it has. =
Those appearances have nothing to do with the semantics of a resource prior=
ity header.

regards

Keith

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Saturday, February 07, 2009 8:29 AM
> To: DRAGE, Keith (Keith); 'Winterbottom, James'; 'Brian
> Rosen'; 'Henning Schulzrinne'
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
> Subject: RE: [Ecrit] RPH
>
> What do you think is the semantic of the Service URN (or the
> respective dial string)?
> Emergency call with special processing needed? Do everything
> so that the call gets through?
>
> How often do you want to say that the call is really
> important to you?
>
> We could invent a few more headers say "Yes, it is really
> important. Believe me -- really, really important. Also add
> location because that it could be needed to locate me.". See
> my other mail where I invented such a new header that from a
> philosophical point of view (not from a practical) makes a
> lot of sense.
>
> Code just needs to know it is important and can do all the
> necessary steps.
> I doubt that someone would write code that does not treat the
> emergency call as less important when an emergency call comes
> in that does not have the ECRIT RPH header present. Would you
> think so?
>
> Ciao
> Hannes
>
> >-----Original Message-----
> >From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> >Sent: 07 February, 2009 02:15
> >To: Winterbottom, James; Hannes Tschofenig; Brian Rosen; Henning
> >Schulzrinne
> >Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
> >Subject: RE: [Ecrit] RPH
> >
> >It is a valid header for that usage. It carries exactly the
> semantics
> >the user wishes to convey, i.e. that the requestor would
> like the call
> >to be treated in processing by the network in a manner
> appropriate to
> >emergency calls.
> >
> >Yes the edge proxy may well review and make up its own mind,
> and either
> >remove, verify or pass on the header, but that does not mean it is
> >wrong from the UE.
> >
> >You might just as well argue that the UE should not inserted a
> >P-Preferred-ID if it knows that the value it contains will
> be the one
> >inserted by the edge proxy.
> >
> >regards
> >
> >Keith
> >
> >
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]]
> >On Behalf
> >> Of Winterbottom, James
> >> Sent: Friday, February 06, 2009 8:02 PM
> >> To: Hannes Tschofenig; Brian Rosen; Henning Schulzrinne
> >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
> >> Subject: Re: [Ecrit] RPH
> >>
> >> Hi All,
> >>
> >> I have followed thi thread with some interest and I
> >struggling to see
> >> a use case for the providing RPH for emergency calls from the
> >> end-point.
> >>
> >> The reference-model call in ECRIT, for better or worse, is for all
> >> calls to go back through a home-VSP.
> >> We placed quite a lot of emphasis, largely for traffing
> reasons, for
> >> the VSP to be able to verify that a call is in fact an
> >emergency call.
> >> This is done by the proxy taking the inband location, doing a LoST
> >> query with the provided URN, and verifying that the resulting
> >> destination URI is the same as the destination URI provide
> >in the SIP
> >> INVITE. My understanding was that VSPs would always do
> this check so
> >> they could tell if they could bill for the call or not,
> and because
> >> the VSP can be use that the call is an emergency call it can
> >apply any
> >> special priorities that may be applicable.
> >> This obviates the need for RPH from the end-point to the network.
> >>
> >> This leaves us with the argument of "it doesn't hurt to it",
> >which is
> >> not a good reason to write a specification.
> >> It was intimated on the geopriv mailing list last year that great
> >> pains had been taken to keep SIP with in the MTU limits of
> UDP over
> >> Ethernet
> >> (http://www.ietf.org/mail-archive/web/geopriv/current/msg06120
> >> .html). Assuming that this is the case, perhaps there is harm in
> >> including information that we know will be ignored.
> >>
> >> Cheers
> >> James
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: [email-masked] on behalf of Hannes Tschofenig
> >> Sent: Fri 2/6/2009 12:33 PM
> >> To: 'Brian Rosen'; 'Henning Schulzrinne'
> >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
> >> Subject: Re: [Ecrit] RPH
> >>
> >> To the story short here is the code for the proxy:
> >>
> >> ---------------------
> >>
> >> IF emergency call was recognized THEN
> >>     execute emergency call specific procedures (priority queuing,
> >> preemption, fetch location, determine routing, do funny
> QoS things &
> >> co) ELSE
> >>     normal call handling procedures.
> >>
> >> ---------------------
> >>
> >> If you can make this differentiation between an emergency
> call and a
> >> regular call then you can also do everything that is necessary for
> >> emergency call handling.
> >>
> >> Brian + Keith: Please tell me that we cannot do the above with our
> >> currently specified mechanisms.
> >>
> >> Ciao
> >> Hannes
> >>
> >> >-----Original Message-----
> >> >From: Brian Rosen [mailto:[email-masked]]
> >> >Sent: 06 February, 2009 17:49
> >> >To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
> >> >Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >> >Subject: RE: [Ecrit] RPH
> >> >
> >> >I agree that not all networks will permit (or pay attention
> >> >to) a priority request from an end device.
> >> >
> >> >No one has asked for that.
> >> >
> >> >The namespace request has several uses, one of which is within an
> >> >emergency services IP network, one of which is between
> >> elements within
> >> >a public network controlled by the operator, and one of
> which is an
> >> >endpoint request for resource priority.
> >> >
> >> >Those of us requesting this work proceed are happy if the
> >> endpoint part
> >> >is simply left as possible (MAY), and, speaking for myself,
> >> having the
> >> >draft discuss the security implications of endpoint marking is
> >> >reasonable.
> >> >
> >> >Having discussed this issue with an implementation team who
> >> worked on
> >> >MLPP systems, I am confident I know what I'm talking about,
> >> but YMMV.
> >> >The fact that you could, if you wanted to, give resource
> >> priority to a
> >> >call you decided, however you decided, was an emergency
> call is an
> >> >implementation decision, and not subject to standardization.
> >> >
> >> >RPH is the IETF standard way for one entity to request resource
> >> >priority of another entity in a SIP system.  We're asking for a
> >> >namespace to use that within the domain of emergency calls.
> >> That is, I
> >> >think, a VERY reasonable request.
> >> >
> >> >Brian
> >> >
> >> >> -----Original Message-----
> >> >> From: Henning Schulzrinne [mailto:[email-masked]]
> >> >> Sent: Friday, February 06, 2009 10:33 AM
> >> >> To: Hannes Tschofenig
> >> >> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
> >> >> Subject: Re: [Ecrit] RPH
> >> >>
> >> >> To chime in here:
> >> >>
> >> >> I don't think it's productive to simply state that 4412
> >> >doesn't worry
> >> >> about authorization, so we shouldn't either (simplifying a bit).
> >> >> Authorization was discussed repeatedly, and the general
> >> >assumption was
> >> >> that there were two conditions: Either the user invoking
> >resource-
> >> >> priority was well known and had a set of permissions that
> >could be
> >> >> checked in real time or there are ways to deal with abuse
> >> after the
> >> >> fact in ways that deter abuse (the court-martial kind of
> >> thing in a
> >> >> military context).
> >> >>
> >> >> The RFC 4412 security consideration (11.2) call this out
> >in pretty
> >> >> strong language:
> >> >>
> >> >>   Prioritized access to network and end-system resources imposes
> >> >>     particularly stringent requirements on authentication and
> >> >>     authorization mechanisms, since access to prioritized
> >> >resources may
> >> >>     impact overall system stability and performance and not
> >> >just result
> >> >>     in theft of, say, a single phone call.
> >> >> Thus, the question is whether we have such strong
> >> authentication in
> >> >> emergency calling. In some cases, such as residential
> fixed line
> >> >> deployments where ISP =3D VSP, we're probably pretty close,
> >> in others,
> >> >> such as prepaid cell phones or hot spots or VSP-only
> >providers, we
> >> >> aren't.
> >> >>
> >> >> The other point that I think Hannes is making is that the
> >> >information
> >> >> is either redundant or dangerous. If a processing element
> >> recognizes
> >> >> the call as being an emergency call, it can apply whatever
> >> treatment
> >> >> it deems appropriate and doesn't need additional
> >> information. If it
> >> >> doesn't or can't, using just the RPH can be rather
> >> dangerous unless
> >> >> that element can be reasonably certain that there is strong
> >> >> authentication and recourse.
> >> >>
> >> >> I don't buy the argument that somehow finding the RPH is
> >> faster than
> >> >> just looking for the identifier. Thus, given that the
> >> information is
> >> >> either redundant or dangerous, I fail to see the advantage.
> >> >>
> >> >> Henning
> >> >>
> >> >>
> >> >> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
> >> >>
> >> >> > Don't get hung up on the details. There are ways to
> optimize it.
> >> >> > That was
> >> >> > not the point of the code example.
> >> >> >
> >> >> > The problem that my pseudo code should have shown you
> >is that you
> >> >> > * don't gain anything with RPH marking for the emergency
> >> call case
> >> >> > from the SIP UA towards the outbound proxy since the
> >> functionality
> >> >> > is already provide otherwise. How often does the proxy
> >> need to get
> >> >> > told that this is an emergency call todo whatever
> >emergency call
> >> >> > handling procedures are necessary?
> >> >> > * you only introduce fraud problems (if you are not
> >> >careful and you
> >> >> > understand the security stuff well enough)
> >> >> >
> >> >> > If you can point me to people who implement the RPH
> >> emergency call
> >> >> > case please do so. I would love to talk to them.
> >> >> >
> >> >> > Ciao
> >> >> > Hannes
> >> >> >
> >> >> > PS: You need to parse incoming messages to some extend
> >> so that you
> >> >> > know what it contains :-) Only looking for the emergency
> >> >RPH header
> >> >> > (and not for the Service URN/dial
> >> >> > string) would exactly be the DoS/fraud attack I am
> >worried about.
> >> >> > That's the thing Henning was worried about (go and
> >listen to the
> >> >> > past meeting minutes).
> >> >> >
> >> >> >
> >> >> >> Hannes
> >> >> >>
> >> >> >> You need to talk to people who really implement this kind
> >> >of thing.
> >> >> >> You are way off.
> >> >> >>
> >> >> >> When you implement a resource priority system, the
> >> point of doing
> >> >> >> that is to look though the queue of work and pick out the
> >> >ones with
> >> >> >> priority, handling them first.  You don't do all the
> >> parsing, you
> >> >> >> don't do a lot of decision tree.
> >> >> >>
> >> >> >> Typically:
> >> >> >> Check for DoS things, like too big messages, etc Do a
> >> quick scan
> >> >> >> for the RPH message header If found:
> >> >> >> Parse the message
> >> >> >> Determine validity
> >> >> >> Determine priority
> >> >> >> Queue on the correct work queue
> >> >> >>
> >> >> >> The first two actions have to be very fast.  Anyone who
> >> builds a
> >> >> >> SIP thingie will tell you that parsing is one of the
> big cycle
> >> >> >> consumers: if you have to parse every message BEFORE you
> >> >determine
> >> >> >> priority, you can't give much resource priority.
> >> >> >> Once you get the whole message parsed, you might as
> >well finish
> >> >> >> working on it, because you've done so much of the work.
> >> >> >> OTHOH, finding the end-of-message delimiter and
> doing a quick
> >> >> >> string search for RPH is fast.  If you are doing
> >> >priority, you need
> >> >> >> to keep all the priority processing pretty uniform,
> and pretty
> >> >> >> simple, or you tend to spend too much time futzing around
> >> >figuring
> >> >> >> out what to do.  You put all the priority related stuff
> >> together,
> >> >> >> and use as much common code as possible.
> >> >> >>
> >> >> >> Brian
> >> >> >>
> >> >> >>> -----Original Message-----
> >> >> >>> From: [email-masked] [mailto:[email-masked]]
> >> >> >> On Behalf
> >> >> >>> Of Hannes Tschofenig
> >> >> >>> Sent: Friday, February 06, 2009 8:41 AM
> >> >> >>> To: 'Hannes Tschofenig'; 'Janet P Gunn'
> >> >> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-
> >> >> >>> [email-masked]
> >> >> >>> Subject: [Ecrit] RPH
> >> >> >>>
> >> >> >>> Over lunch I was also thinking how an outbound proxy would
> >> >> implement
> >> >> >>> some of the emergency procedures. Here are some thoughts:
> >> >> >>>
> >> >> >>> ---------------------------------------------------
> >> >> >>>
> >> >> >>> // Process incoming message
> >> >> >>> Parse(msg);
> >> >> >>>
> >> >> >>> // SIP INVITE without Service URN // legacy devices If
> >> >> >>> (recognize-dialstring(msg)=3D=3DTRUE) {  // we got an
> >> emergency call
> >> >> >>> going on  emergency=3DTRUE;  if (dialstring(msg) =3D=3D 911)
> >> >> >>> serviceURN=3Durn:service:sos; } else if
> >> >> >>> (recognize-serviceURN(msg)=3D=3DTRUE) {  // oh. A updated
> >> >device that
> >> >> >>> has a service URN attached to the
> >> >> call
> >> >> >>>  serviceURN=3Dretrieve_ServiceURN(msg);
> >> >> >>>  emergency=3DTRUE;
> >> >> >>> } else {
> >> >> >>>  // standard SIP message
> >> >> >>>  // regular processing
> >> >> >>>  process(msg);
> >> >> >>>  emergency=3DFALSE;
> >> >> >>> }
> >> >> >>>
> >> >> >>> If (emergency =3D=3D TRUE) {
> >> >> >>>   // make sure that the emergency call does not get
> >> >dropped on the
> >> >> >>> floor
> >> >> >>>   // skip authorization failures
> >> >> >>>   // give the call a special treatment
> >> >> >>>   lots-of-code-here();
> >> >> >>>
> >> >> >>>   // trigger all the QoS signaling you have in the
> >> >network to make
> >> >> >>> James happy
> >> >> >>>   trigger-qos();
> >> >> >>>
> >> >> >>>   // query location
> >> >> >>>   location=3Dretrieve-location();
> >> >> >>>
> >> >> >>>   // determine next hop
> >> >> >>>   next-hop=3Dlost(location, serviceURN)
> >> >> >>>
> >> >> >>>   // attach RPH marking to outgoing msg to make James and
> >> >> >> Keith happy
> >> >> >>>   msg=3Dadd(msg, RPH);
> >> >> >>>
> >> >> >>>   send(msg, next-hop);
> >> >> >>> }
> >> >> >>>
> >> >> >>> If ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D TRUE)) =
{
> >> >> >>>   // all the emergency related processing done
> already upfront
> >> >> >>>   // hence I log something.
> >> >> >>>   log(RPH_WAS_PRESENT_JUHU);
> >> >> >>> } else if ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D
> >> >FALSE)) {
> >> >> >>> // this is not an emergency call  // this is something
> >> >like GETS
> >> >> >>> result=3Dspecial-authorization-procedure(user);
> >> >> >>>
> >> >> >>>  if (result =3D=3D AUTHORIZED) {
> >> >> >>>    // do some priority & preemption thing here.
> >> >> >>>    // trigger all the QoS you have
> >> >> >>>    lots-of-code-here();
> >> >> >>>  } else {
> >> >> >>>    log("NOT AUTHORIZED; don't DoS my network");  } }
> >> else {  //
> >> >> >>> don't need todo any RPH processing  // this
> includes the case
> >> >> >>> where the call was an emergency call but the RPH
> >> >> >>>
> >> >> >>>  // marking was not there.
> >> >> >>>  nothing();
> >> >> >>> }
> >> >> >>>
> >> >> >>> ---------------------------------------------------
> >> >> >>>
> >> >> >>>
> >> >> >>> Ciao
> >> >> >>> Hannes
> >> >> >>>
> >> >> >>>> -----Original Message-----
> >> >> >>>> From: [email-masked]
> >> [mailto:[email-masked]] On
> >> >> >>>> Behalf Of Hannes Tschofenig
> >> >> >>>> Sent: 06 February, 2009 15:07
> >> >> >>>> To: 'Janet P Gunn'
> >> >> >>>> Cc: 'ECRIT'; [email-masked];
> Tschofenig,Hannes (NSN -
> >> >> >>> FI/Espoo)
> >> >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
> >> Agenda (RPH)
> >> >> >>>>
> >> >> >>>> Who would define something that could prevent DoS problems?
> >> >> >>>>
> >> >> >>>> ________________________________
> >> >> >>>>
> >> >> >>>>       From: Janet P Gunn [mailto:[email-masked]]
> >> >> >>>>       Sent: 06 February, 2009 14:11
> >> >> >>>>       To: Hannes Tschofenig
> >> >> >>>>       Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >> >> >>>> [email-masked]; Tschofenig, Hannes (NSN -
> FI/Espoo);
> >> >> 'James
> >> >> >>>> M. Polk'
> >> >> >>>>       Subject: Re: [Ecrit] ECRIT Virtual Interim
> >> >Meeting: Agenda (RPH)
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>       But there is nothing IN RFC4412 that specifically
> >> >> >> addresses how to
> >> >> >>>> prevent any particular namespace being used for DoS.
> >> Anyone/any
> >> >> UA
> >> >> >>>> can ATTEMPT to invoke priority treatment by attaching
> >> RPH.  For
> >> >> all
> >> >> >>>> of the 4412 namespaces, as with the new proposed
> >> namespace, the
> >> >> >>>> mechanisms for preventing DoS are not specified in the
> >> >> >> document that
> >> >> >>>> defines the namespace.
> >> >> >>>> They are/will be specified elsewhere.
> >> >> >>>>
> >> >> >>>>       Janet
> >> >> >>>>
> >> >> >>>>       This is a PRIVATE message. If you are not
> the intended
> >> >> >> recipient,
> >> >> >>>> please delete without copying and kindly advise us by
> >> e-mail of
> >> >> the
> >> >> >>>> mistake in delivery.
> >> >> >>>>       NOTE: Regardless of content, this e-mail shall not
> >> >> >> operate to bind
> >> >> >>>> CSC to any order or other contract unless pursuant to
> >> explicit
> >> >> >>>> written agreement or government initiative expressly
> >> permitting
> >> >> the
> >> >> >>>> use of e-mail for such purpose.
> >> >> >>>>
> >> >> >>>>       [email-masked] wrote on 02/06/2009
> 04:21:51 AM:
> >> >> >>>>
> >> >> >>>>       > Hi James,
> >> >> >>>>       >
> >> >> >>>>       > I have read RFC 4412 and also the GETS/MLPP IETF
> >> >> >> documents. What I
> >> >> >>>> would
> >> >> >>>>       > like to point out is that there is more than just a
> >> >> >> header and
> >> >> >>>> values within
> >> >> >>>>       > the header that have to be considered in order to
> >> >> >> make a judgement
> >> >> >>>> of what
> >> >> >>>>       > is appropriate and what isn't. There is an
> >> >> >> architectural question
> >> >> >>>> and
> >> >> >>>>       > whether the environment we are using the stuff is
> >> >> >> indeed providing
> >> >> >>>> the
> >> >> >>>>       > properties you need for the solution to be
> >> >appropriate.
> >> >> >>>>       >
> >> >> >>>>       > Let me describe in more detail what I meant (and
> >> >> >> please correct me
> >> >> >>>> if I am
> >> >> >>>>       > wrong).
> >> >> >>>>       >
> >> >> >>>>       > Getting priority for SIP requests when using a GETS
> >> >> >> alike scenario
> >> >> >>>> means
> >> >> >>>>       > that the entity that issues the request is
> specially
> >> >> >> authorized
> >> >> >>>> since
> >> >> >>>>       > otherwise you introduce a nice denial of
> >> >service attack. This
> >> >> >>>> authorization
> >> >> >>>>       > is tied to the entity that makes the request. For
> >> >> >> example, the
> >> >> >>>> person is
> >> >> >>>>       > working for the government and has special rights.
> >> >> >>>> James Bond as a (not so)
> >> >> >>>>       > secret agent might have these rights.
> >> >> >>>>       >
> >> >> >>>>       > The emergency services case
> >> >(citizen-to-authority) is a bit
> >> >> >>>> different as
> >> >> >>>>       > there aren't really special rights with respect to
> >> >> >> authorization
> >> >> >>>> tied to
> >> >> >>>>       > individuals. Instead, the fact that something is an
> >> >> >> emergency is
> >> >> >>>> purely a
> >> >> >>>>       > judgement of the human that dials a special number.
> >> >> >>>> To deal with fraud, we
> >> >> >>>>       > discussed in the group on what we can
> actually do to
> >> >> >> ensure that
> >> >> >>>> end users
> >> >> >>>>       > do not bypass security procedures (such as
> >> >> >> authorization checks,
> >> >> >>>> charging
> >> >> >>>>       > and so on). Part of this investigation was
> >> >the publication of
> >> >> >>>>       > http://www.ietf.org/rfc/rfc5069.txt that also
> >> >describes this
> >> >> >>>> issue.
> >> >> >>>>       >
> >> >> >>>>       > So, imagine the implementation of a SIP
> proxy (and we
> >> >> >> implemented
> >> >> >>>> that
> >> >> >>>>       > stuff) that receives a call that contains a Service
> >> >> >> URN. The code
> >> >> >>>> branches
> >> >> >>>>       > into a special mode where everything is done
> >> >so that the call
> >> >> >>>> receives
> >> >> >>>>       > appropriate treatment and does not get
> dropped on the
> >> >> >> floor. The
> >> >> >>>> way how the
> >> >> >>>>       > Service URN is placed in the message
> ensures that the
> >> >> >> call cannot
> >> >> >>>> go to my
> >> >> >>>>       > friend (instead of the PSAP) unless the
> end host ran
> >> >> >> LoST already.
> >> >> >>>> In the
> >> >> >>>>       > latter case, we discussed this also on the
> list for a
> >> >> >> while and
> >> >> >>>> Richard even
> >> >> >>>>       > wrote a draft about it in the context of the
> >> >location hiding
> >> >> >>>> topic, we said
> >> >> >>>>       > that the proxy would have to run LoST if he
> >> >cares about a
> >> >> >>>> potential
> >> >> >>>>       > fraudulent usage.
> >> >> >>>>       >
> >> >> >>>>       > So, what do we need todo in order to provide
> >> >secure RFC 4412
> >> >> >>>> functionality
> >> >> >>>>       > in our context?
> >> >> >>>>       >
> >> >> >>>>       > Do you think that the current text in
> >> >> >>>>       >
> >> >> >>>>
> >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >> >> >>>> gency-rph-nam
> >> >> >>>>       > espace-00.txt reflects any of the
> >> >above-described issues:
> >> >> >>>>       > "
> >> >> >>>>       >    The Security considerations that apply
> to RFC 4412
> >> >> >>>> [RFC4412]
> >> >> >>>> apply
> >> >> >>>>       >    here.  This document introduces no new security
> >> >> >>>> issues relative
> >> >> >>>> to
> >> >> >>>>       >    RFC 4412.
> >> >> >>>>       > "
> >> >> >>>>       >
> >> >> >>>>       > From various discussions in GEOPRIV I recall
> >> >that you are
> >> >> >>>> super-sensitive
> >> >> >>>>       > regarding security and privacy. For some
> reasons you
> >> >> >> don't seem to
> >> >> >>>> have the
> >> >> >>>>       > same concerns here. I would like to
> >> >understand your reasoning.
> >> >> >>>>       >
> >> >> >>>>       > Please also do me another favor: Don't always say
> >> >> >> that I don't
> >> >> >>>> understand
> >> >> >>>>       > the subject. Even if that would be the
> case it isn't
> >> >> >> particular
> >> >> >>>> fair given
> >> >> >>>>       > that different folks had to educate you on other
> >> >> >> topics in the
> >> >> >>>> past as well.
> >> >> >>>>       > Additionally, if you listen to the audio recordings
> >> >> >> then you will
> >> >> >>>> notice
> >> >> >>>>       > that Henning, Ted, and Jon do not seem to
> understand
> >> >> >> the issue
> >> >> >>>> either as
> >> >> >>>>       > they have raised similar issues during the
> >> >F2F meetings.
> >> >> >>>>       >
> >> >> >>>>       > Ciao
> >> >> >>>>       > Hannes
> >> >> >>>>       >
> >> >> >>>>       >
> >> >> >>>>       > >Hannes - I believe it is you who do not understand
> >> >> >> RFC 4412 --
> >> >> >>>>       > >and many of us are trying to get that
> >> >through to you, but you
> >> >> >>>>       > >don't seem to want to listen/read.
> >> >> >>>>       > >
> >> >> >>>>       > >RFC 4412 is *for* priority marking SIP requests,
> >> >> >>>>       > >
> >> >> >>>>       > >One use is GETS.
> >> >> >>>>       > >
> >> >> >>>>       > >One use is MLPP.
> >> >> >>>>       > >
> >> >> >>>>       > >These examples are in RFC 4412 because there
> >> >were specific
> >> >> >>>>       > >namespaces being created for the IANA section of
> >> >> >> that document.
> >> >> >>>>       > >
> >> >> >>>>       > >Reading the whole document, you will see
> >> >that RPH can be
> >> >> >>>>       > >specified for other uses than GETS or MLPP
> >> >specifically.
> >> >> >>>>       > >
> >> >> >>>>       > >I knew when I wrote RFC 4412 that one day we
> >> >would specify a
> >> >> >>>>       > >namespace for ECRIT (the "esnet" namespace
> >> >now) -- but I also
> >> >> >>>>       > >knew it was premature for RFC 4412 to
> >> >incorporate that
> >> >> >>>>       > >namespace, that a future doc to RFC 4412
> >> >would have to be
> >> >> >>>>       > >written to do this. Brian and I talked about
> >> >this at the
> >> >> >>>>       > >original NENA meeting that created the IP
> WGs there
> >> >> >> (in August
> >> >> >>>>       > >of 03).  We both agreed we should wait
> until it was
> >> >> >>>>       > >appropriate to the work in the IETF to
> >> >submit this document
> >> >> >>>>       > >that is now
> >> >> >>>>       >
> >> >> >>>>>
> >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >> >> >>>>       > >gency-rph-namespace-00.txt
> >> >> >>>>       > >
> >> >> >>>>       > >Yet, you seem to want to use some additional
> >> >mechanism to
> >> >> >>>>       > >indicate priority of a call in SIP.  That
> >> >means you want to
> >> >> >>>>       > >introduce a second way to accomplish this in SIP.
> >> >> >>>> Why do you
> >> >> >>>>       > >want to promote a separate way to do something SIP
> >> >> >> has already
> >> >> >>>>       > >defined? That will cause interoperability
> issues and
> >> >> >> we both know
> >> >> >>>> that.
> >> >> >>>>       > >
> >> >> >>>>       > >You've said to me (and others) that you
> >> >believe RPH is just
> >> >> >>>>       > >another way to accomplish what sos or a URI can
> >> >> >> indicate - and
> >> >> >>>>       > >you're wrong.  Your way would be
> >> >_the_second_way_to_do_it,
> >> >> >>>>       > >because SIP already considers RPH to be
> >> >*the*way* to priority
> >> >> >>>>       > >mark SIP requests.
> >> >> >>>>       > >
> >> >> >>>>       > >If you don't believe me (no comment), then
> >> >why do you not
> >> >> >>>>       > >believe the SIP WG chair (who knows more
> >> >about SIP than both
> >> >> >>>>       > >of us) - who, on this thread, has again said
> >> >to you "RFC 4412
> >> >> >>>>       > >(RPH) is the SIP mechanism to priority mark
> >> >SIP requests"?
> >> >> >>>>       > >
> >> >> >>>>       > >Further, I believe it is inappropriate to
> >> >prohibit endpoints
> >> >> >>>>       > >from being able to set the esnet namespace.
> >> >I absolutely
> >> >> >>>>       > >believe it will not be needed most of the
> >> >time, but I believe
> >> >> >>>>       > >if someone does find a valid use for
> >> >endpoints to mark
> >> >> >>>>       > >priority in SIP, this ID - once it has
> >> >become an RFC -- will
> >> >> >>>>       > >have to be obsoleted with a new RFC
> saying the exact
> >> >> >> opposite.
> >> >> >>>>       > >
> >> >> >>>>       > >(color me confused ... over and over again)
> >> >> >>>>       > >
> >> >> >>>>       > >James
> >> >> >>>>       > >
> >> >> >>>>       > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >> >> >>>>       > >>Keith, please understand that the usage
> of RFC 4412
> >> >> >> for GETS and
> >> >> >>>> for
> >> >> >>>>       > >>the type of emergency call we discuss here is
> >> >> >> different. Just
> >> >> >>>> looking
> >> >> >>>>       > >>at the header and the name of the
> >namespace is a bit
> >> >> >>>>       > >artificial. I hope
> >> >> >>>>       > >>you understand that.
> >> >> >>>>       > >>
> >> >> >>>>       > >> >-----Original Message-----
> >> >> >>>>       > >> >From: DRAGE, Keith (Keith)
> >> >> >>>> [mailto:[email-masked]]
> >> >> >>>>       > >> >Sent: 05 February, 2009 14:55
> >> >> >>>>       > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M.
> >> >> >>>> Polk'; 'Tschofenig,
> >> >> >>>>       > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >> >> >>>>       > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
> >> >> >>>> Meeting: Agenda (my
> >> >> >>>>
> >> >> >>>>       > >> >mistake)
> >> >> >>>>       > >> >
> >> >> >>>>       > >> >Which is exactly what RFC 4412
> specifies for all
> >> >> >> namespaces.
> >> >> >>>>       > >> >
> >> >> >>>>       > >> >regards
> >> >> >>>>       > >> >
> >> >> >>>>       > >> >Keith
> >> >> >>>>       > >> >
> >> >> >>>>       > >> >> -----Original Message-----
> >> >> >>>>       > >> >> From: [email-masked]
> >> >> >> [mailto:[email-masked]]
> >> >> >>>>       > >> >On Behalf
> >> >> >>>>       > >> >> Of Brian Rosen
> >> >> >>>>       > >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >> >> >>>>       > >> >> To: 'Hannes Tschofenig'; 'James M.
> >> >Polk'; 'Tschofenig,
> >> >> >>>>       > >Hannes (NSN
> >> >> >>>>       > >> >> - FI/Espoo)'; 'ECRIT'
> >> >> >>>>       > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
> >> >> >>>> Meeting: Agenda (my
> >> >> >>>>       > >> >> mistake)
> >> >> >>>>       > >> >>
> >> >> >>>>       > >> >> The value is that in some networks
> >> >where priority for
> >> >> >>>>       > >> >emergency calls
> >> >> >>>>       > >> >> is appropriate, and appropriate
> >> >policing of marking is
> >> >> >>>>       > >implemented,
> >> >> >>>>       > >> >> emergency calls will receive
> resource priority.
> >> >> >>>>       > >> >>
> >> >> >>>>       > >> >> Not all networks would need policing.  Some
> >> >> >> will.  Policing
> >> >> >>>> could
> >> >> >>>>       > >> >> be to Route header/R-URI content, but other
> >> >> >> criteria are
> >> >> >>>> possible.
> >> >> >>>>       > >> >>
> >> >> >>>>       > >> >> Not all networks will need resource priority
> >> >> >> for emergency
> >> >> >>>> calls.
> >> >> >>>>       > >> >> Fine, ignore this marking/namespace.
> >> >> >>>>       > >> >>
> >> >> >>>>       > >> >> Brian
> >> >> >>>>       > >> >> > -----Original Message-----
> >> >> >>>>       > >> >> > From: Hannes Tschofenig
> >> >> >>>> [mailto:[email-masked]]
> >> >> >>>>       > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >> >> >>>>       > >> >> > To: 'Brian Rosen'; 'James M. Polk';
> >> >> >> Tschofenig, Hannes
> >> >> >>>> (NSN -
> >> >> >>>>       > >> >> > FI/Espoo); 'ECRIT'
> >> >> >>>>       > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
> >> >> >>>> Meeting: Agenda (my
> >> >> >>>>       > >> >> > mistake)
> >> >> >>>>       > >> >> >
> >> >> >>>>       > >> >> > I don't even see the value in
> permitting the
> >> >> >> endpoint todo
> >> >> >>>> the
> >> >> >>>>       > >> >> > RPH marking.
> >> >> >>>>       > >> >> > In addition to the security concerns
> >> >there is also the
> >> >> >>>>       > >> >problem that
> >> >> >>>>       > >> >> > there are more options to implement without
> >> >> >> an additional
> >> >> >>>> value.
> >> >> >>>>       > >> >> >
> >> >> >>>>       > >> >> > >-----Original Message-----
> >> >> >>>>       > >> >> > >From: Brian Rosen
> [mailto:[email-masked]]
> >> >> >>>>       > >> >> > >Sent: 05 February, 2009 00:03
> >> >> >>>>       > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
> >> >> >> 'Tschofenig,
> >> >> >>>>       > >> >> Hannes (NSN -
> >> >> >>>>       > >> >> > >FI/Espoo)'; 'ECRIT'
> >> >> >>>>       > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual
> >> >Interim Meeting:
> >> >> >>>> Agenda (my
> >> >> >>>>       > >> >> > mistake)
> >> >> >>>>       > >> >> > >
> >> >> >>>>       > >> >> > >Hannes
> >> >> >>>>       > >> >> > >
> >> >> >>>>       > >> >> > >This matches my understanding
> >> >precisely.  We wish to
> >> >> >>>>       > >> >> permit endpoints
> >> >> >>>>       > >> >> > >to mark. We do not require it, and
> >> >don't necessarily
> >> >> >>>> expect it
> >> >> >>>>       > >> >> > >in many (even
> >> >> >>>>       > >> >> > >most) cases.  We don't wish to see the
> >> >> >> document prohibit
> >> >> >>>> it.
> >> >> >>>>       > >> >> > >We all seem to agree it has value
> within the
> >> >> >> Emergency
> >> >> >>>>       > >> >Services IP
> >> >> >>>>       > >> >> > >Networks.
> >> >> >>>>       > >> >> > >
> >> >> >>>>       > >> >> > >Brian
> >> >> >>>>       > >> >> > >
> >> >> >>>>       > >> >> > >> -----Original Message-----
> >> >> >>>>       > >> >> > >> From: [email-masked]
> >> >> >>>> [mailto:[email-masked]]
> >> >> >>>>       > >> >> > >On Behalf
> >> >> >>>>       > >> >> > >> Of James M. Polk
> >> >> >>>>       > >> >> > >> Sent: Wednesday, February 04,
> 2009 4:01 PM
> >> >> >>>>       > >> >> > >> To: Hannes Tschofenig; Tschofenig,
> >> >Hannes (NSN -
> >> >> >>>>       > >> >> FI/Espoo); 'ECRIT'
> >> >> >>>>       > >> >> > >> Subject: Re: [Ecrit] ECRIT
> Virtual Interim
> >> >> >>>> Meeting:
> >> >> >>>>       > >Agenda (my
> >> >> >>>>       > >> >> > >> mistake)
> >> >> >>>>       > >> >> > >>
> >> >> >>>>       > >> >> > >> At 02:37 PM 2/4/2009, Hannes
> >> >Tschofenig wrote:
> >> >> >>>>       > >> >> > >> > > James wrote:
> >> >> >>>>       > >> >> > >> > >> you are the _lone_ voice not
> >> >> >> supporting this ID,
> >> >> >>>>       > >> >> > >> >
> >> >> >>>>       > >> >> > >> >Listening to the audio
> recording of past
> >> >> >> meetings I
> >> >> >>>> have to
> >> >> >>>>       > >> >> > >say that
> >> >> >>>>       > >> >> > >> >I
> >> >> >>>>       > >> >> > >> was
> >> >> >>>>       > >> >> > >> >not the only persons raising
> >> >concerns about the
> >> >> >>>> document.
> >> >> >>>>       > >> >> > >> >That was probably the reason why you
> >> >> >> agreed to limit
> >> >> >>>> the
> >> >> >>>>       > >> >> > >scope of the
> >> >> >>>>       > >> >> > >> >document (which you didn't later do) to
> >> >> >> get folks to
> >> >> >>>> agree
> >> >> >>>>       > >> >> > >to make it
> >> >> >>>>       > >> >> > >> a WG
> >> >> >>>>       > >> >> > >> >item.
> >> >> >>>>       > >> >> > >>
> >> >> >>>>       > >> >> > >> re-listen to the audio please
> >> >> >>>>       > >> >> > >>
> >> >> >>>>       > >> >> > >> Ted's concerns were consistent with most
> >> >> >>>> (all?) other
> >> >> >>>>       > >> >> concerns --
> >> >> >>>>       > >> >> > >> which were based on the premise
> of whether
> >> >> >> or not the
> >> >> >>>>       > >> >> UAC should be
> >> >> >>>>       > >> >> > >> trusted to initiate the marking on the
> >> >> >> INVITE.  The
> >> >> >>>> most
> >> >> >>>>       > >> >> > >> recent version has backed off this
> >> >to a "can" --
> >> >> >>>> meaning not
> >> >> >>>>       > >> >prohibited
> >> >> >>>>       > >> >> > >> (i.e., no 2119 text).  I also backed off
> >> >> >> the text in
> >> >> >>>> the
> >> >> >>>>       > >> >> SP domain
> >> >> >>>>       > >> >> > >> part to "can", such that there is
> >> >no 2119 text
> >> >> >>>>       > >> >mandating or even
> >> >> >>>>       > >> >> > >> recommending its usage there. I also do
> >> >> >> not prohibit
> >> >> >>>> its
> >> >> >>>>       > >> >> > >use, based on
> >> >> >>>>       > >> >> > >> local policy.  Keith has come
> forward with
> >> >> >> the specific
> >> >> >>>>
> >> >> >>>>       > >> >> > >> request that non-ESInet networks be
> >> >> >> allowed to mark and
> >> >> >>>> pay
> >> >> >>>>       > >> >attention to
> >> >> >>>>       > >> >> > >> this priority indication -- with IMS as
> >> >> >> the specific
> >> >> >>>> example
> >> >> >>>>       > >> >> > >> he wishes to have this valid for.
> >> >> >>>>       > >> >> > >>
> >> >> >>>>       > >> >> > >> Where there is no disagreement, save for
> >> >> >> your recent
> >> >> >>>>       > >> >> > >pushback - is in
> >> >> >>>>       > >> >> > >> the ESInet, which is where Brian
> >> >has requested it's
> >> >> >>>>       > >> >> > >definition in the
> >> >> >>>>       > >> >> > >> IETF on behalf of NENA.  He's the i3 WG
> >> >> >> chair within
> >> >> >>>>       > >> >> NENA, and if
> >> >> >>>>       > >> >> > >> he asks for it, are you going to say you
> >> >> >> know better
> >> >> >>>> than he?
> >> >> >>>>       > >> >> > >>
> >> >> >>>>       > >> >> > >>
> >> >> >>>>       > >> >> > >> >Btw, I not disagreeing with
> the document
> >> >> >> as such. I
> >> >> >>>>       > >> >just want to
> >> >> >>>>       > >> >> > the
> >> >> >>>>       > >> >> > >> scope
> >> >> >>>>       > >> >> > >> >to change. The usage of RPH
> >> >within the emergency
> >> >> >>>>       > >> >> services network
> >> >> >>>>       > >> >> > is
> >> >> >>>>       > >> >> > >> fine
> >> >> >>>>       > >> >> > >> >for me. I may get convinced to
> start the
> >> >> >> RPH marking
> >> >> >>>> from
> >> >> >>>>       > >> >> > >the the VSP
> >> >> >>>>       > >> >> > >> >towards the PSAP. I feel
> uneasy about the
> >> >> >> end host
> >> >> >>>> doing
> >> >> >>>>       > >> >> > >the marking.
> >> >> >>>>       > >> >> > >>
> >> >> >>>>       > >> >> > >> please read what I wrote above, and then
> >> >> >> re-read the
> >> >> >>>>       > >> >most recent
> >> >> >>>>       > >> >> > >> version of the ID. I don't have
> endpoints
> >> >> >> that SHOULD
> >> >> >>>> or
> >> >> >>>>       > >> >> MUST mark
> >> >> >>>>       > >> >> > >> anything wrt RPH.  I also don't want to
> >> >> >> prohibit it,
> >> >> >>>>       > >> >> because there
> >> >> >>>>       > >> >> > >> might be cases (that I don't know
> >> >of) of valid uses
> >> >> >>>>       > >> >> under certain
> >> >> >>>>       > >> >> > >> circumstances.  Figure 1 is very clear
> >> >> >> that there are 3
> >> >> >>>>       > >> >> networking
> >> >> >>>>       > >> >> > >> parts to consider
> >> >> >>>>       > >> >> > >>
> >> >> >>>>       > >> >> > >> #1 - from the endpoint
> >> >> >>>>       > >> >> > >> #2 - within the VSP
> >> >> >>>>       > >> >> > >> #3 - within the ESInet
> >> >> >>>>       > >> >> > >>
> >> >> >>>>       > >> >> > >> the most recent ID version has "can" for
> >> >> >> #s 1 and 2,
> >> >> >>>> and
> >> >> >>>>       > >> >> > >2119 language
> >> >> >>>>       > >> >> > >> offering those supporting this
> >> >> >> specification will have
> >> >> >>>> RPH
> >> >> >>>>       > >> >> > >> adherence within #3 (the ESInet).
> >> >> >>>>       > >> >> > >>
> >> >> >>>>       > >> >> > >> What other scope changes do you want,
> >> >> >> because I haven't
> >> >> >>>>       > >> >> heard them.
> >> >> >>>>       > >> >> > >>
> >> >> >>>>       > >> >> > >> I only heard you claim in email
> during the
> >> >> >> last IETF
> >> >> >>>> and in
> >> >> >>>>       > >> >> > >the ECRIT
> >> >> >>>>       > >> >> > >> session that RPH should not be
> >> >used for priority
> >> >> >>>> marking
> >> >> >>>>       > >> >> requests.
> >> >> >>>>       > >> >> > >> This is something Keith (SIP WG
> >> >chair) voiced his
> >> >> >>>> opposition
> >> >> >>>>       > >> >> > >> to your views regarding
> creating a second
> >> >> >> means for SIP
> >> >> >>>> to
> >> >> >>>>       > >> >priority
> >> >> >>>>       > >> >> > >> mark request "when SIP already has one
> >> >> >> interoperable
> >> >> >>>> way to
> >> >> >>>>       > >> >> > >> accomplish this... it's call
> the RP header
> >> >> >> mechanism".
> >> >> >>>>       > >> >> > >>
> >> >> >>>>       > >> >> > >> >I don't see advantages -- only
> >> >disadvantages.
> >> >> >>>>       > >> >> > >> >
> >> >> >>>>       > >> >> > >> >Ciao
> >> >> >>>>       > >> >> > >> >Hannes
> >> >> >>>>       > >> >> > >>
> >> >> >>>>       > >> >> > >>
> >> >_______________________________________________
> >> >> >>>>       > >> >> > >> Ecrit mailing list
> >> >> >>>>       > >> >> > >> [email-masked]
> >> >> >>>>       > >> >> > >>
> >https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >>>>       > >> >> > >
> >> >> >>>>       > >> >>
> >> >> >>>>       > >> >>
> _______________________________________________
> >> >> >>>>       > >> >> Ecrit mailing list
> >> >> >>>>       > >> >> [email-masked]
> >> >> >>>>       > >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >>>>       > >> >>
> >> >> >>>>       > >> >
> >> >> >>>>       > >
> >> >> >>>>       >
> >> >> >>>>       > _______________________________________________
> >> >> >>>>       > Ecrit mailing list
> >> >> >>>>       > [email-masked]
> >> >> >>>>       > https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> _______________________________________________
> >> >> >>>> Ecrit mailing list
> >> >> >>>> [email-masked]
> >> >> >>>> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >>>>
> >> >> >>>
> >> >> >>> _______________________________________________
> >> >> >>> Ecrit mailing list
> >> >> >>> [email-masked]
> >> >> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >>
> >> >> >
> >> >> > _______________________________________________
> >> >> > Ecrit mailing list
> >> >> > [email-masked]
> >> >> > https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >
> >> >
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >>
> >> --------------------------------------------------------------
> >> ----------------------------------
> >> This message is for the designated recipient only and may contain
> >> privileged, proprietary, or otherwise private information.
> >> If you have received it in error, please notify the sender
> >immediately
> >> and delete the original.  Any unauthorized use of this email is
> >> prohibited.
> >> --------------------------------------------------------------
> >> ----------------------------------
> >> [mf2]
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >
>
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'DRAGE, Keith \(Keith\)'" <[email-masked]>, "'Winterbottom, James'" <[email-masked]>, "'Brian Rosen'" <[email-masked]>, "'Henning Schulzrinne'" <[email-masked]>
Date: Sun, 8 Feb 2009 11:23:55 +0200
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] RPH

Hi Keith, 

it seems that further arguments from my side will not help to convince you. 
That happens. 

Ciao
Hannes
 
>-----Original Message-----
>From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
>Sent: 08 February, 2009 02:59
>To: Hannes Tschofenig; 'Winterbottom, James'; 'Brian Rosen'; 
>'Henning Schulzrinne'
>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
>Subject: RE: [Ecrit] RPH
>
>We go round and round in circles.
>
>We had this discussion on the mail list before the last IETF meeting.
>
>Different headers have different semantics. The service urn 
>appears in a part of the SIP message where RFC 3261 defines 
>exactly the semantics it has. Those appearances have nothing 
>to do with the semantics of a resource priority header.
>
>regards
>
>Keith
>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[email-masked]]
>> Sent: Saturday, February 07, 2009 8:29 AM
>> To: DRAGE, Keith (Keith); 'Winterbottom, James'; 'Brian Rosen'; 
>> 'Henning Schulzrinne'
>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
>> Subject: RE: [Ecrit] RPH
>>
>> What do you think is the semantic of the Service URN (or the 
>> respective dial string)?
>> Emergency call with special processing needed? Do everything so that 
>> the call gets through?
>>
>> How often do you want to say that the call is really 
>important to you?
>>
>> We could invent a few more headers say "Yes, it is really important. 
>> Believe me -- really, really important. Also add location 
>because that 
>> it could be needed to locate me.". See my other mail where I 
>invented 
>> such a new header that from a philosophical point of view 
>(not from a 
>> practical) makes a lot of sense.
>>
>> Code just needs to know it is important and can do all the necessary 
>> steps.
>> I doubt that someone would write code that does not treat the 
>> emergency call as less important when an emergency call 
>comes in that 
>> does not have the ECRIT RPH header present. Would you think so?
>>
>> Ciao
>> Hannes
>>
>> >-----Original Message-----
>> >From: DRAGE, Keith (Keith) [mailto:[email-masked]]
>> >Sent: 07 February, 2009 02:15
>> >To: Winterbottom, James; Hannes Tschofenig; Brian Rosen; Henning 
>> >Schulzrinne
>> >Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>> >Subject: RE: [Ecrit] RPH
>> >
>> >It is a valid header for that usage. It carries exactly the
>> semantics
>> >the user wishes to convey, i.e. that the requestor would
>> like the call
>> >to be treated in processing by the network in a manner
>> appropriate to
>> >emergency calls.
>> >
>> >Yes the edge proxy may well review and make up its own mind,
>> and either
>> >remove, verify or pass on the header, but that does not mean it is 
>> >wrong from the UE.
>> >
>> >You might just as well argue that the UE should not inserted a 
>> >P-Preferred-ID if it knows that the value it contains will
>> be the one
>> >inserted by the edge proxy.
>> >
>> >regards
>> >
>> >Keith
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> From: [email-masked] [mailto:[email-masked]]
>> >On Behalf
>> >> Of Winterbottom, James
>> >> Sent: Friday, February 06, 2009 8:02 PM
>> >> To: Hannes Tschofenig; Brian Rosen; Henning Schulzrinne
>> >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>> >> Subject: Re: [Ecrit] RPH
>> >>
>> >> Hi All,
>> >>
>> >> I have followed thi thread with some interest and I
>> >struggling to see
>> >> a use case for the providing RPH for emergency calls from the 
>> >> end-point.
>> >>
>> >> The reference-model call in ECRIT, for better or worse, 
>is for all 
>> >> calls to go back through a home-VSP.
>> >> We placed quite a lot of emphasis, largely for traffing
>> reasons, for
>> >> the VSP to be able to verify that a call is in fact an
>> >emergency call.
>> >> This is done by the proxy taking the inband location, 
>doing a LoST 
>> >> query with the provided URN, and verifying that the resulting 
>> >> destination URI is the same as the destination URI provide
>> >in the SIP
>> >> INVITE. My understanding was that VSPs would always do
>> this check so
>> >> they could tell if they could bill for the call or not,
>> and because
>> >> the VSP can be use that the call is an emergency call it can
>> >apply any
>> >> special priorities that may be applicable.
>> >> This obviates the need for RPH from the end-point to the network.
>> >>
>> >> This leaves us with the argument of "it doesn't hurt to it",
>> >which is
>> >> not a good reason to write a specification.
>> >> It was intimated on the geopriv mailing list last year that great 
>> >> pains had been taken to keep SIP with in the MTU limits of
>> UDP over
>> >> Ethernet
>> >> (http://www.ietf.org/mail-archive/web/geopriv/current/msg06120
>> >> .html). Assuming that this is the case, perhaps there is harm in 
>> >> including information that we know will be ignored.
>> >>
>> >> Cheers
>> >> James
>> >>
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: [email-masked] on behalf of Hannes Tschofenig
>> >> Sent: Fri 2/6/2009 12:33 PM
>> >> To: 'Brian Rosen'; 'Henning Schulzrinne'
>> >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
>> >> Subject: Re: [Ecrit] RPH
>> >>
>> >> To the story short here is the code for the proxy:
>> >>
>> >> ---------------------
>> >>
>> >> IF emergency call was recognized THEN
>> >>     execute emergency call specific procedures (priority queuing, 
>> >> preemption, fetch location, determine routing, do funny
>> QoS things &
>> >> co) ELSE
>> >>     normal call handling procedures.
>> >>
>> >> ---------------------
>> >>
>> >> If you can make this differentiation between an emergency
>> call and a
>> >> regular call then you can also do everything that is 
>necessary for 
>> >> emergency call handling.
>> >>
>> >> Brian + Keith: Please tell me that we cannot do the above 
>with our 
>> >> currently specified mechanisms.
>> >>
>> >> Ciao
>> >> Hannes
>> >>
>> >> >-----Original Message-----
>> >> >From: Brian Rosen [mailto:[email-masked]]
>> >> >Sent: 06 February, 2009 17:49
>> >> >To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
>> >> >Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
>> >> >Subject: RE: [Ecrit] RPH
>> >> >
>> >> >I agree that not all networks will permit (or pay attention
>> >> >to) a priority request from an end device.
>> >> >
>> >> >No one has asked for that.
>> >> >
>> >> >The namespace request has several uses, one of which is 
>within an 
>> >> >emergency services IP network, one of which is between
>> >> elements within
>> >> >a public network controlled by the operator, and one of
>> which is an
>> >> >endpoint request for resource priority.
>> >> >
>> >> >Those of us requesting this work proceed are happy if the
>> >> endpoint part
>> >> >is simply left as possible (MAY), and, speaking for myself,
>> >> having the
>> >> >draft discuss the security implications of endpoint marking is 
>> >> >reasonable.
>> >> >
>> >> >Having discussed this issue with an implementation team who
>> >> worked on
>> >> >MLPP systems, I am confident I know what I'm talking about,
>> >> but YMMV.
>> >> >The fact that you could, if you wanted to, give resource
>> >> priority to a
>> >> >call you decided, however you decided, was an emergency
>> call is an
>> >> >implementation decision, and not subject to standardization.
>> >> >
>> >> >RPH is the IETF standard way for one entity to request resource 
>> >> >priority of another entity in a SIP system.  We're asking for a 
>> >> >namespace to use that within the domain of emergency calls.
>> >> That is, I
>> >> >think, a VERY reasonable request.
>> >> >
>> >> >Brian
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Henning Schulzrinne [mailto:[email-masked]]
>> >> >> Sent: Friday, February 06, 2009 10:33 AM
>> >> >> To: Hannes Tschofenig
>> >> >> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>> >> >> Subject: Re: [Ecrit] RPH
>> >> >>
>> >> >> To chime in here:
>> >> >>
>> >> >> I don't think it's productive to simply state that 4412
>> >> >doesn't worry
>> >> >> about authorization, so we shouldn't either 
>(simplifying a bit).
>> >> >> Authorization was discussed repeatedly, and the general
>> >> >assumption was
>> >> >> that there were two conditions: Either the user invoking
>> >resource-
>> >> >> priority was well known and had a set of permissions that
>> >could be
>> >> >> checked in real time or there are ways to deal with abuse
>> >> after the
>> >> >> fact in ways that deter abuse (the court-martial kind of
>> >> thing in a
>> >> >> military context).
>> >> >>
>> >> >> The RFC 4412 security consideration (11.2) call this out
>> >in pretty
>> >> >> strong language:
>> >> >>
>> >> >>   Prioritized access to network and end-system 
>resources imposes
>> >> >>     particularly stringent requirements on authentication and
>> >> >>     authorization mechanisms, since access to prioritized
>> >> >resources may
>> >> >>     impact overall system stability and performance and not
>> >> >just result
>> >> >>     in theft of, say, a single phone call.
>> >> >> Thus, the question is whether we have such strong
>> >> authentication in
>> >> >> emergency calling. In some cases, such as residential
>> fixed line
>> >> >> deployments where ISP = VSP, we're probably pretty close,
>> >> in others,
>> >> >> such as prepaid cell phones or hot spots or VSP-only
>> >providers, we
>> >> >> aren't.
>> >> >>
>> >> >> The other point that I think Hannes is making is that the
>> >> >information
>> >> >> is either redundant or dangerous. If a processing element
>> >> recognizes
>> >> >> the call as being an emergency call, it can apply whatever
>> >> treatment
>> >> >> it deems appropriate and doesn't need additional
>> >> information. If it
>> >> >> doesn't or can't, using just the RPH can be rather
>> >> dangerous unless
>> >> >> that element can be reasonably certain that there is strong 
>> >> >> authentication and recourse.
>> >> >>
>> >> >> I don't buy the argument that somehow finding the RPH is
>> >> faster than
>> >> >> just looking for the identifier. Thus, given that the
>> >> information is
>> >> >> either redundant or dangerous, I fail to see the advantage.
>> >> >>
>> >> >> Henning
>> >> >>
>> >> >>
>> >> >> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:
>> >> >>
>> >> >> > Don't get hung up on the details. There are ways to
>> optimize it.
>> >> >> > That was
>> >> >> > not the point of the code example.
>> >> >> >
>> >> >> > The problem that my pseudo code should have shown you
>> >is that you
>> >> >> > * don't gain anything with RPH marking for the emergency
>> >> call case
>> >> >> > from the SIP UA towards the outbound proxy since the
>> >> functionality
>> >> >> > is already provide otherwise. How often does the proxy
>> >> need to get
>> >> >> > told that this is an emergency call todo whatever
>> >emergency call
>> >> >> > handling procedures are necessary?
>> >> >> > * you only introduce fraud problems (if you are not
>> >> >careful and you
>> >> >> > understand the security stuff well enough)
>> >> >> >
>> >> >> > If you can point me to people who implement the RPH
>> >> emergency call
>> >> >> > case please do so. I would love to talk to them.
>> >> >> >
>> >> >> > Ciao
>> >> >> > Hannes
>> >> >> >
>> >> >> > PS: You need to parse incoming messages to some extend
>> >> so that you
>> >> >> > know what it contains :-) Only looking for the emergency
>> >> >RPH header
>> >> >> > (and not for the Service URN/dial
>> >> >> > string) would exactly be the DoS/fraud attack I am
>> >worried about.
>> >> >> > That's the thing Henning was worried about (go and
>> >listen to the
>> >> >> > past meeting minutes).
>> >> >> >
>> >> >> >
>> >> >> >> Hannes
>> >> >> >>
>> >> >> >> You need to talk to people who really implement this kind
>> >> >of thing.
>> >> >> >> You are way off.
>> >> >> >>
>> >> >> >> When you implement a resource priority system, the
>> >> point of doing
>> >> >> >> that is to look though the queue of work and pick out the
>> >> >ones with
>> >> >> >> priority, handling them first.  You don't do all the
>> >> parsing, you
>> >> >> >> don't do a lot of decision tree.
>> >> >> >>
>> >> >> >> Typically:
>> >> >> >> Check for DoS things, like too big messages, etc Do a
>> >> quick scan
>> >> >> >> for the RPH message header If found:
>> >> >> >> Parse the message
>> >> >> >> Determine validity
>> >> >> >> Determine priority
>> >> >> >> Queue on the correct work queue
>> >> >> >>
>> >> >> >> The first two actions have to be very fast.  Anyone who
>> >> builds a
>> >> >> >> SIP thingie will tell you that parsing is one of the
>> big cycle
>> >> >> >> consumers: if you have to parse every message BEFORE you
>> >> >determine
>> >> >> >> priority, you can't give much resource priority.
>> >> >> >> Once you get the whole message parsed, you might as
>> >well finish
>> >> >> >> working on it, because you've done so much of the work.
>> >> >> >> OTHOH, finding the end-of-message delimiter and
>> doing a quick
>> >> >> >> string search for RPH is fast.  If you are doing
>> >> >priority, you need
>> >> >> >> to keep all the priority processing pretty uniform,
>> and pretty
>> >> >> >> simple, or you tend to spend too much time futzing around
>> >> >figuring
>> >> >> >> out what to do.  You put all the priority related stuff
>> >> together,
>> >> >> >> and use as much common code as possible.
>> >> >> >>
>> >> >> >> Brian
>> >> >> >>
>> >> >> >>> -----Original Message-----
>> >> >> >>> From: [email-masked] 
>[mailto:[email-masked]]
>> >> >> >> On Behalf
>> >> >> >>> Of Hannes Tschofenig
>> >> >> >>> Sent: Friday, February 06, 2009 8:41 AM
>> >> >> >>> To: 'Hannes Tschofenig'; 'Janet P Gunn'
>> >> >> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- 
>> >> >> >>> [email-masked]
>> >> >> >>> Subject: [Ecrit] RPH
>> >> >> >>>
>> >> >> >>> Over lunch I was also thinking how an outbound proxy would
>> >> >> implement
>> >> >> >>> some of the emergency procedures. Here are some thoughts:
>> >> >> >>>
>> >> >> >>> ---------------------------------------------------
>> >> >> >>>
>> >> >> >>> // Process incoming message
>> >> >> >>> Parse(msg);
>> >> >> >>>
>> >> >> >>> // SIP INVITE without Service URN // legacy devices If
>> >> >> >>> (recognize-dialstring(msg)==TRUE) {  // we got an
>> >> emergency call
>> >> >> >>> going on  emergency=TRUE;  if (dialstring(msg) == 911) 
>> >> >> >>> serviceURN=urn:service:sos; } else if
>> >> >> >>> (recognize-serviceURN(msg)==TRUE) {  // oh. A updated
>> >> >device that
>> >> >> >>> has a service URN attached to the
>> >> >> call
>> >> >> >>>  serviceURN=retrieve_ServiceURN(msg);
>> >> >> >>>  emergency=TRUE;
>> >> >> >>> } else {
>> >> >> >>>  // standard SIP message
>> >> >> >>>  // regular processing
>> >> >> >>>  process(msg);
>> >> >> >>>  emergency=FALSE;
>> >> >> >>> }
>> >> >> >>>
>> >> >> >>> If (emergency == TRUE) {
>> >> >> >>>   // make sure that the emergency call does not get
>> >> >dropped on the
>> >> >> >>> floor
>> >> >> >>>   // skip authorization failures
>> >> >> >>>   // give the call a special treatment
>> >> >> >>>   lots-of-code-here();
>> >> >> >>>
>> >> >> >>>   // trigger all the QoS signaling you have in the
>> >> >network to make
>> >> >> >>> James happy
>> >> >> >>>   trigger-qos();
>> >> >> >>>
>> >> >> >>>   // query location
>> >> >> >>>   location=retrieve-location();
>> >> >> >>>
>> >> >> >>>   // determine next hop
>> >> >> >>>   next-hop=lost(location, serviceURN)
>> >> >> >>>
>> >> >> >>>   // attach RPH marking to outgoing msg to make James and
>> >> >> >> Keith happy
>> >> >> >>>   msg=add(msg, RPH);
>> >> >> >>>
>> >> >> >>>   send(msg, next-hop);
>> >> >> >>> }
>> >> >> >>>
>> >> >> >>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) {
>> >> >> >>>   // all the emergency related processing done
>> already upfront
>> >> >> >>>   // hence I log something.
>> >> >> >>>   log(RPH_WAS_PRESENT_JUHU); } else if 
>((rph-present(msg) == 
>> >> >> >>> TRUE) && (emergency ==
>> >> >FALSE)) {
>> >> >> >>> // this is not an emergency call  // this is something
>> >> >like GETS
>> >> >> >>> result=special-authorization-procedure(user);
>> >> >> >>>
>> >> >> >>>  if (result == AUTHORIZED) {
>> >> >> >>>    // do some priority & preemption thing here.
>> >> >> >>>    // trigger all the QoS you have
>> >> >> >>>    lots-of-code-here();
>> >> >> >>>  } else {
>> >> >> >>>    log("NOT AUTHORIZED; don't DoS my network");  } }
>> >> else {  //
>> >> >> >>> don't need todo any RPH processing  // this
>> includes the case
>> >> >> >>> where the call was an emergency call but the RPH
>> >> >> >>>
>> >> >> >>>  // marking was not there.
>> >> >> >>>  nothing();
>> >> >> >>> }
>> >> >> >>>
>> >> >> >>> ---------------------------------------------------
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> Ciao
>> >> >> >>> Hannes
>> >> >> >>>
>> >> >> >>>> -----Original Message-----
>> >> >> >>>> From: [email-masked]
>> >> [mailto:[email-masked]] On
>> >> >> >>>> Behalf Of Hannes Tschofenig
>> >> >> >>>> Sent: 06 February, 2009 15:07
>> >> >> >>>> To: 'Janet P Gunn'
>> >> >> >>>> Cc: 'ECRIT'; [email-masked];
>> Tschofenig,Hannes (NSN -
>> >> >> >>> FI/Espoo)
>> >> >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
>> >> Agenda (RPH)
>> >> >> >>>>
>> >> >> >>>> Who would define something that could prevent DoS 
>problems?
>> >> >> >>>>
>> >> >> >>>> ________________________________
>> >> >> >>>>
>> >> >> >>>>       From: Janet P Gunn [mailto:[email-masked]]
>> >> >> >>>>       Sent: 06 February, 2009 14:11
>> >> >> >>>>       To: Hannes Tschofenig
>> >> >> >>>>       Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; 
>> >> >> >>>> [email-masked]; Tschofenig, Hannes (NSN -
>> FI/Espoo);
>> >> >> 'James
>> >> >> >>>> M. Polk'
>> >> >> >>>>       Subject: Re: [Ecrit] ECRIT Virtual Interim
>> >> >Meeting: Agenda (RPH)
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>       But there is nothing IN RFC4412 that specifically
>> >> >> >> addresses how to
>> >> >> >>>> prevent any particular namespace being used for DoS.
>> >> Anyone/any
>> >> >> UA
>> >> >> >>>> can ATTEMPT to invoke priority treatment by attaching
>> >> RPH.  For
>> >> >> all
>> >> >> >>>> of the 4412 namespaces, as with the new proposed
>> >> namespace, the
>> >> >> >>>> mechanisms for preventing DoS are not specified in the
>> >> >> >> document that
>> >> >> >>>> defines the namespace.
>> >> >> >>>> They are/will be specified elsewhere.
>> >> >> >>>>
>> >> >> >>>>       Janet
>> >> >> >>>>
>> >> >> >>>>       This is a PRIVATE message. If you are not
>> the intended
>> >> >> >> recipient,
>> >> >> >>>> please delete without copying and kindly advise us by
>> >> e-mail of
>> >> >> the
>> >> >> >>>> mistake in delivery.
>> >> >> >>>>       NOTE: Regardless of content, this e-mail shall not
>> >> >> >> operate to bind
>> >> >> >>>> CSC to any order or other contract unless pursuant to
>> >> explicit
>> >> >> >>>> written agreement or government initiative expressly
>> >> permitting
>> >> >> the
>> >> >> >>>> use of e-mail for such purpose.
>> >> >> >>>>
>> >> >> >>>>       [email-masked] wrote on 02/06/2009
>> 04:21:51 AM:
>> >> >> >>>>
>> >> >> >>>>       > Hi James,
>> >> >> >>>>       >
>> >> >> >>>>       > I have read RFC 4412 and also the GETS/MLPP IETF
>> >> >> >> documents. What I
>> >> >> >>>> would
>> >> >> >>>>       > like to point out is that there is more 
>than just a
>> >> >> >> header and
>> >> >> >>>> values within
>> >> >> >>>>       > the header that have to be considered in order to
>> >> >> >> make a judgement
>> >> >> >>>> of what
>> >> >> >>>>       > is appropriate and what isn't. There is an
>> >> >> >> architectural question
>> >> >> >>>> and
>> >> >> >>>>       > whether the environment we are using the stuff is
>> >> >> >> indeed providing
>> >> >> >>>> the
>> >> >> >>>>       > properties you need for the solution to be
>> >> >appropriate.
>> >> >> >>>>       >
>> >> >> >>>>       > Let me describe in more detail what I meant (and
>> >> >> >> please correct me
>> >> >> >>>> if I am
>> >> >> >>>>       > wrong).
>> >> >> >>>>       >
>> >> >> >>>>       > Getting priority for SIP requests when 
>using a GETS
>> >> >> >> alike scenario
>> >> >> >>>> means
>> >> >> >>>>       > that the entity that issues the request is
>> specially
>> >> >> >> authorized
>> >> >> >>>> since
>> >> >> >>>>       > otherwise you introduce a nice denial of
>> >> >service attack. This
>> >> >> >>>> authorization
>> >> >> >>>>       > is tied to the entity that makes the request. For
>> >> >> >> example, the
>> >> >> >>>> person is
>> >> >> >>>>       > working for the government and has special rights.
>> >> >> >>>> James Bond as a (not so)
>> >> >> >>>>       > secret agent might have these rights.
>> >> >> >>>>       >
>> >> >> >>>>       > The emergency services case
>> >> >(citizen-to-authority) is a bit
>> >> >> >>>> different as
>> >> >> >>>>       > there aren't really special rights with respect to
>> >> >> >> authorization
>> >> >> >>>> tied to
>> >> >> >>>>       > individuals. Instead, the fact that 
>something is an
>> >> >> >> emergency is
>> >> >> >>>> purely a
>> >> >> >>>>       > judgement of the human that dials a 
>special number.
>> >> >> >>>> To deal with fraud, we
>> >> >> >>>>       > discussed in the group on what we can
>> actually do to
>> >> >> >> ensure that
>> >> >> >>>> end users
>> >> >> >>>>       > do not bypass security procedures (such as
>> >> >> >> authorization checks,
>> >> >> >>>> charging
>> >> >> >>>>       > and so on). Part of this investigation was
>> >> >the publication of
>> >> >> >>>>       > http://www.ietf.org/rfc/rfc5069.txt that also
>> >> >describes this
>> >> >> >>>> issue.
>> >> >> >>>>       >
>> >> >> >>>>       > So, imagine the implementation of a SIP
>> proxy (and we
>> >> >> >> implemented
>> >> >> >>>> that
>> >> >> >>>>       > stuff) that receives a call that contains 
>a Service
>> >> >> >> URN. The code
>> >> >> >>>> branches
>> >> >> >>>>       > into a special mode where everything is done
>> >> >so that the call
>> >> >> >>>> receives
>> >> >> >>>>       > appropriate treatment and does not get
>> dropped on the
>> >> >> >> floor. The
>> >> >> >>>> way how the
>> >> >> >>>>       > Service URN is placed in the message
>> ensures that the
>> >> >> >> call cannot
>> >> >> >>>> go to my
>> >> >> >>>>       > friend (instead of the PSAP) unless the
>> end host ran
>> >> >> >> LoST already.
>> >> >> >>>> In the
>> >> >> >>>>       > latter case, we discussed this also on the
>> list for a
>> >> >> >> while and
>> >> >> >>>> Richard even
>> >> >> >>>>       > wrote a draft about it in the context of the
>> >> >location hiding
>> >> >> >>>> topic, we said
>> >> >> >>>>       > that the proxy would have to run LoST if he
>> >> >cares about a
>> >> >> >>>> potential
>> >> >> >>>>       > fraudulent usage.
>> >> >> >>>>       >
>> >> >> >>>>       > So, what do we need todo in order to provide
>> >> >secure RFC 4412
>> >> >> >>>> functionality
>> >> >> >>>>       > in our context?
>> >> >> >>>>       >
>> >> >> >>>>       > Do you think that the current text in
>> >> >> >>>>       >
>> >> >> >>>>
>> >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>> >> >> >>>> gency-rph-nam
>> >> >> >>>>       > espace-00.txt reflects any of the
>> >> >above-described issues:
>> >> >> >>>>       > "
>> >> >> >>>>       >    The Security considerations that apply
>> to RFC 4412
>> >> >> >>>> [RFC4412]
>> >> >> >>>> apply
>> >> >> >>>>       >    here.  This document introduces no new security
>> >> >> >>>> issues relative
>> >> >> >>>> to
>> >> >> >>>>       >    RFC 4412.
>> >> >> >>>>       > "
>> >> >> >>>>       >
>> >> >> >>>>       > From various discussions in GEOPRIV I recall
>> >> >that you are
>> >> >> >>>> super-sensitive
>> >> >> >>>>       > regarding security and privacy. For some
>> reasons you
>> >> >> >> don't seem to
>> >> >> >>>> have the
>> >> >> >>>>       > same concerns here. I would like to
>> >> >understand your reasoning.
>> >> >> >>>>       >
>> >> >> >>>>       > Please also do me another favor: Don't always say
>> >> >> >> that I don't
>> >> >> >>>> understand
>> >> >> >>>>       > the subject. Even if that would be the
>> case it isn't
>> >> >> >> particular
>> >> >> >>>> fair given
>> >> >> >>>>       > that different folks had to educate you on other
>> >> >> >> topics in the
>> >> >> >>>> past as well.
>> >> >> >>>>       > Additionally, if you listen to the audio 
>recordings
>> >> >> >> then you will
>> >> >> >>>> notice
>> >> >> >>>>       > that Henning, Ted, and Jon do not seem to
>> understand
>> >> >> >> the issue
>> >> >> >>>> either as
>> >> >> >>>>       > they have raised similar issues during the
>> >> >F2F meetings.
>> >> >> >>>>       >
>> >> >> >>>>       > Ciao
>> >> >> >>>>       > Hannes
>> >> >> >>>>       >
>> >> >> >>>>       >
>> >> >> >>>>       > >Hannes - I believe it is you who do not 
>understand
>> >> >> >> RFC 4412 --
>> >> >> >>>>       > >and many of us are trying to get that
>> >> >through to you, but you
>> >> >> >>>>       > >don't seem to want to listen/read.
>> >> >> >>>>       > >
>> >> >> >>>>       > >RFC 4412 is *for* priority marking SIP requests,
>> >> >> >>>>       > >
>> >> >> >>>>       > >One use is GETS.
>> >> >> >>>>       > >
>> >> >> >>>>       > >One use is MLPP.
>> >> >> >>>>       > >
>> >> >> >>>>       > >These examples are in RFC 4412 because there
>> >> >were specific
>> >> >> >>>>       > >namespaces being created for the IANA section of
>> >> >> >> that document.
>> >> >> >>>>       > >
>> >> >> >>>>       > >Reading the whole document, you will see
>> >> >that RPH can be
>> >> >> >>>>       > >specified for other uses than GETS or MLPP
>> >> >specifically.
>> >> >> >>>>       > >
>> >> >> >>>>       > >I knew when I wrote RFC 4412 that one day we
>> >> >would specify a
>> >> >> >>>>       > >namespace for ECRIT (the "esnet" namespace
>> >> >now) -- but I also
>> >> >> >>>>       > >knew it was premature for RFC 4412 to
>> >> >incorporate that
>> >> >> >>>>       > >namespace, that a future doc to RFC 4412
>> >> >would have to be
>> >> >> >>>>       > >written to do this. Brian and I talked about
>> >> >this at the
>> >> >> >>>>       > >original NENA meeting that created the IP
>> WGs there
>> >> >> >> (in August
>> >> >> >>>>       > >of 03).  We both agreed we should wait
>> until it was
>> >> >> >>>>       > >appropriate to the work in the IETF to
>> >> >submit this document
>> >> >> >>>>       > >that is now
>> >> >> >>>>       >
>> >> >> >>>>>
>> >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
>> >> >> >>>>       > >gency-rph-namespace-00.txt
>> >> >> >>>>       > >
>> >> >> >>>>       > >Yet, you seem to want to use some additional
>> >> >mechanism to
>> >> >> >>>>       > >indicate priority of a call in SIP.  That
>> >> >means you want to
>> >> >> >>>>       > >introduce a second way to accomplish this in SIP.
>> >> >> >>>> Why do you
>> >> >> >>>>       > >want to promote a separate way to do 
>something SIP
>> >> >> >> has already
>> >> >> >>>>       > >defined? That will cause interoperability
>> issues and
>> >> >> >> we both know
>> >> >> >>>> that.
>> >> >> >>>>       > >
>> >> >> >>>>       > >You've said to me (and others) that you
>> >> >believe RPH is just
>> >> >> >>>>       > >another way to accomplish what sos or a URI can
>> >> >> >> indicate - and
>> >> >> >>>>       > >you're wrong.  Your way would be
>> >> >_the_second_way_to_do_it,
>> >> >> >>>>       > >because SIP already considers RPH to be
>> >> >*the*way* to priority
>> >> >> >>>>       > >mark SIP requests.
>> >> >> >>>>       > >
>> >> >> >>>>       > >If you don't believe me (no comment), then
>> >> >why do you not
>> >> >> >>>>       > >believe the SIP WG chair (who knows more
>> >> >about SIP than both
>> >> >> >>>>       > >of us) - who, on this thread, has again said
>> >> >to you "RFC 4412
>> >> >> >>>>       > >(RPH) is the SIP mechanism to priority mark
>> >> >SIP requests"?
>> >> >> >>>>       > >
>> >> >> >>>>       > >Further, I believe it is inappropriate to
>> >> >prohibit endpoints
>> >> >> >>>>       > >from being able to set the esnet namespace.
>> >> >I absolutely
>> >> >> >>>>       > >believe it will not be needed most of the
>> >> >time, but I believe
>> >> >> >>>>       > >if someone does find a valid use for
>> >> >endpoints to mark
>> >> >> >>>>       > >priority in SIP, this ID - once it has
>> >> >become an RFC -- will
>> >> >> >>>>       > >have to be obsoleted with a new RFC
>> saying the exact
>> >> >> >> opposite.
>> >> >> >>>>       > >
>> >> >> >>>>       > >(color me confused ... over and over again)
>> >> >> >>>>       > >
>> >> >> >>>>       > >James
>> >> >> >>>>       > >
>> >> >> >>>>       > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
>> >> >> >>>>       > >>Keith, please understand that the usage
>> of RFC 4412
>> >> >> >> for GETS and
>> >> >> >>>> for
>> >> >> >>>>       > >>the type of emergency call we discuss here is
>> >> >> >> different. Just
>> >> >> >>>> looking
>> >> >> >>>>       > >>at the header and the name of the
>> >namespace is a bit
>> >> >> >>>>       > >artificial. I hope
>> >> >> >>>>       > >>you understand that.
>> >> >> >>>>       > >>
>> >> >> >>>>       > >> >-----Original Message-----
>> >> >> >>>>       > >> >From: DRAGE, Keith (Keith) 
>> >> >> >>>> [mailto:[email-masked]]
>> >> >> >>>>       > >> >Sent: 05 February, 2009 14:55
>> >> >> >>>>       > >> >To: Brian Rosen; 'Hannes Tschofenig'; 
>'James M.
>> >> >> >>>> Polk'; 'Tschofenig,
>> >> >> >>>>       > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
>> >> >> >>>>       > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim
>> >> >> >>>> Meeting: Agenda (my
>> >> >> >>>>
>> >> >> >>>>       > >> >mistake)
>> >> >> >>>>       > >> >
>> >> >> >>>>       > >> >Which is exactly what RFC 4412
>> specifies for all
>> >> >> >> namespaces.
>> >> >> >>>>       > >> >
>> >> >> >>>>       > >> >regards
>> >> >> >>>>       > >> >
>> >> >> >>>>       > >> >Keith
>> >> >> >>>>       > >> >
>> >> >> >>>>       > >> >> -----Original Message-----
>> >> >> >>>>       > >> >> From: [email-masked]
>> >> >> >> [mailto:[email-masked]]
>> >> >> >>>>       > >> >On Behalf
>> >> >> >>>>       > >> >> Of Brian Rosen
>> >> >> >>>>       > >> >> Sent: Wednesday, February 04, 2009 10:19 PM
>> >> >> >>>>       > >> >> To: 'Hannes Tschofenig'; 'James M.
>> >> >Polk'; 'Tschofenig,
>> >> >> >>>>       > >Hannes (NSN
>> >> >> >>>>       > >> >> - FI/Espoo)'; 'ECRIT'
>> >> >> >>>>       > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim
>> >> >> >>>> Meeting: Agenda (my
>> >> >> >>>>       > >> >> mistake)
>> >> >> >>>>       > >> >>
>> >> >> >>>>       > >> >> The value is that in some networks
>> >> >where priority for
>> >> >> >>>>       > >> >emergency calls
>> >> >> >>>>       > >> >> is appropriate, and appropriate
>> >> >policing of marking is
>> >> >> >>>>       > >implemented,
>> >> >> >>>>       > >> >> emergency calls will receive
>> resource priority.
>> >> >> >>>>       > >> >>
>> >> >> >>>>       > >> >> Not all networks would need policing.  Some
>> >> >> >> will.  Policing
>> >> >> >>>> could
>> >> >> >>>>       > >> >> be to Route header/R-URI content, but other
>> >> >> >> criteria are
>> >> >> >>>> possible.
>> >> >> >>>>       > >> >>
>> >> >> >>>>       > >> >> Not all networks will need resource priority
>> >> >> >> for emergency
>> >> >> >>>> calls.
>> >> >> >>>>       > >> >> Fine, ignore this marking/namespace.
>> >> >> >>>>       > >> >>
>> >> >> >>>>       > >> >> Brian
>> >> >> >>>>       > >> >> > -----Original Message-----
>> >> >> >>>>       > >> >> > From: Hannes Tschofenig 
>> >> >> >>>> [mailto:[email-masked]]
>> >> >> >>>>       > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
>> >> >> >>>>       > >> >> > To: 'Brian Rosen'; 'James M. Polk';
>> >> >> >> Tschofenig, Hannes
>> >> >> >>>> (NSN -
>> >> >> >>>>       > >> >> > FI/Espoo); 'ECRIT'
>> >> >> >>>>       > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim
>> >> >> >>>> Meeting: Agenda (my
>> >> >> >>>>       > >> >> > mistake)
>> >> >> >>>>       > >> >> >
>> >> >> >>>>       > >> >> > I don't even see the value in
>> permitting the
>> >> >> >> endpoint todo
>> >> >> >>>> the
>> >> >> >>>>       > >> >> > RPH marking.
>> >> >> >>>>       > >> >> > In addition to the security concerns
>> >> >there is also the
>> >> >> >>>>       > >> >problem that
>> >> >> >>>>       > >> >> > there are more options to 
>implement without
>> >> >> >> an additional
>> >> >> >>>> value.
>> >> >> >>>>       > >> >> >
>> >> >> >>>>       > >> >> > >-----Original Message-----
>> >> >> >>>>       > >> >> > >From: Brian Rosen
>> [mailto:[email-masked]]
>> >> >> >>>>       > >> >> > >Sent: 05 February, 2009 00:03
>> >> >> >>>>       > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig';
>> >> >> >> 'Tschofenig,
>> >> >> >>>>       > >> >> Hannes (NSN -
>> >> >> >>>>       > >> >> > >FI/Espoo)'; 'ECRIT'
>> >> >> >>>>       > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual
>> >> >Interim Meeting:
>> >> >> >>>> Agenda (my
>> >> >> >>>>       > >> >> > mistake)
>> >> >> >>>>       > >> >> > >
>> >> >> >>>>       > >> >> > >Hannes
>> >> >> >>>>       > >> >> > >
>> >> >> >>>>       > >> >> > >This matches my understanding
>> >> >precisely.  We wish to
>> >> >> >>>>       > >> >> permit endpoints
>> >> >> >>>>       > >> >> > >to mark. We do not require it, and
>> >> >don't necessarily
>> >> >> >>>> expect it
>> >> >> >>>>       > >> >> > >in many (even
>> >> >> >>>>       > >> >> > >most) cases.  We don't wish to see the
>> >> >> >> document prohibit
>> >> >> >>>> it.
>> >> >> >>>>       > >> >> > >We all seem to agree it has value
>> within the
>> >> >> >> Emergency
>> >> >> >>>>       > >> >Services IP
>> >> >> >>>>       > >> >> > >Networks.
>> >> >> >>>>       > >> >> > >
>> >> >> >>>>       > >> >> > >Brian
>> >> >> >>>>       > >> >> > >
>> >> >> >>>>       > >> >> > >> -----Original Message-----
>> >> >> >>>>       > >> >> > >> From: [email-masked] 
>> >> >> >>>> [mailto:[email-masked]]
>> >> >> >>>>       > >> >> > >On Behalf
>> >> >> >>>>       > >> >> > >> Of James M. Polk
>> >> >> >>>>       > >> >> > >> Sent: Wednesday, February 04,
>> 2009 4:01 PM
>> >> >> >>>>       > >> >> > >> To: Hannes Tschofenig; Tschofenig,
>> >> >Hannes (NSN -
>> >> >> >>>>       > >> >> FI/Espoo); 'ECRIT'
>> >> >> >>>>       > >> >> > >> Subject: Re: [Ecrit] ECRIT
>> Virtual Interim
>> >> >> >>>> Meeting:
>> >> >> >>>>       > >Agenda (my
>> >> >> >>>>       > >> >> > >> mistake)
>> >> >> >>>>       > >> >> > >>
>> >> >> >>>>       > >> >> > >> At 02:37 PM 2/4/2009, Hannes
>> >> >Tschofenig wrote:
>> >> >> >>>>       > >> >> > >> > > James wrote:
>> >> >> >>>>       > >> >> > >> > >> you are the _lone_ voice not
>> >> >> >> supporting this ID,
>> >> >> >>>>       > >> >> > >> >
>> >> >> >>>>       > >> >> > >> >Listening to the audio
>> recording of past
>> >> >> >> meetings I
>> >> >> >>>> have to
>> >> >> >>>>       > >> >> > >say that
>> >> >> >>>>       > >> >> > >> >I
>> >> >> >>>>       > >> >> > >> was
>> >> >> >>>>       > >> >> > >> >not the only persons raising
>> >> >concerns about the
>> >> >> >>>> document.
>> >> >> >>>>       > >> >> > >> >That was probably the reason why you
>> >> >> >> agreed to limit
>> >> >> >>>> the
>> >> >> >>>>       > >> >> > >scope of the
>> >> >> >>>>       > >> >> > >> >document (which you didn't 
>later do) to
>> >> >> >> get folks to
>> >> >> >>>> agree
>> >> >> >>>>       > >> >> > >to make it
>> >> >> >>>>       > >> >> > >> a WG
>> >> >> >>>>       > >> >> > >> >item.
>> >> >> >>>>       > >> >> > >>
>> >> >> >>>>       > >> >> > >> re-listen to the audio please
>> >> >> >>>>       > >> >> > >>
>> >> >> >>>>       > >> >> > >> Ted's concerns were consistent 
>with most
>> >> >> >>>> (all?) other
>> >> >> >>>>       > >> >> concerns --
>> >> >> >>>>       > >> >> > >> which were based on the premise
>> of whether
>> >> >> >> or not the
>> >> >> >>>>       > >> >> UAC should be
>> >> >> >>>>       > >> >> > >> trusted to initiate the marking on the
>> >> >> >> INVITE.  The
>> >> >> >>>> most
>> >> >> >>>>       > >> >> > >> recent version has backed off this
>> >> >to a "can" --
>> >> >> >>>> meaning not
>> >> >> >>>>       > >> >prohibited
>> >> >> >>>>       > >> >> > >> (i.e., no 2119 text).  I also 
>backed off
>> >> >> >> the text in
>> >> >> >>>> the
>> >> >> >>>>       > >> >> SP domain
>> >> >> >>>>       > >> >> > >> part to "can", such that there is
>> >> >no 2119 text
>> >> >> >>>>       > >> >mandating or even
>> >> >> >>>>       > >> >> > >> recommending its usage there. I also do
>> >> >> >> not prohibit
>> >> >> >>>> its
>> >> >> >>>>       > >> >> > >use, based on
>> >> >> >>>>       > >> >> > >> local policy.  Keith has come
>> forward with
>> >> >> >> the specific
>> >> >> >>>>
>> >> >> >>>>       > >> >> > >> request that non-ESInet networks be
>> >> >> >> allowed to mark and
>> >> >> >>>> pay
>> >> >> >>>>       > >> >attention to
>> >> >> >>>>       > >> >> > >> this priority indication -- with IMS as
>> >> >> >> the specific
>> >> >> >>>> example
>> >> >> >>>>       > >> >> > >> he wishes to have this valid for.
>> >> >> >>>>       > >> >> > >>
>> >> >> >>>>       > >> >> > >> Where there is no 
>disagreement, save for
>> >> >> >> your recent
>> >> >> >>>>       > >> >> > >pushback - is in
>> >> >> >>>>       > >> >> > >> the ESInet, which is where Brian
>> >> >has requested it's
>> >> >> >>>>       > >> >> > >definition in the
>> >> >> >>>>       > >> >> > >> IETF on behalf of NENA.  He's the i3 WG
>> >> >> >> chair within
>> >> >> >>>>       > >> >> NENA, and if
>> >> >> >>>>       > >> >> > >> he asks for it, are you going 
>to say you
>> >> >> >> know better
>> >> >> >>>> than he?
>> >> >> >>>>       > >> >> > >>
>> >> >> >>>>       > >> >> > >>
>> >> >> >>>>       > >> >> > >> >Btw, I not disagreeing with
>> the document
>> >> >> >> as such. I
>> >> >> >>>>       > >> >just want to
>> >> >> >>>>       > >> >> > the
>> >> >> >>>>       > >> >> > >> scope
>> >> >> >>>>       > >> >> > >> >to change. The usage of RPH
>> >> >within the emergency
>> >> >> >>>>       > >> >> services network
>> >> >> >>>>       > >> >> > is
>> >> >> >>>>       > >> >> > >> fine
>> >> >> >>>>       > >> >> > >> >for me. I may get convinced to
>> start the
>> >> >> >> RPH marking
>> >> >> >>>> from
>> >> >> >>>>       > >> >> > >the the VSP
>> >> >> >>>>       > >> >> > >> >towards the PSAP. I feel
>> uneasy about the
>> >> >> >> end host
>> >> >> >>>> doing
>> >> >> >>>>       > >> >> > >the marking.
>> >> >> >>>>       > >> >> > >>
>> >> >> >>>>       > >> >> > >> please read what I wrote 
>above, and then
>> >> >> >> re-read the
>> >> >> >>>>       > >> >most recent
>> >> >> >>>>       > >> >> > >> version of the ID. I don't have
>> endpoints
>> >> >> >> that SHOULD
>> >> >> >>>> or
>> >> >> >>>>       > >> >> MUST mark
>> >> >> >>>>       > >> >> > >> anything wrt RPH.  I also don't want to
>> >> >> >> prohibit it,
>> >> >> >>>>       > >> >> because there
>> >> >> >>>>       > >> >> > >> might be cases (that I don't know
>> >> >of) of valid uses
>> >> >> >>>>       > >> >> under certain
>> >> >> >>>>       > >> >> > >> circumstances.  Figure 1 is very clear
>> >> >> >> that there are 3
>> >> >> >>>>       > >> >> networking
>> >> >> >>>>       > >> >> > >> parts to consider
>> >> >> >>>>       > >> >> > >>
>> >> >> >>>>       > >> >> > >> #1 - from the endpoint
>> >> >> >>>>       > >> >> > >> #2 - within the VSP
>> >> >> >>>>       > >> >> > >> #3 - within the ESInet
>> >> >> >>>>       > >> >> > >>
>> >> >> >>>>       > >> >> > >> the most recent ID version has 
>"can" for
>> >> >> >> #s 1 and 2,
>> >> >> >>>> and
>> >> >> >>>>       > >> >> > >2119 language
>> >> >> >>>>       > >> >> > >> offering those supporting this
>> >> >> >> specification will have
>> >> >> >>>> RPH
>> >> >> >>>>       > >> >> > >> adherence within #3 (the ESInet).
>> >> >> >>>>       > >> >> > >>
>> >> >> >>>>       > >> >> > >> What other scope changes do you want,
>> >> >> >> because I haven't
>> >> >> >>>>       > >> >> heard them.
>> >> >> >>>>       > >> >> > >>
>> >> >> >>>>       > >> >> > >> I only heard you claim in email
>> during the
>> >> >> >> last IETF
>> >> >> >>>> and in
>> >> >> >>>>       > >> >> > >the ECRIT
>> >> >> >>>>       > >> >> > >> session that RPH should not be
>> >> >used for priority
>> >> >> >>>> marking
>> >> >> >>>>       > >> >> requests.
>> >> >> >>>>       > >> >> > >> This is something Keith (SIP WG
>> >> >chair) voiced his
>> >> >> >>>> opposition
>> >> >> >>>>       > >> >> > >> to your views regarding
>> creating a second
>> >> >> >> means for SIP
>> >> >> >>>> to
>> >> >> >>>>       > >> >priority
>> >> >> >>>>       > >> >> > >> mark request "when SIP already has one
>> >> >> >> interoperable
>> >> >> >>>> way to
>> >> >> >>>>       > >> >> > >> accomplish this... it's call
>> the RP header
>> >> >> >> mechanism".
>> >> >> >>>>       > >> >> > >>
>> >> >> >>>>       > >> >> > >> >I don't see advantages -- only
>> >> >disadvantages.
>> >> >> >>>>       > >> >> > >> >
>> >> >> >>>>       > >> >> > >> >Ciao
>> >> >> >>>>       > >> >> > >> >Hannes
>> >> >> >>>>       > >> >> > >>
>> >> >> >>>>       > >> >> > >>
>> >> >_______________________________________________
>> >> >> >>>>       > >> >> > >> Ecrit mailing list
>> >> >> >>>>       > >> >> > >> [email-masked]
>> >> >> >>>>       > >> >> > >>
>> >https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >>>>       > >> >> > >
>> >> >> >>>>       > >> >>
>> >> >> >>>>       > >> >>
>> _______________________________________________
>> >> >> >>>>       > >> >> Ecrit mailing list
>> >> >> >>>>       > >> >> [email-masked]
>> >> >> >>>>       > >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >>>>       > >> >>
>> >> >> >>>>       > >> >
>> >> >> >>>>       > >
>> >> >> >>>>       >
>> >> >> >>>>       > _______________________________________________
>> >> >> >>>>       > Ecrit mailing list
>> >> >> >>>>       > [email-masked]
>> >> >> >>>>       > https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> _______________________________________________
>> >> >> >>>> Ecrit mailing list
>> >> >> >>>> [email-masked]
>> >> >> >>>> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>> _______________________________________________
>> >> >> >>> Ecrit mailing list
>> >> >> >>> [email-masked]
>> >> >> >>> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >>
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > Ecrit mailing list
>> >> >> > [email-masked]
>> >> >> > https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >
>> >> >
>> >>
>> >> _______________________________________________
>> >> Ecrit mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >>
>> >>
>> >> --------------------------------------------------------------
>> >> ----------------------------------
>> >> This message is for the designated recipient only and may contain 
>> >> privileged, proprietary, or otherwise private information.
>> >> If you have received it in error, please notify the sender
>> >immediately
>> >> and delete the original.  Any unauthorized use of this email is 
>> >> prohibited.
>> >> --------------------------------------------------------------
>> >> ----------------------------------
>> >> [mf2]
>> >>
>> >> _______________________________________________
>> >> Ecrit mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >>
>> >
>>
>>
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sun, 8 Feb 2009 11:32:25 +0200
Cc: [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

Hi Martin, 

Your remarks are a bit a short.

Clearly, authentication and authorization can come in different forms. 
This was actually one of the discussion we had so far that the authorization
mechanisms for the GETS RPH and the proposed ECRIT RPH is different. 

So, could you elaborate a bit? 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of DOLLY, MARTIN C, ATTLABS
>Sent: 07 February, 2009 19:30
>To: [email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: [Ecrit] Semantics Re: RPH
>
>Do you have a clue dude? A+A of an user comes in many forms.
>
>----- Original Message -----
>From: [email-masked] <[email-masked]>
>To: Janet P Gunn <[email-masked]>
>Cc: ECRIT <[email-masked]>; [email-masked] 
><[email-masked]>
>Sent: Sat Feb 07 11:56:42 2009
>Subject: Re: [Ecrit] Semantics  Re:  RPH
>
>Please see my earlier message as to why your approach fails 
>for the UA- inserted case where not all emergency calls have 
>RPH markings. I think it would be a really bad idea if 
>emergency calls with RPH are treated differently than 
>emergency calls without it. (Again, I'm talking about the 
>user-initiated calls. An ESNET can do whatever it wants and 
>can assign extra priority to calls from citizens that have 
>bought PBA stickers or zip codes that pay more taxes, but 
>that's a separate
>problem.)
>
>I also don't believe your implementation logic. A much better 
>approach is to semantically declare the class of call early on 
>(e.g., based on the URN or after 
>authentication/authorization), and make that part of the call 
>state record, rather than hunt for headers each time a 
>handling decision needs to be made. Given the authorization 
>requirements, just looking at "has header X" is never going to 
>be sufficient anyway.
>
>Henning
>
>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:
>
>>
>>
>> .
>>
>> [email-masked] wrote on 02/07/2009 03:14:57 AM:
>>
>> > PLEASE try to understand that the syntax is similar (header, new
>> namespace,
>> > new values)
>> > BUT the semantic is different.
>> >
>> > For all message it is true that the sender can add whatever they
>> want. The
>> > big question is what does it mean for the recipient.
>> >
>> > This is what the discussion is about.
>> >
>> On the contrary, the semantic is, or at least can be, very similar.
>>
>> Consider the hypothetical, but plausible, case of a network with an 
>> explicit call/capacity admission process, in which both 911-type- 
>> emergency calls and GETS calls get preferential admission 
>treatment.  
>> By the time the INVITE gets to this Functional Module/ block 
>of code, 
>> all authentication, authorization, and changes/ confirmation of the 
>> destination have already taken place.  All this block of code deals 
>> with is call/capacity admission.
>>
>> For the sake of argument, suppose this is the nature of the 
>> preference.
>>
>> 1) For INVITEs without RPH, or with an RPH this network does 
>not use/ 
>> understand, if the admission process fails, the INVITE fails
>>
>> 2) For INVITEs with RPH with the ets namespace, if the admission 
>> process initially fails, the INVITE is put in queue until the 
>> resources become available so it can be admitted.
>>
>> 3) For INVITEs with RPH with the esnet namespace, if the admission 
>> process initially fails, the INVITE is put in queue, but at lower 
>> priority than the calls with the ets namespace.
>>
>> With the esnet namespace, this block of code only needs to deal with 
>> the RPH in determining which INVITEs to reject, and which to queue, 
>> and how.
>>
>> But if there is no esnet namespace for RPH, then this block of code 
>> would need to deal with BOTH the RPH and the URN.  That would be a 
>> completely unnecessary complication.
>>
>> Janet
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'Janet P Gunn'" <[email-masked]>
Date: Sun, 8 Feb 2009 11:48:28 +0200
Cc: 'ECRIT' <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

Hi Janet, 
 
thanks for your text. I think I am getting a better understanding of the
scenarios you have in mind. 

Let me comment inline (search for [hannes]):

	Consider the hypothetical, but plausible, case of a network with an
explicit call/capacity admission process, in which both 911-type-emergency
calls and GETS calls get preferential admission treatment.  By the time the
INVITE gets to this Functional Module/ block of code, all authentication,
authorization, and changes/confirmation of the destination have already
taken place.  All this block of code deals with is call/capacity admission. 
	
	For the sake of argument, suppose this is the nature of the
preference. 
	
	1) For INVITEs without RPH, or with an RPH this network does not
use/understand, if the admission process fails, the INVITE fails 
	
[hannes] This is the non-emergency case, I suspect. Section 4.6.2 of RFC
4412 discusses when to fail an INVITE if the RPH marking is not understood.
It does not always fail.

	2) For INVITEs with RPH with the ets namespace, if the admission
process initially fails, the INVITE is put in queue until the resources
become available so it can be admitted. 
	
	3) For INVITEs with RPH with the esnet namespace, if the admission
process initially fails, the INVITE is put in queue, but at lower priority
than the calls with the ets namespace. 

[hannes] Is this an INVITE for an emergecy call? I suspect, yes.  What
priority is given to the emergency call in relationship to the calls with
the ETS namespace is a local policy matter? Or: would you like to put a
description of it into
draft-ietf-ecrit-local-emergency-rph-namespace-00.txt? 

What happens with an non-emergency call invite that has the esnet RPH
marking? Does it get the emergency call treatement? 

	With the esnet namespace, this block of code only needs to deal with
the RPH in determining which INVITEs to reject, and which to queue, and how.

[hannes] You talk about rejecting the INVITE: Emergency calls do not get
rejected regardless of the RPH marking. 
	
	But if there is no esnet namespace for RPH, then this block of code
would need to deal with BOTH the RPH and the URN.  That would be a
completely unnecessary complication. 

[hannes] Are you saying that you wouldn't look at the Service URN / dial
string when the esnet RPH namespace is present? 

I believe I now better understand what you (and maybe James and Keith) want
to accomplish.

You would like to allow the VSP to have two types of emergency calls: 
* "normal" emergency calls that would be placed in a queue as they arrive
  (These are the calls that are only marked as emergency calls using a
Service URN 
   or contain a special dial string.)
* esnet RPH marked emergency calls that would skip other calls in the queue
(if there is a queue and this queue contains non-emergency calls). These
calls are sort of better than the "normal" emergency calls.

Did I correctly understand it? Is this the scenario you had in mind with the
esnet RPH mechanism? 	

If someone would like to create two classes of emergency calls in that
fashion then additional marking would be justified. 

Ciao
Hannes

	Janet

Content-class: urn:content-classes:message
Date: Sun, 8 Feb 2009 07:12:16 -0500
From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

From: "Hannes Tschofenig" <[email-masked]>
To: "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sun, 8 Feb 2009 15:14:32 +0200
Cc: [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

Hi Martin, 

Thanks for the quick response. 

I am aware of these network access authentication and authorization
procedures (including the authentication and authorization procedure at the
SIP layer). They are clearly important for some of the RPH usage scenarios. 

For this specific case (the new esnet RPH mechanism) there are additional
facets that needs to be considered (beyond the above-mentioned security
aspects): 

* What does the esnet RPH usage mean in the context of an emergency call
(for example, in comparison to an emergency call without esnet RPH usage)? 

* For emergency calls the authorization procedures are different than with
regular calls. There are certainly differences to the GETS-alike calls as
well. (We ignore for a moment that there are these unauthenticated emergency
calls where even the authentication procedure is missing.) The current
security consideration section does not acknowledge these differences. 

It would be helpful that draft-ietf-ecrit-local-emergency-rph-namespace
captures some of these aspects to allow those who implement and deploy the
esnet RPH mechanism to understand what it does and how to correctly
implement it.  

Ciao
Hannes

PS: There are details that also need to be discussed. For example, which
esnet value would the device use for an emergency call? "esnet.0",
"esnet.1", "esnet.2", "esnet.3", "esnet.4". Out-of-scope is a possible
answer but it will not help the implementer in doing it's job. Is there a
specific default value (maybe the highest value, just to be sure)? Would the
UA get provisioned to pick a specific value? What is the provisioning
mechanism? Is there a relationship between the esnet values and the Service
URN values? Do the urn:service:counseling:* services get a lower priority
than the urn:service:sos:* services?   

>Hannes,
>
>We need to understand the attachment of the UE to the network. 
>There is an AA process prior to allowing any use. Without this 
>we would not trust the RPH, even for ETS, never mind 911
>
>Martin
>
>----- Original Message -----
>From: Hannes Tschofenig <[email-masked]>
>To: DOLLY, MARTIN C, ATTLABS; [email-masked] 
><[email-masked]>; [email-masked] <[email-masked]>
>Cc: [email-masked] <[email-masked]>
>Sent: Sun Feb 08 04:32:25 2009
>Subject: RE: [Ecrit] Semantics  Re:  RPH
>
>Hi Martin, 
>
>Your remarks are a bit a short.
>
>Clearly, authentication and authorization can come in different forms. 
>This was actually one of the discussion we had so far that the 
>authorization mechanisms for the GETS RPH and the proposed 
>ECRIT RPH is different. 
>
>So, could you elaborate a bit? 
>
>Ciao
>Hannes
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>>Of DOLLY, MARTIN C, ATTLABS
>>Sent: 07 February, 2009 19:30
>>To: [email-masked]; [email-masked]
>>Cc: [email-masked]; [email-masked]
>>Subject: Re: [Ecrit] Semantics Re: RPH
>>
>>Do you have a clue dude? A+A of an user comes in many forms.
>>
>>----- Original Message -----
>>From: [email-masked] <[email-masked]>
>>To: Janet P Gunn <[email-masked]>
>>Cc: ECRIT <[email-masked]>; [email-masked] 
>><[email-masked]>
>>Sent: Sat Feb 07 11:56:42 2009
>>Subject: Re: [Ecrit] Semantics  Re:  RPH
>>
>>Please see my earlier message as to why your approach fails 
>for the UA- 
>>inserted case where not all emergency calls have RPH 
>markings. I think 
>>it would be a really bad idea if emergency calls with RPH are treated 
>>differently than emergency calls without it. (Again, I'm 
>talking about 
>>the user-initiated calls. An ESNET can do whatever it wants and can 
>>assign extra priority to calls from citizens that have bought PBA 
>>stickers or zip codes that pay more taxes, but that's a separate
>>problem.)
>>
>>I also don't believe your implementation logic. A much better 
>approach 
>>is to semantically declare the class of call early on (e.g., based on 
>>the URN or after authentication/authorization), and make that part of 
>>the call state record, rather than hunt for headers each time a 
>>handling decision needs to be made. Given the authorization 
>>requirements, just looking at "has header X" is never going to be 
>>sufficient anyway.
>>
>>Henning
>>
>>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:
>>
>>>
>>>
>>> .
>>>
>>> [email-masked] wrote on 02/07/2009 03:14:57 AM:
>>>
>>> > PLEASE try to understand that the syntax is similar (header, new
>>> namespace,
>>> > new values)
>>> > BUT the semantic is different.
>>> >
>>> > For all message it is true that the sender can add whatever they
>>> want. The
>>> > big question is what does it mean for the recipient.
>>> >
>>> > This is what the discussion is about.
>>> >
>>> On the contrary, the semantic is, or at least can be, very similar.
>>>
>>> Consider the hypothetical, but plausible, case of a network with an 
>>> explicit call/capacity admission process, in which both 911-type- 
>>> emergency calls and GETS calls get preferential admission
>>treatment.  
>>> By the time the INVITE gets to this Functional Module/ block
>>of code,
>>> all authentication, authorization, and changes/ confirmation of the 
>>> destination have already taken place.  All this block of code deals 
>>> with is call/capacity admission.
>>>
>>> For the sake of argument, suppose this is the nature of the 
>>> preference.
>>>
>>> 1) For INVITEs without RPH, or with an RPH this network does
>>not use/
>>> understand, if the admission process fails, the INVITE fails
>>>
>>> 2) For INVITEs with RPH with the ets namespace, if the admission 
>>> process initially fails, the INVITE is put in queue until the 
>>> resources become available so it can be admitted.
>>>
>>> 3) For INVITEs with RPH with the esnet namespace, if the admission 
>>> process initially fails, the INVITE is put in queue, but at lower 
>>> priority than the calls with the ets namespace.
>>>
>>> With the esnet namespace, this block of code only needs to 
>deal with 
>>> the RPH in determining which INVITEs to reject, and which to queue, 
>>> and how.
>>>
>>> But if there is no esnet namespace for RPH, then this block of code 
>>> would need to deal with BOTH the RPH and the URN.  That would be a 
>>> completely unnecessary complication.
>>>
>>> Janet
>>
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/ecrit
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/ecrit
>>
>
>

Content-class: urn:content-classes:message
Date: Sun, 8 Feb 2009 09:02:01 -0500
From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "'Henning Schulzrinne'" <[email-masked]>, "'James M. Polk'" <[email-masked]>
Date: Sun, 8 Feb 2009 15:04:38 +0100
Accept-Language: en-US
acceptlanguage: en-US
Cc: 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] RPH

The semantics of the individual namespaces is part of the queue service alg=
orithm. The authentication policy is part of the individual namespace.=20

I see no need at all to specify the former in an RFC. I don't see the need =
for a lot of detail on the latter.=20

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]=20
> Sent: Saturday, February 07, 2009 8:15 AM
> To: DRAGE, Keith (Keith); 'Henning Schulzrinne'; 'James M. Polk'
> Cc: 'ECRIT'
> Subject: RE: [Ecrit] RPH
>=20
> PLEASE try to understand that the syntax is similar (header,=20
> new namespace, new values) BUT the semantic is different.=20
> =20
> For all message it is true that the sender can add whatever=20
> they want. The big question is what does it mean for the recipient.=20
>=20
> This is what the discussion is about.=20
>=20
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]=20
> On Behalf=20
> >Of DRAGE, Keith (Keith)
> >Sent: 07 February, 2009 02:22
> >To: Henning Schulzrinne; James M. Polk
> >Cc: ECRIT
> >Subject: Re: [Ecrit] RPH
> >
> >Well to be honest, I thought RFC 4412 defined exactly the usage from=20
> >the UA of any RPH header, and noone appears to be seeking to change=20
> >that. Any UE can insert an RPH header, and the outbound proxy that=20
> >understands RPH can use this as absolute, guidance, or completely=20
> >ignore it and throw it away depending on whatever rules it decides=20
> >apply to its usage of that namespace. IETF does not write=20
> those rules,=20
> >just defines the namespace.
> >
> >So I disagree with the statement of "underspecified" in relation to=20
> >this.
> >
> >regards
> >
> >Keith
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]]
> >On Behalf
> >> Of Henning Schulzrinne
> >> Sent: Friday, February 06, 2009 10:29 PM
> >> To: James M. Polk
> >> Cc: ECRIT
> >> Subject: Re: [Ecrit] RPH
> >>=20
> >> To restate: I will object to any text mentioning use of=20
> ESNET in UAs.
> >> It's useless (since under-specified), likely to be harmful
> >to reliable
> >> network operation and just causes confusion. The text should
> >describe
> >> when it is useful (within a "closed"
> >> ESNET, presumably) and what conditions need to be met in order to=20
> >> ensure reliable and secure usage. That something might be useful=20
> >> somewhere else is always true, in any specification, but we
> >don't add
> >> a "This document does not prevent the use of this mechanism
> >somewhere
> >> else." in documents.
> >>=20
> >> Henning
> >>=20
> >> On Feb 6, 2009, at 5:21 PM, James M. Polk wrote:
> >>=20
> >> > At 04:05 PM 2/6/2009, Henning Schulzrinne wrote:
> >> >> James,
> >> >>
> >> >> we don't go through every possible SIP header that might
> >> be inserted
> >> >> into emergency requests. Yes, somebody could add RPH, but this=20
> >> >> applies to PAI and dozens of other SIP headers as well. So far,=20
> >> >> nobody has provided, in my opinion, a compelling use=20
> case that is=20
> >> >> worth documenting. "It could be useful somewhere for something"
> >> >> doesn't cut it. I have provided multiple reasons why I
> >> think that it
> >> >> is a bad idea for (normal) UAs to do so, none of which
> >you address.
> >> >
> >> >
> >> >> I see no need to  say "do not insert RPH",
> >> >
> >> > this is the only thing - right now - that I'm afraid one of us=20
> >> > believes should be the case. I'm glad you are not joining that=20
> >> > position.  I really do not want to highlight the idea fo
> >> UAs inserting
> >> > esnet, but I believe sometime down the road - some customer
> >> will come
> >> > up with a valid reason for this, and I don't want to=20
> state in text=20
> >> > that it is prevented from being inserted (and yet have the
> >> vendor who
> >> > wants to sell to that customer also want that vendor to
> >> adhere to this
> >> > spec as well).
> >> >
> >> > I'm just advocating we not have the text prevent its inclusion.
> >> >
> >> > As I've said, I will beef up the security considerations
> >> section wrt
> >> > UA insertion of esnet - unless others object to this...
> >>=20
> >> _______________________________________________
> >> Ecrit mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>=20
> >_______________________________________________
> >Ecrit mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/ecrit
> >
>=20
> =

From: "Hannes Tschofenig" <[email-masked]>
To: "'DRAGE, Keith \(Keith\)'" <[email-masked]>, "'Henning Schulzrinne'" <[email-masked]>, "'James M. Polk'" <[email-masked]>
Date: Sun, 8 Feb 2009 20:42:14 +0200
Cc: 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] RPH

I think we will not come to an agreement. 

Our approaches are just too different: Your approach is to describe the
syntax. I want a bit of the semantic being described. 

Ciao
Hannes

>-----Original Message-----
>From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
>Sent: 08 February, 2009 16:05
>To: Hannes Tschofenig; 'Henning Schulzrinne'; 'James M. Polk'
>Cc: 'ECRIT'
>Subject: RE: [Ecrit] RPH
>
>The semantics of the individual namespaces is part of the 
>queue service algorithm. The authentication policy is part of 
>the individual namespace. 
>
>I see no need at all to specify the former in an RFC. I don't 
>see the need for a lot of detail on the latter. 
>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[email-masked]]
>> Sent: Saturday, February 07, 2009 8:15 AM
>> To: DRAGE, Keith (Keith); 'Henning Schulzrinne'; 'James M. Polk'
>> Cc: 'ECRIT'
>> Subject: RE: [Ecrit] RPH
>> 
>> PLEASE try to understand that the syntax is similar (header, new 
>> namespace, new values) BUT the semantic is different.
>>  
>> For all message it is true that the sender can add whatever 
>they want. 
>> The big question is what does it mean for the recipient.
>> 
>> This is what the discussion is about. 
>> 
>> >-----Original Message-----
>> >From: [email-masked] [mailto:[email-masked]]
>> On Behalf
>> >Of DRAGE, Keith (Keith)
>> >Sent: 07 February, 2009 02:22
>> >To: Henning Schulzrinne; James M. Polk
>> >Cc: ECRIT
>> >Subject: Re: [Ecrit] RPH
>> >
>> >Well to be honest, I thought RFC 4412 defined exactly the 
>usage from 
>> >the UA of any RPH header, and noone appears to be seeking to change 
>> >that. Any UE can insert an RPH header, and the outbound proxy that 
>> >understands RPH can use this as absolute, guidance, or completely 
>> >ignore it and throw it away depending on whatever rules it decides 
>> >apply to its usage of that namespace. IETF does not write
>> those rules,
>> >just defines the namespace.
>> >
>> >So I disagree with the statement of "underspecified" in relation to 
>> >this.
>> >
>> >regards
>> >
>> >Keith
>> >
>> >> -----Original Message-----
>> >> From: [email-masked] [mailto:[email-masked]]
>> >On Behalf
>> >> Of Henning Schulzrinne
>> >> Sent: Friday, February 06, 2009 10:29 PM
>> >> To: James M. Polk
>> >> Cc: ECRIT
>> >> Subject: Re: [Ecrit] RPH
>> >> 
>> >> To restate: I will object to any text mentioning use of
>> ESNET in UAs.
>> >> It's useless (since under-specified), likely to be harmful
>> >to reliable
>> >> network operation and just causes confusion. The text should
>> >describe
>> >> when it is useful (within a "closed"
>> >> ESNET, presumably) and what conditions need to be met in order to 
>> >> ensure reliable and secure usage. That something might be useful 
>> >> somewhere else is always true, in any specification, but we
>> >don't add
>> >> a "This document does not prevent the use of this mechanism
>> >somewhere
>> >> else." in documents.
>> >> 
>> >> Henning
>> >> 
>> >> On Feb 6, 2009, at 5:21 PM, James M. Polk wrote:
>> >> 
>> >> > At 04:05 PM 2/6/2009, Henning Schulzrinne wrote:
>> >> >> James,
>> >> >>
>> >> >> we don't go through every possible SIP header that might
>> >> be inserted
>> >> >> into emergency requests. Yes, somebody could add RPH, but this 
>> >> >> applies to PAI and dozens of other SIP headers as 
>well. So far, 
>> >> >> nobody has provided, in my opinion, a compelling use
>> case that is
>> >> >> worth documenting. "It could be useful somewhere for something"
>> >> >> doesn't cut it. I have provided multiple reasons why I
>> >> think that it
>> >> >> is a bad idea for (normal) UAs to do so, none of which
>> >you address.
>> >> >
>> >> >
>> >> >> I see no need to  say "do not insert RPH",
>> >> >
>> >> > this is the only thing - right now - that I'm afraid one of us 
>> >> > believes should be the case. I'm glad you are not joining that 
>> >> > position.  I really do not want to highlight the idea fo
>> >> UAs inserting
>> >> > esnet, but I believe sometime down the road - some customer
>> >> will come
>> >> > up with a valid reason for this, and I don't want to
>> state in text
>> >> > that it is prevented from being inserted (and yet have the
>> >> vendor who
>> >> > wants to sell to that customer also want that vendor to
>> >> adhere to this
>> >> > spec as well).
>> >> >
>> >> > I'm just advocating we not have the text prevent its inclusion.
>> >> >
>> >> > As I've said, I will beef up the security considerations
>> >> section wrt
>> >> > UA insertion of esnet - unless others object to this...
>> >> 
>> >> _______________________________________________
>> >> Ecrit mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> 
>> >_______________________________________________
>> >Ecrit mailing list
>> >[email-masked]
>> >https://www.ietf.org/mailman/listinfo/ecrit
>> >
>> 
>> 
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sun, 8 Feb 2009 20:45:21 +0200
Cc: [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

Not sure what you mean. 

Let me ask you a basic question that we have been struggling with for some
time in this discussion that Janet recently highlighted: 

How do you treat an esnet RPH marked 9-1-1 call in comparison to a 9-1-1
call that does not have the esnet RPH marking? In what sense does the
processing in the SIP proxy differ? 

Ciao
Hannes
 
>-----Original Message-----
>From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
>Sent: 08 February, 2009 16:02
>To: [email-masked]; [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: Re: [Ecrit] Semantics Re: RPH
>
>These are the rule, not the exception. I do not care about the 
>internet free scenarios. 
>
>----- Original Message -----
>From: Hannes Tschofenig <[email-masked]>
>To: DOLLY, MARTIN C, ATTLABS; [email-masked] 
><[email-masked]>; [email-masked] <[email-masked]>
>Cc: [email-masked] <[email-masked]>
>Sent: Sun Feb 08 08:14:32 2009
>Subject: RE: [Ecrit] Semantics  Re:  RPH
>
>Hi Martin, 
>
>Thanks for the quick response. 
>
>I am aware of these network access authentication and 
>authorization procedures (including the authentication and 
>authorization procedure at the SIP layer). They are clearly 
>important for some of the RPH usage scenarios. 
>
>For this specific case (the new esnet RPH mechanism) there are 
>additional facets that needs to be considered (beyond the 
>above-mentioned security
>aspects): 
>
>* What does the esnet RPH usage mean in the context of an 
>emergency call (for example, in comparison to an emergency 
>call without esnet RPH usage)? 
>
>* For emergency calls the authorization procedures are 
>different than with regular calls. There are certainly 
>differences to the GETS-alike calls as well. (We ignore for a 
>moment that there are these unauthenticated emergency calls 
>where even the authentication procedure is missing.) The 
>current security consideration section does not acknowledge 
>these differences. 
>
>It would be helpful that draft-ietf-ecrit-local-emergency-rph-namespace
>captures some of these aspects to allow those who implement 
>and deploy the esnet RPH mechanism to understand what it does 
>and how to correctly implement it.  
>
>Ciao
>Hannes
>
>PS: There are details that also need to be discussed. For 
>example, which esnet value would the device use for an 
>emergency call? "esnet.0", "esnet.1", "esnet.2", "esnet.3", 
>"esnet.4". Out-of-scope is a possible answer but it will not 
>help the implementer in doing it's job. Is there a specific 
>default value (maybe the highest value, just to be sure)? 
>Would the UA get provisioned to pick a specific value? What is 
>the provisioning mechanism? Is there a relationship between 
>the esnet values and the Service URN values? Do the 
>urn:service:counseling:* services get a lower priority
>than the urn:service:sos:* services?   
>
>>Hannes,
>>
>>We need to understand the attachment of the UE to the network. 
>>There is an AA process prior to allowing any use. Without 
>this we would 
>>not trust the RPH, even for ETS, never mind 911
>>
>>Martin
>>
>>----- Original Message -----
>>From: Hannes Tschofenig <[email-masked]>
>>To: DOLLY, MARTIN C, ATTLABS; [email-masked] 
>><[email-masked]>; [email-masked] <[email-masked]>
>>Cc: [email-masked] <[email-masked]>
>>Sent: Sun Feb 08 04:32:25 2009
>>Subject: RE: [Ecrit] Semantics  Re:  RPH
>>
>>Hi Martin,
>>
>>Your remarks are a bit a short.
>>
>>Clearly, authentication and authorization can come in 
>different forms. 
>>This was actually one of the discussion we had so far that the 
>>authorization mechanisms for the GETS RPH and the proposed 
>ECRIT RPH is 
>>different.
>>
>>So, could you elaborate a bit? 
>>
>>Ciao
>>Hannes
>>
>>>-----Original Message-----
>>>From: [email-masked] [mailto:[email-masked]]
>>On Behalf
>>>Of DOLLY, MARTIN C, ATTLABS
>>>Sent: 07 February, 2009 19:30
>>>To: [email-masked]; [email-masked]
>>>Cc: [email-masked]; [email-masked]
>>>Subject: Re: [Ecrit] Semantics Re: RPH
>>>
>>>Do you have a clue dude? A+A of an user comes in many forms.
>>>
>>>----- Original Message -----
>>>From: [email-masked] <[email-masked]>
>>>To: Janet P Gunn <[email-masked]>
>>>Cc: ECRIT <[email-masked]>; [email-masked] 
>>><[email-masked]>
>>>Sent: Sat Feb 07 11:56:42 2009
>>>Subject: Re: [Ecrit] Semantics  Re:  RPH
>>>
>>>Please see my earlier message as to why your approach fails
>>for the UA-
>>>inserted case where not all emergency calls have RPH
>>markings. I think
>>>it would be a really bad idea if emergency calls with RPH 
>are treated 
>>>differently than emergency calls without it. (Again, I'm
>>talking about
>>>the user-initiated calls. An ESNET can do whatever it wants and can 
>>>assign extra priority to calls from citizens that have bought PBA 
>>>stickers or zip codes that pay more taxes, but that's a separate
>>>problem.)
>>>
>>>I also don't believe your implementation logic. A much better
>>approach
>>>is to semantically declare the class of call early on (e.g., 
>based on 
>>>the URN or after authentication/authorization), and make 
>that part of 
>>>the call state record, rather than hunt for headers each time a 
>>>handling decision needs to be made. Given the authorization 
>>>requirements, just looking at "has header X" is never going to be 
>>>sufficient anyway.
>>>
>>>Henning
>>>
>>>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:
>>>
>>>>
>>>>
>>>> .
>>>>
>>>> [email-masked] wrote on 02/07/2009 03:14:57 AM:
>>>>
>>>> > PLEASE try to understand that the syntax is similar (header, new
>>>> namespace,
>>>> > new values)
>>>> > BUT the semantic is different.
>>>> >
>>>> > For all message it is true that the sender can add whatever they
>>>> want. The
>>>> > big question is what does it mean for the recipient.
>>>> >
>>>> > This is what the discussion is about.
>>>> >
>>>> On the contrary, the semantic is, or at least can be, very similar.
>>>>
>>>> Consider the hypothetical, but plausible, case of a 
>network with an 
>>>> explicit call/capacity admission process, in which both 911-type- 
>>>> emergency calls and GETS calls get preferential admission
>>>treatment.  
>>>> By the time the INVITE gets to this Functional Module/ block
>>>of code,
>>>> all authentication, authorization, and changes/ 
>confirmation of the 
>>>> destination have already taken place.  All this block of 
>code deals 
>>>> with is call/capacity admission.
>>>>
>>>> For the sake of argument, suppose this is the nature of the 
>>>> preference.
>>>>
>>>> 1) For INVITEs without RPH, or with an RPH this network does
>>>not use/
>>>> understand, if the admission process fails, the INVITE fails
>>>>
>>>> 2) For INVITEs with RPH with the ets namespace, if the admission 
>>>> process initially fails, the INVITE is put in queue until the 
>>>> resources become available so it can be admitted.
>>>>
>>>> 3) For INVITEs with RPH with the esnet namespace, if the admission 
>>>> process initially fails, the INVITE is put in queue, but at lower 
>>>> priority than the calls with the ets namespace.
>>>>
>>>> With the esnet namespace, this block of code only needs to
>>deal with
>>>> the RPH in determining which INVITEs to reject, and which 
>to queue, 
>>>> and how.
>>>>
>>>> But if there is no esnet namespace for RPH, then this 
>block of code 
>>>> would need to deal with BOTH the RPH and the URN.  That would be a 
>>>> completely unnecessary complication.
>>>>
>>>> Janet
>>>
>>>_______________________________________________
>>>Ecrit mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>_______________________________________________
>>>Ecrit mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>
>>
>
>

To: "Hannes Tschofenig" <[email-masked]>
From: Janet P Gunn <[email-masked]>
Date: Sun, 8 Feb 2009 15:12:50 -0500
Cc: [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

This is a multipart message in MIME format.
--=_alternative 006F076685257557_=
Content-Type: text/plain; charset="US-ASCII"

Up to local policy.

Janet

"Hannes Tschofenig" <[email-masked]> wrote on 02/08/2009 
01:45:21 PM:

> Not sure what you mean. 
> 
> Let me ask you a basic question that we have been struggling with for 
some
> time in this discussion that Janet recently highlighted: 
> 
> How do you treat an esnet RPH marked 9-1-1 call in comparison to a 9-1-1
> call that does not have the esnet RPH marking? In what sense does the
> processing in the SIP proxy differ? 
> 
> Ciao
> Hannes
> 
> >-----Original Message-----
> >From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
> >Sent: 08 February, 2009 16:02
> >To: [email-masked]; [email-masked]; [email-masked]
> >Cc: [email-masked]
> >Subject: Re: [Ecrit] Semantics Re: RPH
> >
> >These are the rule, not the exception. I do not care about the 
> >internet free scenarios. 
> >
> >----- Original Message -----
> >From: Hannes Tschofenig <[email-masked]>
> >To: DOLLY, MARTIN C, ATTLABS; [email-masked] 
> ><[email-masked]>; [email-masked] <[email-masked]>
> >Cc: [email-masked] <[email-masked]>
> >Sent: Sun Feb 08 08:14:32 2009
> >Subject: RE: [Ecrit] Semantics  Re:  RPH
> >
> >Hi Martin, 
> >
> >Thanks for the quick response. 
> >
> >I am aware of these network access authentication and 
> >authorization procedures (including the authentication and 
> >authorization procedure at the SIP layer). They are clearly 
> >important for some of the RPH usage scenarios. 
> >
> >For this specific case (the new esnet RPH mechanism) there are 
> >additional facets that needs to be considered (beyond the 
> >above-mentioned security
> >aspects): 
> >
> >* What does the esnet RPH usage mean in the context of an 
> >emergency call (for example, in comparison to an emergency 
> >call without esnet RPH usage)? 
> >
> >* For emergency calls the authorization procedures are 
> >different than with regular calls. There are certainly 
> >differences to the GETS-alike calls as well. (We ignore for a 
> >moment that there are these unauthenticated emergency calls 
> >where even the authentication procedure is missing.) The 
> >current security consideration section does not acknowledge 
> >these differences. 
> >
> >It would be helpful that draft-ietf-ecrit-local-emergency-rph-namespace
> >captures some of these aspects to allow those who implement 
> >and deploy the esnet RPH mechanism to understand what it does 
> >and how to correctly implement it. 
> >
> >Ciao
> >Hannes
> >
> >PS: There are details that also need to be discussed. For 
> >example, which esnet value would the device use for an 
> >emergency call? "esnet.0", "esnet.1", "esnet.2", "esnet.3", 
> >"esnet.4". Out-of-scope is a possible answer but it will not 
> >help the implementer in doing it's job. Is there a specific 
> >default value (maybe the highest value, just to be sure)? 
> >Would the UA get provisioned to pick a specific value? What is 
> >the provisioning mechanism? Is there a relationship between 
> >the esnet values and the Service URN values? Do the 
> >urn:service:counseling:* services get a lower priority
> >than the urn:service:sos:* services? 
> >
> >>Hannes,
> >>
> >>We need to understand the attachment of the UE to the network. 
> >>There is an AA process prior to allowing any use. Without 
> >this we would 
> >>not trust the RPH, even for ETS, never mind 911
> >>
> >>Martin
> >>
> >>----- Original Message -----
> >>From: Hannes Tschofenig <[email-masked]>
> >>To: DOLLY, MARTIN C, ATTLABS; [email-masked] 
> >><[email-masked]>; [email-masked] <[email-masked]>
> >>Cc: [email-masked] <[email-masked]>
> >>Sent: Sun Feb 08 04:32:25 2009
> >>Subject: RE: [Ecrit] Semantics  Re:  RPH
> >>
> >>Hi Martin,
> >>
> >>Your remarks are a bit a short.
> >>
> >>Clearly, authentication and authorization can come in 
> >different forms. 
> >>This was actually one of the discussion we had so far that the 
> >>authorization mechanisms for the GETS RPH and the proposed 
> >ECRIT RPH is 
> >>different.
> >>
> >>So, could you elaborate a bit? 
> >>
> >>Ciao
> >>Hannes
> >>
> >>>-----Original Message-----
> >>>From: [email-masked] [mailto:[email-masked]]
> >>On Behalf
> >>>Of DOLLY, MARTIN C, ATTLABS
> >>>Sent: 07 February, 2009 19:30
> >>>To: [email-masked]; [email-masked]
> >>>Cc: [email-masked]; [email-masked]
> >>>Subject: Re: [Ecrit] Semantics Re: RPH
> >>>
> >>>Do you have a clue dude? A+A of an user comes in many forms.
> >>>
> >>>----- Original Message -----
> >>>From: [email-masked] <[email-masked]>
> >>>To: Janet P Gunn <[email-masked]>
> >>>Cc: ECRIT <[email-masked]>; [email-masked] 
> >>><[email-masked]>
> >>>Sent: Sat Feb 07 11:56:42 2009
> >>>Subject: Re: [Ecrit] Semantics  Re:  RPH
> >>>
> >>>Please see my earlier message as to why your approach fails
> >>for the UA-
> >>>inserted case where not all emergency calls have RPH
> >>markings. I think
> >>>it would be a really bad idea if emergency calls with RPH 
> >are treated 
> >>>differently than emergency calls without it. (Again, I'm
> >>talking about
> >>>the user-initiated calls. An ESNET can do whatever it wants and can 
> >>>assign extra priority to calls from citizens that have bought PBA 
> >>>stickers or zip codes that pay more taxes, but that's a separate
> >>>problem.)
> >>>
> >>>I also don't believe your implementation logic. A much better
> >>approach
> >>>is to semantically declare the class of call early on (e.g., 
> >based on 
> >>>the URN or after authentication/authorization), and make 
> >that part of 
> >>>the call state record, rather than hunt for headers each time a 
> >>>handling decision needs to be made. Given the authorization 
> >>>requirements, just looking at "has header X" is never going to be 
> >>>sufficient anyway.
> >>>
> >>>Henning
> >>>
> >>>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:
> >>>
> >>>>
> >>>>
> >>>> .
> >>>>
> >>>> [email-masked] wrote on 02/07/2009 03:14:57 AM:
> >>>>
> >>>> > PLEASE try to understand that the syntax is similar (header, new
> >>>> namespace,
> >>>> > new values)
> >>>> > BUT the semantic is different.
> >>>> >
> >>>> > For all message it is true that the sender can add whatever they
> >>>> want. The
> >>>> > big question is what does it mean for the recipient.
> >>>> >
> >>>> > This is what the discussion is about.
> >>>> >
> >>>> On the contrary, the semantic is, or at least can be, very similar.
> >>>>
> >>>> Consider the hypothetical, but plausible, case of a 
> >network with an 
> >>>> explicit call/capacity admission process, in which both 911-type- 
> >>>> emergency calls and GETS calls get preferential admission
> >>>treatment. 
> >>>> By the time the INVITE gets to this Functional Module/ block
> >>>of code,
> >>>> all authentication, authorization, and changes/ 
> >confirmation of the 
> >>>> destination have already taken place.  All this block of 
> >code deals 
> >>>> with is call/capacity admission.
> >>>>
> >>>> For the sake of argument, suppose this is the nature of the 
> >>>> preference.
> >>>>
> >>>> 1) For INVITEs without RPH, or with an RPH this network does
> >>>not use/
> >>>> understand, if the admission process fails, the INVITE fails
> >>>>
> >>>> 2) For INVITEs with RPH with the ets namespace, if the admission 
> >>>> process initially fails, the INVITE is put in queue until the 
> >>>> resources become available so it can be admitted.
> >>>>
> >>>> 3) For INVITEs with RPH with the esnet namespace, if the admission 
> >>>> process initially fails, the INVITE is put in queue, but at lower 
> >>>> priority than the calls with the ets namespace.
> >>>>
> >>>> With the esnet namespace, this block of code only needs to
> >>deal with
> >>>> the RPH in determining which INVITEs to reject, and which 
> >to queue, 
> >>>> and how.
> >>>>
> >>>> But if there is no esnet namespace for RPH, then this 
> >block of code 
> >>>> would need to deal with BOTH the RPH and the URN.  That would be a 
> >>>> completely unnecessary complication.
> >>>>
> >>>> Janet
> >>>
> >>>_______________________________________________
> >>>Ecrit mailing list
> >>>[email-masked]
> >>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>_______________________________________________
> >>>Ecrit mailing list
> >>>[email-masked]
> >>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>
> >>
> >>
> >
> >
> 

--=_alternative 006F076685257557_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif"><br>
<br>
Up to local policy.</font>
<br>
<br><font size=2 face="sans-serif">Janet</font>
<br>
<br><font size=2><tt>&quot;Hannes Tschofenig&quot; &lt;[email-masked]&gt;
wrote on 02/08/2009 01:45:21 PM:<br>
<br>
&gt; Not sure what you mean. <br>
&gt; <br>
&gt; Let me ask you a basic question that we have been struggling with
for some<br>
&gt; time in this discussion that Janet recently highlighted: <br>
&gt; <br>
&gt; How do you treat an esnet RPH marked 9-1-1 call in comparison to a
9-1-1<br>
&gt; call that does not have the esnet RPH marking? In what sense does
the<br>
&gt; processing in the SIP proxy differ? <br>
&gt; <br>
&gt; Ciao<br>
&gt; Hannes<br>
&gt; &nbsp;<br>
&gt; &gt;-----Original Message-----<br>
&gt; &gt;From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] <br>
&gt; &gt;Sent: 08 February, 2009 16:02<br>
&gt; &gt;To: [email-masked]; [email-masked]; [email-masked]<br>
&gt; &gt;Cc: [email-masked]<br>
&gt; &gt;Subject: Re: [Ecrit] Semantics Re: RPH<br>
&gt; &gt;<br>
&gt; &gt;These are the rule, not the exception. I do not care about the
<br>
&gt; &gt;internet free scenarios. <br>
&gt; &gt;<br>
&gt; &gt;----- Original Message -----<br>
&gt; &gt;From: Hannes Tschofenig &lt;[email-masked]&gt;<br>
&gt; &gt;To: DOLLY, MARTIN C, ATTLABS; [email-masked] <br>
&gt; &gt;&lt;[email-masked]&gt;; [email-masked] &lt;[email-masked]&gt;<br>
&gt; &gt;Cc: [email-masked] &lt;[email-masked]&gt;<br>
&gt; &gt;Sent: Sun Feb 08 08:14:32 2009<br>
&gt; &gt;Subject: RE: [Ecrit] Semantics &nbsp;Re: &nbsp;RPH<br>
&gt; &gt;<br>
&gt; &gt;Hi Martin, <br>
&gt; &gt;<br>
&gt; &gt;Thanks for the quick response. <br>
&gt; &gt;<br>
&gt; &gt;I am aware of these network access authentication and <br>
&gt; &gt;authorization procedures (including the authentication and <br>
&gt; &gt;authorization procedure at the SIP layer). They are clearly <br>
&gt; &gt;important for some of the RPH usage scenarios. <br>
&gt; &gt;<br>
&gt; &gt;For this specific case (the new esnet RPH mechanism) there are
<br>
&gt; &gt;additional facets that needs to be considered (beyond the <br>
&gt; &gt;above-mentioned security<br>
&gt; &gt;aspects): <br>
&gt; &gt;<br>
&gt; &gt;* What does the esnet RPH usage mean in the context of an <br>
&gt; &gt;emergency call (for example, in comparison to an emergency <br>
&gt; &gt;call without esnet RPH usage)? <br>
&gt; &gt;<br>
&gt; &gt;* For emergency calls the authorization procedures are <br>
&gt; &gt;different than with regular calls. There are certainly <br>
&gt; &gt;differences to the GETS-alike calls as well. (We ignore for a
<br>
&gt; &gt;moment that there are these unauthenticated emergency calls <br>
&gt; &gt;where even the authentication procedure is missing.) The <br>
&gt; &gt;current security consideration section does not acknowledge <br>
&gt; &gt;these differences. <br>
&gt; &gt;<br>
&gt; &gt;It would be helpful that draft-ietf-ecrit-local-emergency-rph-namespace<br>
&gt; &gt;captures some of these aspects to allow those who implement <br>
&gt; &gt;and deploy the esnet RPH mechanism to understand what it does
<br>
&gt; &gt;and how to correctly implement it. &nbsp;<br>
&gt; &gt;<br>
&gt; &gt;Ciao<br>
&gt; &gt;Hannes<br>
&gt; &gt;<br>
&gt; &gt;PS: There are details that also need to be discussed. For <br>
&gt; &gt;example, which esnet value would the device use for an <br>
&gt; &gt;emergency call? &quot;esnet.0&quot;, &quot;esnet.1&quot;, &quot;esnet.2&quot;,
&quot;esnet.3&quot;, <br>
&gt; &gt;&quot;esnet.4&quot;. Out-of-scope is a possible answer but it
will not <br>
&gt; &gt;help the implementer in doing it's job. Is there a specific <br>
&gt; &gt;default value (maybe the highest value, just to be sure)? <br>
&gt; &gt;Would the UA get provisioned to pick a specific value? What is
<br>
&gt; &gt;the provisioning mechanism? Is there a relationship between <br>
&gt; &gt;the esnet values and the Service URN values? Do the <br>
&gt; &gt;urn:service:counseling:* services get a lower priority<br>
&gt; &gt;than the urn:service:sos:* services? &nbsp; <br>
&gt; &gt;<br>
&gt; &gt;&gt;Hannes,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;We need to understand the attachment of the UE to the network.
<br>
&gt; &gt;&gt;There is an AA process prior to allowing any use. Without
<br>
&gt; &gt;this we would <br>
&gt; &gt;&gt;not trust the RPH, even for ETS, never mind 911<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;Martin<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;----- Original Message -----<br>
&gt; &gt;&gt;From: Hannes Tschofenig &lt;[email-masked]&gt;<br>
&gt; &gt;&gt;To: DOLLY, MARTIN C, ATTLABS; [email-masked] <br>
&gt; &gt;&gt;&lt;[email-masked]&gt;; [email-masked] &lt;[email-masked]&gt;<br>
&gt; &gt;&gt;Cc: [email-masked] &lt;[email-masked]&gt;<br>
&gt; &gt;&gt;Sent: Sun Feb 08 04:32:25 2009<br>
&gt; &gt;&gt;Subject: RE: [Ecrit] Semantics &nbsp;Re: &nbsp;RPH<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;Hi Martin,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;Your remarks are a bit a short.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;Clearly, authentication and authorization can come in <br>
&gt; &gt;different forms. <br>
&gt; &gt;&gt;This was actually one of the discussion we had so far that
the <br>
&gt; &gt;&gt;authorization mechanisms for the GETS RPH and the proposed
<br>
&gt; &gt;ECRIT RPH is <br>
&gt; &gt;&gt;different.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;So, could you elaborate a bit? <br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;Ciao<br>
&gt; &gt;&gt;Hannes<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt;-----Original Message-----<br>
&gt; &gt;&gt;&gt;From: [email-masked] [mailto:[email-masked]]<br>
&gt; &gt;&gt;On Behalf<br>
&gt; &gt;&gt;&gt;Of DOLLY, MARTIN C, ATTLABS<br>
&gt; &gt;&gt;&gt;Sent: 07 February, 2009 19:30<br>
&gt; &gt;&gt;&gt;To: [email-masked]; [email-masked]<br>
&gt; &gt;&gt;&gt;Cc: [email-masked]; [email-masked]<br>
&gt; &gt;&gt;&gt;Subject: Re: [Ecrit] Semantics Re: RPH<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;Do you have a clue dude? A+A of an user comes in many
forms.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;----- Original Message -----<br>
&gt; &gt;&gt;&gt;From: [email-masked] &lt;[email-masked]&gt;<br>
&gt; &gt;&gt;&gt;To: Janet P Gunn &lt;[email-masked]&gt;<br>
&gt; &gt;&gt;&gt;Cc: ECRIT &lt;[email-masked]&gt;; [email-masked]
<br>
&gt; &gt;&gt;&gt;&lt;[email-masked]&gt;<br>
&gt; &gt;&gt;&gt;Sent: Sat Feb 07 11:56:42 2009<br>
&gt; &gt;&gt;&gt;Subject: Re: [Ecrit] Semantics &nbsp;Re: &nbsp;RPH<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;Please see my earlier message as to why your approach
fails<br>
&gt; &gt;&gt;for the UA-<br>
&gt; &gt;&gt;&gt;inserted case where not all emergency calls have RPH<br>
&gt; &gt;&gt;markings. I think<br>
&gt; &gt;&gt;&gt;it would be a really bad idea if emergency calls with
RPH <br>
&gt; &gt;are treated <br>
&gt; &gt;&gt;&gt;differently than emergency calls without it. (Again, I'm<br>
&gt; &gt;&gt;talking about<br>
&gt; &gt;&gt;&gt;the user-initiated calls. An ESNET can do whatever it
wants and can <br>
&gt; &gt;&gt;&gt;assign extra priority to calls from citizens that have
bought PBA <br>
&gt; &gt;&gt;&gt;stickers or zip codes that pay more taxes, but that's
a separate<br>
&gt; &gt;&gt;&gt;problem.)<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;I also don't believe your implementation logic. A much
better<br>
&gt; &gt;&gt;approach<br>
&gt; &gt;&gt;&gt;is to semantically declare the class of call early on
(e.g., <br>
&gt; &gt;based on <br>
&gt; &gt;&gt;&gt;the URN or after authentication/authorization), and make
<br>
&gt; &gt;that part of <br>
&gt; &gt;&gt;&gt;the call state record, rather than hunt for headers each
time a <br>
&gt; &gt;&gt;&gt;handling decision needs to be made. Given the authorization
<br>
&gt; &gt;&gt;&gt;requirements, just looking at &quot;has header X&quot;
is never going to be <br>
&gt; &gt;&gt;&gt;sufficient anyway.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;Henning<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; .<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; [email-masked] wrote on 02/07/2009 03:14:57
AM:<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; &gt; PLEASE try to understand that the syntax is
similar (header, new<br>
&gt; &gt;&gt;&gt;&gt; namespace,<br>
&gt; &gt;&gt;&gt;&gt; &gt; new values)<br>
&gt; &gt;&gt;&gt;&gt; &gt; BUT the semantic is different.<br>
&gt; &gt;&gt;&gt;&gt; &gt;<br>
&gt; &gt;&gt;&gt;&gt; &gt; For all message it is true that the sender can
add whatever they<br>
&gt; &gt;&gt;&gt;&gt; want. The<br>
&gt; &gt;&gt;&gt;&gt; &gt; big question is what does it mean for the recipient.<br>
&gt; &gt;&gt;&gt;&gt; &gt;<br>
&gt; &gt;&gt;&gt;&gt; &gt; This is what the discussion is about.<br>
&gt; &gt;&gt;&gt;&gt; &gt;<br>
&gt; &gt;&gt;&gt;&gt; On the contrary, the semantic is, or at least can
be, very similar.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; Consider the hypothetical, but plausible, case of
a <br>
&gt; &gt;network with an <br>
&gt; &gt;&gt;&gt;&gt; explicit call/capacity admission process, in which
both 911-type- <br>
&gt; &gt;&gt;&gt;&gt; emergency calls and GETS calls get preferential admission<br>
&gt; &gt;&gt;&gt;treatment. &nbsp;<br>
&gt; &gt;&gt;&gt;&gt; By the time the INVITE gets to this Functional Module/
block<br>
&gt; &gt;&gt;&gt;of code,<br>
&gt; &gt;&gt;&gt;&gt; all authentication, authorization, and changes/ <br>
&gt; &gt;confirmation of the <br>
&gt; &gt;&gt;&gt;&gt; destination have already taken place. &nbsp;All this
block of <br>
&gt; &gt;code deals <br>
&gt; &gt;&gt;&gt;&gt; with is call/capacity admission.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; For the sake of argument, suppose this is the nature
of the <br>
&gt; &gt;&gt;&gt;&gt; preference.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; 1) For INVITEs without RPH, or with an RPH this network
does<br>
&gt; &gt;&gt;&gt;not use/<br>
&gt; &gt;&gt;&gt;&gt; understand, if the admission process fails, the INVITE
fails<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; 2) For INVITEs with RPH with the ets namespace, if
the admission <br>
&gt; &gt;&gt;&gt;&gt; process initially fails, the INVITE is put in queue
until the <br>
&gt; &gt;&gt;&gt;&gt; resources become available so it can be admitted.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; 3) For INVITEs with RPH with the esnet namespace,
if the admission <br>
&gt; &gt;&gt;&gt;&gt; process initially fails, the INVITE is put in queue,
but at lower <br>
&gt; &gt;&gt;&gt;&gt; priority than the calls with the ets namespace.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; With the esnet namespace, this block of code only
needs to<br>
&gt; &gt;&gt;deal with<br>
&gt; &gt;&gt;&gt;&gt; the RPH in determining which INVITEs to reject, and
which <br>
&gt; &gt;to queue, <br>
&gt; &gt;&gt;&gt;&gt; and how.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; But if there is no esnet namespace for RPH, then
this <br>
&gt; &gt;block of code <br>
&gt; &gt;&gt;&gt;&gt; would need to deal with BOTH the RPH and the URN.
&nbsp;That would be a <br>
&gt; &gt;&gt;&gt;&gt; completely unnecessary complication.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; Janet<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;_______________________________________________<br>
&gt; &gt;&gt;&gt;Ecrit mailing list<br>
&gt; &gt;&gt;&gt;[email-masked]<br>
&gt; &gt;&gt;&gt;https://www.ietf.org/mailman/listinfo/ecrit<br>
&gt; &gt;&gt;&gt;_______________________________________________<br>
&gt; &gt;&gt;&gt;Ecrit mailing list<br>
&gt; &gt;&gt;&gt;[email-masked]<br>
&gt; &gt;&gt;&gt;https://www.ietf.org/mailman/listinfo/ecrit<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; <br>
</tt></font>
--=_alternative 006F076685257557_=--

From: "Hannes Tschofenig" <[email-masked]>
To: "'Janet P Gunn'" <[email-masked]>
Date: Mon, 9 Feb 2009 09:34:42 +0200
Cc: [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

I could have guessed the response already. 

I believe that the draft would benefit from a few sentences that describes
what "local policy" decisions the operator deploying this mechanism has to
make. 

Ciao
Hannes

________________________________

	From: Janet P Gunn [mailto:[email-masked]] 
	Sent: 08 February, 2009 22:13
	To: Hannes Tschofenig
	Cc: [email-masked]; [email-masked]; 'DOLLY, MARTIN C, ATTLABS'
	Subject: RE: [Ecrit] Semantics Re: RPH

	
	Up to local policy. 
	
	Janet 
	
	"Hannes Tschofenig" <[email-masked]> wrote on 02/08/2009
01:45:21 PM:
	
	> Not sure what you mean. 
	> 
	> Let me ask you a basic question that we have been struggling with
for some
	> time in this discussion that Janet recently highlighted: 
	> 
	> How do you treat an esnet RPH marked 9-1-1 call in comparison to a
9-1-1
	> call that does not have the esnet RPH marking? In what sense does
the
	> processing in the SIP proxy differ? 
	> 
	> Ciao
	> Hannes
	>  
	> >-----Original Message-----
	> >From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
	> >Sent: 08 February, 2009 16:02
	> >To: [email-masked]; [email-masked];
[email-masked]
	> >Cc: [email-masked]
	> >Subject: Re: [Ecrit] Semantics Re: RPH
	> >
	> >These are the rule, not the exception. I do not care about the 
	> >internet free scenarios. 
	> >
	> >----- Original Message -----
	> >From: Hannes Tschofenig <[email-masked]>
	> >To: DOLLY, MARTIN C, ATTLABS; [email-masked] 
	> ><[email-masked]>; [email-masked] <[email-masked]>
	> >Cc: [email-masked] <[email-masked]>
	> >Sent: Sun Feb 08 08:14:32 2009
	> >Subject: RE: [Ecrit] Semantics  Re:  RPH
	> >
	> >Hi Martin, 
	> >
	> >Thanks for the quick response. 
	> >
	> >I am aware of these network access authentication and 
	> >authorization procedures (including the authentication and 
	> >authorization procedure at the SIP layer). They are clearly 
	> >important for some of the RPH usage scenarios. 
	> >
	> >For this specific case (the new esnet RPH mechanism) there are 
	> >additional facets that needs to be considered (beyond the 
	> >above-mentioned security
	> >aspects): 
	> >
	> >* What does the esnet RPH usage mean in the context of an 
	> >emergency call (for example, in comparison to an emergency 
	> >call without esnet RPH usage)? 
	> >
	> >* For emergency calls the authorization procedures are 
	> >different than with regular calls. There are certainly 
	> >differences to the GETS-alike calls as well. (We ignore for a 
	> >moment that there are these unauthenticated emergency calls 
	> >where even the authentication procedure is missing.) The 
	> >current security consideration section does not acknowledge 
	> >these differences. 
	> >
	> >It would be helpful that
draft-ietf-ecrit-local-emergency-rph-namespace
	> >captures some of these aspects to allow those who implement 
	> >and deploy the esnet RPH mechanism to understand what it does 
	> >and how to correctly implement it.  
	> >
	> >Ciao
	> >Hannes
	> >
	> >PS: There are details that also need to be discussed. For 
	> >example, which esnet value would the device use for an 
	> >emergency call? "esnet.0", "esnet.1", "esnet.2", "esnet.3", 
	> >"esnet.4". Out-of-scope is a possible answer but it will not 
	> >help the implementer in doing it's job. Is there a specific 
	> >default value (maybe the highest value, just to be sure)? 
	> >Would the UA get provisioned to pick a specific value? What is 
	> >the provisioning mechanism? Is there a relationship between 
	> >the esnet values and the Service URN values? Do the 
	> >urn:service:counseling:* services get a lower priority
	> >than the urn:service:sos:* services?   
	> >
	> >>Hannes,
	> >>
	> >>We need to understand the attachment of the UE to the network. 
	> >>There is an AA process prior to allowing any use. Without 
	> >this we would 
	> >>not trust the RPH, even for ETS, never mind 911
	> >>
	> >>Martin
	> >>
	> >>----- Original Message -----
	> >>From: Hannes Tschofenig <[email-masked]>
	> >>To: DOLLY, MARTIN C, ATTLABS; [email-masked] 
	> >><[email-masked]>; [email-masked] <[email-masked]>
	> >>Cc: [email-masked] <[email-masked]>
	> >>Sent: Sun Feb 08 04:32:25 2009
	> >>Subject: RE: [Ecrit] Semantics  Re:  RPH
	> >>
	> >>Hi Martin,
	> >>
	> >>Your remarks are a bit a short.
	> >>
	> >>Clearly, authentication and authorization can come in 
	> >different forms. 
	> >>This was actually one of the discussion we had so far that the 
	> >>authorization mechanisms for the GETS RPH and the proposed 
	> >ECRIT RPH is 
	> >>different.
	> >>
	> >>So, could you elaborate a bit? 
	> >>
	> >>Ciao
	> >>Hannes
	> >>
	> >>>-----Original Message-----
	> >>>From: [email-masked] [mailto:[email-masked]]
	> >>On Behalf
	> >>>Of DOLLY, MARTIN C, ATTLABS
	> >>>Sent: 07 February, 2009 19:30
	> >>>To: [email-masked]; [email-masked]
	> >>>Cc: [email-masked]; [email-masked]
	> >>>Subject: Re: [Ecrit] Semantics Re: RPH
	> >>>
	> >>>Do you have a clue dude? A+A of an user comes in many forms.
	> >>>
	> >>>----- Original Message -----
	> >>>From: [email-masked] <[email-masked]>
	> >>>To: Janet P Gunn <[email-masked]>
	> >>>Cc: ECRIT <[email-masked]>; [email-masked] 
	> >>><[email-masked]>
	> >>>Sent: Sat Feb 07 11:56:42 2009
	> >>>Subject: Re: [Ecrit] Semantics  Re:  RPH
	> >>>
	> >>>Please see my earlier message as to why your approach fails
	> >>for the UA-
	> >>>inserted case where not all emergency calls have RPH
	> >>markings. I think
	> >>>it would be a really bad idea if emergency calls with RPH 
	> >are treated 
	> >>>differently than emergency calls without it. (Again, I'm
	> >>talking about
	> >>>the user-initiated calls. An ESNET can do whatever it wants and
can 
	> >>>assign extra priority to calls from citizens that have bought
PBA 
	> >>>stickers or zip codes that pay more taxes, but that's a
separate
	> >>>problem.)
	> >>>
	> >>>I also don't believe your implementation logic. A much better
	> >>approach
	> >>>is to semantically declare the class of call early on (e.g., 
	> >based on 
	> >>>the URN or after authentication/authorization), and make 
	> >that part of 
	> >>>the call state record, rather than hunt for headers each time a

	> >>>handling decision needs to be made. Given the authorization 
	> >>>requirements, just looking at "has header X" is never going to
be 
	> >>>sufficient anyway.
	> >>>
	> >>>Henning
	> >>>
	> >>>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:
	> >>>
	> >>>>
	> >>>>
	> >>>> .
	> >>>>
	> >>>> [email-masked] wrote on 02/07/2009 03:14:57 AM:
	> >>>>
	> >>>> > PLEASE try to understand that the syntax is similar
(header, new
	> >>>> namespace,
	> >>>> > new values)
	> >>>> > BUT the semantic is different.
	> >>>> >
	> >>>> > For all message it is true that the sender can add whatever
they
	> >>>> want. The
	> >>>> > big question is what does it mean for the recipient.
	> >>>> >
	> >>>> > This is what the discussion is about.
	> >>>> >
	> >>>> On the contrary, the semantic is, or at least can be, very
similar.
	> >>>>
	> >>>> Consider the hypothetical, but plausible, case of a 
	> >network with an 
	> >>>> explicit call/capacity admission process, in which both
911-type- 
	> >>>> emergency calls and GETS calls get preferential admission
	> >>>treatment.  
	> >>>> By the time the INVITE gets to this Functional Module/ block
	> >>>of code,
	> >>>> all authentication, authorization, and changes/ 
	> >confirmation of the 
	> >>>> destination have already taken place.  All this block of 
	> >code deals 
	> >>>> with is call/capacity admission.
	> >>>>
	> >>>> For the sake of argument, suppose this is the nature of the 
	> >>>> preference.
	> >>>>
	> >>>> 1) For INVITEs without RPH, or with an RPH this network does
	> >>>not use/
	> >>>> understand, if the admission process fails, the INVITE fails
	> >>>>
	> >>>> 2) For INVITEs with RPH with the ets namespace, if the
admission 
	> >>>> process initially fails, the INVITE is put in queue until the

	> >>>> resources become available so it can be admitted.
	> >>>>
	> >>>> 3) For INVITEs with RPH with the esnet namespace, if the
admission 
	> >>>> process initially fails, the INVITE is put in queue, but at
lower 
	> >>>> priority than the calls with the ets namespace.
	> >>>>
	> >>>> With the esnet namespace, this block of code only needs to
	> >>deal with
	> >>>> the RPH in determining which INVITEs to reject, and which 
	> >to queue, 
	> >>>> and how.
	> >>>>
	> >>>> But if there is no esnet namespace for RPH, then this 
	> >block of code 
	> >>>> would need to deal with BOTH the RPH and the URN.  That would
be a 
	> >>>> completely unnecessary complication.
	> >>>>
	> >>>> Janet
	> >>>
	> >>>_______________________________________________
	> >>>Ecrit mailing list
	> >>>[email-masked]
	> >>>https://www.ietf.org/mailman/listinfo/ecrit
	> >>>_______________________________________________
	> >>>Ecrit mailing list
	> >>>[email-masked]
	> >>>https://www.ietf.org/mailman/listinfo/ecrit
	> >>>
	> >>
	> >>
	> >
	> >
	> 

From: "Hannes Tschofenig" <[email-masked]>
To: "'Janet P Gunn'" <[email-masked]>, "'Brian Rosen'" <[email-masked]>
Date: Mon, 9 Feb 2009 15:47:25 +0200
Cc: [email-masked], [email-masked]
Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos?

-- found this old mail in my inbox. 

Hi Janet, 
 
that's certainly true. The main problems are unregistered phones
(unauthenticated emergency calls). 

Still, many regulators do not give clear signs that they would discontinue
this practise and hence network operators are (in an phase of uncertainty)
are prepared to support it. 
The latest example that I am aware of where a regulator indicates the demand
for it comes from Canada. 
 
As such, I would argue that the situation between emergency email and
(unauthenticated) emergency calls isn't all that different. 

Ciao
Hannes
 
________________________________

	From: Janet P Gunn [mailto:[email-masked]] 
	Sent: 02 February, 2009 22:07
	To: Brian Rosen
	Cc: [email-masked]; [email-masked]; 'Hannes Tschofenig';
'James M. Polk'
	Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos?

	However, current PSTN emergency calls suffer from both "Emergency
butt calls", and people making "Emergency" calls as a way of
testing/demonstrating that an unsubscribed handset is functional (apparently
a big problem in European "flea market" scenarios). 
	
	Quite analogous to spam. 
	
	Janet
	
	This is a PRIVATE message. If you are not the intended recipient,
please delete without copying and kindly advise us by e-mail of the mistake
in delivery. 
	NOTE: Regardless of content, this e-mail shall not operate to bind
CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose. 
	
	[email-masked] wrote on 02/02/2009 09:51:56 AM:
	
	> 
	> > - had a HIGH likelihood of SPAM on the recepient's end
	> Increasingly true of SMS, but this is true, sadly
	> 
	> > - SPAM could in general become the biggest issue wrt actually
having
	> > someone at the PSAP have to "look" at each and every message
because
	> > no one can build in the proper automated filters to cover all
	> > possible misspellings of a legitimate email message
	> No doubt about it.  Not clear that is reason enough to kill the
idea, but
	> it's certainly an issue.  On the other hand, that would argue that
no
	> improvement to email other than spam related improvements should
be
	> accepted.

From: "Hannes Tschofenig" <[email-masked]>
To: <[email-masked]>
Date: Mon, 9 Feb 2009 17:50:14 +0200
Cc: 'ext Gonzalo Camarillo' <[email-masked]>
Subject: [Ecrit] Next steps for draft-patel-ecrit-sos-parameter-03.txt

Hi all, 

After the 3GPP - IETF conference call last week I had a chat with Jon about
the next steps regarding
http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt

As mentioned on the list we wanted to submit a re-charter proposal after the
PhoneBCP document left the working group. It seems that this is not fast
enough for the 3GPP folks. 

Jon offered to AD sponsor that document and I asked Gonzalo to be the expert
reviewer for it. 

Ciao
Hannes

Date: Mon, 9 Feb 2009 09:03:34 -0800
To: "James M. Polk" <[email-masked]>, Hannes Tschofenig <[email-masked]>, "'DOLLY, MARTIN C,  ATTLABS'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
From: Ted Hardie <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ecrit] RPH

Howdy,
	After reading through the discussion through Monday morning
and seeing a remarkable lack of convergence, I began wondering if
the core of the issue isn't way back here:

James Polk wrote:
>Along comes a new ID that defines a new RP namespaces in SIP for
>ECRIT, called "esnet".
>
>This new namespace is needed because the 5 header-values defined in
>RFC 4412 do not match the usage for the ECRIT effort, therefore a new
>one needs to be created.
>
>RFCV 4412 is not tied to GETS and MLPP, it is tied to the creation of
>the idea of "RESOURCE-PRIORITY" in SIP, *and* - it happens to create
>5 IANA registered namespaces (and associated priority-values).

If the new RP namespace in SIP is only for ESNET, defining a header for it
and describing what to do is both relatively trivial and, I would argue,
pretty well understood.  ESNET can be understood for this purpose as
a closed network or a relatively tightly bound overlay.  Defining the
semantics for what happens in that network/for that overlay is clearly
only up to those operating that network.  The rest of us can ignore it,
as the spec allows.

Where we seem to have wrapped ourselves around the axles is whether
this namespace is for *uses of ECRIT* rather than *ESNET nodes*.  If
it is for any use of ECRIT, then the semantics get a lot fuzzier (since there
may be other mechanisms at play) and the apparent intention seems to
be that every node that cares about ECRIT must understand ESNET markings.
When I go back and look at draft-ietf-ecrit-local-emergency-rph-namespace-00,
this text seems a major part of that:

  This new namespace can be from a caller in
   distress, or added at the entry server into an emergency services
   managed network, towards a public safety answering point (PSAP),
   i.e., the 911 or 112-based emergency services call taker.  This
   new namespace can be used between PSAPs, and between a PSAP and
   first responders and their organizations.

As a way forward, I suggest we separate out the PSAP--first responder/organizations
use case and define only a namespace for that.  If we need a second namespace
for caller insertion/entry server insertion, we can create that.  Strings are cheap.
But there seems to be a long road ahead in combining the two, since the kinds
of devices that have to care and the kinds of networks they may have to traverse
seem different enough to hinder early consensus.

			regards,
				Ted Hardie

Date: Mon, 09 Feb 2009 11:13:21 -0600
To: "Hannes Tschofenig" <[email-masked]>, "'DRAGE, Keith \(Keith\)'" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)

At 02:32 AM 2/7/2009, Hannes Tschofenig wrote:

> >I don't believe anyone has been saying that. GETS and
> >emergency are two different namespaces that work within the
> >overvall framework of RPH.
> >
> >You implement RPH, and then configure or tailor it to the
> >namespaces you need to support, not provide a separate
> >implementation for every namespace you are called upon to support.
>
>
>This is exactly the trap Henning warned us during the last meeting.
>Because the authorization handling is totally different (because of the
>different context) you need to write different code. If you don't then you
>introduce these security problems.
>
>The draft at least needs to contain a super big SECURITY WARNING so that
>implements don't make that mistake. Currently it says "no security issues
>beyond the initial RPH document".

I've already agreed to write a more robust sec. cons. section just 
for the UAC insertion case... so please stop harping on this point -- 
unless I don't write it into the next version.

>This is clearly wrong and even leads
>experts like you to go along the wrong track.
>
> >
> >Go that way and every request will take hours to traverse end to end.
>Not sure what you mean.
>
>Ciao
>Hannes
>
> >
> >regards
> >
> >Keith
> >
> >> -----Original Message-----
> >> From: Hannes Tschofenig [mailto:[email-masked]]
> >> Sent: Friday, February 06, 2009 10:47 PM
> >> To: 'James M. Polk'
> >> Cc: DRAGE, Keith (Keith); 'Brian Rosen'; Tschofenig, Hannes (NSN -
> >> FI/Espoo); 'ECRIT'
> >> Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
> >>
> >> Good that you agree that GETS usage of RPH and the one we discuss in
> >> ECRIT is different.
> >> So far, some folks have been saying "what works for GETS
> >works for the
> >> ECRIT case as well".
> >>
> >> I argued that the environment is different and hence just
> >referencing
> >> RFC
> >> 4412 isn't good enough.
> >>
> >> >-----Original Message-----
> >> >From: James M. Polk [mailto:[email-masked]]
> >> >Sent: 07 February, 2009 00:02
> >> >To: Hannes Tschofenig
> >> >Cc: 'DRAGE, Keith (Keith)'; 'Brian Rosen'; Tschofenig,
> >Hannes (NSN -
> >> >FI/Espoo); 'ECRIT'
> >> >Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
> >> >
> >> >At 03:21 AM 2/6/2009, Hannes Tschofenig wrote:
> >> >>Hi James,
> >> >>
> >> >>I have read RFC 4412 and also the GETS/MLPP IETF documents. What I
> >> >>would like to point out is that there is more than just a
> >> header and
> >> >>values within the header that have to be considered in order
> >> >to make a
> >> >>judgement of what is appropriate and what isn't. There is an
> >> >>architectural question and whether the environment we are
> >using the
> >> >>stuff is indeed providing the properties you need for the
> >> >solution to be appropriate.
> >> >>
> >> >>Let me describe in more detail what I meant (and please
> >> >correct me if I
> >> >>am wrong).
> >> >>
> >> >>Getting priority for SIP requests when using a GETS alike scenario
> >> >>means that the entity that issues the request is specially
> >> authorized
> >> >>since otherwise you introduce a nice denial of service attack.
> >> >
> >> >You are missing a step in GETS here.  The endpoint, who
> >> sends the GETS
> >> >set-up as an INVITE is not already authorized (not the
> >> device, not the
> >> >user).  In North America, there is a 10 digit GETS number that is
> >> >dialed (that I won't give out right now on an open list) -
> >and there
> >> >literally is only 1 number available to dial for this service.
> >> >Literally anyone can dial this number today in North America
> >> (no matter
> >> >where the phone is - as long as it is in North America --
> >> and I might
> >> >be too limiting in that it is dialable from anywhere, because it is
> >> >going to a North American destination).
> >> >
> >> >Once this number is dialed, it is answered by an authentication and
> >> >authorization IVR.  This IVR challenges each caller for their
> >> >authentication passcode, and a password). Once this has been
> >> >successfully entered, then call is NOW authorized to
> >proceed towards
> >> >its destination number - this step is only known to the authorizing
> >> >system because the destination 10 digit number is NOT entered until
> >> >after the authentication and authorization step has completed.
> >> >
> >> >The authorized caller is prompted with a new dial tone - in
> >> which they
> >> >can enter any number on the planet and receive preferential
> >> treatment
> >> >through as many carriers (in IP, it's
> >> >SPs) that have implemented this GETS service (which is an
> >> SLA with the
> >> >Department of Homeland Security now).
> >> >
> >> >Merely entering the GETS RP namespace is never intended,
> >> alone, to gain
> >> >any preferential treatment -- other than towards this
> >> authentication &
> >> >authorization IVR.
> >> >
> >> >I hope you can see that this is a completely separate type
> >> of service
> >> >and implementation type than ECRIT based emergency calling will use.
> >> >
> >> >BTW - to your comment below about me not calling your name
> >> out when you
> >> >are incorrect because I have been equally incorrect
> >> >-- I'm not sure I've been spared as much as you think, given
> >> that many
> >> >have called me out by name when they've felt I've been wrong
> >> over the
> >> >years.
> >> >
> >> >>This authorization
> >> >>is tied to the entity that makes the request. For example,
> >> the person
> >> >>is working for the government and has special rights. James
> >> Bond as a
> >> >>(not so) secret agent might have these rights.
> >> >>
> >> >>The emergency services case (citizen-to-authority) is a bit
> >> different
> >> >>as there aren't really special rights with respect to
> >authorization
> >> >>tied to individuals. Instead, the fact that something is an
> >> emergency
> >> >>is purely a judgement of the human that dials a special
> >> >number. To deal
> >> >>with fraud, we discussed in the group on what we can
> >actually do to
> >> >>ensure that end users do not bypass security procedures (such as
> >> >>authorization checks, charging and so on). Part of this
> >> investigation
> >> >>was the publication of http://www.ietf.org/rfc/rfc5069.txt
> >> >that also describes this issue.
> >> >>
> >> >>So, imagine the implementation of a SIP proxy (and we
> >> implemented that
> >> >>stuff) that receives a call that contains a Service URN. The code
> >> >>branches into a special mode where everything is done so that
> >> >the call
> >> >>receives appropriate treatment and does not get dropped on
> >> the floor.
> >> >>The way how the Service URN is placed in the message
> >> ensures that the
> >> >>call cannot go to my friend (instead of the PSAP) unless
> >> the end host
> >> >>ran LoST already. In the latter case, we discussed this
> >also on the
> >> >>list for a while and Richard even wrote a draft about it in
> >> >the context
> >> >>of the location hiding topic, we said that the proxy would
> >> >have to run
> >> >>LoST if he cares about a potential fraudulent usage.
> >> >>
> >> >>So, what do we need todo in order to provide secure RFC 4412
> >> >>functionality in our context?
> >> >>
> >> >>Do you think that the current text in
> >> >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-eme
> >> >rgency-rp
> >> >>h-nam espace-00.txt reflects any of the above-described issues:
> >> >>"
> >> >>    The Security considerations that apply to RFC 4412
> >> [RFC4412] apply
> >> >>    here.  This document introduces no new security issues
> >> relative to
> >> >>    RFC 4412.
> >> >>"
> >> >>
> >> >> From various discussions in GEOPRIV I recall that you are
> >> >>super-sensitive regarding security and privacy. For some
> >> reasons you
> >> >>don't seem to have the same concerns here. I would like to
> >> >understand your reasoning.
> >> >>
> >> >>Please also do me another favor: Don't always say that I don't
> >> >>understand the subject. Even if that would be the case it isn't
> >> >>particular fair given that different folks had to educate you
> >> >on other topics in the past as well.
> >> >>Additionally, if you listen to the audio recordings then you will
> >> >>notice that Henning, Ted, and Jon do not seem to understand
> >> the issue
> >> >>either as they have raised similar issues during the F2F meetings.
> >> >>
> >> >>Ciao
> >> >>Hannes
> >> >>
> >> >>
> >> >> >Hannes - I believe it is you who do not understand RFC
> >> 4412 -- and
> >> >> >many of us are trying to get that through to you, but you
> >> >don't seem
> >> >> >to want to listen/read.
> >> >> >
> >> >> >RFC 4412 is *for* priority marking SIP requests,
> >> >> >
> >> >> >One use is GETS.
> >> >> >
> >> >> >One use is MLPP.
> >> >> >
> >> >> >These examples are in RFC 4412 because there were specific
> >> >namespaces
> >> >> >being created for the IANA section of that document.
> >> >> >
> >> >> >Reading the whole document, you will see that RPH can be
> >> specified
> >> >> >for other uses than GETS or MLPP specifically.
> >> >> >
> >> >> >I knew when I wrote RFC 4412 that one day we would specify a
> >> >> >namespace for ECRIT (the "esnet" namespace now) -- but I
> >> >also knew it
> >> >> >was premature for RFC 4412 to incorporate that namespace, that a
> >> >> >future doc to RFC 4412 would have to be written to do this.
> >> >Brian and
> >> >> >I talked about this at the original NENA meeting that
> >> >created the IP
> >> >> >WGs there (in August of 03).  We both agreed we should wait
> >> >until it
> >> >> >was appropriate to the work in the IETF to submit this
> >> >document that
> >> >> >is now
> >> >> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >> >> >gency-rph-namespace-00.txt
> >> >> >
> >> >> >Yet, you seem to want to use some additional mechanism to
> >> indicate
> >> >> >priority of a call in SIP.  That means you want to
> >> >introduce a second
> >> >> >way to accomplish this in SIP.  Why do you want to promote
> >> >a separate
> >> >> >way to do something SIP has already defined? That will cause
> >> >> >interoperability issues and we both know that.
> >> >> >
> >> >> >You've said to me (and others) that you believe RPH is
> >> just another
> >> >> >way to accomplish what sos or a URI can indicate - and
> >> >you're wrong.
> >> >> >Your way would be _the_second_way_to_do_it, because SIP already
> >> >> >considers RPH to be *the*way* to priority mark SIP requests.
> >> >> >
> >> >> >If you don't believe me (no comment), then why do you not
> >> >believe the
> >> >> >SIP WG chair (who knows more about SIP than both of us)
> >- who, on
> >> >> >this thread, has again said to you "RFC 4412
> >> >> >(RPH) is the SIP mechanism to priority mark SIP requests"?
> >> >> >
> >> >> >Further, I believe it is inappropriate to prohibit
> >endpoints from
> >> >> >being able to set the esnet namespace.  I absolutely
> >> >believe it will
> >> >> >not be needed most of the time, but I believe if someone
> >> >does find a
> >> >> >valid use for endpoints to mark priority in SIP, this ID
> >> - once it
> >> >> >has become an RFC -- will have to be obsoleted with a new
> >> >RFC saying
> >> >> >the exact opposite.
> >> >> >
> >> >> >(color me confused ... over and over again)
> >> >> >
> >> >> >James
> >> >> >
> >> >> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >> >> >>Keith, please understand that the usage of RFC 4412 for
> >> >GETS and for
> >> >> >>the type of emergency call we discuss here is different. Just
> >> >> >>looking at the header and the name of the namespace is a bit
> >> >> >artificial. I hope
> >> >> >>you understand that.
> >> >> >>
> >> >> >> >-----Original Message-----
> >> >> >> >From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> >> >> >> >Sent: 05 February, 2009 14:55
> >> >> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk';
> >> >> >> >'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >> >> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >> >> >mistake)
> >> >> >> >
> >> >> >> >Which is exactly what RFC 4412 specifies for all namespaces.
> >> >> >> >
> >> >> >> >regards
> >> >> >> >
> >> >> >> >Keith
> >> >> >> >
> >> >> >> >> -----Original Message-----
> >> >> >> >> From: [email-masked] [mailto:[email-masked]]
> >> >> >> >On Behalf
> >> >> >> >> Of Brian Rosen
> >> >> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >> >> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
> >> >> >Hannes (NSN
> >> >> >> >> - FI/Espoo)'; 'ECRIT'
> >> >> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
> >> Agenda (my
> >> >> >> >> mistake)
> >> >> >> >>
> >> >> >> >> The value is that in some networks where priority for
> >> >> >> >emergency calls
> >> >> >> >> is appropriate, and appropriate policing of marking is
> >> >> >implemented,
> >> >> >> >> emergency calls will receive resource priority.
> >> >> >> >>
> >> >> >> >> Not all networks would need policing.  Some will.  Policing
> >> >> >> >> could be to Route header/R-URI content, but other
> >> >criteria are possible.
> >> >> >> >>
> >> >> >> >> Not all networks will need resource priority for
> >> >emergency calls.
> >> >> >> >> Fine, ignore this marking/namespace.
> >> >> >> >>
> >> >> >> >> Brian
> >> >> >> >> > -----Original Message-----
> >> >> >> >> > From: Hannes Tschofenig [mailto:[email-masked]]
> >> >> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >> >> >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig,
> >> >Hannes (NSN -
> >> >> >> >> > FI/Espoo); 'ECRIT'
> >> >> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting:
> >> >Agenda (my
> >> >> >> >> > mistake)
> >> >> >> >> >
> >> >> >> >> > I don't even see the value in permitting the
> >> >endpoint todo the
> >> >> >> >> > RPH marking.
> >> >> >> >> > In addition to the security concerns there is also the
> >> >> >> >problem that
> >> >> >> >> > there are more options to implement without an
> >> >additional value.
> >> >> >> >> >
> >> >> >> >> > >-----Original Message-----
> >> >> >> >> > >From: Brian Rosen [mailto:[email-masked]]
> >> >> >> >> > >Sent: 05 February, 2009 00:03
> >> >> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,
> >> >> >> >> Hannes (NSN -
> >> >> >> >> > >FI/Espoo)'; 'ECRIT'
> >> >> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim
> >> Meeting: Agenda
> >> >> >> >> > >(my
> >> >> >> >> > mistake)
> >> >> >> >> > >
> >> >> >> >> > >Hannes
> >> >> >> >> > >
> >> >> >> >> > >This matches my understanding precisely.  We wish to
> >> >> >> >> permit endpoints
> >> >> >> >> > >to mark. We do not require it, and don't
> >> necessarily expect
> >> >> >> >> > >it in many (even
> >> >> >> >> > >most) cases.  We don't wish to see the document
> >> prohibit it.
> >> >> >> >> > >We all seem to agree it has value within the Emergency
> >> >> >> >Services IP
> >> >> >> >> > >Networks.
> >> >> >> >> > >
> >> >> >> >> > >Brian
> >> >> >> >> > >
> >> >> >> >> > >> -----Original Message-----
> >> >> >> >> > >> From: [email-masked]
> >> >> >> >> > >> [mailto:[email-masked]]
> >> >> >> >> > >On Behalf
> >> >> >> >> > >> Of James M. Polk
> >> >> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> >> >> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
> >> >> >> >> FI/Espoo); 'ECRIT'
> >> >> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
> >> >> >Agenda (my
> >> >> >> >> > >> mistake)
> >> >> >> >> > >>
> >> >> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> >> >> >> >> > >> > > James wrote:
> >> >> >> >> > >> > >> you are the _lone_ voice not supporting this ID,
> >> >> >> >> > >> >
> >> >> >> >> > >> >Listening to the audio recording of past
> >> meetings I have
> >> >> >> >> > >> >to
> >> >> >> >> > >say that
> >> >> >> >> > >> >I
> >> >> >> >> > >> was
> >> >> >> >> > >> >not the only persons raising concerns about
> >> the document.
> >> >> >> >> > >> >That was probably the reason why you agreed to
> >> limit the
> >> >> >> >> > >scope of the
> >> >> >> >> > >> >document (which you didn't later do) to get
> >> >folks to agree
> >> >> >> >> > >to make it
> >> >> >> >> > >> a WG
> >> >> >> >> > >> >item.
> >> >> >> >> > >>
> >> >> >> >> > >> re-listen to the audio please
> >> >> >> >> > >>
> >> >> >> >> > >> Ted's concerns were consistent with most (all?) other
> >> >> >> >> concerns --
> >> >> >> >> > >> which were based on the premise of whether or not the
> >> >> >> >> UAC should be
> >> >> >> >> > >> trusted to initiate the marking on the INVITE.
> >> The most
> >> >> >> >> > >> recent version has backed off this to a "can"
> >> -- meaning
> >> >> >> >> > >> not
> >> >> >> >prohibited
> >> >> >> >> > >> (i.e., no 2119 text).  I also backed off the
> >text in the
> >> >> >> >> SP domain
> >> >> >> >> > >> part to "can", such that there is no 2119 text
> >> >> >> >mandating or even
> >> >> >> >> > >> recommending its usage there. I also do not
> >prohibit its
> >> >> >> >> > >use, based on
> >> >> >> >> > >> local policy.  Keith has come forward with the
> >specific
> >> >> >> >> > >> request that non-ESInet networks be allowed to
> >> >mark and pay
> >> >> >> >attention to
> >> >> >> >> > >> this priority indication -- with IMS as the specific
> >> >> >> >> > >> example he wishes to have this valid for.
> >> >> >> >> > >>
> >> >> >> >> > >> Where there is no disagreement, save for your recent
> >> >> >> >> > >pushback - is in
> >> >> >> >> > >> the ESInet, which is where Brian has requested it's
> >> >> >> >> > >definition in the
> >> >> >> >> > >> IETF on behalf of NENA.  He's the i3 WG chair within
> >> >> >> >> NENA, and if
> >> >> >> >> > >> he asks for it, are you going to say you know
> >> >better than he?
> >> >> >> >> > >>
> >> >> >> >> > >>
> >> >> >> >> > >> >Btw, I not disagreeing with the document as such. I
> >> >> >> >just want to
> >> >> >> >> > the
> >> >> >> >> > >> scope
> >> >> >> >> > >> >to change. The usage of RPH within the emergency
> >> >> >> >> services network
> >> >> >> >> > is
> >> >> >> >> > >> fine
> >> >> >> >> > >> >for me. I may get convinced to start the RPH
> >> marking from
> >> >> >> >> > >the the VSP
> >> >> >> >> > >> >towards the PSAP. I feel uneasy about the end
> >> host doing
> >> >> >> >> > >the marking.
> >> >> >> >> > >>
> >> >> >> >> > >> please read what I wrote above, and then re-read the
> >> >> >> >most recent
> >> >> >> >> > >> version of the ID. I don't have endpoints that
> >SHOULD or
> >> >> >> >> MUST mark
> >> >> >> >> > >> anything wrt RPH.  I also don't want to prohibit it,
> >> >> >> >> because there
> >> >> >> >> > >> might be cases (that I don't know of) of valid uses
> >> >> >> >> under certain
> >> >> >> >> > >> circumstances.  Figure 1 is very clear that there are 3
> >> >> >> >> networking
> >> >> >> >> > >> parts to consider
> >> >> >> >> > >>
> >> >> >> >> > >> #1 - from the endpoint
> >> >> >> >> > >> #2 - within the VSP
> >> >> >> >> > >> #3 - within the ESInet
> >> >> >> >> > >>
> >> >> >> >> > >> the most recent ID version has "can" for #s 1
> >and 2, and
> >> >> >> >> > >2119 language
> >> >> >> >> > >> offering those supporting this specification will
> >> >have RPH
> >> >> >> >> > >> adherence within #3 (the ESInet).
> >> >> >> >> > >>
> >> >> >> >> > >> What other scope changes do you want, because I haven't
> >> >> >> >> heard them.
> >> >> >> >> > >>
> >> >> >> >> > >> I only heard you claim in email during the last
> >> >IETF and in
> >> >> >> >> > >the ECRIT
> >> >> >> >> > >> session that RPH should not be used for
> >priority marking
> >> >> >> >> requests.
> >> >> >> >> > >> This is something Keith (SIP WG chair) voiced his
> >> >> >> >> > >> opposition to your views regarding creating a
> >> >second means
> >> >> >> >> > >> for SIP to
> >> >> >> >priority
> >> >> >> >> > >> mark request "when SIP already has one
> >> >interoperable way to
> >> >> >> >> > >> accomplish this... it's call the RP header mechanism".
> >> >> >> >> > >>
> >> >> >> >> > >> >I don't see advantages -- only disadvantages.
> >> >> >> >> > >> >
> >> >> >> >> > >> >Ciao
> >> >> >> >> > >> >Hannes
> >> >> >> >> > >>
> >> >> >> >> > >> _______________________________________________
> >> >> >> >> > >> Ecrit mailing list
> >> >> >> >> > >> [email-masked]
> >> >> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >> >> > >
> >> >> >> >>
> >> >> >> >> _______________________________________________
> >> >> >> >> Ecrit mailing list
> >> >> >> >> [email-masked]
> >> >> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >> >>
> >> >> >> >
> >> >> >
> >> >
> >>
> >>
> >

Date: Mon, 09 Feb 2009 11:20:52 -0600
To: "Hannes Tschofenig" <[email-masked]>, "'Janet P Gunn'" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: 'ECRIT' <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

At 03:48 AM 2/8/2009, Hannes Tschofenig wrote:
>Hi Janet,
>
>thanks for your text. I think I am getting a better understanding of the
>scenarios you have in mind.
>
>Let me comment inline (search for [hannes]):
>
>         Consider the hypothetical, but plausible, case of a network with an
>explicit call/capacity admission process, in which both 911-type-emergency
>calls and GETS calls get preferential admission treatment.  By the time the
>INVITE gets to this Functional Module/ block of code, all authentication,
>authorization, and changes/confirmation of the destination have already
>taken place.  All this block of code deals with is call/capacity admission.
>
>         For the sake of argument, suppose this is the nature of the
>preference.
>
>         1) For INVITEs without RPH, or with an RPH this network does not
>use/understand, if the admission process fails, the INVITE fails
>
>[hannes] This is the non-emergency case, I suspect. Section 4.6.2 of RFC
>4412 discusses when to fail an INVITE if the RPH marking is not understood.
>It does not always fail.
>
>         2) For INVITEs with RPH with the ets namespace, if the admission
>process initially fails, the INVITE is put in queue until the resources
>become available so it can be admitted.
>
>         3) For INVITEs with RPH with the esnet namespace, if the admission
>process initially fails, the INVITE is put in queue, but at lower priority
>than the calls with the ets namespace.
>
>[hannes] Is this an INVITE for an emergecy call? I suspect, yes.  What
>priority is given to the emergency call in relationship to the calls with
>the ETS namespace is a local policy matter?

this is always a local policy decision - and cannot go into any IETF 
doc, other than to remind everyone that "the relative priority order 
rules of section 8 of RFC 4412 MUST be maintained".

>Or: would you like to put a
>description of it into
>draft-ietf-ecrit-local-emergency-rph-namespace-00.txt?
>
>What happens with an non-emergency call invite that has the esnet RPH
>marking? Does it get the emergency call treatement?
>
>
>         With the esnet namespace, this block of code only needs to deal with
>the RPH in determining which INVITEs to reject, and which to queue, and how.
>
>
>[hannes] You talk about rejecting the INVITE: Emergency calls do not get
>rejected regardless of the RPH marking.

this statement is assuming all emergency calls do in fact get through 
-- and that is simply not the case today, so what basis are you 
making this argument from?

>
>         But if there is no esnet namespace for RPH, then this block of code
>would need to deal with BOTH the RPH and the URN.  That would be a
>completely unnecessary complication.
>
>[hannes] Are you saying that you wouldn't look at the Service URN / dial
>string when the esnet RPH namespace is present?
>
>
>I believe I now better understand what you (and maybe James and Keith) want
>to accomplish.
>
>
>You would like to allow the VSP to have two types of emergency calls:
>* "normal" emergency calls that would be placed in a queue as they arrive
>   (These are the calls that are only marked as emergency calls using a
>Service URN
>    or contain a special dial string.)
>* esnet RPH marked emergency calls that would skip other calls in the queue
>(if there is a queue and this queue contains non-emergency calls). These
>calls are sort of better than the "normal" emergency calls.
>
>Did I correctly understand it? Is this the scenario you had in mind with the
>esnet RPH mechanism?
>
>If someone would like to create two classes of emergency calls in that
>fashion then additional marking would be justified.
>
>Ciao
>Hannes
>
>         Janet
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'Ted Hardie'" <[email-masked]>, "'James M. Polk'" <[email-masked]>, "'DOLLY, MARTIN C,  ATTLABS'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 9 Feb 2009 19:36:49 +0200
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] RPH

You captured the discussion quite well. 

Separating out the PSAP--first responder/organizations use case and define
only a namespace for that sounds good to me and would reflect what James had
agreed to a while ago. 

Ciao
Hannes

>-----Original Message-----
>From: Ted Hardie [mailto:[email-masked]] 
>Sent: 09 February, 2009 19:04
>To: James M. Polk; Hannes Tschofenig; 'DOLLY, MARTIN C, 
>ATTLABS'; [email-masked]; [email-masked]
>Cc: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
>Subject: Re: [Ecrit] RPH
>
>Howdy,
>	After reading through the discussion through Monday 
>morning and seeing a remarkable lack of convergence, I began 
>wondering if the core of the issue isn't way back here:
>
>James Polk wrote:
>>Along comes a new ID that defines a new RP namespaces in SIP 
>for ECRIT, 
>>called "esnet".
>>
>>This new namespace is needed because the 5 header-values 
>defined in RFC 
>>4412 do not match the usage for the ECRIT effort, therefore a new one 
>>needs to be created.
>>
>>RFCV 4412 is not tied to GETS and MLPP, it is tied to the creation of 
>>the idea of "RESOURCE-PRIORITY" in SIP, *and* - it happens to create
>>5 IANA registered namespaces (and associated priority-values).
>
>
>If the new RP namespace in SIP is only for ESNET, defining a 
>header for it and describing what to do is both relatively 
>trivial and, I would argue, pretty well understood.  ESNET can 
>be understood for this purpose as a closed network or a 
>relatively tightly bound overlay.  Defining the semantics for 
>what happens in that network/for that overlay is clearly only 
>up to those operating that network.  The rest of us can ignore 
>it, as the spec allows.
>
>Where we seem to have wrapped ourselves around the axles is 
>whether this namespace is for *uses of ECRIT* rather than 
>*ESNET nodes*.  If it is for any use of ECRIT, then the 
>semantics get a lot fuzzier (since there may be other 
>mechanisms at play) and the apparent intention seems to be 
>that every node that cares about ECRIT must understand ESNET markings.
>When I go back and look at 
>draft-ietf-ecrit-local-emergency-rph-namespace-00,
>this text seems a major part of that:
>
>  This new namespace can be from a caller in
>   distress, or added at the entry server into an emergency services
>   managed network, towards a public safety answering point (PSAP),
>   i.e., the 911 or 112-based emergency services call taker.  This
>   new namespace can be used between PSAPs, and between a PSAP and
>   first responders and their organizations.
>
>As a way forward, I suggest we separate out the PSAP--first 
>responder/organizations use case and define only a namespace 
>for that.  If we need a second namespace for caller 
>insertion/entry server insertion, we can create that.  Strings 
>are cheap.
>But there seems to be a long road ahead in combining the two, 
>since the kinds of devices that have to care and the kinds of 
>networks they may have to traverse seem different enough to 
>hinder early consensus.
>
>			regards,
>				Ted Hardie
>

Date: Mon, 09 Feb 2009 11:41:17 -0600
To: "Hannes Tschofenig" <[email-masked]>, "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

At 07:14 AM 2/8/2009, Hannes Tschofenig wrote:
>Hi Martin,
>
>Thanks for the quick response.
>
>I am aware of these network access authentication and authorization
>procedures (including the authentication and authorization procedure at the
>SIP layer). They are clearly important for some of the RPH usage scenarios.
>
>For this specific case (the new esnet RPH mechanism) there are additional
>facets that needs to be considered (beyond the above-mentioned security
>aspects):
>
>* What does the esnet RPH usage mean in the context of an emergency call
>(for example, in comparison to an emergency call without esnet RPH usage)?
>
>* For emergency calls the authorization procedures are different than with
>regular calls. There are certainly differences to the GETS-alike calls as
>well. (We ignore for a moment that there are these unauthenticated emergency
>calls where even the authentication procedure is missing.) The current
>security consideration section does not acknowledge these differences.
>
>It would be helpful that draft-ietf-ecrit-local-emergency-rph-namespace
>captures some of these aspects to allow those who implement and deploy the
>esnet RPH mechanism to understand what it does and how to correctly
>implement it.

I wholly disagree with this desire. This 
draft-ietf-ecrit-local-emergency-rph-namespace creates the namespace, 
it does not create the associated semantics for use of this namespace 
that are specific to NENA or EENA. That is up to NENA or EENA to 
specify.  It is also up to the AT&T's and Verizon's of the world to 
define what the exact semantics are within their respective networks 
are to satisfy whatever regulations they have in their local 
jurisdictions (which are different from each other -- and what the 
IETF knows nothing about).

For example, each group of emergency callers thinks *their* type of 
emergency should get preferential treatment over other types of 
emergencies. To be specific, which type of emergency call is more 
important: a GETS type call or a 911/112 type call?

It is not up to the IETF to decide that. It is up to the local 
policies of the jurisdiction and the SP to figure that out. This is 
not inconsistent with RFC 4412 - in fact, RFC 4412 built this aspect 
into its text.

The esnet namespace should follow RFC 4412's guidelines in 
coordination with those from the local authorities and the local SPs 
to determine how they are going to configure their operations.  At 
that point, it's up to the local SP to buy products from vendors that 
can meet the requirements of that local configuration.

Therefore, draft-ietf-ecrit-local-emergency-rph-namespace should not 
have any additional text articulating guidance how to configure their 
networks. RFC 4412 defines all the guidance they need at this time.

When operational experience proves something ought to be modified 
within that guidance, then a new doc should be written suggesting 
that/those modification(s).

>Ciao
>Hannes
>
>PS: There are details that also need to be discussed. For example, which
>esnet value would the device use for an emergency call? "esnet.0",
>"esnet.1", "esnet.2", "esnet.3", "esnet.4". Out-of-scope is a possible
>answer but it will not help the implementer in doing it's job.

see the very same explanation above as to why this isn't something 
that ought be in an IETF doc.

>Is there a
>specific default value (maybe the highest value, just to be sure)?

there is not, and choosing one the highest or lowest value limits 
adjustments and the "what if we determine one day something else is 
actually more important" question.

>Would the UA get provisioned to pick a specific value?

if this were in scope of this doc, I'd suggest this be done through 
something like RFC 3841 "SIP Call Preferences"

>What is the provisioning mechanism?

this depends on the choice, but Caller Prefs has a mechanism.

>Is there a relationship between the esnet values and the Service URN values?

should there be?

I don't know, and think this is a local (matrix) matter -- or a 
NENA/EENA matter

>Do the urn:service:counseling:* services get a lower priority than 
>the urn:service:sos:* services?

only if local policy gives urn:service:counseling:* any priority, 
then local policy will determine what priority in relation to sos.

Remember - some of these decisions will be based on the capacity (BW 
and # of call takers) within the local jurisdiction -- which is again 
something the IETF cannot give guidance on at this point , if ever

> >Hannes,
> >
> >We need to understand the attachment of the UE to the network.
> >There is an AA process prior to allowing any use. Without this
> >we would not trust the RPH, even for ETS, never mind 911
> >
> >Martin
> >
> >----- Original Message -----
> >From: Hannes Tschofenig <[email-masked]>
> >To: DOLLY, MARTIN C, ATTLABS; [email-masked]
> ><[email-masked]>; [email-masked] <[email-masked]>
> >Cc: [email-masked] <[email-masked]>
> >Sent: Sun Feb 08 04:32:25 2009
> >Subject: RE: [Ecrit] Semantics  Re:  RPH
> >
> >Hi Martin,
> >
> >Your remarks are a bit a short.
> >
> >Clearly, authentication and authorization can come in different forms.
> >This was actually one of the discussion we had so far that the
> >authorization mechanisms for the GETS RPH and the proposed
> >ECRIT RPH is different.
> >
> >So, could you elaborate a bit?
> >
> >Ciao
> >Hannes
> >
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]]
> >On Behalf
> >>Of DOLLY, MARTIN C, ATTLABS
> >>Sent: 07 February, 2009 19:30
> >>To: [email-masked]; [email-masked]
> >>Cc: [email-masked]; [email-masked]
> >>Subject: Re: [Ecrit] Semantics Re: RPH
> >>
> >>Do you have a clue dude? A+A of an user comes in many forms.
> >>
> >>----- Original Message -----
> >>From: [email-masked] <[email-masked]>
> >>To: Janet P Gunn <[email-masked]>
> >>Cc: ECRIT <[email-masked]>; [email-masked]
> >><[email-masked]>
> >>Sent: Sat Feb 07 11:56:42 2009
> >>Subject: Re: [Ecrit] Semantics  Re:  RPH
> >>
> >>Please see my earlier message as to why your approach fails
> >for the UA-
> >>inserted case where not all emergency calls have RPH
> >markings. I think
> >>it would be a really bad idea if emergency calls with RPH are treated
> >>differently than emergency calls without it. (Again, I'm
> >talking about
> >>the user-initiated calls. An ESNET can do whatever it wants and can
> >>assign extra priority to calls from citizens that have bought PBA
> >>stickers or zip codes that pay more taxes, but that's a separate
> >>problem.)
> >>
> >>I also don't believe your implementation logic. A much better
> >approach
> >>is to semantically declare the class of call early on (e.g., based on
> >>the URN or after authentication/authorization), and make that part of
> >>the call state record, rather than hunt for headers each time a
> >>handling decision needs to be made. Given the authorization
> >>requirements, just looking at "has header X" is never going to be
> >>sufficient anyway.
> >>
> >>Henning
> >>
> >>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:
> >>
> >>>
> >>>
> >>> .
> >>>
> >>> [email-masked] wrote on 02/07/2009 03:14:57 AM:
> >>>
> >>> > PLEASE try to understand that the syntax is similar (header, new
> >>> namespace,
> >>> > new values)
> >>> > BUT the semantic is different.
> >>> >
> >>> > For all message it is true that the sender can add whatever they
> >>> want. The
> >>> > big question is what does it mean for the recipient.
> >>> >
> >>> > This is what the discussion is about.
> >>> >
> >>> On the contrary, the semantic is, or at least can be, very similar.
> >>>
> >>> Consider the hypothetical, but plausible, case of a network with an
> >>> explicit call/capacity admission process, in which both 911-type-
> >>> emergency calls and GETS calls get preferential admission
> >>treatment.
> >>> By the time the INVITE gets to this Functional Module/ block
> >>of code,
> >>> all authentication, authorization, and changes/ confirmation of the
> >>> destination have already taken place.  All this block of code deals
> >>> with is call/capacity admission.
> >>>
> >>> For the sake of argument, suppose this is the nature of the
> >>> preference.
> >>>
> >>> 1) For INVITEs without RPH, or with an RPH this network does
> >>not use/
> >>> understand, if the admission process fails, the INVITE fails
> >>>
> >>> 2) For INVITEs with RPH with the ets namespace, if the admission
> >>> process initially fails, the INVITE is put in queue until the
> >>> resources become available so it can be admitted.
> >>>
> >>> 3) For INVITEs with RPH with the esnet namespace, if the admission
> >>> process initially fails, the INVITE is put in queue, but at lower
> >>> priority than the calls with the ets namespace.
> >>>
> >>> With the esnet namespace, this block of code only needs to
> >deal with
> >>> the RPH in determining which INVITEs to reject, and which to queue,
> >>> and how.
> >>>
> >>> But if there is no esnet namespace for RPH, then this block of code
> >>> would need to deal with BOTH the RPH and the URN.  That would be a
> >>> completely unnecessary complication.
> >>>
> >>> Janet
> >>
> >>_______________________________________________
> >>Ecrit mailing list
> >>[email-masked]
> >>https://www.ietf.org/mailman/listinfo/ecrit
> >>_______________________________________________
> >>Ecrit mailing list
> >>[email-masked]
> >>https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >
> >
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

Date: Mon, 09 Feb 2009 11:49:12 -0600
To: "Hannes Tschofenig" <[email-masked]>, "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

At 12:45 PM 2/8/2009, Hannes Tschofenig wrote:
>Not sure what you mean.
>
>Let me ask you a basic question that we have been struggling with for some
>time in this discussion that Janet recently highlighted:
>
>How do you treat an esnet RPH marked 9-1-1 call in comparison to a 9-1-1
>call that does not have the esnet RPH marking?

this is a local policy issue -- that might include a contractual 
aspect (i.e., all GETS SLAs will be based on contracts).

It certainly isn't up to the IETF

>In what sense does the
>processing in the SIP proxy differ?
>
>Ciao
>Hannes
>
> >-----Original Message-----
> >From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]]
> >Sent: 08 February, 2009 16:02
> >To: [email-masked]; [email-masked]; [email-masked]
> >Cc: [email-masked]
> >Subject: Re: [Ecrit] Semantics Re: RPH
> >
> >These are the rule, not the exception. I do not care about the
> >internet free scenarios.
> >
> >----- Original Message -----
> >From: Hannes Tschofenig <[email-masked]>
> >To: DOLLY, MARTIN C, ATTLABS; [email-masked]
> ><[email-masked]>; [email-masked] <[email-masked]>
> >Cc: [email-masked] <[email-masked]>
> >Sent: Sun Feb 08 08:14:32 2009
> >Subject: RE: [Ecrit] Semantics  Re:  RPH
> >
> >Hi Martin,
> >
> >Thanks for the quick response.
> >
> >I am aware of these network access authentication and
> >authorization procedures (including the authentication and
> >authorization procedure at the SIP layer). They are clearly
> >important for some of the RPH usage scenarios.
> >
> >For this specific case (the new esnet RPH mechanism) there are
> >additional facets that needs to be considered (beyond the
> >above-mentioned security
> >aspects):
> >
> >* What does the esnet RPH usage mean in the context of an
> >emergency call (for example, in comparison to an emergency
> >call without esnet RPH usage)?
> >
> >* For emergency calls the authorization procedures are
> >different than with regular calls. There are certainly
> >differences to the GETS-alike calls as well. (We ignore for a
> >moment that there are these unauthenticated emergency calls
> >where even the authentication procedure is missing.) The
> >current security consideration section does not acknowledge
> >these differences.
> >
> >It would be helpful that draft-ietf-ecrit-local-emergency-rph-namespace
> >captures some of these aspects to allow those who implement
> >and deploy the esnet RPH mechanism to understand what it does
> >and how to correctly implement it.
> >
> >Ciao
> >Hannes
> >
> >PS: There are details that also need to be discussed. For
> >example, which esnet value would the device use for an
> >emergency call? "esnet.0", "esnet.1", "esnet.2", "esnet.3",
> >"esnet.4". Out-of-scope is a possible answer but it will not
> >help the implementer in doing it's job. Is there a specific
> >default value (maybe the highest value, just to be sure)?
> >Would the UA get provisioned to pick a specific value? What is
> >the provisioning mechanism? Is there a relationship between
> >the esnet values and the Service URN values? Do the
> >urn:service:counseling:* services get a lower priority
> >than the urn:service:sos:* services?
> >
> >>Hannes,
> >>
> >>We need to understand the attachment of the UE to the network.
> >>There is an AA process prior to allowing any use. Without
> >this we would
> >>not trust the RPH, even for ETS, never mind 911
> >>
> >>Martin
> >>
> >>----- Original Message -----
> >>From: Hannes Tschofenig <[email-masked]>
> >>To: DOLLY, MARTIN C, ATTLABS; [email-masked]
> >><[email-masked]>; [email-masked] <[email-masked]>
> >>Cc: [email-masked] <[email-masked]>
> >>Sent: Sun Feb 08 04:32:25 2009
> >>Subject: RE: [Ecrit] Semantics  Re:  RPH
> >>
> >>Hi Martin,
> >>
> >>Your remarks are a bit a short.
> >>
> >>Clearly, authentication and authorization can come in
> >different forms.
> >>This was actually one of the discussion we had so far that the
> >>authorization mechanisms for the GETS RPH and the proposed
> >ECRIT RPH is
> >>different.
> >>
> >>So, could you elaborate a bit?
> >>
> >>Ciao
> >>Hannes
> >>
> >>>-----Original Message-----
> >>>From: [email-masked] [mailto:[email-masked]]
> >>On Behalf
> >>>Of DOLLY, MARTIN C, ATTLABS
> >>>Sent: 07 February, 2009 19:30
> >>>To: [email-masked]; [email-masked]
> >>>Cc: [email-masked]; [email-masked]
> >>>Subject: Re: [Ecrit] Semantics Re: RPH
> >>>
> >>>Do you have a clue dude? A+A of an user comes in many forms.
> >>>
> >>>----- Original Message -----
> >>>From: [email-masked] <[email-masked]>
> >>>To: Janet P Gunn <[email-masked]>
> >>>Cc: ECRIT <[email-masked]>; [email-masked]
> >>><[email-masked]>
> >>>Sent: Sat Feb 07 11:56:42 2009
> >>>Subject: Re: [Ecrit] Semantics  Re:  RPH
> >>>
> >>>Please see my earlier message as to why your approach fails
> >>for the UA-
> >>>inserted case where not all emergency calls have RPH
> >>markings. I think
> >>>it would be a really bad idea if emergency calls with RPH
> >are treated
> >>>differently than emergency calls without it. (Again, I'm
> >>talking about
> >>>the user-initiated calls. An ESNET can do whatever it wants and can
> >>>assign extra priority to calls from citizens that have bought PBA
> >>>stickers or zip codes that pay more taxes, but that's a separate
> >>>problem.)
> >>>
> >>>I also don't believe your implementation logic. A much better
> >>approach
> >>>is to semantically declare the class of call early on (e.g.,
> >based on
> >>>the URN or after authentication/authorization), and make
> >that part of
> >>>the call state record, rather than hunt for headers each time a
> >>>handling decision needs to be made. Given the authorization
> >>>requirements, just looking at "has header X" is never going to be
> >>>sufficient anyway.
> >>>
> >>>Henning
> >>>
> >>>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:
> >>>
> >>>>
> >>>>
> >>>> .
> >>>>
> >>>> [email-masked] wrote on 02/07/2009 03:14:57 AM:
> >>>>
> >>>> > PLEASE try to understand that the syntax is similar (header, new
> >>>> namespace,
> >>>> > new values)
> >>>> > BUT the semantic is different.
> >>>> >
> >>>> > For all message it is true that the sender can add whatever they
> >>>> want. The
> >>>> > big question is what does it mean for the recipient.
> >>>> >
> >>>> > This is what the discussion is about.
> >>>> >
> >>>> On the contrary, the semantic is, or at least can be, very similar.
> >>>>
> >>>> Consider the hypothetical, but plausible, case of a
> >network with an
> >>>> explicit call/capacity admission process, in which both 911-type-
> >>>> emergency calls and GETS calls get preferential admission
> >>>treatment.
> >>>> By the time the INVITE gets to this Functional Module/ block
> >>>of code,
> >>>> all authentication, authorization, and changes/
> >confirmation of the
> >>>> destination have already taken place.  All this block of
> >code deals
> >>>> with is call/capacity admission.
> >>>>
> >>>> For the sake of argument, suppose this is the nature of the
> >>>> preference.
> >>>>
> >>>> 1) For INVITEs without RPH, or with an RPH this network does
> >>>not use/
> >>>> understand, if the admission process fails, the INVITE fails
> >>>>
> >>>> 2) For INVITEs with RPH with the ets namespace, if the admission
> >>>> process initially fails, the INVITE is put in queue until the
> >>>> resources become available so it can be admitted.
> >>>>
> >>>> 3) For INVITEs with RPH with the esnet namespace, if the admission
> >>>> process initially fails, the INVITE is put in queue, but at lower
> >>>> priority than the calls with the ets namespace.
> >>>>
> >>>> With the esnet namespace, this block of code only needs to
> >>deal with
> >>>> the RPH in determining which INVITEs to reject, and which
> >to queue,
> >>>> and how.
> >>>>
> >>>> But if there is no esnet namespace for RPH, then this
> >block of code
> >>>> would need to deal with BOTH the RPH and the URN.  That would be a
> >>>> completely unnecessary complication.
> >>>>
> >>>> Janet
> >>>
> >>>_______________________________________________
> >>>Ecrit mailing list
> >>>[email-masked]
> >>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>_______________________________________________
> >>>Ecrit mailing list
> >>>[email-masked]
> >>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>
> >>
> >>
> >
> >
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

Date: Mon, 09 Feb 2009 11:52:03 -0600
To: "Hannes Tschofenig" <[email-masked]>, "'Janet P Gunn'" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

At 01:34 AM 2/9/2009, Hannes Tschofenig wrote:
>I could have guessed the response already.
>
>I believe that the draft would benefit from a few sentences that describes
>what "local policy" decisions the operator deploying this mechanism has to
>make.

how does that satisfy any, much less all operators' questions -- 
other than referring to the relative priority order section (8) - as 
well as other text contained within RFC 4412?

>Ciao
>Hannes
>
>________________________________
>
>         From: Janet P Gunn [mailto:[email-masked]]
>         Sent: 08 February, 2009 22:13
>         To: Hannes Tschofenig
>         Cc: [email-masked]; [email-masked]; 'DOLLY, MARTIN C, ATTLABS'
>         Subject: RE: [Ecrit] Semantics Re: RPH
>
>
>
>
>
>         Up to local policy.
>
>         Janet
>
>         "Hannes Tschofenig" <[email-masked]> wrote on 02/08/2009
>01:45:21 PM:
>
>         > Not sure what you mean.
>         >
>         > Let me ask you a basic question that we have been struggling with
>for some
>         > time in this discussion that Janet recently highlighted:
>         >
>         > How do you treat an esnet RPH marked 9-1-1 call in comparison to a
>9-1-1
>         > call that does not have the esnet RPH marking? In what sense does
>the
>         > processing in the SIP proxy differ?
>         >
>         > Ciao
>         > Hannes
>         >
>         > >-----Original Message-----
>         > >From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]]
>         > >Sent: 08 February, 2009 16:02
>         > >To: [email-masked]; [email-masked];
>[email-masked]
>         > >Cc: [email-masked]
>         > >Subject: Re: [Ecrit] Semantics Re: RPH
>         > >
>         > >These are the rule, not the exception. I do not care about the
>         > >internet free scenarios.
>         > >
>         > >----- Original Message -----
>         > >From: Hannes Tschofenig <[email-masked]>
>         > >To: DOLLY, MARTIN C, ATTLABS; [email-masked]
>         > ><[email-masked]>; [email-masked] <[email-masked]>
>         > >Cc: [email-masked] <[email-masked]>
>         > >Sent: Sun Feb 08 08:14:32 2009
>         > >Subject: RE: [Ecrit] Semantics  Re:  RPH
>         > >
>         > >Hi Martin,
>         > >
>         > >Thanks for the quick response.
>         > >
>         > >I am aware of these network access authentication and
>         > >authorization procedures (including the authentication and
>         > >authorization procedure at the SIP layer). They are clearly
>         > >important for some of the RPH usage scenarios.
>         > >
>         > >For this specific case (the new esnet RPH mechanism) there are
>         > >additional facets that needs to be considered (beyond the
>         > >above-mentioned security
>         > >aspects):
>         > >
>         > >* What does the esnet RPH usage mean in the context of an
>         > >emergency call (for example, in comparison to an emergency
>         > >call without esnet RPH usage)?
>         > >
>         > >* For emergency calls the authorization procedures are
>         > >different than with regular calls. There are certainly
>         > >differences to the GETS-alike calls as well. (We ignore for a
>         > >moment that there are these unauthenticated emergency calls
>         > >where even the authentication procedure is missing.) The
>         > >current security consideration section does not acknowledge
>         > >these differences.
>         > >
>         > >It would be helpful that
>draft-ietf-ecrit-local-emergency-rph-namespace
>         > >captures some of these aspects to allow those who implement
>         > >and deploy the esnet RPH mechanism to understand what it does
>         > >and how to correctly implement it.
>         > >
>         > >Ciao
>         > >Hannes
>         > >
>         > >PS: There are details that also need to be discussed. For
>         > >example, which esnet value would the device use for an
>         > >emergency call? "esnet.0", "esnet.1", "esnet.2", "esnet.3",
>         > >"esnet.4". Out-of-scope is a possible answer but it will not
>         > >help the implementer in doing it's job. Is there a specific
>         > >default value (maybe the highest value, just to be sure)?
>         > >Would the UA get provisioned to pick a specific value? What is
>         > >the provisioning mechanism? Is there a relationship between
>         > >the esnet values and the Service URN values? Do the
>         > >urn:service:counseling:* services get a lower priority
>         > >than the urn:service:sos:* services?
>         > >
>         > >>Hannes,
>         > >>
>         > >>We need to understand the attachment of the UE to the network.
>         > >>There is an AA process prior to allowing any use. Without
>         > >this we would
>         > >>not trust the RPH, even for ETS, never mind 911
>         > >>
>         > >>Martin
>         > >>
>         > >>----- Original Message -----
>         > >>From: Hannes Tschofenig <[email-masked]>
>         > >>To: DOLLY, MARTIN C, ATTLABS; [email-masked]
>         > >><[email-masked]>; [email-masked] <[email-masked]>
>         > >>Cc: [email-masked] <[email-masked]>
>         > >>Sent: Sun Feb 08 04:32:25 2009
>         > >>Subject: RE: [Ecrit] Semantics  Re:  RPH
>         > >>
>         > >>Hi Martin,
>         > >>
>         > >>Your remarks are a bit a short.
>         > >>
>         > >>Clearly, authentication and authorization can come in
>         > >different forms.
>         > >>This was actually one of the discussion we had so far that the
>         > >>authorization mechanisms for the GETS RPH and the proposed
>         > >ECRIT RPH is
>         > >>different.
>         > >>
>         > >>So, could you elaborate a bit?
>         > >>
>         > >>Ciao
>         > >>Hannes
>         > >>
>         > >>>-----Original Message-----
>         > >>>From: [email-masked] [mailto:[email-masked]]
>         > >>On Behalf
>         > >>>Of DOLLY, MARTIN C, ATTLABS
>         > >>>Sent: 07 February, 2009 19:30
>         > >>>To: [email-masked]; [email-masked]
>         > >>>Cc: [email-masked]; [email-masked]
>         > >>>Subject: Re: [Ecrit] Semantics Re: RPH
>         > >>>
>         > >>>Do you have a clue dude? A+A of an user comes in many forms.
>         > >>>
>         > >>>----- Original Message -----
>         > >>>From: [email-masked] <[email-masked]>
>         > >>>To: Janet P Gunn <[email-masked]>
>         > >>>Cc: ECRIT <[email-masked]>; [email-masked]
>         > >>><[email-masked]>
>         > >>>Sent: Sat Feb 07 11:56:42 2009
>         > >>>Subject: Re: [Ecrit] Semantics  Re:  RPH
>         > >>>
>         > >>>Please see my earlier message as to why your approach fails
>         > >>for the UA-
>         > >>>inserted case where not all emergency calls have RPH
>         > >>markings. I think
>         > >>>it would be a really bad idea if emergency calls with RPH
>         > >are treated
>         > >>>differently than emergency calls without it. (Again, I'm
>         > >>talking about
>         > >>>the user-initiated calls. An ESNET can do whatever it wants and
>can
>         > >>>assign extra priority to calls from citizens that have bought
>PBA
>         > >>>stickers or zip codes that pay more taxes, but that's a
>separate
>         > >>>problem.)
>         > >>>
>         > >>>I also don't believe your implementation logic. A much better
>         > >>approach
>         > >>>is to semantically declare the class of call early on (e.g.,
>         > >based on
>         > >>>the URN or after authentication/authorization), and make
>         > >that part of
>         > >>>the call state record, rather than hunt for headers each time a
>
>         > >>>handling decision needs to be made. Given the authorization
>         > >>>requirements, just looking at "has header X" is never going to
>be
>         > >>>sufficient anyway.
>         > >>>
>         > >>>Henning
>         > >>>
>         > >>>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:
>         > >>>
>         > >>>>
>         > >>>>
>         > >>>> .
>         > >>>>
>         > >>>> [email-masked] wrote on 02/07/2009 03:14:57 AM:
>         > >>>>
>         > >>>> > PLEASE try to understand that the syntax is similar
>(header, new
>         > >>>> namespace,
>         > >>>> > new values)
>         > >>>> > BUT the semantic is different.
>         > >>>> >
>         > >>>> > For all message it is true that the sender can add whatever
>they
>         > >>>> want. The
>         > >>>> > big question is what does it mean for the recipient.
>         > >>>> >
>         > >>>> > This is what the discussion is about.
>         > >>>> >
>         > >>>> On the contrary, the semantic is, or at least can be, very
>similar.
>         > >>>>
>         > >>>> Consider the hypothetical, but plausible, case of a
>         > >network with an
>         > >>>> explicit call/capacity admission process, in which both
>911-type-
>         > >>>> emergency calls and GETS calls get preferential admission
>         > >>>treatment.
>         > >>>> By the time the INVITE gets to this Functional Module/ block
>         > >>>of code,
>         > >>>> all authentication, authorization, and changes/
>         > >confirmation of the
>         > >>>> destination have already taken place.  All this block of
>         > >code deals
>         > >>>> with is call/capacity admission.
>         > >>>>
>         > >>>> For the sake of argument, suppose this is the nature of the
>         > >>>> preference.
>         > >>>>
>         > >>>> 1) For INVITEs without RPH, or with an RPH this network does
>         > >>>not use/
>         > >>>> understand, if the admission process fails, the INVITE fails
>         > >>>>
>         > >>>> 2) For INVITEs with RPH with the ets namespace, if the
>admission
>         > >>>> process initially fails, the INVITE is put in queue until the
>
>         > >>>> resources become available so it can be admitted.
>         > >>>>
>         > >>>> 3) For INVITEs with RPH with the esnet namespace, if the
>admission
>         > >>>> process initially fails, the INVITE is put in queue, but at
>lower
>         > >>>> priority than the calls with the ets namespace.
>         > >>>>
>         > >>>> With the esnet namespace, this block of code only needs to
>         > >>deal with
>         > >>>> the RPH in determining which INVITEs to reject, and which
>         > >to queue,
>         > >>>> and how.
>         > >>>>
>         > >>>> But if there is no esnet namespace for RPH, then this
>         > >block of code
>         > >>>> would need to deal with BOTH the RPH and the URN.  That would
>be a
>         > >>>> completely unnecessary complication.
>         > >>>>
>         > >>>> Janet
>         > >>>
>         > >>>_______________________________________________
>         > >>>Ecrit mailing list
>         > >>>[email-masked]
>         > >>>https://www.ietf.org/mailman/listinfo/ecrit
>         > >>>_______________________________________________
>         > >>>Ecrit mailing list
>         > >>>[email-masked]
>         > >>>https://www.ietf.org/mailman/listinfo/ecrit
>         > >>>
>         > >>
>         > >>
>         > >
>         > >
>         >
>
>
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

From: "Hannes Tschofenig" <[email-masked]>
To: "'James M. Polk'" <[email-masked]>, "'Janet P Gunn'" <[email-masked]>
Date: Mon, 9 Feb 2009 19:48:56 +0200
Cc: 'ECRIT' <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

>>[hannes] You talk about rejecting the INVITE: Emergency calls do not 
>>get rejected regardless of the RPH marking.
>
>this statement is assuming all emergency calls do in fact get through
>-- and that is simply not the case today, so what basis are 
>you making this argument from?
>

I would always mark my emergency calls with the highest priority (currently
"esnet.4") since they are really important to me (hopefully the software
marks without asking me as a caller in stress). If they still don't get
through then the marking was not of much help either. 

Maybe we need more priority levels. We could serve the highest values just
for us :-)
(This is a joke!)

Seriously, you need to explain how RPH marking would help against rejected
emergency calls. 

Date: Mon, 09 Feb 2009 12:06:14 -0600
To: Ted Hardie <[email-masked]>, Hannes Tschofenig <[email-masked]>, "'DOLLY, MARTIN C,  ATTLABS'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ecrit] RPH

Ted -- comments at the bottom

At 11:03 AM 2/9/2009, Ted Hardie wrote:
>Howdy,
>         After reading through the discussion through Monday morning
>and seeing a remarkable lack of convergence, I began wondering if
>the core of the issue isn't way back here:
>
>James Polk wrote:
> >Along comes a new ID that defines a new RP namespaces in SIP for
> >ECRIT, called "esnet".
> >
> >This new namespace is needed because the 5 header-values defined in
> >RFC 4412 do not match the usage for the ECRIT effort, therefore a new
> >one needs to be created.
> >
> >RFCV 4412 is not tied to GETS and MLPP, it is tied to the creation of
> >the idea of "RESOURCE-PRIORITY" in SIP, *and* - it happens to create
> >5 IANA registered namespaces (and associated priority-values).
>
>
>If the new RP namespace in SIP is only for ESNET, defining a header for it
>and describing what to do is both relatively trivial and, I would argue,
>pretty well understood.  ESNET can be understood for this purpose as
>a closed network or a relatively tightly bound overlay.  Defining the
>semantics for what happens in that network/for that overlay is clearly
>only up to those operating that network.  The rest of us can ignore it,
>as the spec allows.
>
>Where we seem to have wrapped ourselves around the axles is whether
>this namespace is for *uses of ECRIT* rather than *ESNET nodes*.  If
>it is for any use of ECRIT, then the semantics get a lot fuzzier (since there
>may be other mechanisms at play) and the apparent intention seems to
>be that every node that cares about ECRIT must understand ESNET markings.
>When I go back and look at draft-ietf-ecrit-local-emergency-rph-namespace-00,
>this text seems a major part of that:
>
>   This new namespace can be from a caller in
>    distress, or added at the entry server into an emergency services
>    managed network, towards a public safety answering point (PSAP),
>    i.e., the 911 or 112-based emergency services call taker.  This
>    new namespace can be used between PSAPs, and between a PSAP and
>    first responders and their organizations.
>
>As a way forward, I suggest we separate out the PSAP--first 
>responder/organizations
>use case and define only a namespace for that.  If we need a second namespace
>for caller insertion/entry server insertion, we can create 
>that.  Strings are cheap.
>But there seems to be a long road ahead in combining the two, since the kinds
>of devices that have to care and the kinds of networks they may have 
>to traverse
>seem different enough to hinder early consensus.

While I generally agree with you -- until you imply that the two 
namespaces ought go be in separate docs that have to meet somewhere 
future somewhere in the middle of the network.

         Please let me know if I've misread what you meant to say.

On this, I have two thoughts:

#1 - that several vendors and SPs have already asked for this 
namespace to be possible in their respective VSP products and service 
offerings - and your implied solution blows that up.

and

#2 - that creating (in the future) a second namespace to map directly 
to the esnet (and it's 5 priority-values) from the UAC or VSP seems 
like it might be begging for a lack of interoperability waiting to 
happen type of problem.

I can definitely rewrite the text emphasizing the esnet namespace is 
for the ESInet first, with the possibility of having it come in from 
a reliable VSP, and even a reliable UAC/UE off that reliable VSP.

>                         regards,
>                                 Ted Hardie

From: "Hannes Tschofenig" <[email-masked]>
To: "'James M. Polk'" <[email-masked]>, "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 9 Feb 2009 20:08:01 +0200
Cc: [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

>>It would be helpful that 
>draft-ietf-ecrit-local-emergency-rph-namespace
>>captures some of these aspects to allow those who implement 
>and deploy 
>>the esnet RPH mechanism to understand what it does and how to 
>correctly 
>>implement it.
>
>I wholly disagree with this desire. This 
>draft-ietf-ecrit-local-emergency-rph-namespace creates the 
>namespace, it does not create the associated semantics for use 
>of this namespace that are specific to NENA or EENA. That is 
>up to NENA or EENA to specify.  It is also up to the AT&T's 
>and Verizon's of the world to define what the exact semantics 
>are within their respective networks are to satisfy whatever 
>regulations they have in their local jurisdictions (which are 
>different from each other -- and what the IETF knows nothing about).
>
>For example, each group of emergency callers thinks *their* 
>type of emergency should get preferential treatment over other 
>types of emergencies. To be specific, which type of emergency 
>call is more
>important: a GETS type call or a 911/112 type call?

I agree that this is a policy decision (as long as my emergency call with an
inappropriate marking does not get dropped). 

What I was asking for is to describe the difference in authorization
handling. 

>
>It is not up to the IETF to decide that. It is up to the local 
>policies of the jurisdiction and the SP to figure that out. 
>This is not inconsistent with RFC 4412 - in fact, RFC 4412 
>built this aspect into its text.
>
>The esnet namespace should follow RFC 4412's guidelines in 
>coordination with those from the local authorities and the 
>local SPs to determine how they are going to configure their 
>operations.  At that point, it's up to the local SP to buy 
>products from vendors that can meet the requirements of that 
>local configuration.

This does not work when you have end points doing this stuff since these end
devices can be used everywhere. 

An operator can for sure decide to buy a box that does fancy marking
techniques and offers different ways to configure the box todo so. No doubt.

>
>Therefore, draft-ietf-ecrit-local-emergency-rph-namespace 
>should not have any additional text articulating guidance how 
>to configure their networks. RFC 4412 defines all the guidance 
>they need at this time.
>
>When operational experience proves something ought to be 
>modified within that guidance, then a new doc should be 
>written suggesting that/those modification(s).

When I wrote, for example, the following sentence: 

  #* What does the esnet RPH usage mean in the context of an emergency 
  #call (for example, in comparison to an emergency call without esnet RPH
usage)?

I was hoping that someone would think about the possible "local policy
settings" that could make sense. 

If an emergency call with the esnet RPH marking gets treated better than an
emergency call without such a marking then someone might come up with the
idea of marking every emergency call with the highest priority. If everyone
does this then the purpose of the priority system is lost. 

Treating an emergency call with an esnet RPH marking worse than one without
it wouldn't make a lot of sense since otherwise nobody would do the marking
anymore. 

Treating an emergency call with an esnet RPH marking in the same fashion as
other emergency calls would defeat the purpose of the additional marking. 

The above-mentioned cases assume that the SIP UA vendor (or someone else
configuring the marking) knows the local policy at the VSP. If it is not
known at all and all the above cases are equally likely then it does not
make sense to mark the call. 

Not so trivial to come up with something useful.

Ciao
Hannes

>>Ciao
>>Hannes
>>
>>PS: There are details that also need to be discussed. For example, 
>>which esnet value would the device use for an emergency call? 
>>"esnet.0", "esnet.1", "esnet.2", "esnet.3", "esnet.4". 
>Out-of-scope is 
>>a possible answer but it will not help the implementer in 
>doing it's job.
>
>see the very same explanation above as to why this isn't 
>something that ought be in an IETF doc.
>
>>Is there a
>>specific default value (maybe the highest value, just to be sure)?
>
>there is not, and choosing one the highest or lowest value 
>limits adjustments and the "what if we determine one day 
>something else is actually more important" question.
>
>>Would the UA get provisioned to pick a specific value?
>
>if this were in scope of this doc, I'd suggest this be done 
>through something like RFC 3841 "SIP Call Preferences"
>
>>What is the provisioning mechanism?
>
>this depends on the choice, but Caller Prefs has a mechanism.
>
>>Is there a relationship between the esnet values and the 
>Service URN values?
>
>should there be?
>
>I don't know, and think this is a local (matrix) matter -- or 
>a NENA/EENA matter
>
>>Do the urn:service:counseling:* services get a lower priority 
>than the 
>>urn:service:sos:* services?
>
>only if local policy gives urn:service:counseling:* any 
>priority, then local policy will determine what priority in 
>relation to sos.
>
>Remember - some of these decisions will be based on the 
>capacity (BW and # of call takers) within the local 
>jurisdiction -- which is again something the IETF cannot give 
>guidance on at this point , if ever
>
>
>> >Hannes,
>> >
>> >We need to understand the attachment of the UE to the network.
>> >There is an AA process prior to allowing any use. Without this we 
>> >would not trust the RPH, even for ETS, never mind 911
>> >
>> >Martin
>> >
>> >----- Original Message -----
>> >From: Hannes Tschofenig <[email-masked]>
>> >To: DOLLY, MARTIN C, ATTLABS; [email-masked] 
>> ><[email-masked]>; [email-masked] <[email-masked]>
>> >Cc: [email-masked] <[email-masked]>
>> >Sent: Sun Feb 08 04:32:25 2009
>> >Subject: RE: [Ecrit] Semantics  Re:  RPH
>> >
>> >Hi Martin,
>> >
>> >Your remarks are a bit a short.
>> >
>> >Clearly, authentication and authorization can come in 
>different forms.
>> >This was actually one of the discussion we had so far that the 
>> >authorization mechanisms for the GETS RPH and the proposed 
>ECRIT RPH 
>> >is different.
>> >
>> >So, could you elaborate a bit?
>> >
>> >Ciao
>> >Hannes
>> >
>> >>-----Original Message-----
>> >>From: [email-masked] [mailto:[email-masked]]
>> >On Behalf
>> >>Of DOLLY, MARTIN C, ATTLABS
>> >>Sent: 07 February, 2009 19:30
>> >>To: [email-masked]; [email-masked]
>> >>Cc: [email-masked]; [email-masked]
>> >>Subject: Re: [Ecrit] Semantics Re: RPH
>> >>
>> >>Do you have a clue dude? A+A of an user comes in many forms.
>> >>
>> >>----- Original Message -----
>> >>From: [email-masked] <[email-masked]>
>> >>To: Janet P Gunn <[email-masked]>
>> >>Cc: ECRIT <[email-masked]>; [email-masked] 
>> >><[email-masked]>
>> >>Sent: Sat Feb 07 11:56:42 2009
>> >>Subject: Re: [Ecrit] Semantics  Re:  RPH
>> >>
>> >>Please see my earlier message as to why your approach fails
>> >for the UA-
>> >>inserted case where not all emergency calls have RPH
>> >markings. I think
>> >>it would be a really bad idea if emergency calls with RPH are 
>> >>treated differently than emergency calls without it. (Again, I'm
>> >talking about
>> >>the user-initiated calls. An ESNET can do whatever it 
>wants and can 
>> >>assign extra priority to calls from citizens that have bought PBA 
>> >>stickers or zip codes that pay more taxes, but that's a separate
>> >>problem.)
>> >>
>> >>I also don't believe your implementation logic. A much better
>> >approach
>> >>is to semantically declare the class of call early on (e.g., based 
>> >>on the URN or after authentication/authorization), and make that 
>> >>part of the call state record, rather than hunt for headers each 
>> >>time a handling decision needs to be made. Given the authorization 
>> >>requirements, just looking at "has header X" is never going to be 
>> >>sufficient anyway.
>> >>
>> >>Henning
>> >>
>> >>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:
>> >>
>> >>>
>> >>>
>> >>> .
>> >>>
>> >>> [email-masked] wrote on 02/07/2009 03:14:57 AM:
>> >>>
>> >>> > PLEASE try to understand that the syntax is similar 
>(header, new
>> >>> namespace,
>> >>> > new values)
>> >>> > BUT the semantic is different.
>> >>> >
>> >>> > For all message it is true that the sender can add 
>whatever they
>> >>> want. The
>> >>> > big question is what does it mean for the recipient.
>> >>> >
>> >>> > This is what the discussion is about.
>> >>> >
>> >>> On the contrary, the semantic is, or at least can be, 
>very similar.
>> >>>
>> >>> Consider the hypothetical, but plausible, case of a network with 
>> >>> an explicit call/capacity admission process, in which both 
>> >>> 911-type- emergency calls and GETS calls get preferential 
>> >>> admission
>> >>treatment.
>> >>> By the time the INVITE gets to this Functional Module/ block
>> >>of code,
>> >>> all authentication, authorization, and changes/ confirmation of 
>> >>> the destination have already taken place.  All this 
>block of code 
>> >>> deals with is call/capacity admission.
>> >>>
>> >>> For the sake of argument, suppose this is the nature of the 
>> >>> preference.
>> >>>
>> >>> 1) For INVITEs without RPH, or with an RPH this network does
>> >>not use/
>> >>> understand, if the admission process fails, the INVITE fails
>> >>>
>> >>> 2) For INVITEs with RPH with the ets namespace, if the admission 
>> >>> process initially fails, the INVITE is put in queue until the 
>> >>> resources become available so it can be admitted.
>> >>>
>> >>> 3) For INVITEs with RPH with the esnet namespace, if the 
>admission 
>> >>> process initially fails, the INVITE is put in queue, but 
>at lower 
>> >>> priority than the calls with the ets namespace.
>> >>>
>> >>> With the esnet namespace, this block of code only needs to
>> >deal with
>> >>> the RPH in determining which INVITEs to reject, and which to 
>> >>> queue, and how.
>> >>>
>> >>> But if there is no esnet namespace for RPH, then this block of 
>> >>> code would need to deal with BOTH the RPH and the URN.  
>That would 
>> >>> be a completely unnecessary complication.
>> >>>
>> >>> Janet
>> >>
>> >>_______________________________________________
>> >>Ecrit mailing list
>> >>[email-masked]
>> >>https://www.ietf.org/mailman/listinfo/ecrit
>> >>_______________________________________________
>> >>Ecrit mailing list
>> >>[email-masked]
>> >>https://www.ietf.org/mailman/listinfo/ecrit
>> >>
>> >
>> >
>>
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/ecrit
>

Date: Mon, 09 Feb 2009 12:17:51 -0600
To: "Hannes Tschofenig" <[email-masked]>, "'Ted Hardie'" <[email-masked]>, "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, <[email-masked]>,  <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] RPH

At 11:36 AM 2/9/2009, Hannes Tschofenig wrote:
>You captured the discussion quite well.
>
>Separating out the PSAP--first responder/organizations use case and define
>only a namespace for that sounds good to me and would reflect what James had
>agreed to a while ago.

When I agree to it, several folks asked me not to limit this 
namespace's usage to just within the ESInet -- and that's why it 
remains a possibility in the VSP (though not a SHOULD or a MUST 
implement, but a "can"), and whatever UAC/UE the VSP wants to vouch for.

>Ciao
>Hannes
>
> >-----Original Message-----
> >From: Ted Hardie [mailto:[email-masked]]
> >Sent: 09 February, 2009 19:04
> >To: James M. Polk; Hannes Tschofenig; 'DOLLY, MARTIN C,
> >ATTLABS'; [email-masked]; [email-masked]
> >Cc: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
> >Subject: Re: [Ecrit] RPH
> >
> >Howdy,
> >       After reading through the discussion through Monday
> >morning and seeing a remarkable lack of convergence, I began
> >wondering if the core of the issue isn't way back here:
> >
> >James Polk wrote:
> >>Along comes a new ID that defines a new RP namespaces in SIP
> >for ECRIT,
> >>called "esnet".
> >>
> >>This new namespace is needed because the 5 header-values
> >defined in RFC
> >>4412 do not match the usage for the ECRIT effort, therefore a new one
> >>needs to be created.
> >>
> >>RFCV 4412 is not tied to GETS and MLPP, it is tied to the creation of
> >>the idea of "RESOURCE-PRIORITY" in SIP, *and* - it happens to create
> >>5 IANA registered namespaces (and associated priority-values).
> >
> >
> >If the new RP namespace in SIP is only for ESNET, defining a
> >header for it and describing what to do is both relatively
> >trivial and, I would argue, pretty well understood.  ESNET can
> >be understood for this purpose as a closed network or a
> >relatively tightly bound overlay.  Defining the semantics for
> >what happens in that network/for that overlay is clearly only
> >up to those operating that network.  The rest of us can ignore
> >it, as the spec allows.
> >
> >Where we seem to have wrapped ourselves around the axles is
> >whether this namespace is for *uses of ECRIT* rather than
> >*ESNET nodes*.  If it is for any use of ECRIT, then the
> >semantics get a lot fuzzier (since there may be other
> >mechanisms at play) and the apparent intention seems to be
> >that every node that cares about ECRIT must understand ESNET markings.
> >When I go back and look at
> >draft-ietf-ecrit-local-emergency-rph-namespace-00,
> >this text seems a major part of that:
> >
> >  This new namespace can be from a caller in
> >   distress, or added at the entry server into an emergency services
> >   managed network, towards a public safety answering point (PSAP),
> >   i.e., the 911 or 112-based emergency services call taker.  This
> >   new namespace can be used between PSAPs, and between a PSAP and
> >   first responders and their organizations.
> >
> >As a way forward, I suggest we separate out the PSAP--first
> >responder/organizations use case and define only a namespace
> >for that.  If we need a second namespace for caller
> >insertion/entry server insertion, we can create that.  Strings
> >are cheap.
> >But there seems to be a long road ahead in combining the two,
> >since the kinds of devices that have to care and the kinds of
> >networks they may have to traverse seem different enough to
> >hinder early consensus.
> >
> >                       regards,
> >                               Ted Hardie
> >

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: "James M. Polk" <[email-masked]>, Hannes Tschofenig <[email-masked]>, "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 9 Feb 2009 19:23:21 +0100
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Ecrit] Semantics  Re:  RPH

Concur with James.

Keith=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> On Behalf Of James M. Polk
> Sent: Monday, February 09, 2009 5:41 PM
> To: Hannes Tschofenig; 'DOLLY, MARTIN C, ATTLABS';=20
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Ecrit] Semantics Re: RPH
>=20
> At 07:14 AM 2/8/2009, Hannes Tschofenig wrote:
> >Hi Martin,
> >
> >Thanks for the quick response.
> >
> >I am aware of these network access authentication and authorization=20
> >procedures (including the authentication and authorization=20
> procedure at=20
> >the SIP layer). They are clearly important for some of the=20
> RPH usage scenarios.
> >
> >For this specific case (the new esnet RPH mechanism) there are=20
> >additional facets that needs to be considered (beyond the=20
> >above-mentioned security
> >aspects):
> >
> >* What does the esnet RPH usage mean in the context of an emergency=20
> >call (for example, in comparison to an emergency call=20
> without esnet RPH usage)?
> >
> >* For emergency calls the authorization procedures are=20
> different than=20
> >with regular calls. There are certainly differences to the=20
> GETS-alike=20
> >calls as well. (We ignore for a moment that there are these=20
> >unauthenticated emergency calls where even the=20
> authentication procedure=20
> >is missing.) The current security consideration section does=20
> not acknowledge these differences.
> >
> >It would be helpful that=20
> draft-ietf-ecrit-local-emergency-rph-namespace
> >captures some of these aspects to allow those who implement=20
> and deploy=20
> >the esnet RPH mechanism to understand what it does and how=20
> to correctly=20
> >implement it.
>=20
> I wholly disagree with this desire. This=20
> draft-ietf-ecrit-local-emergency-rph-namespace creates the=20
> namespace, it does not create the associated semantics for=20
> use of this namespace that are specific to NENA or EENA. That=20
> is up to NENA or EENA to specify.  It is also up to the=20
> AT&T's and Verizon's of the world to define what the exact=20
> semantics are within their respective networks are to satisfy=20
> whatever regulations they have in their local jurisdictions=20
> (which are different from each other -- and what the IETF=20
> knows nothing about).
>=20
> For example, each group of emergency callers thinks *their*=20
> type of emergency should get preferential treatment over=20
> other types of emergencies. To be specific, which type of=20
> emergency call is more
> important: a GETS type call or a 911/112 type call?
>=20
> It is not up to the IETF to decide that. It is up to the=20
> local policies of the jurisdiction and the SP to figure that=20
> out. This is not inconsistent with RFC 4412 - in fact, RFC=20
> 4412 built this aspect into its text.
>=20
> The esnet namespace should follow RFC 4412's guidelines in=20
> coordination with those from the local authorities and the=20
> local SPs to determine how they are going to configure their=20
> operations.  At that point, it's up to the local SP to buy=20
> products from vendors that can meet the requirements of that=20
> local configuration.
>=20
> Therefore, draft-ietf-ecrit-local-emergency-rph-namespace=20
> should not have any additional text articulating guidance how=20
> to configure their networks. RFC 4412 defines all the=20
> guidance they need at this time.
>=20
> When operational experience proves something ought to be=20
> modified within that guidance, then a new doc should be=20
> written suggesting that/those modification(s).
>=20
>=20
> >Ciao
> >Hannes
> >
> >PS: There are details that also need to be discussed. For example,=20
> >which esnet value would the device use for an emergency call?=20
> >"esnet.0", "esnet.1", "esnet.2", "esnet.3", "esnet.4".=20
> Out-of-scope is=20
> >a possible answer but it will not help the implementer in=20
> doing it's job.
>=20
> see the very same explanation above as to why this isn't=20
> something that ought be in an IETF doc.
>=20
> >Is there a
> >specific default value (maybe the highest value, just to be sure)?
>=20
> there is not, and choosing one the highest or lowest value=20
> limits adjustments and the "what if we determine one day=20
> something else is actually more important" question.
>=20
> >Would the UA get provisioned to pick a specific value?
>=20
> if this were in scope of this doc, I'd suggest this be done=20
> through something like RFC 3841 "SIP Call Preferences"
>=20
> >What is the provisioning mechanism?
>=20
> this depends on the choice, but Caller Prefs has a mechanism.
>=20
> >Is there a relationship between the esnet values and the=20
> Service URN values?
>=20
> should there be?
>=20
> I don't know, and think this is a local (matrix) matter -- or=20
> a NENA/EENA matter
>=20
> >Do the urn:service:counseling:* services get a lower=20
> priority than the=20
> >urn:service:sos:* services?
>=20
> only if local policy gives urn:service:counseling:* any=20
> priority, then local policy will determine what priority in=20
> relation to sos.
>=20
> Remember - some of these decisions will be based on the=20
> capacity (BW and # of call takers) within the local=20
> jurisdiction -- which is again something the IETF cannot give=20
> guidance on at this point , if ever
>=20
>=20
> > >Hannes,
> > >
> > >We need to understand the attachment of the UE to the network.
> > >There is an AA process prior to allowing any use. Without this we=20
> > >would not trust the RPH, even for ETS, never mind 911
> > >
> > >Martin
> > >
> > >----- Original Message -----
> > >From: Hannes Tschofenig <[email-masked]>
> > >To: DOLLY, MARTIN C, ATTLABS; [email-masked]=20
> > ><[email-masked]>; [email-masked] <[email-masked]>
> > >Cc: [email-masked] <[email-masked]>
> > >Sent: Sun Feb 08 04:32:25 2009
> > >Subject: RE: [Ecrit] Semantics  Re:  RPH
> > >
> > >Hi Martin,
> > >
> > >Your remarks are a bit a short.
> > >
> > >Clearly, authentication and authorization can come in=20
> different forms.
> > >This was actually one of the discussion we had so far that the=20
> > >authorization mechanisms for the GETS RPH and the proposed=20
> ECRIT RPH=20
> > >is different.
> > >
> > >So, could you elaborate a bit?
> > >
> > >Ciao
> > >Hannes
> > >
> > >>-----Original Message-----
> > >>From: [email-masked] [mailto:[email-masked]]
> > >On Behalf
> > >>Of DOLLY, MARTIN C, ATTLABS
> > >>Sent: 07 February, 2009 19:30
> > >>To: [email-masked]; [email-masked]
> > >>Cc: [email-masked]; [email-masked]
> > >>Subject: Re: [Ecrit] Semantics Re: RPH
> > >>
> > >>Do you have a clue dude? A+A of an user comes in many forms.
> > >>
> > >>----- Original Message -----
> > >>From: [email-masked] <[email-masked]>
> > >>To: Janet P Gunn <[email-masked]>
> > >>Cc: ECRIT <[email-masked]>; [email-masked]=20
> > >><[email-masked]>
> > >>Sent: Sat Feb 07 11:56:42 2009
> > >>Subject: Re: [Ecrit] Semantics  Re:  RPH
> > >>
> > >>Please see my earlier message as to why your approach fails
> > >for the UA-
> > >>inserted case where not all emergency calls have RPH
> > >markings. I think
> > >>it would be a really bad idea if emergency calls with RPH are=20
> > >>treated differently than emergency calls without it. (Again, I'm
> > >talking about
> > >>the user-initiated calls. An ESNET can do whatever it=20
> wants and can=20
> > >>assign extra priority to calls from citizens that have bought PBA=20
> > >>stickers or zip codes that pay more taxes, but that's a separate
> > >>problem.)
> > >>
> > >>I also don't believe your implementation logic. A much better
> > >approach
> > >>is to semantically declare the class of call early on=20
> (e.g., based=20
> > >>on the URN or after authentication/authorization), and make that=20
> > >>part of the call state record, rather than hunt for headers each=20
> > >>time a handling decision needs to be made. Given the=20
> authorization=20
> > >>requirements, just looking at "has header X" is never going to be=20
> > >>sufficient anyway.
> > >>
> > >>Henning
> > >>
> > >>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:
> > >>
> > >>>
> > >>>
> > >>> .
> > >>>
> > >>> [email-masked] wrote on 02/07/2009 03:14:57 AM:
> > >>>
> > >>> > PLEASE try to understand that the syntax is similar=20
> (header, new
> > >>> namespace,
> > >>> > new values)
> > >>> > BUT the semantic is different.
> > >>> >
> > >>> > For all message it is true that the sender can add=20
> whatever they
> > >>> want. The
> > >>> > big question is what does it mean for the recipient.
> > >>> >
> > >>> > This is what the discussion is about.
> > >>> >
> > >>> On the contrary, the semantic is, or at least can be,=20
> very similar.
> > >>>
> > >>> Consider the hypothetical, but plausible, case of a=20
> network with=20
> > >>> an explicit call/capacity admission process, in which both=20
> > >>> 911-type- emergency calls and GETS calls get preferential=20
> > >>> admission
> > >>treatment.
> > >>> By the time the INVITE gets to this Functional Module/ block
> > >>of code,
> > >>> all authentication, authorization, and changes/ confirmation of=20
> > >>> the destination have already taken place.  All this=20
> block of code=20
> > >>> deals with is call/capacity admission.
> > >>>
> > >>> For the sake of argument, suppose this is the nature of the=20
> > >>> preference.
> > >>>
> > >>> 1) For INVITEs without RPH, or with an RPH this network does
> > >>not use/
> > >>> understand, if the admission process fails, the INVITE fails
> > >>>
> > >>> 2) For INVITEs with RPH with the ets namespace, if the=20
> admission=20
> > >>> process initially fails, the INVITE is put in queue until the=20
> > >>> resources become available so it can be admitted.
> > >>>
> > >>> 3) For INVITEs with RPH with the esnet namespace, if=20
> the admission=20
> > >>> process initially fails, the INVITE is put in queue,=20
> but at lower=20
> > >>> priority than the calls with the ets namespace.
> > >>>
> > >>> With the esnet namespace, this block of code only needs to
> > >deal with
> > >>> the RPH in determining which INVITEs to reject, and which to=20
> > >>> queue, and how.
> > >>>
> > >>> But if there is no esnet namespace for RPH, then this block of=20
> > >>> code would need to deal with BOTH the RPH and the URN. =20
> That would=20
> > >>> be a completely unnecessary complication.
> > >>>
> > >>> Janet
> > >>
> > >>_______________________________________________
> > >>Ecrit mailing list
> > >>[email-masked]
> > >>https://www.ietf.org/mailman/listinfo/ecrit
> > >>_______________________________________________
> > >>Ecrit mailing list
> > >>[email-masked]
> > >>https://www.ietf.org/mailman/listinfo/ecrit
> > >>
> > >
> > >
> >
> >_______________________________________________
> >Ecrit mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/ecrit
>=20
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
> =

From: Henning Schulzrinne <[email-masked]>
To: "James M. Polk" <[email-masked]>
Date: Mon, 9 Feb 2009 13:28:26 -0500
Cc: ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

And for all the reasons that Hannes keeps pointing out and that nobody  
else seems to be addressing, this remains a fundamentally bad idea for  
customer-to-ESNET calls. I look forward to serving as expert witness  
during the class action trial when a provider has to explain why their  
customers got better emergency service since they somehow included the  
right magic token that was only given to "privileged" VSPs and ISPs.

On a more prosaic level: The last thing we need in SIP is more user  
agent configuration that adds exactly zero value and adds more failure  
scenarios. ("Oops, forgot to configure that option - now your  
emergency calls get treated like calls for pizza delivery.") We don't  
want NENA-specific phones - a standards-compliant phone needs to work  
out of the box, literally, anywhere in the world and get the same  
emergency call treatment as other such phones.

Beyond vague allusions to catch-all terms like "local policy" or  
"could be useful", nobody has answered Hannes' question as to *why*  
somebody would treat a customer-originated emergency call with RPH  
differently than one without and why this would be a good idea if one  
did. If they are always treated the same, it's just needless  
complexity and an additional failure mode.

Given the damage this can do in customer-originated calls, this is not  
just a harmless "why not" idea, it is a seriously bad idea.

In general, in the IETF, including a protocol feature requires a  
convincing functional argument. It is not up to the detractors to  
convince the proponents of a solution that it is useless, but the  
other way around.

Henning

On Feb 9, 2009, at 1:17 PM, James M. Polk wrote:

> At 11:36 AM 2/9/2009, Hannes Tschofenig wrote:
>> You captured the discussion quite well.
>>
>> Separating out the PSAP--first responder/organizations use case and  
>> define
>> only a namespace for that sounds good to me and would reflect what  
>> James had
>> agreed to a while ago.
>
> When I agree to it, several folks asked me not to limit this  
> namespace's usage to just within the ESInet -- and that's why it  
> remains a possibility in the VSP (though not a SHOULD or a MUST  
> implement, but a "can"), and whatever UAC/UE the VSP wants to vouch  
> for.
>

From: Henning Schulzrinne <[email-masked]>
To: Ted Hardie <[email-masked]>
Date: Mon, 9 Feb 2009 13:31:36 -0500
Cc: ECRIT <[email-masked]>
Subject: Re: [Ecrit] RPH

I agree with Ted on the first part. We can then discuss whether the  
second part is really helpful.

> As a way forward, I suggest we separate out the PSAP--first  
> responder/organizations
> use case and define only a namespace for that.  If we need a second  
> namespace
> for caller insertion/entry server insertion, we can create that.   
> Strings are cheap.
> But there seems to be a long road ahead in combining the two, since  
> the kinds
> of devices that have to care and the kinds of networks they may have  
> to traverse
> seem different enough to hinder early consensus.
>
> 			regards,
> 				Ted Hardie
>

Date: Mon, 09 Feb 2009 12:36:28 -0600
To: "Hannes Tschofenig" <[email-masked]>, "'Janet P Gunn'" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: 'ECRIT' <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

At 11:48 AM 2/9/2009, Hannes Tschofenig wrote:
> >>[hannes] You talk about rejecting the INVITE: Emergency calls do not
> >>get rejected regardless of the RPH marking.
> >
> >this statement is assuming all emergency calls do in fact get through
> >-- and that is simply not the case today, so what basis are
> >you making this argument from?
> >
>
>I would always mark my emergency calls with the highest priority (currently
>"esnet.4") since they are really important to me (hopefully the software
>marks without asking me as a caller in stress).

This is the other type of "relative importance" -- i.e., yours. And 
while I'm not saying your wrong here, I'm saying 911 or 112 calls 
aren't always the most important calls in the network.

For example, is the police chief's call to the fire chief more or 
less important than a citizen's call into a PSAP?

Be careful when you answer this -- because this is a local policy 
decision -- and not all jurisdictions will have the same policy. 
Therefore choosing to mark the 911/112 calls with the highest 
indication is already wrong for some jurisdictions.

There are other examples that I can offer.

I, personally, believe the 911/112 calls should be marked - as a 
default - as "esnet.1" with only 1 other level below it for 
non-emergency communications -- to be used for things such as IM 
between call centers (which is an existing requirement - and 
therefore needs a priority mark).

Politics will have the chiefs of various departments have the highest 
level. That's "esnet.4"

I, personally, believe the next level ought to go to the first 
responders that are currently in a fire or gun fight. This is 
currently handled over radio links, but we don't know these are going 
to stay on RF over the next 10 years (and in fact have several 
vendors working on solutions over IP right now). So that's "esnet.3"

I, personally, believe the next level ("esnet.2") ought to go to the 
command centers for inter-command communications, including the 
on-site supervisors of a larger than normal incident (like a large 
fire or SWAT).

Nearly all of this will not take the same path as the citizen to 
authority calls, but has to get marked differently because they are 
just different level of events.

>If they still don't get through then the marking was not of much help either.
>
>Maybe we need more priority levels. We could serve the highest values just
>for us :-)
>(This is a joke!)

well... to bring up flexibility, I've just listed 5 uses (i.e., the 5 
proposed levels) and that doesn't allow too much else to be inserted 
that I haven't talked about.  Perhaps there should be more available 
to the PSAP/first responder community?  It doesn't mean they have to 
use them all -- and 4412 does say the number of priority levels 
SHOULD NOT change over time, for interoperability reasons...

>Seriously, you need to explain how RPH marking would help against rejected
>emergency calls.

it isn't a question about whether or not RPH would help with 
rejection of calls, you asserted that emergency calls weren't 
rejected - and I am correcting you with the fact that in today's 
networks, 911 and 112 calls are rejected all the time.  RPH cannot 
address all of the situations in which the calls would otherwise be rejected.

Date: Mon, 09 Feb 2009 12:45:51 -0600
To: "Hannes Tschofenig" <[email-masked]>, "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ecrit] Semantics  Re:  RPH

At 12:08 PM 2/9/2009, Hannes Tschofenig wrote:

> >>It would be helpful that
> >draft-ietf-ecrit-local-emergency-rph-namespace
> >>captures some of these aspects to allow those who implement
> >and deploy
> >>the esnet RPH mechanism to understand what it does and how to
> >correctly
> >>implement it.
> >
> >I wholly disagree with this desire. This
> >draft-ietf-ecrit-local-emergency-rph-namespace creates the
> >namespace, it does not create the associated semantics for use
> >of this namespace that are specific to NENA or EENA. That is
> >up to NENA or EENA to specify.  It is also up to the AT&T's
> >and Verizon's of the world to define what the exact semantics
> >are within their respective networks are to satisfy whatever
> >regulations they have in their local jurisdictions (which are
> >different from each other -- and what the IETF knows nothing about).
> >
> >For example, each group of emergency callers thinks *their*
> >type of emergency should get preferential treatment over other
> >types of emergencies. To be specific, which type of emergency
> >call is more
> >important: a GETS type call or a 911/112 type call?
>
>I agree that this is a policy decision (as long as my emergency call with an
>inappropriate marking does not get dropped).
>
>What I was asking for is to describe the difference in authorization
>handling.

I firmly believe that is out of scope for this  doc (that just 
creates the namespace)

> >
> >It is not up to the IETF to decide that. It is up to the local
> >policies of the jurisdiction and the SP to figure that out.
> >This is not inconsistent with RFC 4412 - in fact, RFC 4412
> >built this aspect into its text.
> >
> >The esnet namespace should follow RFC 4412's guidelines in
> >coordination with those from the local authorities and the
> >local SPs to determine how they are going to configure their
> >operations.  At that point, it's up to the local SP to buy
> >products from vendors that can meet the requirements of that
> >local configuration.
>
>This does not work when you have end points doing this stuff since these end
>devices can be used everywhere.

but the endpoint that is attached to the VSP is going to be 
challenged by that VSP for the correct marking.

the endpoints that aren't attached to any VSP are going to be 
challenged by the ESInet ESRP, which will quickly determine this SIP 
request didn't come from an authorized VSP (I say authorized here 
because I believe each local or regional ESInet is going to have a 
trust relationship with VSPs - ensuring the VSP does the primary 
filtering of messages instead of the ESRP having to do it all, all the time.

>An operator can for sure decide to buy a box that does fancy marking
>techniques and offers different ways to configure the box todo so. No doubt.

yep -- that's one reason I don't want to forbid the marking outside 
of the ESInet, where VSPs can make that choice to get 'more engaged' 
with the program.

> >
> >Therefore, draft-ietf-ecrit-local-emergency-rph-namespace
> >should not have any additional text articulating guidance how
> >to configure their networks. RFC 4412 defines all the guidance
> >they need at this time.
> >
> >When operational experience proves something ought to be
> >modified within that guidance, then a new doc should be
> >written suggesting that/those modification(s).
>
>When I wrote, for example, the following sentence:
>
>   #* What does the esnet RPH usage mean in the context of an emergency
>   #call (for example, in comparison to an emergency call without esnet RPH
>usage)?
>
>I was hoping that someone would think about the possible "local policy
>settings" that could make sense.

Read my last message (I just sent it) and see if this is something 
that you want me to put into an appendix as a non-binding guidance or 
format... obviously this is something that we can modify

>If an emergency call with the esnet RPH marking gets treated better than an
>emergency call without such a marking then someone might come up with the
>idea of marking every emergency call with the highest priority. If everyone
>does this then the purpose of the priority system is lost.

hopefully the VSPs will engage at some point and start marking down 
those priority values that are too high (down to the normal esnet marking).

>Treating an emergency call with an esnet RPH marking worse than one without
>it wouldn't make a lot of sense since otherwise nobody would do the marking
>anymore.
>
>Treating an emergency call with an esnet RPH marking in the same fashion as
>other emergency calls would defeat the purpose of the additional marking.
>
>The above-mentioned cases assume that the SIP UA vendor (or someone else
>configuring the marking) knows the local policy at the VSP. If it is not
>known at all and all the above cases are equally likely then it does not
>make sense to mark the call.
>
>Not so trivial to come up with something useful.
>
>Ciao
>Hannes
>
> >>Ciao
> >>Hannes
> >>
> >>PS: There are details that also need to be discussed. For example,
> >>which esnet value would the device use for an emergency call?
> >>"esnet.0", "esnet.1", "esnet.2", "esnet.3", "esnet.4".
> >Out-of-scope is
> >>a possible answer but it will not help the implementer in
> >doing it's job.
> >
> >see the very same explanation above as to why this isn't
> >something that ought be in an IETF doc.
> >
> >>Is there a
> >>specific default value (maybe the highest value, just to be sure)?
> >
> >there is not, and choosing one the highest or lowest value
> >limits adjustments and the "what if we determine one day
> >something else is actually more important" question.
> >
> >>Would the UA get provisioned to pick a specific value?
> >
> >if this were in scope of this doc, I'd suggest this be done
> >through something like RFC 3841 "SIP Call Preferences"
> >
> >>What is the provisioning mechanism?
> >
> >this depends on the choice, but Caller Prefs has a mechanism.
> >
> >>Is there a relationship between the esnet values and the
> >Service URN values?
> >
> >should there be?
> >
> >I don't know, and think this is a local (matrix) matter -- or
> >a NENA/EENA matter
> >
> >>Do the urn:service:counseling:* services get a lower priority
> >than the
> >>urn:service:sos:* services?
> >
> >only if local policy gives urn:service:counseling:* any
> >priority, then local policy will determine what priority in
> >relation to sos.
> >
> >Remember - some of these decisions will be based on the
> >capacity (BW and # of call takers) within the local
> >jurisdiction -- which is again something the IETF cannot give
> >guidance on at this point , if ever
> >
> >
> >> >Hannes,
> >> >
> >> >We need to understand the attachment of the UE to the network.
> >> >There is an AA process prior to allowing any use. Without this we
> >> >would not trust the RPH, even for ETS, never mind 911
> >> >
> >> >Martin
> >> >
> >> >----- Original Message -----
> >> >From: Hannes Tschofenig <[email-masked]>
> >> >To: DOLLY, MARTIN C, ATTLABS; [email-masked]
> >> ><[email-masked]>; [email-masked] <[email-masked]>
> >> >Cc: [email-masked] <[email-masked]>
> >> >Sent: Sun Feb 08 04:32:25 2009
> >> >Subject: RE: [Ecrit] Semantics  Re:  RPH
> >> >
> >> >Hi Martin,
> >> >
> >> >Your remarks are a bit a short.
> >> >
> >> >Clearly, authentication and authorization can come in
> >different forms.
> >> >This was actually one of the discussion we had so far that the
> >> >authorization mechanisms for the GETS RPH and the proposed
> >ECRIT RPH
> >> >is different.
> >> >
> >> >So, could you elaborate a bit?
> >> >
> >> >Ciao
> >> >Hannes
> >> >
> >> >>-----Original Message-----
> >> >>From: [email-masked] [mailto:[email-masked]]
> >> >On Behalf
> >> >>Of DOLLY, MARTIN C, ATTLABS
> >> >>Sent: 07 February, 2009 19:30
> >> >>To: [email-masked]; [email-masked]
> >> >>Cc: [email-masked]; [email-masked]
> >> >>Subject: Re: [Ecrit] Semantics Re: RPH
> >> >>
> >> >>Do you have a clue dude? A+A of an user comes in many forms.
> >> >>
> >> >>----- Original Message -----
> >> >>From: [email-masked] <[email-masked]>
> >> >>To: Janet P Gunn <[email-masked]>
> >> >>Cc: ECRIT <[email-masked]>; [email-masked]
> >> >><[email-masked]>
> >> >>Sent: Sat Feb 07 11:56:42 2009
> >> >>Subject: Re: [Ecrit] Semantics  Re:  RPH
> >> >>
> >> >>Please see my earlier message as to why your approach fails
> >> >for the UA-
> >> >>inserted case where not all emergency calls have RPH
> >> >markings. I think
> >> >>it would be a really bad idea if emergency calls with RPH are
> >> >>treated differently than emergency calls without it. (Again, I'm
> >> >talking about
> >> >>the user-initiated calls. An ESNET can do whatever it
> >wants and can
> >> >>assign extra priority to calls from citizens that have bought PBA
> >> >>stickers or zip codes that pay more taxes, but that's a separate
> >> >>problem.)
> >> >>
> >> >>I also don't believe your implementation logic. A much better
> >> >approach
> >> >>is to semantically declare the class of call early on (e.g., based
> >> >>on the URN or after authentication/authorization), and make that
> >> >>part of the call state record, rather than hunt for headers each
> >> >>time a handling decision needs to be made. Given the authorization
> >> >>requirements, just looking at "has header X" is never going to be
> >> >>sufficient anyway.
> >> >>
> >> >>Henning
> >> >>
> >> >>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:
> >> >>
> >> >>>
> >> >>>
> >> >>> .
> >> >>>
> >> >>> [email-masked] wrote on 02/07/2009 03:14:57 AM:
> >> >>>
> >> >>> > PLEASE try to understand that the syntax is similar
> >(header, new
> >> >>> namespace,
> >> >>> > new values)
> >> >>> > BUT the semantic is different.
> >> >>> >
> >> >>> > For all message it is true that the sender can add
> >whatever they
> >> >>> want. The
> >> >>> > big question is what does it mean for the recipient.
> >> >>> >
> >> >>> > This is what the discussion is about.
> >> >>> >
> >> >>> On the contrary, the semantic is, or at least can be,
> >very similar.
> >> >>>
> >> >>> Consider the hypothetical, but plausible, case of a network with
> >> >>> an explicit call/capacity admission process, in which both
> >> >>> 911-type- emergency calls and GETS calls get preferential
> >> >>> admission
> >> >>treatment.
> >> >>> By the time the INVITE gets to this Functional Module/ block
> >> >>of code,
> >> >>> all authentication, authorization, and changes/ confirmation of
> >> >>> the destination have already taken place.  All this
> >block of code
> >> >>> deals with is call/capacity admission.
> >> >>>
> >> >>> For the sake of argument, suppose this is the nature of the
> >> >>> preference.
> >> >>>
> >> >>> 1) For INVITEs without RPH, or with an RPH this network does
> >> >>not use/
> >> >>> understand, if the admission process fails, the INVITE fails
> >> >>>
> >> >>> 2) For INVITEs with RPH with the ets namespace, if the admission
> >> >>> process initially fails, the INVITE is put in queue until the
> >> >>> resources become available so it can be admitted.
> >> >>>
> >> >>> 3) For INVITEs with RPH with the esnet namespace, if the
> >admission
> >> >>> process initially fails, the INVITE is put in queue, but
> >at lower
> >> >>> priority than the calls with the ets namespace.
> >> >>>
> >> >>> With the esnet namespace, this block of code only needs to
> >> >deal with
> >> >>> the RPH in determining which INVITEs to reject, and which to
> >> >>> queue, and how.
> >> >>>
> >> >>> But if there is no esnet namespace for RPH, then this block of
> >> >>> code would need to deal with BOTH the RPH and the URN.
> >That would
> >> >>> be a completely unnecessary complication.
> >> >>>
> >> >>> Janet
> >> >>
> >> >>_______________________________________________
> >> >>Ecrit mailing list
> >> >>[email-masked]
> >> >>https://www.ietf.org/mailman/listinfo/ecrit
> >> >>_______________________________________________
> >> >>Ecrit mailing list
> >> >>[email-masked]
> >> >>https://www.ietf.org/mailman/listinfo/ecrit
> >> >>
> >> >
> >> >
> >>
> >>_______________________________________________
> >>Ecrit mailing list
> >>[email-masked]
> >>https://www.ietf.org/mailman/listinfo/ecrit
> >

To: "James M. Polk" <[email-masked]>
From: Anthony D Pike <[email-masked]>
Date: Mon, 9 Feb 2009 14:06:37 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: [Ecrit] RPH Priority order for ESNET observation against Priority of other namespaces defined in RFC 4412

This is a multipart message in MIME format.
--=_alternative 0068981485257558_=
Content-Type: text/plain; charset="US-ASCII"

Hi James

as I have been following emails on RPH I noticed that the Priority for 
esnet namespace is defined as 

(lowest)  esnet.0
                  esnet.1
                  esnet.2
                  esnet.3
(highest) esnet.4
 
Where the numerical order flows from (lowest=0) to (Highest=4)

Where as in RFC 4412 the numerical order for wps, q735 and ets namespaces 
is the other way around (Highest=0 to Lowest=4)

(lowest)  wps.4   q735.4   ets.4
                  wps.3   q735.3  est.3
                  wps.2   q735.2  ets.2
                  wps.1   q735.1        ets.1
(highest) wps.0   q736.0  est.0

I'm not sure if there is any reason for the reverse numerical odering of 
the esnet namespace, but it would seem good practice to keep them 
consistent? 

Tony 

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.
--=_alternative 0068981485257558_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">Hi James</font>
<br>
<br><font size=2 face="sans-serif">as I have been following emails on RPH
I noticed that the Priority for esnet namespace is defined as </font>
<br>
<br><font size=2 face="sans-serif">(lowest) &nbsp;esnet.0</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; esnet.1</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; esnet.2</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; esnet.3</font>
<br><font size=2 face="sans-serif">(highest) esnet.4</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;<br>
Where the numerical order flows from (lowest=0) to (Highest=4)</font>
<br>
<br><font size=2 face="sans-serif">Where as in RFC 4412 the numerical order
for wps, q735 and ets namespaces is the other way around (Highest=0 to
Lowest=4)</font>
<br>
<br><font size=2 face="sans-serif">(lowest) &nbsp;wps.4 &nbsp; q735.4 &nbsp;
ets.4</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; wps.3 &nbsp; q735.3 &nbsp;est.3</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; wps.2 &nbsp; q735.2 &nbsp;ets.2</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; wps.1 &nbsp; q735.1 &nbsp; &nbsp; &nbsp; &nbsp;ets.1</font>
<br><font size=2 face="sans-serif">(highest) wps.0 &nbsp; q736.0 &nbsp;est.0</font>
<br>
<br><font size=2 face="sans-serif">I'm not sure if there is any reason
for the reverse numerical odering of the esnet namespace, but it would
seem good practice to keep them consistent? </font>
<br>
<br><font size=2 face="sans-serif">Tony </font>
<br><font size=2 face="sans-serif"><br>
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. <br>
NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.</font>
--=_alternative 0068981485257558_=--

Date: Mon, 09 Feb 2009 13:13:29 -0600
To: Henning Schulzrinne <[email-masked]>, Ted Hardie <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: ECRIT <[email-masked]>
Subject: [Ecrit] RPH "esnet" in the 3 areas of the network

I'd like to focus on one part of the network, and it's not from the 
endpoint, for a moment to attempt to break this thread up to 
discussion each of the 3 parts of the overall e2e emergency call.

Figure 1 within this ID gives 3 parts of the network,

         - from the UAC/UE,
         - within the VSP, and
         - within the ESInet.

I think everyone (currently voicing opinions on these threads) agree 
with allowing the "esnet" RPH namespace within the ESInet - so I 
won't talk about that part any further.

That leaves the first two parts still open for discussion even though 
we've already been hashing this out pretty brutally for some time now.

Addressing what Henning agreed to (Ted's message) below, it appears 
each sees not benefit to VSPs processing the esnet namespace, and 
Henning is less enthusiastic about allowing a UAC or UE setting the 
namespace -- to the point of calling this pointless and dangerous.  I 
think Hannes is close to this opinion.

Keith, Brian, Martin Dolly, Janet, Marc and I want to allow the 
UAC/UE to set the namespace (i.e., not prohibit it), and want the VSP 
to mark emergency SIP requests (or remark if done so incorrectly) 
with the "esnet" RPH namespace.

Some VSPs are going to directly attach to entry points to a ESInet, 
and there can be a relationship there, off-loading the ESRP within 
the ESInet from being the first entity from doing any checks on 
incoming emergency calls.

Is there contention from Ted, Henning or Hannes (or anyone else) to 
disallow or *NOT* have text (or a diagram) in this ID from showing a 
VSP being able to either marking or remarking an RPH esnet namespace?

I think the is more resistance to NOT allowing this than from the 
UAC/UE - which is why I want to ask about only this piece of the puzzle.

James

At 12:31 PM 2/9/2009, Henning Schulzrinne wrote:

>I agree with Ted on the first part. We can then discuss whether the
>second part is really helpful.
>
>>As a way forward, I suggest we separate out the PSAP--first
>>responder/organizations use case and define only a namespace for that.

>>If we need a second
>>namespace
>>for caller insertion/entry server insertion, we can create that.
>>Strings are cheap.
>>But there seems to be a long road ahead in combining the two, since
>>the kinds
>>of devices that have to care and the kinds of networks they may have
>>to traverse
>>seem different enough to hinder early consensus.
>>
>>                         regards,
>>                                 Ted Hardie
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

Date: Mon, 09 Feb 2009 13:29:50 -0600
To: Anthony D Pike <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Ecrit] RPH Priority order for ESNET observation against Priority of other namespaces defined in RFC 4412

Tony

Actually, granting higher priority to higher numbers is more the 
practice of everyone, and existing MLPP folks set the tone for the 
ets and wps namespaces.  For example, RSVP has 2^32 priority values, 
with the highest number having the highest priority.

This reverse order was a struggle for a lot of folks when RFC 4412 
was still draft... but the idea was for that very mature system, they 
knew exactly what they wanted, and didn't want anything to receive 
greater priority than priority zero (0), as would have been the case 
if the highest priority were something like 5, and someone wanted a 
new priority level, with the next available number being 6. In this 
case, would 6 have had greater priority than 5?  What if the 
President of the US were already 5, who would implement a system that 
gave anyone greater priority than the highest ranking official within 
any country?  Answer => no one.  So they made the Prez priority 0.

(Janet - go with the flow here!)

Now, each namespace is going to have its own priority list, and it 
can be letters or numbers or strings.  It's up to the namespace owner 
to set the order, and its up to the operators that choose to 
implement more than one namespace to work out the details of the 
relative priority order between more than one namespace. See section 
8 of RFC 4412 for this critical detail.

Given that the concept of prioritizing emergency communications will 
be new to PSAPs and first responders, they do not have a mature 
system like MLPP has.  So locking them into a ceiling that's in 
descending order will undoubtedly cause some problems for some 
jurisdictions that either underestimate which type of communication 
ought to have which priority-value, or end up - down the road - using 
or needing more priority-levels than they originally planned.  Either 
way, it's a pain to reset all devices to a new map of what priority 
levels go with what type of emergency communication.

Does this make sense?

James

At 01:06 PM 2/9/2009, Anthony D Pike wrote:

>Hi James
>
>as I have been following emails on RPH I noticed that the Priority 
>for esnet namespace is defined as
>
>(lowest)  esnet.0
>                   esnet.1
>                   esnet.2
>                   esnet.3
>(highest) esnet.4
>
>Where the numerical order flows from (lowest=0) to (Highest=4)
>
>Where as in RFC 4412 the numerical order for wps, q735 and ets 
>namespaces is the other way around (Highest=0 to Lowest=4)
>
>(lowest)  wps.4   q735.4   ets.4
>                   wps.3   q735.3  est.3
>                   wps.2   q735.2  ets.2
>                   wps.1   q735.1        ets.1
>(highest) wps.0   q736.0  est.0
>
>I'm not sure if there is any reason for the reverse numerical 
>odering of the esnet namespace, but it would seem good practice to 
>keep them consistent?
>
>Tony
>
>This is a PRIVATE message. If you are not the intended recipient, 
>please delete without copying and kindly advise us by e-mail of the 
>mistake in delivery.
>NOTE: Regardless of content, this e-mail shall not operate to bind 
>CSC to any order or other contract unless pursuant to explicit 
>written agreement or government initiative expressly permitting the 
>use of e-mail for such purpose.

To: "James M. Polk" <[email-masked]>
From: Anthony D Pike <[email-masked]>
Date: Mon, 9 Feb 2009 14:56:48 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Ecrit] RPH Priority order for ESNET observation against Priority of other namespaces defined in RFC 4412

This is a multipart message in MIME format.
--=_alternative 006D1F9085257558_=
Content-Type: text/plain; charset="US-ASCII"

Yes that makes sense, I figured there was a good explanation.

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.

"James M. Polk" <[email-masked]> 
02/09/2009 02:29 PM

To
Anthony D Pike/ESI/CSC@CSC
cc
"[email-masked]" <[email-masked]>
Subject
Re: RPH Priority order for ESNET observation against Priority  of other 
namespaces defined in RFC 4412

Tony

Actually, granting higher priority to higher numbers is more the 
practice of everyone, and existing MLPP folks set the tone for the 
ets and wps namespaces.  For example, RSVP has 2^32 priority values, 
with the highest number having the highest priority.

This reverse order was a struggle for a lot of folks when RFC 4412 
was still draft... but the idea was for that very mature system, they 
knew exactly what they wanted, and didn't want anything to receive 
greater priority than priority zero (0), as would have been the case 
if the highest priority were something like 5, and someone wanted a 
new priority level, with the next available number being 6. In this 
case, would 6 have had greater priority than 5?  What if the 
President of the US were already 5, who would implement a system that 
gave anyone greater priority than the highest ranking official within 
any country?  Answer => no one.  So they made the Prez priority 0.

(Janet - go with the flow here!)

Now, each namespace is going to have its own priority list, and it 
can be letters or numbers or strings.  It's up to the namespace owner 
to set the order, and its up to the operators that choose to 
implement more than one namespace to work out the details of the 
relative priority order between more than one namespace. See section 
8 of RFC 4412 for this critical detail.

Given that the concept of prioritizing emergency communications will 
be new to PSAPs and first responders, they do not have a mature 
system like MLPP has.  So locking them into a ceiling that's in 
descending order will undoubtedly cause some problems for some 
jurisdictions that either underestimate which type of communication 
ought to have which priority-value, or end up - down the road - using 
or needing more priority-levels than they originally planned.  Either 
way, it's a pain to reset all devices to a new map of what priority 
levels go with what type of emergency communication.

Does this make sense?

James

At 01:06 PM 2/9/2009, Anthony D Pike wrote:

>Hi James
>
>as I have been following emails on RPH I noticed that the Priority 
>for esnet namespace is defined as
>
>(lowest)  esnet.0
>                   esnet.1
>                   esnet.2
>                   esnet.3
>(highest) esnet.4
>
>Where the numerical order flows from (lowest=0) to (Highest=4)
>
>Where as in RFC 4412 the numerical order for wps, q735 and ets 
>namespaces is the other way around (Highest=0 to Lowest=4)
>
>(lowest)  wps.4   q735.4   ets.4
>                   wps.3   q735.3  est.3
>                   wps.2   q735.2  ets.2
>                   wps.1   q735.1        ets.1
>(highest) wps.0   q736.0  est.0
>
>I'm not sure if there is any reason for the reverse numerical 
>odering of the esnet namespace, but it would seem good practice to 
>keep them consistent?
>
>Tony
>
>This is a PRIVATE message. If you are not the intended recipient, 
>please delete without copying and kindly advise us by e-mail of the 
>mistake in delivery.
>NOTE: Regardless of content, this e-mail shall not operate to bind 
>CSC to any order or other contract unless pursuant to explicit 
>written agreement or government initiative expressly permitting the 
>use of e-mail for such purpose.

--=_alternative 006D1F9085257558_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">Yes that makes sense, I figured there
was a good explanation.<br>
<br>
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. <br>
NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>&quot;James M. Polk&quot;
&lt;[email-masked]&gt;</b> </font>
<p><font size=1 face="sans-serif">02/09/2009 02:29 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Anthony D Pike/ESI/CSC@CSC</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">&quot;[email-masked]&quot; &lt;[email-masked]&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: RPH Priority order for ESNET observation
against Priority &nbsp;of other namespaces defined in RFC 4412</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>Tony<br>
<br>
Actually, granting higher priority to higher numbers is more the <br>
practice of everyone, and existing MLPP folks set the tone for the <br>
ets and wps namespaces. &nbsp;For example, RSVP has 2^32 priority values,
<br>
with the highest number having the highest priority.<br>
<br>
This reverse order was a struggle for a lot of folks when RFC 4412 <br>
was still draft... but the idea was for that very mature system, they <br>
knew exactly what they wanted, and didn't want anything to receive <br>
greater priority than priority zero (0), as would have been the case <br>
if the highest priority were something like 5, and someone wanted a <br>
new priority level, with the next available number being 6. In this <br>
case, would 6 have had greater priority than 5? &nbsp;What if the <br>
President of the US were already 5, who would implement a system that <br>
gave anyone greater priority than the highest ranking official within <br>
any country? &nbsp;Answer =&gt; no one. &nbsp;So they made the Prez priority
0.<br>
<br>
(Janet - go with the flow here!)<br>
<br>
Now, each namespace is going to have its own priority list, and it <br>
can be letters or numbers or strings. &nbsp;It's up to the namespace owner
<br>
to set the order, and its up to the operators that choose to <br>
implement more than one namespace to work out the details of the <br>
relative priority order between more than one namespace. See section <br>
8 of RFC 4412 for this critical detail.<br>
<br>
Given that the concept of prioritizing emergency communications will <br>
be new to PSAPs and first responders, they do not have a mature <br>
system like MLPP has. &nbsp;So locking them into a ceiling that's in <br>
descending order will undoubtedly cause some problems for some <br>
jurisdictions that either underestimate which type of communication <br>
ought to have which priority-value, or end up - down the road - using <br>
or needing more priority-levels than they originally planned. &nbsp;Either
<br>
way, it's a pain to reset all devices to a new map of what priority <br>
levels go with what type of emergency communication.<br>
<br>
Does this make sense?<br>
<br>
James<br>
<br>
At 01:06 PM 2/9/2009, Anthony D Pike wrote:<br>
<br>
&gt;Hi James<br>
&gt;<br>
&gt;as I have been following emails on RPH I noticed that the Priority
<br>
&gt;for esnet namespace is defined as<br>
&gt;<br>
&gt;(lowest) &nbsp;esnet.0<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; esnet.1<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; esnet.2<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; esnet.3<br>
&gt;(highest) esnet.4<br>
&gt;<br>
&gt;Where the numerical order flows from (lowest=0) to (Highest=4)<br>
&gt;<br>
&gt;Where as in RFC 4412 the numerical order for wps, q735 and ets <br>
&gt;namespaces is the other way around (Highest=0 to Lowest=4)<br>
&gt;<br>
&gt;(lowest) &nbsp;wps.4 &nbsp; q735.4 &nbsp; ets.4<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; wps.3
&nbsp; q735.3 &nbsp;est.3<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; wps.2
&nbsp; q735.2 &nbsp;ets.2<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; wps.1
&nbsp; q735.1 &nbsp; &nbsp; &nbsp; &nbsp;ets.1<br>
&gt;(highest) wps.0 &nbsp; q736.0 &nbsp;est.0<br>
&gt;<br>
&gt;I'm not sure if there is any reason for the reverse numerical <br>
&gt;odering of the esnet namespace, but it would seem good practice to
<br>
&gt;keep them consistent?<br>
&gt;<br>
&gt;Tony<br>
&gt;<br>
&gt;This is a PRIVATE message. If you are not the intended recipient, <br>
&gt;please delete without copying and kindly advise us by e-mail of the
<br>
&gt;mistake in delivery.<br>
&gt;NOTE: Regardless of content, this e-mail shall not operate to bind
<br>
&gt;CSC to any order or other contract unless pursuant to explicit <br>
&gt;written agreement or government initiative expressly permitting the
<br>
&gt;use of e-mail for such purpose.<br>
<br>
</tt></font>
<br>
--=_alternative 006D1F9085257558_=--

Date: Mon, 9 Feb 2009 14:03:27 -0800
To: "James M. Polk" <[email-masked]>, Hannes Tschofenig <[email-masked]>, "'DOLLY, MARTIN C,  ATTLABS'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
From: Ted Hardie <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ecrit] RPH

At 10:06 AM -0800 2/9/09, James M. Polk wrote:
>Ted -- comments at the bottom
>
>While I generally agree with you -- until you imply that the two
>namespaces ought go be in separate docs that have to meet somewhere
>future somewhere in the middle of the network.

I am not sure that they do have to meet somewhere.  If ESNET internal
communications are marked with priority values from foo and customer-to-ESNET
communications are marked with values from the bar namespace, then
any system that might handle both will eventually have to have a mapping
that says something like foo3 is above bar2 but below bar1 (assuming 0 high
for both). But I actually suspect, honestly, that the ESNET internal communication
is really either a private network or an overlay.  If that's the case (and
I could be way off here), the number of times these traffic markings will
be evaluated against each other seems likely to be pretty small.  Maybe
even 0 in some deployment scenarios.

>         Please let me know if I've misread what you meant to say.
>
>On this, I have two thoughts:
>
>#1 - that several vendors and SPs have already asked for this
>namespace to be possible in their respective VSP products and service
>offerings - and your implied solution blows that up.

Well, I think it's already blown up, as I think the chance of consensus
on a customer-to-ESNET namespace seems likely to be slow to emerge.
I'm trying to see if there is a way to get something out without waiting
for that consensus.

>and
>
>#2 - that creating (in the future) a second namespace to map directly
>to the esnet (and it's 5 priority-values) from the UAC or VSP seems
>like it might be begging for a lack of interoperability waiting to
>happen type of problem.

First, this presumes that there will be a second namespace.   Fair enough,
you see a customer need here.  But I am not at all sure that it would
be a one-to-one correspondence.  I think some folks might well argue
that customer-to-ESNET should have only two values:  "not an emergency"
and "emergency", to simplify the discussions of how big an emergency
deserves to go higher than some other emergency.  But I think that's
part of the discussion of this that makes customer-to-ESNET much harder
to work through than ESNET where who gets to decide is crystal, crystal
clear.

>I can definitely rewrite the text emphasizing the esnet namespace is
>for the ESInet first, with the possibility of having it come in from
>a reliable VSP, and even a reliable UAC/UE off that reliable VSP.

And here is where I think the same syntax is being used for two semantics.
If the syntax of value 1 within intra-ESINET communications isn't exactly
the same as value one in customer to-ESINET communications, we look
to be in a very long discussion indeed.  And finding some way of satisfying
everyone that this is the case seems long and drawn out indeed.

Maybe I just more conflict avoidant these days, but I'd like to get
something out and tackle the more difficult things with a sense of
accomplishment than to bog down.  But I'm not really coding this
myself, so it's a suggestion from the sidelines.

					Ted

>>                         regards,
>>                                 Ted Hardie

Content-class: urn:content-classes:message
Date: Mon, 9 Feb 2009 21:12:40 -0600
From: "Thomson, Martin" <[email-masked]>
To: "Edge, Stephen" <[email-masked]>
Cc: ECRIT <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

From: "Edge, Stephen" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Thu, 12 Feb 2009 04:08:22 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Ecrit] Comments on Framework Draft

Hi Hannes

Thanks for all these comments. I have embedded below a number of responses =
(look for [SE: .... ]). The previous suggestions remain, however, unchanged=
 from our perspective. Whether it is worth attempting to align the two solu=
tions more at this stage seems questionable. By including appropriate discl=
aimers, the Framework (and phoneBCP) spec.s can continue to define an optim=
um solution for exactly the call scenarios for which they were really inten=
ded leaving it clearer than before that an alternative solution exists for =
a good portion of the missing cases. Merging part of one solution into the =
other might not create anything very useful and changing one solution or th=
e other risks losing some of its current optimality. But I agree that this =
could still be looked at on one or both sides and in fact in 3GPP we have m=
ade some limited attempts at this already to create a more generic solution=
 with fewer restrictions on AN and VSP combinations.

Kind Regards

Stephen
-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]=20
Sent: Thursday, February 05, 2009 1:18 AM
To: Edge, Stephen; 'ECRIT'
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Stephen,=20

Thanks for your review. A few minor comments.=20

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]=20
>On Behalf Of Edge, Stephen
>Sent: 05 February, 2009 09:50
>To: 'ECRIT'
>Subject: [Ecrit] Comments on Framework Draft
>
>All
>=A0
>draft-ietf-ecrit-framework-07 is (as we see it) a mostly=20
>informative description of how terminals and networks should=20
>support emergency calls made over IP capable facilities to IP=20
>capable PSAPs. It appears intended to cover all types of=20
>access network - including fixed line, WiFi and cellular (e.g.=20
>examples involving each can be found throughout the draft).

Correct. The framework document is the informative description where=20
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.txt
provides the normative part.=20

We thought that this would make it easy for the reader to follow the entire
story best.=20

>=A0
>When we evaluated this with respect to support of wireless=20
>cellular access and WiFi access associated with a cellular=20
>operator (e.g. WLAN or Femto cells integrated into a cellular=20
>network), we found that certain portions of the draft=20
>exhibited one or more of the following characteristics:
>=A0
>=A0=A0=A0 (A) Inconsistent with already standardized wireless solutions
>=A0
>=A0=A0=A0 (B) Inconsistent with essential wireless requirements and=20
>conventions
>=A0
>=A0=A0=A0 (C) Already part of wireless standards or potentially part=20
>of future standards
>=A0
>(A) refers to all portions of the draft framework that differ=20
>from the requirements and procedures currently standardized=20
>for wireless emergency access by 3GPP, 3GPP2 and OMA. This is=20
>a plain difference of solution and could be resolved through=20
>support of both solutions by terminals (with each solution=20
>being used according to the type of access network and VSP) or=20
>could be resolved by supporting only one solution and=20
>accessing only the types of network supporting that solution.=20
>To acknowledge this category, the framework document could=20
>reference the applicable wireless standards and point out that=20
>these are valid alternatives for wireless cellular based access.

You know that we have tried hard over the past few years to harmonize the
work done by different SDOs, including 3GPP. You were involved in some of
these activities.=20

For some reason, various companies did not like such an alignment and hence
we are left with the situation that IMS emergency calling and emergency
calling for everything else works differently.=20

This is unfortunate. Your company was always a big fan of developing a
harmonized solution, right?=20

I doubt that the situation is improved by summarizing other standardization
efforts in this document nor by describing the content of this document in
3GPP, 3GPP2 or OMA documents.=20

[SE: our proposal is only to acknowledge the existence of this other soluti=
on by reference not to try to summarize it.]=20

>(B) refers to portions of the draft that would be unsuitable=20
>for wireless networks even if no alternative solution existed=20
>together with other portions missing from the draft that would=20
>be needed to fully support wireless networks.

Please note that we make a differentiation between wireless and cellular. I
guess you refer to cellular.=20

[SE: mainly yes. And in fact this is just the type of applicability stateme=
nt that we are looking for - i.e. an acknowledgement that the Framework sol=
ution is mainly designed for wireline and non-cellular associated wireless =
access and is not intended to apply in its entirety to cellular associated =
wireless access.]

 Examples of the=20
>former include: (a) emphasis on endpoint derivation of=20
>location, performance of Lost query and receipt of local dial=20
>strings;

Please note that we are talking about location for 2 different purposes
here:=20
* Location for routing=20
* Location for dispatch

It is true that the document puts a focus on the end point obtaining
location (at least for routing). There is, however, a story in there for th=
e
case where the end point does not have access to location at all.=20

Having access to local dial strings at the end point is a very useful thing=
,
if you think about it.=20

Regarding LoST: Please note that LoST can also be executed by the VoIP
provider when routing is required.=20

[SE: yes I was aware of this, but it is treated as something of an exceptio=
n whereas for cellular networks, it is the norm.]

>(b) restriction of LCPs to protocols that require=20
>terminal initiation (not allowing for network initiation as=20
>far as we can tell) and that include two LCPs (DHCP and LLDP)=20
>that are not applicable to (not defined for) cellular access;=20

These two LCPs are only required for devices that can also be used in a
fixed / wireless (but not cellular) environment. In environments where the
end host is expected to only ever use a cellular system these two LCPs need
not to be implemented.=20

Network initiation has never found huge excitement within the members of th=
e
GEOPRIV group. I don't see this is a limitation, to be honest.=20

[SE: there is no problem if the proper cellular disclaimer gets added. Othe=
rwise, I would see the need for some significant change to admit other type=
s of LCP - e.g. OMA SUPL and 3GPP control plane solution.]

>and (c) the requirement that a terminal or at least a LIS will=20
>update the PSAP whenever location changes.

I guess the items below refer to the dynamic location change.

 (a) is impractical=20
>due to network and terminal loading consequences

I guess you see it as more dramatic than it is. The LIS and the PSAP can
control the rate of information disclosure, see
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-03.txt.=
=20

Specifying at what rate the terminal would send up-to-date information is
policy and implementation dependent. =20

 and failure=20
>to support non-IP capable PSAPs;

The IETF ECRIT solution is an IP-based solution and hence the Internet ends
where the last IP node is located.=20
For interworking with non-IP capable PSAPs please take a look at the NENA
i2/i2.5 work, which is the most advanced of its kind.=20

[SE: A problem is that the latest i2.5 draft states that "This issue of the=
 i2 standard supports E9-1-1 for fixed and nomadic VoIP services. Support f=
or mobile VoIP services will be covered in a future release of this documen=
t." We expect that the missing mobile VoIP support will be provided by inco=
rporating the 3GPP/3GPP2 solution as has already occurred for the i3 draft.=
 Whether it may also be supported by extending what is already in the i2.5 =
draft independently of the 3GPP/3GPP2 solution remains to be seen.]

 (b) makes location=20
>verification and updated location provision to PSAPs difficult=20
>or impossible;

Could you elaborate a bit? Not sure I understood the "verification" and the
"updated location provisioning" part.=20

[SE: with terminal initiated location, the terminal can provide location va=
lues that are unreliable or deliberately false (and cannot be verified as s=
uch by the network) and may not provide location updates as needed by a PSA=
P. Even using location by reference (which I agree should be better), the V=
SP plays no part though may be held liable by the PSAP or regulatory bodies=
 for any mistakes.]

 while (c) is also incompatible with support of=20
>existing non-IP capable PSAPs besides increasing terminal load=20
>and possibly interfering with optimum maintenance of the RF=20
>connection (e.g. if a terminal has to tune away from the=20
>serving base station or WLAN periodically to make location=20
>measurements).

I guess you are hunting an academic problem. The document does not say that
you provide a continues stream of location information. We are more
concerned about getting rough location as fast as possible to make the
emergency call routing to happen to the right PSAP and then provide
up-to-date location available to the PSAP for dispatch, when available.=20

Sure, there are corner cases when the emergency caller happens to be in a
fast car driving down the highway and location is constantly changing.=20

[SE: it just seems less efficient to be obtaining and sending a stream of l=
ocation updates rather than obtaining a location update only when the PSAP =
wants it. But I agree that feasibility need not be in question here.]

 Examples of the latter include (d) absence of=20
>support for access to non-IP capable PSAPs as already=20
>mentioned (e.g. to support E911 phase 2 in the US);=20

This is excluded by our charter and, as I said, possible with the solution
NENA has worked out with i2 and i2.5.=20

Please also note that today fixed (and wireless -- but not cellular)
operators are looking for VoIP emergency solutions as they are somewhat
ahead with VoIP deployment compared to cellular operators.

Hence, this will give PSAP operators more time to migrate to an IP-based
environment and these things are happening as we speak. Sure, this all need=
s
time but the cost savings for an IP-based solution (as it was reported to
use at the emergency services workshops) seems to speak in favor of IP.=20

[SE: cellular operators have to support legacy PSAPs so this cannot be out =
of scope for the 3GPP/3GPP2 solution. But again, a short disclaimer to the =
Framework would clarify that.]

(e) no=20
>support for handover from the IP to the circuit domain when a=20
>terminal loses (e.g. moves out of) RF coverage in the IP=20
>domain;=20

Correct. Our charter does not allow us to work on VCC.=20

[SE: also seems a suitable item for a disclaimer.]

and (f) no allowance for limited access modes wherein=20
>a terminal may access a network only to place an emergency=20
>call with ensuing restrictions on (for example) location=20
>acquisition, PSAP callback and caller verification and=20
>identification to the PSAP. To resolve this category either=20
>significant changes to the framework document could be made or=20
>a disclaimer/applicability statement could be added stating=20
>that support of cellular wireless networks and their=20
>associated WLAN and Femto access points is not covered.

This issue in under consideration in the ECRIT working group, see
http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-04.=
t
xt.=20
The reason for us to separate this aspect from the main document is simply
it's complexity and the uncertainty from a regulatory point of view.=20
When you look at the document you will quickly realize that "unauthenticate=
d
emergency calls" in an IP-based context mean much more than they do today.=
=20

We have also discussed this topic at the emergency services workshops and
the different views about this topic are interesting to observe but leave a
lot of fuzziness behind.=20

[SE: can also disclaim this.]

>=A0
>Category (C) comprises concepts and capabilities in the draft=20
>that are either already part of the standardized solution for=20
>wireless networks or that might be added at a later time.=20
>Examples of the former include LoST, SIP location conveyance,=20
>general use of SIP, location for routing versus for dispatch,=20
>cellular positioning methods. Examples of the latter include=20
>use of location references and dereferencing and possible=20
>interworking between the current wireless network solutions=20
>(in 3GPP, 3GPP2 and OMA) and the solution described in this=20
>draft. The presence of this category could be acknowledged by=20
>following the disclaimer for (B) with a statement that certain=20
>portions of the solution are expected to be incorporated into=20
>wireless networks now and/or in the future.

I am not sure I got your point. It is true that we have produced a couple o=
f
specifications and, in case of SIP Location Conveyance, the standardization
effort is not yet completed.=20

[SE: I thought this might show that 3GPP/3GPP2 have been quite diligent in =
attempting to incorporate applicable parts of the IETF solution. This seems=
 actually more a story of success (on both sides).]

>=A0
>We hope that these comments will be seen to be a useful=20
>addition to this review in the sense of enabling a more=20
>precise scoping for the framework document and we are willing=20
>to assist in providing wording for any=20
>disclaimer/applicability statement that the Ecrit working=20
>group may now deem fit to include.

Thanks for your help.=20

>=A0
>Kind Regards
>=A0

Thanks for your detailed review and for trying to help us ensuring that the
document does not raise wrong expectations.=20

Ciao
Hannes

>Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs=20
>(Qualcomm 3GPP2 TSG-X and TSG-C participant)
>
>PS  this being sent on 2/4/09 at 11:50pm PST
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>

Content-class: urn:content-classes:message
Date: Thu, 12 Feb 2009 06:28:11 -0600
From: "Dawson, Martin" <[email-masked]>
To: "Edge, Stephen" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>, "ECRIT" <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

Hello Stephen,=0D=0A=0D=0AThe bulk of your commentary appears to be based o=
n the following tenet - in your words:=0D=0A=0D=0A[SE: mainly yes. And in f=
act this is just the type of applicability statement that we are looking fo=
r - i.e. an acknowledgement that the Framework solution is mainly designed =
for wireline and non-cellular associated wireless access and is not intende=
d to apply in its entirety to cellular associated wireless access.]=0D=0A=0D=
=0AThis is quite untrue. The framework is not mainly designed for Wireline =
and non-cellular associated wireless access. The framework is designed for =
any form of Internet access. You could qualify it as broadband Internet acc=
ess if you want - but even that isn't necessary. To assume that public mobi=
le Internet access networks are somehow different is to miss the point of c=
onvergence.=0D=0A=0D=0A3GPP can define walled garden architectures such as =
IMS if it likes - it is, of course, completely up to that SDO. However, it =
doesn't really have anything to do with the IETF and doesn't, qualitatively=
, warrant a special mention from ECRIT any more than, say, maritime radio a=
nd emergency calling does.=0D=0A=0D=0AWith respect to the following:=0D=0A=0D=
=0A[SE: with terminal initiated location, the terminal can provide location=
 values that are unreliable or deliberately false (and cannot be verified a=
s such by the network) and may not provide location updates as needed by a =
PSAP. Even using location by reference (which I agree should be better), th=
e VSP plays no part though may be held liable by the PSAP or regulatory bod=
ies for any mistakes.]=0D=0A=0D=0AThe VSP plays no part in the location det=
ermination; it is the AN operator that takes this responsibility. This is, =
in fact, the same case today - even in 2G. It's the AN provider that takes =
responsibility for location determination. I cannot see a sensible judgemen=
t being made of a VSP for a piece of information for which they are not res=
ponsible. With all due respect, that sounds like FUD.=0D=0A=0D=0AWith respe=
ct to your point about location-spoofing, you're quite correct and, indeed,=
 that is one reason that LbyR is such a valuable mechanism. There's also a =
draft that describes how the LIS can digitally sign the PIDF-LO. It hasn't =
proved necessary yet but may at some point. It certainly makes one wonder h=
ow 3GPP2 can be so determined to use SUPL when there does not appear to be =
any practical means to validate SET-provided measurements when the RAN is c=
ompletely bypassed.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original=
 Message-----=0D=0AFrom: [email-masked] [mailto:ecrit-bounces@ietf.=
org] On Behalf Of Edge, Stephen=0D=0ASent: Thursday, 12 February 2009 11:08=
 PM=0D=0ATo: Hannes Tschofenig; 'ECRIT'=0D=0ASubject: Re: [Ecrit] Comments =
on Framework Draft=0D=0A=0D=0AHi Hannes=0D=0A=0D=0AThanks for all these com=
ments. I have embedded below a number of responses (look for [SE: .... ]). =
The previous suggestions remain, however, unchanged from our perspective. W=
hether it is worth attempting to align the two solutions more at this stage=
 seems questionable. By including appropriate disclaimers, the Framework (a=
nd phoneBCP) spec.s can continue to define an optimum solution for exactly =
the call scenarios for which they were really intended leaving it clearer t=
han before that an alternative solution exists for a good portion of the mi=
ssing cases. Merging part of one solution into the other might not create a=
nything very useful and changing one solution or the other risks losing som=
e of its current optimality. But I agree that this could still be looked at=
 on one or both sides and in fact in 3GPP we have made some limited attempt=
s at this already to create a more generic solution with fewer restrictions=
 on AN and VSP combinations.=0D=0A=0D=0AKind Regards=0D=0A=0D=0AStephen=0D=0A=
-----Original Message-----=0D=0AFrom: Hannes Tschofenig [mailto:Hannes.Tsch=
[email-masked]]=20=0D=0ASent: Thursday, February 05, 2009 1:18 AM=0D=0ATo: =
Edge, Stephen; 'ECRIT'=0D=0ASubject: RE: [Ecrit] Comments on Framework Draf=
t=0D=0A=0D=0AHi Stephen,=20=0D=0A=0D=0AThanks for your review. A few minor =
comments.=20=0D=0A=0D=0A>-----Original Message-----=0D=0A>From: ecrit-bounc=
[email-masked] [mailto:[email-masked]]=20=0D=0A>On Behalf Of Edge, Ste=
phen=0D=0A>Sent: 05 February, 2009 09:50=0D=0A>To: 'ECRIT'=0D=0A>Subject: [=
Ecrit] Comments on Framework Draft=0D=0A>=0D=0A>All=0D=0A>=A0=0D=0A>draft-i=
etf-ecrit-framework-07 is (as we see it) a mostly=20=0D=0A>informative desc=
ription of how terminals and networks should=20=0D=0A>support emergency cal=
ls made over IP capable facilities to IP=20=0D=0A>capable PSAPs. It appears=
 intended to cover all types of=20=0D=0A>access network - including fixed l=
ine, WiFi and cellular (e.g.=20=0D=0A>examples involving each can be found =
throughout the draft).=0D=0A=0D=0ACorrect. The framework document is the in=
formative description where=20=0D=0Ahttp://www.ietf.org/internet-drafts/dra=
ft-ietf-ecrit-phonebcp-07.txt=0D=0Aprovides the normative part.=20=0D=0A=0D=
=0AWe thought that this would make it easy for the reader to follow the ent=
ire=0D=0Astory best.=20=0D=0A=0D=0A>=A0=0D=0A>When we evaluated this with r=
espect to support of wireless=20=0D=0A>cellular access and WiFi access asso=
ciated with a cellular=20=0D=0A>operator (e.g. WLAN or Femto cells integrat=
ed into a cellular=20=0D=0A>network), we found that certain portions of the=
 draft=20=0D=0A>exhibited one or more of the following characteristics:=0D=0A=
>=A0=0D=0A>=A0=A0=A0 (A) Inconsistent with already standardized wireless so=
lutions=0D=0A>=A0=0D=0A>=A0=A0=A0 (B) Inconsistent with essential wireless =
requirements and=20=0D=0A>conventions=0D=0A>=A0=0D=0A>=A0=A0=A0 (C) Already=
 part of wireless standards or potentially part=20=0D=0A>of future standard=
s=0D=0A>=A0=0D=0A>(A) refers to all portions of the draft framework that di=
ffer=20=0D=0A>from the requirements and procedures currently standardized =0D=
=0A>for wireless emergency access by 3GPP, 3GPP2 and OMA. This is=20=0D=0A>=
a plain difference of solution and could be resolved through=20=0D=0A>suppo=
rt of both solutions by terminals (with each solution=20=0D=0A>being used a=
ccording to the type of access network and VSP) or=20=0D=0A>could be resolv=
ed by supporting only one solution and=20=0D=0A>accessing only the types of=
 network supporting that solution.=20=0D=0A>To acknowledge this category, t=
he framework document could=20=0D=0A>reference the applicable wireless stan=
dards and point out that=20=0D=0A>these are valid alternatives for wireless=
 cellular based access.=0D=0A=0D=0AYou know that we have tried hard over th=
e past few years to harmonize the=0D=0Awork done by different SDOs, includi=
ng 3GPP. You were involved in some of=0D=0Athese activities.=20=0D=0A=0D=0A=
For some reason, various companies did not like such an alignment and hence=0D=
=0Awe are left with the situation that IMS emergency calling and emergency=0D=
=0Acalling for everything else works differently.=20=0D=0A=0D=0AThis is unf=
ortunate. Your company was always a big fan of developing a=0D=0Aharmonized=
 solution, right=3F=20=0D=0A=0D=0AI doubt that the situation is improved by=
 summarizing other standardization=0D=0Aefforts in this document nor by des=
cribing the content of this document in=0D=0A3GPP, 3GPP2 or OMA documents. =0D=
=0A=0D=0A[SE: our proposal is only to acknowledge the existence of this oth=
er solution by reference not to try to summarize it.]=20=0D=0A=0D=0A>(B) re=
fers to portions of the draft that would be unsuitable=20=0D=0A>for wireles=
s networks even if no alternative solution existed=20=0D=0A>together with o=
ther portions missing from the draft that would=20=0D=0A>be needed to fully=
 support wireless networks.=0D=0A=0D=0APlease note that we make a different=
iation between wireless and cellular. I=0D=0Aguess you refer to cellular. =0D=
=0A=0D=0A[SE: mainly yes. And in fact this is just the type of applicabilit=
y statement that we are looking for - i.e. an acknowledgement that the Fram=
ework solution is mainly designed for wireline and non-cellular associated =
wireless access and is not intended to apply in its entirety to cellular as=
sociated wireless access.]=0D=0A=0D=0A Examples of the=20=0D=0A>former incl=
ude: (a) emphasis on endpoint derivation of=20=0D=0A>location, performance =
of Lost query and receipt of local dial=20=0D=0A>strings;=0D=0A=0D=0APlease=
 note that we are talking about location for 2 different purposes=0D=0Ahere=
:=20=0D=0A* Location for routing=20=0D=0A* Location for dispatch=0D=0A=0D=0A=
It is true that the document puts a focus on the end point obtaining=0D=0Al=
ocation (at least for routing). There is, however, a story in there for the=0D=
=0Acase where the end point does not have access to location at all.=20=0D=0A=0D=
=0AHaving access to local dial strings at the end point is a very useful th=
ing,=0D=0Aif you think about it.=20=0D=0A=0D=0ARegarding LoST: Please note =
that LoST can also be executed by the VoIP=0D=0Aprovider when routing is re=
quired.=20=0D=0A=0D=0A[SE: yes I was aware of this, but it is treated as so=
mething of an exception whereas for cellular networks, it is the norm.]=0D=0A=0D=
=0A>(b) restriction of LCPs to protocols that require=20=0D=0A>terminal ini=
tiation (not allowing for network initiation as=20=0D=0A>far as we can tell=
) and that include two LCPs (DHCP and LLDP)=20=0D=0A>that are not applicabl=
e to (not defined for) cellular access;=20=0D=0A=0D=0AThese two LCPs are on=
ly required for devices that can also be used in a=0D=0Afixed / wireless (b=
ut not cellular) environment. In environments where the=0D=0Aend host is ex=
pected to only ever use a cellular system these two LCPs need=0D=0Anot to b=
e implemented.=20=0D=0A=0D=0ANetwork initiation has never found huge excite=
ment within the members of the=0D=0AGEOPRIV group. I don't see this is a li=
mitation, to be honest.=20=0D=0A=0D=0A[SE: there is no problem if the prope=
r cellular disclaimer gets added. Otherwise, I would see the need for some =
significant change to admit other types of LCP - e.g. OMA SUPL and 3GPP con=
trol plane solution.]=0D=0A=0D=0A>and (c) the requirement that a terminal o=
r at least a LIS will=20=0D=0A>update the PSAP whenever location changes.=0D=
=0A=0D=0AI guess the items below refer to the dynamic location change.=0D=0A=0D=
=0A=0D=0A (a) is impractical=20=0D=0A>due to network and terminal loading c=
onsequences=0D=0A=0D=0AI guess you see it as more dramatic than it is. The =
LIS and the PSAP can=0D=0Acontrol the rate of information disclosure, see=0D=
=0Ahttp://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-03.tx=
t.=20=0D=0A=0D=0ASpecifying at what rate the terminal would send up-to-date=
 information is=0D=0Apolicy and implementation dependent. =20=0D=0A=0D=0A a=
nd failure=20=0D=0A>to support non-IP capable PSAPs;=0D=0A=0D=0AThe IETF EC=
RIT solution is an IP-based solution and hence the Internet ends=0D=0Awhere=
 the last IP node is located.=20=0D=0AFor interworking with non-IP capable =
PSAPs please take a look at the NENA=0D=0Ai2/i2.5 work, which is the most a=
dvanced of its kind.=20=0D=0A=0D=0A[SE: A problem is that the latest i2.5 d=
raft states that "This issue of the i2 standard supports E9-1-1 for fixed a=
nd nomadic VoIP services. Support for mobile VoIP services will be covered =
in a future release of this document." We expect that the missing mobile Vo=
IP support will be provided by incorporating the 3GPP/3GPP2 solution as has=
 already occurred for the i3 draft. Whether it may also be supported by ext=
ending what is already in the i2.5 draft independently of the 3GPP/3GPP2 so=
lution remains to be seen.]=0D=0A=0D=0A (b) makes location=20=0D=0A>verific=
ation and updated location provision to PSAPs difficult=20=0D=0A>or impossi=
ble;=0D=0A=0D=0ACould you elaborate a bit=3F Not sure I understood the "ver=
ification" and the=0D=0A"updated location provisioning" part.=20=0D=0A=0D=0A=
[SE: with terminal initiated location, the terminal can provide location va=
lues that are unreliable or deliberately false (and cannot be verified as s=
uch by the network) and may not provide location updates as needed by a PSA=
P. Even using location by reference (which I agree should be better), the V=
SP plays no part though may be held liable by the PSAP or regulatory bodies=
 for any mistakes.]=0D=0A=0D=0A while (c) is also incompatible with support=
 of=20=0D=0A>existing non-IP capable PSAPs besides increasing terminal load=
=20=0D=0A>and possibly interfering with optimum maintenance of the RF=20=0D=
=0A>connection (e.g. if a terminal has to tune away from the=20=0D=0A>servi=
ng base station or WLAN periodically to make location=20=0D=0A>measurements=
).=0D=0A=0D=0AI guess you are hunting an academic problem. The document doe=
s not say that=0D=0Ayou provide a continues stream of location information.=
 We are more=0D=0Aconcerned about getting rough location as fast as possibl=
e to make the=0D=0Aemergency call routing to happen to the right PSAP and t=
hen provide=0D=0Aup-to-date location available to the PSAP for dispatch, wh=
en available.=20=0D=0A=0D=0ASure, there are corner cases when the emergency=
 caller happens to be in a=0D=0Afast car driving down the highway and locat=
ion is constantly changing.=20=0D=0A=0D=0A[SE: it just seems less efficient=
 to be obtaining and sending a stream of location updates rather than obtai=
ning a location update only when the PSAP wants it. But I agree that feasib=
ility need not be in question here.]=0D=0A=0D=0A Examples of the latter inc=
lude (d) absence of=20=0D=0A>support for access to non-IP capable PSAPs as =
already=20=0D=0A>mentioned (e.g. to support E911 phase 2 in the US);=20=0D=0A=0D=
=0AThis is excluded by our charter and, as I said, possible with the soluti=
on=0D=0ANENA has worked out with i2 and i2.5.=20=0D=0A=0D=0APlease also not=
e that today fixed (and wireless -- but not cellular)=0D=0Aoperators are lo=
oking for VoIP emergency solutions as they are somewhat=0D=0Aahead with VoI=
P deployment compared to cellular operators.=0D=0A=0D=0AHence, this will gi=
ve PSAP operators more time to migrate to an IP-based=0D=0Aenvironment and =
these things are happening as we speak. Sure, this all needs=0D=0Atime but =
the cost savings for an IP-based solution (as it was reported to=0D=0Ause a=
t the emergency services workshops) seems to speak in favor of IP.=20=0D=0A=0D=
=0A[SE: cellular operators have to support legacy PSAPs so this cannot be o=
ut of scope for the 3GPP/3GPP2 solution. But again, a short disclaimer to t=
he Framework would clarify that.]=0D=0A=0D=0A(e) no=20=0D=0A>support for ha=
ndover from the IP to the circuit domain when a=20=0D=0A>terminal loses (e.=
g. moves out of) RF coverage in the IP=20=0D=0A>domain;=20=0D=0A=0D=0ACorre=
ct. Our charter does not allow us to work on VCC.=20=0D=0A=0D=0A[SE: also s=
eems a suitable item for a disclaimer.]=0D=0A=0D=0Aand (f) no allowance for=
 limited access modes wherein=20=0D=0A>a terminal may access a network only=
 to place an emergency=20=0D=0A>call with ensuing restrictions on (for exam=
ple) location=20=0D=0A>acquisition, PSAP callback and caller verification a=
nd=20=0D=0A>identification to the PSAP. To resolve this category either=20=0D=
=0A>significant changes to the framework document could be made or=20=0D=0A=
>a disclaimer/applicability statement could be added stating=20=0D=0A>that =
support of cellular wireless networks and their=20=0D=0A>associated WLAN an=
d Femto access points is not covered.=0D=0A=0D=0AThis issue in under consid=
eration in the ECRIT working group, see=0D=0Ahttp://tools.ietf.org/id/draft=
-schulzrinne-ecrit-unauthenticated-access-04.t=0D=0Axt.=20=0D=0AThe reason =
for us to separate this aspect from the main document is simply=0D=0Ait's c=
omplexity and the uncertainty from a regulatory point of view.=20=0D=0AWhen=
 you look at the document you will quickly realize that "unauthenticated=0D=
=0Aemergency calls" in an IP-based context mean much more than they do toda=
y.=20=0D=0A=0D=0AWe have also discussed this topic at the emergency service=
s workshops and=0D=0Athe different views about this topic are interesting t=
o observe but leave a=0D=0Alot of fuzziness behind.=20=0D=0A=0D=0A[SE: can =
also disclaim this.]=0D=0A=0D=0A>=A0=0D=0A>Category (C) comprises concepts =
and capabilities in the draft=20=0D=0A>that are either already part of the =
standardized solution for=20=0D=0A>wireless networks or that might be added=
 at a later time.=20=0D=0A>Examples of the former include LoST, SIP locatio=
n conveyance,=20=0D=0A>general use of SIP, location for routing versus for =
dispatch,=20=0D=0A>cellular positioning methods. Examples of the latter inc=
lude=20=0D=0A>use of location references and dereferencing and possible=20=0D=
=0A>interworking between the current wireless network solutions=20=0D=0A>(i=
n 3GPP, 3GPP2 and OMA) and the solution described in this=20=0D=0A>draft. T=
he presence of this category could be acknowledged by=20=0D=0A>following th=
e disclaimer for (B) with a statement that certain=20=0D=0A>portions of the=
 solution are expected to be incorporated into=20=0D=0A>wireless networks n=
ow and/or in the future.=0D=0A=0D=0AI am not sure I got your point. It is t=
rue that we have produced a couple of=0D=0Aspecifications and, in case of S=
IP Location Conveyance, the standardization=0D=0Aeffort is not yet complete=
d.=20=0D=0A=0D=0A[SE: I thought this might show that 3GPP/3GPP2 have been q=
uite diligent in attempting to incorporate applicable parts of the IETF sol=
ution. This seems actually more a story of success (on both sides).]=0D=0A=0D=
=0A>=A0=0D=0A>We hope that these comments will be seen to be a useful=20=0D=
=0A>addition to this review in the sense of enabling a more=20=0D=0A>precis=
e scoping for the framework document and we are willing=20=0D=0A>to assist =
in providing wording for any=20=0D=0A>disclaimer/applicability statement th=
at the Ecrit working=20=0D=0A>group may now deem fit to include.=0D=0A=0D=0A=
Thanks for your help.=20=0D=0A=0D=0A>=A0=0D=0A>Kind Regards=0D=0A>=A0=0D=0A=0D=
=0A=0D=0AThanks for your detailed review and for trying to help us ensuring=
 that the=0D=0Adocument does not raise wrong expectations.=20=0D=0A=0D=0ACi=
ao=0D=0AHannes=0D=0A=0D=0A=0D=0A>Stephen Edge (Qualcomm 3GPP SA2 participan=
t), Kirk Burroughs=20=0D=0A>(Qualcomm 3GPP2 TSG-X and TSG-C participant)=0D=
=0A>=0D=0A>PS  this being sent on 2/4/09 at 11:50pm PST=0D=0A>=0D=0A>______=
_________________________________________=0D=0A>Ecrit mailing list=0D=0A>Ec=
[email-masked]=0D=0A>https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>=0D=0A=0D=
=0A_______________________________________________=0D=0AEcrit mailing list=0D=
=[email-masked]=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=
=0A------------------------------------------------------------------------=
------------------------=0D=0AThis message is for the designated recipient =
only and may=0D=0Acontain privileged, proprietary, or otherwise private inf=
ormation. =20=0D=0AIf you have received it in error, please notify the send=
er=0D=0Aimmediately and delete the original.  Any unauthorized use of=0D=0A=
this email is prohibited.=0D=0A--------------------------------------------=
----------------------------------------------------=0D=0A[mf2]=0D=0A

From: "Edge, Stephen" <[email-masked]>
To: "Dawson, Martin" <[email-masked]>, Hannes Tschofenig <[email-masked]>, ECRIT <[email-masked]>
Date: Thu, 12 Feb 2009 05:50:46 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Ecrit] Comments on Framework Draft

Hi Martin

Thanks for these comments (and the previous ones which I probably still nee=
d to respond to).

We are discussing two somewhat different, though not totally different, sol=
utions here each with its own particular set of limitations. Neither soluti=
on can currently and legitimately claim to be entirely global. You can call=
 one set of limitations a walled garden if you like (or maybe a more accura=
te description would be one side of a wall) and the other as temporarily ou=
t of scope but that changes nothing. The real issue is how terminals and ne=
twork operators will support IP initiated emergency calls in the most econo=
mic and effective manner in the real world where, for example, IP capable P=
SAPs will initially be quite rare, where circuit capable cellular networks =
will persist for a long time and where support for unauthenticated users ma=
y be mandated in some countries by regulators. An applicability statement i=
n the Framework and phoneBCP spec.s would provide valuable guidance to both=
 operators and vendors - and maybe it will not be quite the one we are prop=
osing either.

I assume (and hope) anyhow that this issue will be discussed within Ecrit -=
 e.g. maybe at the next IETF meeting - and that some consensus will emerge =
as to whether anything in the current drafts needs to be changed or added. =
We are willing to provide further input to that discussion if needed.

Kind Regards

Stephen
-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]]
Sent: Thursday, February 12, 2009 4:28 AM
To: Edge, Stephen; Hannes Tschofenig; ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hello Stephen,

The bulk of your commentary appears to be based on the following tenet - in=
 your words:

[SE: mainly yes. And in fact this is just the type of applicability stateme=
nt that we are looking for - i.e. an acknowledgement that the Framework sol=
ution is mainly designed for wireline and non-cellular associated wireless =
access and is not intended to apply in its entirety to cellular associated =
wireless access.]

This is quite untrue. The framework is not mainly designed for Wireline and=
 non-cellular associated wireless access. The framework is designed for any=
 form of Internet access. You could qualify it as broadband Internet access=
 if you want - but even that isn't necessary. To assume that public mobile =
Internet access networks are somehow different is to miss the point of conv=
ergence.

3GPP can define walled garden architectures such as IMS if it likes - it is=
, of course, completely up to that SDO. However, it doesn't really have any=
thing to do with the IETF and doesn't, qualitatively, warrant a special men=
tion from ECRIT any more than, say, maritime radio and emergency calling do=
es.

With respect to the following:

[SE: with terminal initiated location, the terminal can provide location va=
lues that are unreliable or deliberately false (and cannot be verified as s=
uch by the network) and may not provide location updates as needed by a PSA=
P. Even using location by reference (which I agree should be better), the V=
SP plays no part though may be held liable by the PSAP or regulatory bodies=
 for any mistakes.]

The VSP plays no part in the location determination; it is the AN operator =
that takes this responsibility. This is, in fact, the same case today - eve=
n in 2G. It's the AN provider that takes responsibility for location determ=
ination. I cannot see a sensible judgement being made of a VSP for a piece =
of information for which they are not responsible. With all due respect, th=
at sounds like FUD.

With respect to your point about location-spoofing, you're quite correct an=
d, indeed, that is one reason that LbyR is such a valuable mechanism. There=
's also a draft that describes how the LIS can digitally sign the PIDF-LO. =
It hasn't proved necessary yet but may at some point. It certainly makes on=
e wonder how 3GPP2 can be so determined to use SUPL when there does not app=
ear to be any practical means to validate SET-provided measurements when th=
e RAN is completely bypassed.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of E=
dge, Stephen
Sent: Thursday, 12 February 2009 11:08 PM
To: Hannes Tschofenig; 'ECRIT'
Subject: Re: [Ecrit] Comments on Framework Draft

Hi Hannes

Thanks for all these comments. I have embedded below a number of responses =
(look for [SE: .... ]). The previous suggestions remain, however, unchanged=
 from our perspective. Whether it is worth attempting to align the two solu=
tions more at this stage seems questionable. By including appropriate discl=
aimers, the Framework (and phoneBCP) spec.s can continue to define an optim=
um solution for exactly the call scenarios for which they were really inten=
ded leaving it clearer than before that an alternative solution exists for =
a good portion of the missing cases. Merging part of one solution into the =
other might not create anything very useful and changing one solution or th=
e other risks losing some of its current optimality. But I agree that this =
could still be looked at on one or both sides and in fact in 3GPP we have m=
ade some limited attempts at this already to create a more generic solution=
 with fewer restrictions on AN and VSP combinations.

Kind Regards

Stephen
-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Thursday, February 05, 2009 1:18 AM
To: Edge, Stephen; 'ECRIT'
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Stephen,

Thanks for your review. A few minor comments.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Edge, Stephen
>Sent: 05 February, 2009 09:50
>To: 'ECRIT'
>Subject: [Ecrit] Comments on Framework Draft
>
>All
>
>draft-ietf-ecrit-framework-07 is (as we see it) a mostly
>informative description of how terminals and networks should
>support emergency calls made over IP capable facilities to IP
>capable PSAPs. It appears intended to cover all types of
>access network - including fixed line, WiFi and cellular (e.g.
>examples involving each can be found throughout the draft).

Correct. The framework document is the informative description where
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.txt
provides the normative part.

We thought that this would make it easy for the reader to follow the entire
story best.

>
>When we evaluated this with respect to support of wireless
>cellular access and WiFi access associated with a cellular
>operator (e.g. WLAN or Femto cells integrated into a cellular
>network), we found that certain portions of the draft
>exhibited one or more of the following characteristics:
>
>    (A) Inconsistent with already standardized wireless solutions
>
>    (B) Inconsistent with essential wireless requirements and
>conventions
>
>    (C) Already part of wireless standards or potentially part
>of future standards
>
>(A) refers to all portions of the draft framework that differ
>from the requirements and procedures currently standardized
>for wireless emergency access by 3GPP, 3GPP2 and OMA. This is
>a plain difference of solution and could be resolved through
>support of both solutions by terminals (with each solution
>being used according to the type of access network and VSP) or
>could be resolved by supporting only one solution and
>accessing only the types of network supporting that solution.
>To acknowledge this category, the framework document could
>reference the applicable wireless standards and point out that
>these are valid alternatives for wireless cellular based access.

You know that we have tried hard over the past few years to harmonize the
work done by different SDOs, including 3GPP. You were involved in some of
these activities.

For some reason, various companies did not like such an alignment and hence
we are left with the situation that IMS emergency calling and emergency
calling for everything else works differently.

This is unfortunate. Your company was always a big fan of developing a
harmonized solution, right?

I doubt that the situation is improved by summarizing other standardization
efforts in this document nor by describing the content of this document in
3GPP, 3GPP2 or OMA documents.

[SE: our proposal is only to acknowledge the existence of this other soluti=
on by reference not to try to summarize it.]

>(B) refers to portions of the draft that would be unsuitable
>for wireless networks even if no alternative solution existed
>together with other portions missing from the draft that would
>be needed to fully support wireless networks.

Please note that we make a differentiation between wireless and cellular. I
guess you refer to cellular.

[SE: mainly yes. And in fact this is just the type of applicability stateme=
nt that we are looking for - i.e. an acknowledgement that the Framework sol=
ution is mainly designed for wireline and non-cellular associated wireless =
access and is not intended to apply in its entirety to cellular associated =
wireless access.]

 Examples of the
>former include: (a) emphasis on endpoint derivation of
>location, performance of Lost query and receipt of local dial
>strings;

Please note that we are talking about location for 2 different purposes
here:
* Location for routing
* Location for dispatch

It is true that the document puts a focus on the end point obtaining
location (at least for routing). There is, however, a story in there for th=
e
case where the end point does not have access to location at all.

Having access to local dial strings at the end point is a very useful thing=
,
if you think about it.

Regarding LoST: Please note that LoST can also be executed by the VoIP
provider when routing is required.

[SE: yes I was aware of this, but it is treated as something of an exceptio=
n whereas for cellular networks, it is the norm.]

>(b) restriction of LCPs to protocols that require
>terminal initiation (not allowing for network initiation as
>far as we can tell) and that include two LCPs (DHCP and LLDP)
>that are not applicable to (not defined for) cellular access;

These two LCPs are only required for devices that can also be used in a
fixed / wireless (but not cellular) environment. In environments where the
end host is expected to only ever use a cellular system these two LCPs need
not to be implemented.

Network initiation has never found huge excitement within the members of th=
e
GEOPRIV group. I don't see this is a limitation, to be honest.

[SE: there is no problem if the proper cellular disclaimer gets added. Othe=
rwise, I would see the need for some significant change to admit other type=
s of LCP - e.g. OMA SUPL and 3GPP control plane solution.]

>and (c) the requirement that a terminal or at least a LIS will
>update the PSAP whenever location changes.

I guess the items below refer to the dynamic location change.

 (a) is impractical
>due to network and terminal loading consequences

I guess you see it as more dramatic than it is. The LIS and the PSAP can
control the rate of information disclosure, see
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-03.txt.

Specifying at what rate the terminal would send up-to-date information is
policy and implementation dependent.

 and failure
>to support non-IP capable PSAPs;

The IETF ECRIT solution is an IP-based solution and hence the Internet ends
where the last IP node is located.
For interworking with non-IP capable PSAPs please take a look at the NENA
i2/i2.5 work, which is the most advanced of its kind.

[SE: A problem is that the latest i2.5 draft states that "This issue of the=
 i2 standard supports E9-1-1 for fixed and nomadic VoIP services. Support f=
or mobile VoIP services will be covered in a future release of this documen=
t." We expect that the missing mobile VoIP support will be provided by inco=
rporating the 3GPP/3GPP2 solution as has already occurred for the i3 draft.=
 Whether it may also be supported by extending what is already in the i2.5 =
draft independently of the 3GPP/3GPP2 solution remains to be seen.]

 (b) makes location
>verification and updated location provision to PSAPs difficult
>or impossible;

Could you elaborate a bit? Not sure I understood the "verification" and the
"updated location provisioning" part.

[SE: with terminal initiated location, the terminal can provide location va=
lues that are unreliable or deliberately false (and cannot be verified as s=
uch by the network) and may not provide location updates as needed by a PSA=
P. Even using location by reference (which I agree should be better), the V=
SP plays no part though may be held liable by the PSAP or regulatory bodies=
 for any mistakes.]

 while (c) is also incompatible with support of
>existing non-IP capable PSAPs besides increasing terminal load
>and possibly interfering with optimum maintenance of the RF
>connection (e.g. if a terminal has to tune away from the
>serving base station or WLAN periodically to make location
>measurements).

I guess you are hunting an academic problem. The document does not say that
you provide a continues stream of location information. We are more
concerned about getting rough location as fast as possible to make the
emergency call routing to happen to the right PSAP and then provide
up-to-date location available to the PSAP for dispatch, when available.

Sure, there are corner cases when the emergency caller happens to be in a
fast car driving down the highway and location is constantly changing.

[SE: it just seems less efficient to be obtaining and sending a stream of l=
ocation updates rather than obtaining a location update only when the PSAP =
wants it. But I agree that feasibility need not be in question here.]

 Examples of the latter include (d) absence of
>support for access to non-IP capable PSAPs as already
>mentioned (e.g. to support E911 phase 2 in the US);

This is excluded by our charter and, as I said, possible with the solution
NENA has worked out with i2 and i2.5.

Please also note that today fixed (and wireless -- but not cellular)
operators are looking for VoIP emergency solutions as they are somewhat
ahead with VoIP deployment compared to cellular operators.

Hence, this will give PSAP operators more time to migrate to an IP-based
environment and these things are happening as we speak. Sure, this all need=
s
time but the cost savings for an IP-based solution (as it was reported to
use at the emergency services workshops) seems to speak in favor of IP.

[SE: cellular operators have to support legacy PSAPs so this cannot be out =
of scope for the 3GPP/3GPP2 solution. But again, a short disclaimer to the =
Framework would clarify that.]

(e) no
>support for handover from the IP to the circuit domain when a
>terminal loses (e.g. moves out of) RF coverage in the IP
>domain;

Correct. Our charter does not allow us to work on VCC.

[SE: also seems a suitable item for a disclaimer.]

and (f) no allowance for limited access modes wherein
>a terminal may access a network only to place an emergency
>call with ensuing restrictions on (for example) location
>acquisition, PSAP callback and caller verification and
>identification to the PSAP. To resolve this category either
>significant changes to the framework document could be made or
>a disclaimer/applicability statement could be added stating
>that support of cellular wireless networks and their
>associated WLAN and Femto access points is not covered.

This issue in under consideration in the ECRIT working group, see
http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-04.=
t
xt.
The reason for us to separate this aspect from the main document is simply
it's complexity and the uncertainty from a regulatory point of view.
When you look at the document you will quickly realize that "unauthenticate=
d
emergency calls" in an IP-based context mean much more than they do today.

We have also discussed this topic at the emergency services workshops and
the different views about this topic are interesting to observe but leave a
lot of fuzziness behind.

[SE: can also disclaim this.]

>
>Category (C) comprises concepts and capabilities in the draft
>that are either already part of the standardized solution for
>wireless networks or that might be added at a later time.
>Examples of the former include LoST, SIP location conveyance,
>general use of SIP, location for routing versus for dispatch,
>cellular positioning methods. Examples of the latter include
>use of location references and dereferencing and possible
>interworking between the current wireless network solutions
>(in 3GPP, 3GPP2 and OMA) and the solution described in this
>draft. The presence of this category could be acknowledged by
>following the disclaimer for (B) with a statement that certain
>portions of the solution are expected to be incorporated into
>wireless networks now and/or in the future.

I am not sure I got your point. It is true that we have produced a couple o=
f
specifications and, in case of SIP Location Conveyance, the standardization
effort is not yet completed.

[SE: I thought this might show that 3GPP/3GPP2 have been quite diligent in =
attempting to incorporate applicable parts of the IETF solution. This seems=
 actually more a story of success (on both sides).]

>
>We hope that these comments will be seen to be a useful
>addition to this review in the sense of enabling a more
>precise scoping for the framework document and we are willing
>to assist in providing wording for any
>disclaimer/applicability statement that the Ecrit working
>group may now deem fit to include.

Thanks for your help.

>Kind Regards

Thanks for your detailed review and for trying to help us ensuring that the
document does not raise wrong expectations.

Ciao
Hannes

>Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs
>(Qualcomm 3GPP2 TSG-X and TSG-C participant)
>
>PS  this being sent on 2/4/09 at 11:50pm PST
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>

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

---------------------------------------------------------------------------=
---------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
---------------------------------------------------------------------------=
---------------------
[mf2]

Content-class: urn:content-classes:message
Date: Thu, 12 Feb 2009 08:17:26 -0600
From: "Winterbottom, James" <[email-masked]>
To: "Edge, Stephen" <[email-masked]>, "Dawson, Martin" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>, "ECRIT" <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

Hi Stephen,=0D=0A=0D=0AThe notion of unauthenticated users even in the cell=
ular space is=0D=0Atechnology constrained. If I have an CDMA phone I don't =
expect it to be=0D=0Aable to make emergency calls on a GSM network.=0D=0A=0D=
=0AIn all seriousness, if 3GPP is really concerned about have a solution=0D=
=0Athat will work everywhere, then they need to make the clear separation=0D=
=0Abetween access and application service providers and provide an=0D=0Aarc=
hitecture that fits that. Independent access providers are a reality,=0D=0A=
look at the number of wifi hotspots that exist today=3F Independent voice=0D=
=0Aservice providers are also a reality. Services and applications being=0D=
=0Aintroduced on 3G cell-phones are increasingly become independent of the=0D=
=0Anetwork provider, facebook applications are a good example. To continue=0D=
=0Ato promote achitectures that force an unnecessary binding is doing=0D=0A=
everyone a disservice.=0D=0A=0D=0AI am confident that the ECRIT architectur=
e could be employed in a 3GPP=0D=0Anetwork. As you have said below, aspects=
 that ECRIT does cover are=0D=0Adeemed out of scope for 3GPP. Perhaps expan=
ding the 3GPP scope to=0D=0Ainclude the aspects that it can't currently add=
ress would be a better=0D=0Away to gain alignment with ECRIT. I would also =
be surprised if the=0D=0Asolution were as simple and elegant was what is cu=
rrently on the table.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A=0D=
=0A-----Original Message-----=0D=0AFrom: [email-masked] [mailto:ecr=
[email-masked]] On Behalf=0D=0AOf Edge, Stephen=0D=0ASent: Friday, 13 =
February 2009 12:51 AM=0D=0ATo: Dawson, Martin; Hannes Tschofenig; ECRIT=0D=
=0ASubject: Re: [Ecrit] Comments on Framework Draft=0D=0A=0D=0AHi Martin=0D=
=0A=0D=0AThanks for these comments (and the previous ones which I probably =
still=0D=0Aneed to respond to).=0D=0A=0D=0AWe are discussing two somewhat d=
ifferent, though not totally different,=0D=0Asolutions here each with its o=
wn particular set of limitations. Neither=0D=0Asolution can currently and l=
egitimately claim to be entirely global. You=0D=0Acan call one set of limit=
ations a walled garden if you like (or maybe a=0D=0Amore accurate descripti=
on would be one side of a wall) and the other as=0D=0Atemporarily out of sc=
ope but that changes nothing. The real issue is how=0D=0Aterminals and netw=
ork operators will support IP initiated emergency=0D=0Acalls in the most ec=
onomic and effective manner in the real world where,=0D=0Afor example, IP c=
apable PSAPs will initially be quite rare, where=0D=0Acircuit capable cellu=
lar networks will persist for a long time and where=0D=0Asupport for unauth=
enticated users may be mandated in some countries by=0D=0Aregulators. An ap=
plicability statement in the Framework and phoneBCP=0D=0Aspec.s would provi=
de valuable guidance to both operators and vendors -=0D=0Aand maybe it will=
 not be quite the one we are proposing either.=0D=0A=0D=0AI assume (and hop=
e) anyhow that this issue will be discussed within=0D=0AEcrit - e.g. maybe =
at the next IETF meeting - and that some consensus=0D=0Awill emerge as to w=
hether anything in the current drafts needs to be=0D=0Achanged or added. We=
 are willing to provide further input to that=0D=0Adiscussion if needed.=0D=
=0A=0D=0AKind Regards=0D=0A=0D=0AStephen=0D=0A-----Original Message-----=0D=
=0AFrom: Dawson, Martin [mailto:[email-masked]]=0D=0ASent: Thursd=
ay, February 12, 2009 4:28 AM=0D=0ATo: Edge, Stephen; Hannes Tschofenig; EC=
RIT=0D=0ASubject: RE: [Ecrit] Comments on Framework Draft=0D=0A=0D=0AHello =
Stephen,=0D=0A=0D=0AThe bulk of your commentary appears to be based on the =
following tenet -=0D=0Ain your words:=0D=0A=0D=0A[SE: mainly yes. And in fa=
ct this is just the type of applicability=0D=0Astatement that we are lookin=
g for - i.e. an acknowledgement that the=0D=0AFramework solution is mainly =
designed for wireline and non-cellular=0D=0Aassociated wireless access and =
is not intended to apply in its entirety=0D=0Ato cellular associated wirele=
ss access.]=0D=0A=0D=0AThis is quite untrue. The framework is not mainly de=
signed for Wireline=0D=0Aand non-cellular associated wireless access. The f=
ramework is designed=0D=0Afor any form of Internet access. You could qualif=
y it as broadband=0D=0AInternet access if you want - but even that isn't ne=
cessary. To assume=0D=0Athat public mobile Internet access networks are som=
ehow different is to=0D=0Amiss the point of convergence.=0D=0A=0D=0A3GPP ca=
n define walled garden architectures such as IMS if it likes - it=0D=0Ais, =
of course, completely up to that SDO. However, it doesn't really=0D=0Ahave =
anything to do with the IETF and doesn't, qualitatively, warrant a=0D=0Aspe=
cial mention from ECRIT any more than, say, maritime radio and=0D=0Aemergen=
cy calling does.=0D=0A=0D=0AWith respect to the following:=0D=0A=0D=0A[SE: =
with terminal initiated location, the terminal can provide location=0D=0Ava=
lues that are unreliable or deliberately false (and cannot be verified=0D=0A=
as such by the network) and may not provide location updates as needed=0D=0A=
by a PSAP. Even using location by reference (which I agree should be=0D=0Ab=
etter), the VSP plays no part though may be held liable by the PSAP or=0D=0A=
regulatory bodies for any mistakes.]=0D=0A=0D=0AThe VSP plays no part in th=
e location determination; it is the AN=0D=0Aoperator that takes this respon=
sibility. This is, in fact, the same case=0D=0Atoday - even in 2G. It's the=
 AN provider that takes responsibility for=0D=0Alocation determination. I c=
annot see a sensible judgement being made of=0D=0Aa VSP for a piece of info=
rmation for which they are not responsible.=0D=0AWith all due respect, that=
 sounds like FUD.=0D=0A=0D=0AWith respect to your point about location-spoo=
fing, you're quite correct=0D=0Aand, indeed, that is one reason that LbyR i=
s such a valuable mechanism.=0D=0AThere's also a draft that describes how t=
he LIS can digitally sign the=0D=0APIDF-LO. It hasn't proved necessary yet =
but may at some point. It=0D=0Acertainly makes one wonder how 3GPP2 can be =
so determined to use SUPL=0D=0Awhen there does not appear to be any practic=
al means to validate=0D=0ASET-provided measurements when the RAN is complet=
ely bypassed.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Messa=
ge-----=0D=0AFrom: [email-masked] [mailto:[email-masked]] O=
n Behalf=0D=0AOf Edge, Stephen=0D=0ASent: Thursday, 12 February 2009 11:08 =
PM=0D=0ATo: Hannes Tschofenig; 'ECRIT'=0D=0ASubject: Re: [Ecrit] Comments o=
n Framework Draft=0D=0A=0D=0AHi Hannes=0D=0A=0D=0AThanks for all these comm=
ents. I have embedded below a number of=0D=0Aresponses (look for [SE: .... =
]). The previous suggestions remain,=0D=0Ahowever, unchanged from our persp=
ective. Whether it is worth attempting=0D=0Ato align the two solutions more=
 at this stage seems questionable. By=0D=0Aincluding appropriate disclaimer=
s, the Framework (and phoneBCP) spec.s=0D=0Acan continue to define an optim=
um solution for exactly the call=0D=0Ascenarios for which they were really =
intended leaving it clearer than=0D=0Abefore that an alternative solution e=
xists for a good portion of the=0D=0Amissing cases. Merging part of one sol=
ution into the other might not=0D=0Acreate anything very useful and changin=
g one solution or the other risks=0D=0Alosing some of its current optimalit=
y. But I agree that this could still=0D=0Abe looked at on one or both sides=
 and in fact in 3GPP we have made some=0D=0Alimited attempts at this alread=
y to create a more generic solution with=0D=0Afewer restrictions on AN and =
VSP combinations.=0D=0A=0D=0AKind Regards=0D=0A=0D=0AStephen=0D=0A-----Orig=
inal Message-----=0D=0AFrom: Hannes Tschofenig [mailto:Hannes.Tschofenig@gm=
x.net]=0D=0ASent: Thursday, February 05, 2009 1:18 AM=0D=0ATo: Edge, Stephe=
n; 'ECRIT'=0D=0ASubject: RE: [Ecrit] Comments on Framework Draft=0D=0A=0D=0A=
Hi Stephen,=0D=0A=0D=0AThanks for your review. A few minor comments.=0D=0A=0D=
=0A>-----Original Message-----=0D=0A>From: [email-masked] [mailto:e=
[email-masked]]=0D=0A>On Behalf Of Edge, Stephen=0D=0A>Sent: 05 Febr=
uary, 2009 09:50=0D=0A>To: 'ECRIT'=0D=0A>Subject: [Ecrit] Comments on Frame=
work Draft=0D=0A>=0D=0A>All=0D=0A>=0D=0A>draft-ietf-ecrit-framework-07 is (=
as we see it) a mostly=0D=0A>informative description of how terminals and n=
etworks should=0D=0A>support emergency calls made over IP capable facilitie=
s to IP=0D=0A>capable PSAPs. It appears intended to cover all types of=0D=0A=
>access network - including fixed line, WiFi and cellular (e.g.=0D=0A>examp=
les involving each can be found throughout the draft).=0D=0A=0D=0ACorrect. =
The framework document is the informative description where=0D=0Ahttp://www=
=2Eietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.txt=0D=0Aprovides =
the normative part.=0D=0A=0D=0AWe thought that this would make it easy for =
the reader to follow the=0D=0Aentire=0D=0Astory best.=0D=0A=0D=0A>=0D=0A>Wh=
en we evaluated this with respect to support of wireless=0D=0A>cellular acc=
ess and WiFi access associated with a cellular=0D=0A>operator (e.g. WLAN or=
 Femto cells integrated into a cellular=0D=0A>network), we found that certa=
in portions of the draft=0D=0A>exhibited one or more of the following chara=
cteristics:=0D=0A>=0D=0A>    (A) Inconsistent with already standardized wir=
eless solutions=0D=0A>=0D=0A>    (B) Inconsistent with essential wireless r=
equirements and=0D=0A>conventions=0D=0A>=0D=0A>    (C) Already part of wire=
less standards or potentially part=0D=0A>of future standards=0D=0A>=0D=0A>(=
A) refers to all portions of the draft framework that differ=0D=0A>from the=
 requirements and procedures currently standardized=0D=0A>for wireless emer=
gency access by 3GPP, 3GPP2 and OMA. This is=0D=0A>a plain difference of so=
lution and could be resolved through=0D=0A>support of both solutions by ter=
minals (with each solution=0D=0A>being used according to the type of access=
 network and VSP) or=0D=0A>could be resolved by supporting only one solutio=
n and=0D=0A>accessing only the types of network supporting that solution.=0D=
=0A>To acknowledge this category, the framework document could=0D=0A>refere=
nce the applicable wireless standards and point out that=0D=0A>these are va=
lid alternatives for wireless cellular based access.=0D=0A=0D=0AYou know th=
at we have tried hard over the past few years to harmonize=0D=0Athe=0D=0Awo=
rk done by different SDOs, including 3GPP. You were involved in some=0D=0Ao=
f=0D=0Athese activities.=0D=0A=0D=0AFor some reason, various companies did =
not like such an alignment and=0D=0Ahence=0D=0Awe are left with the situati=
on that IMS emergency calling and emergency=0D=0Acalling for everything els=
e works differently.=0D=0A=0D=0AThis is unfortunate. Your company was alway=
s a big fan of developing a=0D=0Aharmonized solution, right=3F=0D=0A=0D=0AI=
 doubt that the situation is improved by summarizing other=0D=0Astandardiza=
tion=0D=0Aefforts in this document nor by describing the content of this do=
cument=0D=0Ain=0D=0A3GPP, 3GPP2 or OMA documents.=0D=0A=0D=0A[SE: our propo=
sal is only to acknowledge the existence of this other=0D=0Asolution by ref=
erence not to try to summarize it.]=0D=0A=0D=0A>(B) refers to portions of t=
he draft that would be unsuitable=0D=0A>for wireless networks even if no al=
ternative solution existed=0D=0A>together with other portions missing from =
the draft that would=0D=0A>be needed to fully support wireless networks.=0D=
=0A=0D=0APlease note that we make a differentiation between wireless and=0D=
=0Acellular. I=0D=0Aguess you refer to cellular.=0D=0A=0D=0A[SE: mainly yes=
=2E And in fact this is just the type of applicability=0D=0Astatement that =
we are looking for - i.e. an acknowledgement that the=0D=0AFramework soluti=
on is mainly designed for wireline and non-cellular=0D=0Aassociated wireles=
s access and is not intended to apply in its entirety=0D=0Ato cellular asso=
ciated wireless access.]=0D=0A=0D=0A Examples of the=0D=0A>former include: =
(a) emphasis on endpoint derivation of=0D=0A>location, performance of Lost =
query and receipt of local dial=0D=0A>strings;=0D=0A=0D=0APlease note that =
we are talking about location for 2 different purposes=0D=0Ahere:=0D=0A* Lo=
cation for routing=0D=0A* Location for dispatch=0D=0A=0D=0AIt is true that =
the document puts a focus on the end point obtaining=0D=0Alocation (at leas=
t for routing). There is, however, a story in there for=0D=0Athe=0D=0Acase =
where the end point does not have access to location at all.=0D=0A=0D=0AHav=
ing access to local dial strings at the end point is a very useful=0D=0Athi=
ng,=0D=0Aif you think about it.=0D=0A=0D=0ARegarding LoST: Please note that=
 LoST can also be executed by the VoIP=0D=0Aprovider when routing is requir=
ed.=0D=0A=0D=0A[SE: yes I was aware of this, but it is treated as something=
 of an=0D=0Aexception whereas for cellular networks, it is the norm.]=0D=0A=0D=
=0A>(b) restriction of LCPs to protocols that require=0D=0A>terminal initia=
tion (not allowing for network initiation as=0D=0A>far as we can tell) and =
that include two LCPs (DHCP and LLDP)=0D=0A>that are not applicable to (not=
 defined for) cellular access;=0D=0A=0D=0AThese two LCPs are only required =
for devices that can also be used in a=0D=0Afixed / wireless (but not cellu=
lar) environment. In environments where=0D=0Athe=0D=0Aend host is expected =
to only ever use a cellular system these two LCPs=0D=0Aneed=0D=0Anot to be =
implemented.=0D=0A=0D=0ANetwork initiation has never found huge excitement =
within the members of=0D=0Athe=0D=0AGEOPRIV group. I don't see this is a li=
mitation, to be honest.=0D=0A=0D=0A[SE: there is no problem if the proper c=
ellular disclaimer gets added.=0D=0AOtherwise, I would see the need for som=
e significant change to admit=0D=0Aother types of LCP - e.g. OMA SUPL and 3=
GPP control plane solution.]=0D=0A=0D=0A>and (c) the requirement that a ter=
minal or at least a LIS will=0D=0A>update the PSAP whenever location change=
s.=0D=0A=0D=0AI guess the items below refer to the dynamic location change.=0D=
=0A=0D=0A=0D=0A (a) is impractical=0D=0A>due to network and terminal loadin=
g consequences=0D=0A=0D=0AI guess you see it as more dramatic than it is. T=
he LIS and the PSAP can=0D=0Acontrol the rate of information disclosure, se=
e=0D=0Ahttp://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-0=
3.tx=0D=0At.=0D=0A=0D=0ASpecifying at what rate the terminal would send up-=
to-date information=0D=0Ais=0D=0Apolicy and implementation dependent.=0D=0A=0D=
=0A and failure=0D=0A>to support non-IP capable PSAPs;=0D=0A=0D=0AThe IETF =
ECRIT solution is an IP-based solution and hence the Internet=0D=0Aends=0D=0A=
where the last IP node is located.=0D=0AFor interworking with non-IP capabl=
e PSAPs please take a look at the=0D=0ANENA=0D=0Ai2/i2.5 work, which is the=
 most advanced of its kind.=0D=0A=0D=0A[SE: A problem is that the latest i2=
=2E5 draft states that "This issue of=0D=0Athe i2 standard supports E9-1-1 =
for fixed and nomadic VoIP services.=0D=0ASupport for mobile VoIP services =
will be covered in a future release of=0D=0Athis document." We expect that =
the missing mobile VoIP support will be=0D=0Aprovided by incorporating the =
3GPP/3GPP2 solution as has already=0D=0Aoccurred for the i3 draft. Whether =
it may also be supported by extending=0D=0Awhat is already in the i2.5 draf=
t independently of the 3GPP/3GPP2=0D=0Asolution remains to be seen.]=0D=0A=0D=
=0A (b) makes location=0D=0A>verification and updated location provision to=
 PSAPs difficult=0D=0A>or impossible;=0D=0A=0D=0ACould you elaborate a bit=3F=
 Not sure I understood the "verification" and=0D=0Athe=0D=0A"updated locati=
on provisioning" part.=0D=0A=0D=0A[SE: with terminal initiated location, th=
e terminal can provide location=0D=0Avalues that are unreliable or delibera=
tely false (and cannot be verified=0D=0Aas such by the network) and may not=
 provide location updates as needed=0D=0Aby a PSAP. Even using location by =
reference (which I agree should be=0D=0Abetter), the VSP plays no part thou=
gh may be held liable by the PSAP or=0D=0Aregulatory bodies for any mistake=
s.]=0D=0A=0D=0A while (c) is also incompatible with support of=0D=0A>existi=
ng non-IP capable PSAPs besides increasing terminal load=0D=0A>and possibly=
 interfering with optimum maintenance of the RF=0D=0A>connection (e.g. if a=
 terminal has to tune away from the=0D=0A>serving base station or WLAN peri=
odically to make location=0D=0A>measurements).=0D=0A=0D=0AI guess you are h=
unting an academic problem. The document does not say=0D=0Athat=0D=0Ayou pr=
ovide a continues stream of location information. We are more=0D=0Aconcerne=
d about getting rough location as fast as possible to make the=0D=0Aemergen=
cy call routing to happen to the right PSAP and then provide=0D=0Aup-to-dat=
e location available to the PSAP for dispatch, when available.=0D=0A=0D=0AS=
ure, there are corner cases when the emergency caller happens to be in=0D=0A=
a=0D=0Afast car driving down the highway and location is constantly changin=
g.=0D=0A=0D=0A[SE: it just seems less efficient to be obtaining and sending=
 a stream=0D=0Aof location updates rather than obtaining a location update =
only when=0D=0Athe PSAP wants it. But I agree that feasibility need not be =
in question=0D=0Ahere.]=0D=0A=0D=0A Examples of the latter include (d) abse=
nce of=0D=0A>support for access to non-IP capable PSAPs as already=0D=0A>me=
ntioned (e.g. to support E911 phase 2 in the US);=0D=0A=0D=0AThis is exclud=
ed by our charter and, as I said, possible with the=0D=0Asolution=0D=0ANENA=
 has worked out with i2 and i2.5.=0D=0A=0D=0APlease also note that today fi=
xed (and wireless -- but not cellular)=0D=0Aoperators are looking for VoIP =
emergency solutions as they are somewhat=0D=0Aahead with VoIP deployment co=
mpared to cellular operators.=0D=0A=0D=0AHence, this will give PSAP operato=
rs more time to migrate to an IP-based=0D=0Aenvironment and these things ar=
e happening as we speak. Sure, this all=0D=0Aneeds=0D=0Atime but the cost s=
avings for an IP-based solution (as it was reported=0D=0Ato=0D=0Ause at the=
 emergency services workshops) seems to speak in favor of IP.=0D=0A=0D=0A[S=
E: cellular operators have to support legacy PSAPs so this cannot be=0D=0Ao=
ut of scope for the 3GPP/3GPP2 solution. But again, a short disclaimer=0D=0A=
to the Framework would clarify that.]=0D=0A=0D=0A(e) no=0D=0A>support for h=
andover from the IP to the circuit domain when a=0D=0A>terminal loses (e.g.=
 moves out of) RF coverage in the IP=0D=0A>domain;=0D=0A=0D=0ACorrect. Our =
charter does not allow us to work on VCC.=0D=0A=0D=0A[SE: also seems a suit=
able item for a disclaimer.]=0D=0A=0D=0Aand (f) no allowance for limited ac=
cess modes wherein=0D=0A>a terminal may access a network only to place an e=
mergency=0D=0A>call with ensuing restrictions on (for example) location=0D=0A=
>acquisition, PSAP callback and caller verification and=0D=0A>identificatio=
n to the PSAP. To resolve this category either=0D=0A>significant changes to=
 the framework document could be made or=0D=0A>a disclaimer/applicability s=
tatement could be added stating=0D=0A>that support of cellular wireless net=
works and their=0D=0A>associated WLAN and Femto access points is not covere=
d.=0D=0A=0D=0AThis issue in under consideration in the ECRIT working group,=
 see=0D=0Ahttp://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-=
access-=0D=0A04.t=0D=0Axt.=0D=0AThe reason for us to separate this aspect f=
rom the main document is=0D=0Asimply=0D=0Ait's complexity and the uncertain=
ty from a regulatory point of view.=0D=0AWhen you look at the document you =
will quickly realize that=0D=0A"unauthenticated=0D=0Aemergency calls" in an=
 IP-based context mean much more than they do=0D=0Atoday.=0D=0A=0D=0AWe hav=
e also discussed this topic at the emergency services workshops=0D=0Aand=0D=
=0Athe different views about this topic are interesting to observe but=0D=0A=
leave a=0D=0Alot of fuzziness behind.=0D=0A=0D=0A[SE: can also disclaim thi=
s.]=0D=0A=0D=0A>=0D=0A>Category (C) comprises concepts and capabilities in =
the draft=0D=0A>that are either already part of the standardized solution f=
or=0D=0A>wireless networks or that might be added at a later time.=0D=0A>Ex=
amples of the former include LoST, SIP location conveyance,=0D=0A>general u=
se of SIP, location for routing versus for dispatch,=0D=0A>cellular positio=
ning methods. Examples of the latter include=0D=0A>use of location referenc=
es and dereferencing and possible=0D=0A>interworking between the current wi=
reless network solutions=0D=0A>(in 3GPP, 3GPP2 and OMA) and the solution de=
scribed in this=0D=0A>draft. The presence of this category could be acknowl=
edged by=0D=0A>following the disclaimer for (B) with a statement that certa=
in=0D=0A>portions of the solution are expected to be incorporated into=0D=0A=
>wireless networks now and/or in the future.=0D=0A=0D=0AI am not sure I got=
 your point. It is true that we have produced a=0D=0Acouple of=0D=0Aspecifi=
cations and, in case of SIP Location Conveyance, the=0D=0Astandardization=0D=
=0Aeffort is not yet completed.=0D=0A=0D=0A[SE: I thought this might show t=
hat 3GPP/3GPP2 have been quite diligent=0D=0Ain attempting to incorporate a=
pplicable parts of the IETF solution. This=0D=0Aseems actually more a story=
 of success (on both sides).]=0D=0A=0D=0A>=0D=0A>We hope that these comment=
s will be seen to be a useful=0D=0A>addition to this review in the sense of=
 enabling a more=0D=0A>precise scoping for the framework document and we ar=
e willing=0D=0A>to assist in providing wording for any=0D=0A>disclaimer/app=
licability statement that the Ecrit working=0D=0A>group may now deem fit to=
 include.=0D=0A=0D=0AThanks for your help.=0D=0A=0D=0A>=0D=0A>Kind Regards=0D=
=0A>=0D=0A=0D=0A=0D=0AThanks for your detailed review and for trying to hel=
p us ensuring that=0D=0Athe=0D=0Adocument does not raise wrong expectations=
=2E=0D=0A=0D=0ACiao=0D=0AHannes=0D=0A=0D=0A=0D=0A>Stephen Edge (Qualcomm 3G=
PP SA2 participant), Kirk Burroughs=0D=0A>(Qualcomm 3GPP2 TSG-X and TSG-C p=
articipant)=0D=0A>=0D=0A>PS  this being sent on 2/4/09 at 11:50pm PST=0D=0A=
>=0D=0A>_______________________________________________=0D=0A>Ecrit mailing=
 list=0D=0A>[email-masked]=0D=0A>https://www.ietf.org/mailman/listinfo/ecri=
t=0D=0A>=0D=0A=0D=0A_______________________________________________=0D=0AEc=
rit mailing list=0D=[email-masked]=0D=0Ahttps://www.ietf.org/mailman/list=
info/ecrit=0D=0A=0D=0A-----------------------------------------------------=
-------------------=0D=0A------------------------=0D=0AThis message is for =
the designated recipient only and may=0D=0Acontain privileged, proprietary,=
 or otherwise private information.=0D=0AIf you have received it in error, p=
lease notify the sender=0D=0Aimmediately and delete the original.  Any unau=
thorized use of=0D=0Athis email is prohibited.=0D=0A-----------------------=
-------------------------------------------------=0D=0A--------------------=
----=0D=0A[mf2]=0D=0A=0D=0A_______________________________________________=0D=
=0AEcrit mailing list=0D=[email-masked]=0D=0Ahttps://www.ietf.org/mailman=
/listinfo/ecrit=0D=0A=0D=0A------------------------------------------------=
------------------------------------------------=0D=0AThis message is for t=
he designated recipient only and may=0D=0Acontain privileged, proprietary, =
or otherwise private information. =20=0D=0AIf you have received it in error=
, please notify the sender=0D=0Aimmediately and delete the original.  Any u=
nauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------------=
---------------------------------------------------------------------------=
-=0D=0A[mf2]=0D=0A

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[email-masked]; q=dns/txt; s=qcdkim; t=1234487715; x=1266023715; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20<[email-masked]>|To:=20" Winterbottom,=20James"=20<[email-masked]>, =0D=0A=20=20=20=20=20=20=20=20"Dawson,=20Martin"=0D=0A=09 <[email-masked]>,=0D=0A=20=20=20=20=20=20=20=20 Hannes=20Tschofenig=20<[email-masked]>,=20ECRI T=20<[email-masked]>|Date:=20Thu,=2012=20Feb=202009=2017: 15:12=20-0800|Subject:=20RE:=20[Ecrit]=20Comments=20on=20 Framework=20Draft|Thread-Topic:=20[Ecrit]=20Comments=20on =20Framework=20Draft|Thread-Index:=20AcmHZkcFqEtDIGTNRMy2 Xqm0XoWoXwAAnQ6gAWY1w+AAAmT/sAABhntAAAIxaxAAFvw30A=3D=3D |Message-ID:=20<1288E74A73964940B132A0B9EA8D8ABC535F080A@ NASANEXMB04.na.qualcomm.com>|References:=20<1288E74A73964 [email-masked]>< [email-masked]><1288E74A7396 [email-masked]> <[email-masked] om>=0D=0A=20<1288E74A73964940B132A0B9EA8D8ABC535F075F@NAS ANEXMB04.na.qualcomm.com>=0D=0A=20<E51D5B15BFDEFD448F90BD [email-masked]>|In-Reply-To:=20<E51 [email-masked]> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5524"=3B=20a=3D"15447316"; bh=qYQRHy3fLFEsESoKgfOBcjqrV9IPvcaCh+iL2hf0ZBM=; b=VWjqVUtOlSEKlMB8E/PIG+hZpdzEOjwCHa8Vle7dL1716oARgZvnKGEU 9C6mrPv1KhbixNoM9thnQIA31dL//br3vX/w964ZwZkdaBxPjbCGhK/PA vs11ejd9ZKyzAB8r1+jxner5fpT/fdz+rb5Dtud/hxroU7XYjrYm2LdXg s=;
From: "Edge, Stephen" <[email-masked]>
To: "Winterbottom, James" <[email-masked]>, "Dawson, Martin" <[email-masked]>, Hannes Tschofenig <[email-masked]>, ECRIT <[email-masked]>
Date: Thu, 12 Feb 2009 17:15:12 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Ecrit] Comments on Framework Draft

Hi James

Thanks for these further comments. To try to clarify a bit, 3GPP does not c=
laim to have a global solution nor currently is there much interest in atte=
mpting to create one. That is because the primary focus is on supporting ac=
cess to cellular operators offering voice and data service in licensed radi=
o spectrum and subject to specific regulatory requirements concerning emerg=
ency calls. Other access and voice providers are also subject to the same o=
r similar requirements of course and that is why the Ecrit solution is also=
 valuable. One could say that supporting both solutions would be a good ste=
p towards global coverage although many operators and terminal vendors can =
probably get by with just one solution or the other.

I agree that the Ecrit solution probably could be adapted and extended for =
a 3GPP/3GPP2 operator - but it would not be the exact solution that is defi=
ned now because that has too many limitations from a cellular perspective, =
a number of which we have already listed.

The result of this discussion so far seems to be to further reinforce our o=
riginal point (A) and in some ways to substantiate our point (B). The next =
step is simply to acknowledge this more explicitly which is all we are prop=
osing.

Kind Regards

Stephen
-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]]
Sent: Thursday, February 12, 2009 6:17 AM
To: Edge, Stephen; Dawson, Martin; Hannes Tschofenig; ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Stephen,

The notion of unauthenticated users even in the cellular space is
technology constrained. If I have an CDMA phone I don't expect it to be
able to make emergency calls on a GSM network.

In all seriousness, if 3GPP is really concerned about have a solution
that will work everywhere, then they need to make the clear separation
between access and application service providers and provide an
architecture that fits that. Independent access providers are a reality,
look at the number of wifi hotspots that exist today? Independent voice
service providers are also a reality. Services and applications being
introduced on 3G cell-phones are increasingly become independent of the
network provider, facebook applications are a good example. To continue
to promote achitectures that force an unnecessary binding is doing
everyone a disservice.

I am confident that the ECRIT architecture could be employed in a 3GPP
network. As you have said below, aspects that ECRIT does cover are
deemed out of scope for 3GPP. Perhaps expanding the 3GPP scope to
include the aspects that it can't currently address would be a better
way to gain alignment with ECRIT. I would also be surprised if the
solution were as simple and elegant was what is currently on the table.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Edge, Stephen
Sent: Friday, 13 February 2009 12:51 AM
To: Dawson, Martin; Hannes Tschofenig; ECRIT
Subject: Re: [Ecrit] Comments on Framework Draft

Hi Martin

Thanks for these comments (and the previous ones which I probably still
need to respond to).

We are discussing two somewhat different, though not totally different,
solutions here each with its own particular set of limitations. Neither
solution can currently and legitimately claim to be entirely global. You
can call one set of limitations a walled garden if you like (or maybe a
more accurate description would be one side of a wall) and the other as
temporarily out of scope but that changes nothing. The real issue is how
terminals and network operators will support IP initiated emergency
calls in the most economic and effective manner in the real world where,
for example, IP capable PSAPs will initially be quite rare, where
circuit capable cellular networks will persist for a long time and where
support for unauthenticated users may be mandated in some countries by
regulators. An applicability statement in the Framework and phoneBCP
spec.s would provide valuable guidance to both operators and vendors -
and maybe it will not be quite the one we are proposing either.

I assume (and hope) anyhow that this issue will be discussed within
Ecrit - e.g. maybe at the next IETF meeting - and that some consensus
will emerge as to whether anything in the current drafts needs to be
changed or added. We are willing to provide further input to that
discussion if needed.

Kind Regards

Stephen
-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]]
Sent: Thursday, February 12, 2009 4:28 AM
To: Edge, Stephen; Hannes Tschofenig; ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hello Stephen,

The bulk of your commentary appears to be based on the following tenet -
in your words:

[SE: mainly yes. And in fact this is just the type of applicability
statement that we are looking for - i.e. an acknowledgement that the
Framework solution is mainly designed for wireline and non-cellular
associated wireless access and is not intended to apply in its entirety
to cellular associated wireless access.]

This is quite untrue. The framework is not mainly designed for Wireline
and non-cellular associated wireless access. The framework is designed
for any form of Internet access. You could qualify it as broadband
Internet access if you want - but even that isn't necessary. To assume
that public mobile Internet access networks are somehow different is to
miss the point of convergence.

3GPP can define walled garden architectures such as IMS if it likes - it
is, of course, completely up to that SDO. However, it doesn't really
have anything to do with the IETF and doesn't, qualitatively, warrant a
special mention from ECRIT any more than, say, maritime radio and
emergency calling does.

With respect to the following:

[SE: with terminal initiated location, the terminal can provide location
values that are unreliable or deliberately false (and cannot be verified
as such by the network) and may not provide location updates as needed
by a PSAP. Even using location by reference (which I agree should be
better), the VSP plays no part though may be held liable by the PSAP or
regulatory bodies for any mistakes.]

The VSP plays no part in the location determination; it is the AN
operator that takes this responsibility. This is, in fact, the same case
today - even in 2G. It's the AN provider that takes responsibility for
location determination. I cannot see a sensible judgement being made of
a VSP for a piece of information for which they are not responsible.
With all due respect, that sounds like FUD.

With respect to your point about location-spoofing, you're quite correct
and, indeed, that is one reason that LbyR is such a valuable mechanism.
There's also a draft that describes how the LIS can digitally sign the
PIDF-LO. It hasn't proved necessary yet but may at some point. It
certainly makes one wonder how 3GPP2 can be so determined to use SUPL
when there does not appear to be any practical means to validate
SET-provided measurements when the RAN is completely bypassed.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Edge, Stephen
Sent: Thursday, 12 February 2009 11:08 PM
To: Hannes Tschofenig; 'ECRIT'
Subject: Re: [Ecrit] Comments on Framework Draft

Hi Hannes

Thanks for all these comments. I have embedded below a number of
responses (look for [SE: .... ]). The previous suggestions remain,
however, unchanged from our perspective. Whether it is worth attempting
to align the two solutions more at this stage seems questionable. By
including appropriate disclaimers, the Framework (and phoneBCP) spec.s
can continue to define an optimum solution for exactly the call
scenarios for which they were really intended leaving it clearer than
before that an alternative solution exists for a good portion of the
missing cases. Merging part of one solution into the other might not
create anything very useful and changing one solution or the other risks
losing some of its current optimality. But I agree that this could still
be looked at on one or both sides and in fact in 3GPP we have made some
limited attempts at this already to create a more generic solution with
fewer restrictions on AN and VSP combinations.

Kind Regards

Stephen
-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Thursday, February 05, 2009 1:18 AM
To: Edge, Stephen; 'ECRIT'
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Stephen,

Thanks for your review. A few minor comments.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Edge, Stephen
>Sent: 05 February, 2009 09:50
>To: 'ECRIT'
>Subject: [Ecrit] Comments on Framework Draft
>
>All
>
>draft-ietf-ecrit-framework-07 is (as we see it) a mostly
>informative description of how terminals and networks should
>support emergency calls made over IP capable facilities to IP
>capable PSAPs. It appears intended to cover all types of
>access network - including fixed line, WiFi and cellular (e.g.
>examples involving each can be found throughout the draft).

Correct. The framework document is the informative description where
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.txt
provides the normative part.

We thought that this would make it easy for the reader to follow the
entire
story best.

>
>When we evaluated this with respect to support of wireless
>cellular access and WiFi access associated with a cellular
>operator (e.g. WLAN or Femto cells integrated into a cellular
>network), we found that certain portions of the draft
>exhibited one or more of the following characteristics:
>
>    (A) Inconsistent with already standardized wireless solutions
>
>    (B) Inconsistent with essential wireless requirements and
>conventions
>
>    (C) Already part of wireless standards or potentially part
>of future standards
>
>(A) refers to all portions of the draft framework that differ
>from the requirements and procedures currently standardized
>for wireless emergency access by 3GPP, 3GPP2 and OMA. This is
>a plain difference of solution and could be resolved through
>support of both solutions by terminals (with each solution
>being used according to the type of access network and VSP) or
>could be resolved by supporting only one solution and
>accessing only the types of network supporting that solution.
>To acknowledge this category, the framework document could
>reference the applicable wireless standards and point out that
>these are valid alternatives for wireless cellular based access.

You know that we have tried hard over the past few years to harmonize
the
work done by different SDOs, including 3GPP. You were involved in some
of
these activities.

For some reason, various companies did not like such an alignment and
hence
we are left with the situation that IMS emergency calling and emergency
calling for everything else works differently.

This is unfortunate. Your company was always a big fan of developing a
harmonized solution, right?

I doubt that the situation is improved by summarizing other
standardization
efforts in this document nor by describing the content of this document
in
3GPP, 3GPP2 or OMA documents.

[SE: our proposal is only to acknowledge the existence of this other
solution by reference not to try to summarize it.]

>(B) refers to portions of the draft that would be unsuitable
>for wireless networks even if no alternative solution existed
>together with other portions missing from the draft that would
>be needed to fully support wireless networks.

Please note that we make a differentiation between wireless and
cellular. I
guess you refer to cellular.

[SE: mainly yes. And in fact this is just the type of applicability
statement that we are looking for - i.e. an acknowledgement that the
Framework solution is mainly designed for wireline and non-cellular
associated wireless access and is not intended to apply in its entirety
to cellular associated wireless access.]

 Examples of the
>former include: (a) emphasis on endpoint derivation of
>location, performance of Lost query and receipt of local dial
>strings;

Please note that we are talking about location for 2 different purposes
here:
* Location for routing
* Location for dispatch

It is true that the document puts a focus on the end point obtaining
location (at least for routing). There is, however, a story in there for
the
case where the end point does not have access to location at all.

Having access to local dial strings at the end point is a very useful
thing,
if you think about it.

Regarding LoST: Please note that LoST can also be executed by the VoIP
provider when routing is required.

[SE: yes I was aware of this, but it is treated as something of an
exception whereas for cellular networks, it is the norm.]

>(b) restriction of LCPs to protocols that require
>terminal initiation (not allowing for network initiation as
>far as we can tell) and that include two LCPs (DHCP and LLDP)
>that are not applicable to (not defined for) cellular access;

These two LCPs are only required for devices that can also be used in a
fixed / wireless (but not cellular) environment. In environments where
the
end host is expected to only ever use a cellular system these two LCPs
need
not to be implemented.

Network initiation has never found huge excitement within the members of
the
GEOPRIV group. I don't see this is a limitation, to be honest.

[SE: there is no problem if the proper cellular disclaimer gets added.
Otherwise, I would see the need for some significant change to admit
other types of LCP - e.g. OMA SUPL and 3GPP control plane solution.]

>and (c) the requirement that a terminal or at least a LIS will
>update the PSAP whenever location changes.

I guess the items below refer to the dynamic location change.

 (a) is impractical
>due to network and terminal loading consequences

I guess you see it as more dramatic than it is. The LIS and the PSAP can
control the rate of information disclosure, see
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-03.tx
t.

Specifying at what rate the terminal would send up-to-date information
is
policy and implementation dependent.

 and failure
>to support non-IP capable PSAPs;

The IETF ECRIT solution is an IP-based solution and hence the Internet
ends
where the last IP node is located.
For interworking with non-IP capable PSAPs please take a look at the
NENA
i2/i2.5 work, which is the most advanced of its kind.

[SE: A problem is that the latest i2.5 draft states that "This issue of
the i2 standard supports E9-1-1 for fixed and nomadic VoIP services.
Support for mobile VoIP services will be covered in a future release of
this document." We expect that the missing mobile VoIP support will be
provided by incorporating the 3GPP/3GPP2 solution as has already
occurred for the i3 draft. Whether it may also be supported by extending
what is already in the i2.5 draft independently of the 3GPP/3GPP2
solution remains to be seen.]

 (b) makes location
>verification and updated location provision to PSAPs difficult
>or impossible;

Could you elaborate a bit? Not sure I understood the "verification" and
the
"updated location provisioning" part.

[SE: with terminal initiated location, the terminal can provide location
values that are unreliable or deliberately false (and cannot be verified
as such by the network) and may not provide location updates as needed
by a PSAP. Even using location by reference (which I agree should be
better), the VSP plays no part though may be held liable by the PSAP or
regulatory bodies for any mistakes.]

 while (c) is also incompatible with support of
>existing non-IP capable PSAPs besides increasing terminal load
>and possibly interfering with optimum maintenance of the RF
>connection (e.g. if a terminal has to tune away from the
>serving base station or WLAN periodically to make location
>measurements).

I guess you are hunting an academic problem. The document does not say
that
you provide a continues stream of location information. We are more
concerned about getting rough location as fast as possible to make the
emergency call routing to happen to the right PSAP and then provide
up-to-date location available to the PSAP for dispatch, when available.

Sure, there are corner cases when the emergency caller happens to be in
a
fast car driving down the highway and location is constantly changing.

[SE: it just seems less efficient to be obtaining and sending a stream
of location updates rather than obtaining a location update only when
the PSAP wants it. But I agree that feasibility need not be in question
here.]

 Examples of the latter include (d) absence of
>support for access to non-IP capable PSAPs as already
>mentioned (e.g. to support E911 phase 2 in the US);

This is excluded by our charter and, as I said, possible with the
solution
NENA has worked out with i2 and i2.5.

Please also note that today fixed (and wireless -- but not cellular)
operators are looking for VoIP emergency solutions as they are somewhat
ahead with VoIP deployment compared to cellular operators.

Hence, this will give PSAP operators more time to migrate to an IP-based
environment and these things are happening as we speak. Sure, this all
needs
time but the cost savings for an IP-based solution (as it was reported
to
use at the emergency services workshops) seems to speak in favor of IP.

[SE: cellular operators have to support legacy PSAPs so this cannot be
out of scope for the 3GPP/3GPP2 solution. But again, a short disclaimer
to the Framework would clarify that.]

(e) no
>support for handover from the IP to the circuit domain when a
>terminal loses (e.g. moves out of) RF coverage in the IP
>domain;

Correct. Our charter does not allow us to work on VCC.

[SE: also seems a suitable item for a disclaimer.]

and (f) no allowance for limited access modes wherein
>a terminal may access a network only to place an emergency
>call with ensuing restrictions on (for example) location
>acquisition, PSAP callback and caller verification and
>identification to the PSAP. To resolve this category either
>significant changes to the framework document could be made or
>a disclaimer/applicability statement could be added stating
>that support of cellular wireless networks and their
>associated WLAN and Femto access points is not covered.

This issue in under consideration in the ECRIT working group, see
http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-
04.t
xt.
The reason for us to separate this aspect from the main document is
simply
it's complexity and the uncertainty from a regulatory point of view.
When you look at the document you will quickly realize that
"unauthenticated
emergency calls" in an IP-based context mean much more than they do
today.

We have also discussed this topic at the emergency services workshops
and
the different views about this topic are interesting to observe but
leave a
lot of fuzziness behind.

[SE: can also disclaim this.]

>
>Category (C) comprises concepts and capabilities in the draft
>that are either already part of the standardized solution for
>wireless networks or that might be added at a later time.
>Examples of the former include LoST, SIP location conveyance,
>general use of SIP, location for routing versus for dispatch,
>cellular positioning methods. Examples of the latter include
>use of location references and dereferencing and possible
>interworking between the current wireless network solutions
>(in 3GPP, 3GPP2 and OMA) and the solution described in this
>draft. The presence of this category could be acknowledged by
>following the disclaimer for (B) with a statement that certain
>portions of the solution are expected to be incorporated into
>wireless networks now and/or in the future.

I am not sure I got your point. It is true that we have produced a
couple of
specifications and, in case of SIP Location Conveyance, the
standardization
effort is not yet completed.

[SE: I thought this might show that 3GPP/3GPP2 have been quite diligent
in attempting to incorporate applicable parts of the IETF solution. This
seems actually more a story of success (on both sides).]

>
>We hope that these comments will be seen to be a useful
>addition to this review in the sense of enabling a more
>precise scoping for the framework document and we are willing
>to assist in providing wording for any
>disclaimer/applicability statement that the Ecrit working
>group may now deem fit to include.

Thanks for your help.

>Kind Regards

Thanks for your detailed review and for trying to help us ensuring that
the
document does not raise wrong expectations.

Ciao
Hannes

>Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs
>(Qualcomm 3GPP2 TSG-X and TSG-C participant)
>
>PS  this being sent on 2/4/09 at 11:50pm PST
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>

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

------------------------------------------------------------------------
------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------
------------------------
[mf2]

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

---------------------------------------------------------------------------=
---------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
---------------------------------------------------------------------------=
---------------------
[mf2]

Date: Fri, 13 Feb 2009 22:18:12 +0100
From: Karl Heinz Wolf <[email-masked]>
To: [email-masked], ECRIT <[email-masked]>
Subject: [Ecrit] code sprint @ IETF 74?

are there plans for an ECRIT/GEOPRIV code sprint at the next IETF meeting?

thanks,

karl heinz

From: [email-masked]
To: [email-masked]
Date: Sun, 15 Feb 2009 09:30:01 -0800 (PST)
Cc: [email-masked]
Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-03.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF.

	Title           : Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements
	Author(s)       : H. Schulzrinne, H. Tschofenig
	Filename        : draft-ietf-ecrit-lost-sync-03.txt
	Pages           : 26
	Date            : 2009-02-15

The Location-to-Service Translation (LoST) protocol is an XML-based
protocol for mapping service identifiers and geodetic or civic
location information to service URIs and service boundaries.  In
particular, it can be used to determine the location-appropriate
Public Safety Answering Point (PSAP) for emergency services.

The main data structure, the XML <mapping> element, used for
encapsulating information about service boundaries is defined in the
LoST protocol specification and circumscribes the region within which
all locations map to the same service URI or set of URIs for a given
service.

This document defines an XML protocol to exchange these mappings
between two nodes.  As motived in the Location-to-URL Mapping
Architecture document this mechanism is useful for the
synchronization of top-level LoST Forest Guides.  This document is,
however, even useful in a deployment that does not make use of the
LoST protocol but purely wants to distribute service boundaries.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ecrit-lost-sync-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From: "Hannes Tschofenig" <[email-masked]>
To: <[email-masked]>
Date: Sun, 15 Feb 2009 22:17:48 +0200
Subject: [Ecrit] LoST Sync

This is a multi-part message in MIME format.

------=_NextPart_000_004B_01C98FBB.3C99F9B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Based on the feedback from Richard and Karl Heinz I have updated the
document: 
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-03.txt

Ciao
Hannes

------=_NextPart_000_004B_01C98FBB.3C99F9B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>LoST Sync</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D4 FACE=3D"Courier New">Based on the feedback from =
Richard and Karl Heinz I have updated the document: </FONT>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-03=
.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D4 FACE=3D"Courier =
New">http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-03.tx=
t</FONT></U></A>
</P>

<P><FONT SIZE=3D4 FACE=3D"Courier New">Ciao</FONT>

<BR><FONT SIZE=3D4 FACE=3D"Courier New">Hannes</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_004B_01C98FBB.3C99F9B0--

Content-class: urn:content-classes:message
Date: Mon, 16 Feb 2009 11:26:55 +0200
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
To: <[email-masked]>, "ECRIT" <[email-masked]>
Subject: Re: [Ecrit] code sprint @ IETF 74?

Hi Karl Heinz,=20

I am available on Saturday before the IETF meeting.=20

I would be interested in reviewing / testing the RFC 4776 and RFC
3825/draft-thomson-geopriv-3825bis code.=20

I could also test the RADIUS GEOPRIV stuff.=20

I wonder whether it would be possible to test the LoST Sync mechanism.=20

Ciao
Hannes

>-----Original Message-----
>From: [email-masked]=20
>[mailto:[email-masked]] On Behalf Of ext Karl Heinz Wolf
>Sent: 13 February, 2009 23:18
>To: [email-masked]; ECRIT
>Subject: code sprint @ IETF 74?
>
>
>are there plans for an ECRIT/GEOPRIV code sprint at the next=20
>IETF meeting?
>
>thanks,
>
>karl heinz
>
>--~--~---------~--~----~------------~-------~--~----~
>You received this message because you are subscribed to the=20
>Google Groups "Location Implementation" group.
>To post to this group, send email to [email-masked]=20
>To unsubscribe from this group, send email to=20
>[email-masked]
>For more options, visit this group at=20
>http://groups.google.com/group/loc-imp?hl=3Den
>-~----------~----~----~----~------~----~------~--~---
>
>

From: "Hannes Tschofenig" <[email-masked]>
To: "ECRIT" <[email-masked]>
Date: Wed, 18 Feb 2009 21:10:13 +0200
Subject: [Ecrit] PROTO shepherd for RPH

In a discussion with Marc we decided that Marc is going to be the PROTO
shepherd for the document. 
I believe that I would not do a good job with this document. 

Marc is also going to brainstorm on how to move forward with it. 

Ciao
Hannes

From: "Brian Rosen" <[email-masked]>
To: "'Edge, Stephen'" <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Wed, 18 Feb 2009 14:07:21 -0500
Subject: Re: [Ecrit] Comments on Framework Draft

I have bit my tongue on this one for a long time.

Stephen, with respect, please go talk to 3GPP management and ask them  =
why
there has been no participation in the ecrit effort despite multiple =
YEARS
of begging them to get involved.  To put it frankly, 3GPP is quite =
willing
to bully IETF into doing its work on its schedule, but cannot be =
bothered to
get work done it knows it will eventually have to do when the IETF asks =
it
to do so.

3GPP understands the mess that is being created by not participating.  =
They
know full well that when they finally get around to dealing with PS
terminated emergency calls, that there will be a lot of resistance to
changing fully specified and implemented standards to more closely align
with 3GPP standards.  I expect you will have several interworking =
functions
to define and build.

So, politely, please go away, we're finishing work we dearly wanted you =
all
to be involved with for years, but you refused to do anything.  It's too
late for this rev.

Now, having said that, there are quite a few people who have =
participated in
the IETF work who are IMS aware and I believe that despite your fears,
everything you need is in the specs.  The mechanisms we have defined =
provide
the ability for the network to insert location, recognize and mark =
emergency
calls, and route on behalf of endpoints.  An E-CSCF could quite
straightforwardly provide a SIP call towards an ecrit compatible PSAP.  =
The
only not-quite-nice interwork would be from SUPL to HELD (or SIP), but =
it's
pretty easy to do that.  I'll also note that we have tried to get OMA =
and
IETF to cooperate on location protocols, but we have been spectacularly
unsuccessful at that effort also.

Brian

 =20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Edge, Stephen
> Sent: Thursday, February 05, 2009 2:50 AM
> To: 'ECRIT'
> Subject: [Ecrit] Comments on Framework Draft
>=20
> All
>=20
> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative
> description of how terminals and networks should support emergency
> calls made over IP capable facilities to IP capable PSAPs. It appears
> intended to cover all types of access network - including fixed line,
> WiFi and cellular (e.g. examples involving each can be found =
throughout
> the draft).
>=20
> When we evaluated this with respect to support of wireless cellular
> access and WiFi access associated with a cellular operator (e.g. WLAN
> or Femto cells integrated into a cellular network), we found that
> certain portions of the draft exhibited one or more of the following
> characteristics:
>=20
> =A0=A0=A0 (A) Inconsistent with already standardized wireless =
solutions
>=20
> =A0=A0=A0 (B) Inconsistent with essential wireless requirements and
> conventions
>=20
> =A0=A0=A0 (C) Already part of wireless standards or potentially part =
of
> future standards
>=20
> (A) refers to all portions of the draft framework that differ from the
> requirements and procedures currently standardized for wireless
> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference of
> solution and could be resolved through support of both solutions by
> terminals (with each solution being used according to the type of
> access network and VSP) or could be resolved by supporting only one
> solution and accessing only the types of network supporting that
> solution. To acknowledge this category, the framework document could
> reference the applicable wireless standards and point out that these
> are valid alternatives for wireless cellular based access.
>=20
> (B) refers to portions of the draft that would be unsuitable for
> wireless networks even if no alternative solution existed together =
with
> other portions missing from the draft that would be needed to fully
> support wireless networks. Examples of the former include: (a) =
emphasis
> on endpoint derivation of location, performance of Lost query and
> receipt of local dial strings; (b) restriction of LCPs to protocols
> that require terminal initiation (not allowing for network initiation
> as far as we can tell) and that include two LCPs (DHCP and LLDP) that
> are not applicable to (not defined for) cellular access; and (c) the
> requirement that a terminal or at least a LIS will update the PSAP
> whenever location changes. (a) is impractical due to network and
> terminal loading consequences and failure to support non-IP capable
> PSAPs; (b) makes location verification and updated location provision
> to PSAPs difficult or impossible; while (c) is also incompatible with
> support of existing non-IP capable PSAPs besides increasing terminal
> load and possibly interfering with optimum maintenance of the RF
> connection (e.g. if a terminal has to tune away from the serving base
> station or WLAN periodically to make location measurements). Examples
> of the latter include (d) absence of support for access to non-IP
> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in =
the
> US); (e) no support for handover from the IP to the circuit domain =
when
> a terminal loses (e.g. moves out of) RF coverage in the IP domain; and
> (f) no allowance for limited access modes wherein a terminal may =
access
> a network only to place an emergency call with ensuing restrictions on
> (for example) location acquisition, PSAP callback and caller
> verification and identification to the PSAP. To resolve this category
> either significant changes to the framework document could be made or =
a
> disclaimer/applicability statement could be added stating that support
> of cellular wireless networks and their associated WLAN and Femto
> access points is not covered.
>=20
> Category (C) comprises concepts and capabilities in the draft that are
> either already part of the standardized solution for wireless networks
> or that might be added at a later time. Examples of the former include
> LoST, SIP location conveyance, general use of SIP, location for =
routing
> versus for dispatch, cellular positioning methods. Examples of the
> latter include use of location references and dereferencing and
> possible interworking between the current wireless network solutions
> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. The
> presence of this category could be acknowledged by following the
> disclaimer for (B) with a statement that certain portions of the
> solution are expected to be incorporated into wireless networks now
> and/or in the future.
>=20
> We hope that these comments will be seen to be a useful addition to
> this review in the sense of enabling a more precise scoping for the
> framework document and we are willing to assist in providing wording
> for any disclaimer/applicability statement that the Ecrit working =
group
> may now deem fit to include.
>=20
> Kind Regards
>=20
> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm
> 3GPP2 TSG-X and TSG-C participant)
>=20
> PS  this being sent on 2/4/09 at 11:50pm PST
>=20
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

From: "Brian Rosen" <[email-masked]>
To: "'Ted Hardie'" <[email-masked]>, "'James M. Polk'" <[email-masked]>, "'Hannes Tschofenig'" <[email-masked]>, "'DOLLY, MARTIN C,  ATTLABS'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 18 Feb 2009 14:07:21 -0500
Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] RPH

I have deliberately stayed out of this for a while, not even reading the
thread while I did some other things, but I am back now.

There are a couple of uses for multiple levels of priority from the endpoint
to the network.  Most of them are for things other than voice calls.  For
example, a device that sends an "alert" or data-only message may have a
notion of importance of the alert.  A serious building fire which tripped
multiple alarms is higher priority than a possible intruder.  In most
jurisdictions, alerts may not have as high priority than voice calls.  One
example of a voice call with an endpoint notion of multiple priority is a
situation where the caller is supplying supplemental information ("did you
know that there is a wheel on the road 1/4" mile down the road from that
multiple car accident?").  I'm not suggesting we know how to recommend how
to use this in a UI for example, but there are use cases.

In those examples, there is no other marking an intermediary could use to
determine priority.

It makes sense to use the resource priority header to request resource
priority.  It does not make sense for the IETF to define usage specific
markings for resource priority, even at the cost of some additional work, or
the possibility that the end device may not follow the recommendations.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ted Hardie
> Sent: Monday, February 09, 2009 5:03 PM
> To: James M. Polk; Hannes Tschofenig; 'DOLLY, MARTIN C, ATTLABS';
> [email-masked]; [email-masked]
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
> Subject: Re: [Ecrit] RPH
> 
> At 10:06 AM -0800 2/9/09, James M. Polk wrote:
> >Ted -- comments at the bottom
> >
> >While I generally agree with you -- until you imply that the two
> >namespaces ought go be in separate docs that have to meet somewhere
> >future somewhere in the middle of the network.
> 
> I am not sure that they do have to meet somewhere.  If ESNET internal
> communications are marked with priority values from foo and customer-
> to-ESNET
> communications are marked with values from the bar namespace, then
> any system that might handle both will eventually have to have a
> mapping
> that says something like foo3 is above bar2 but below bar1 (assuming 0
> high
> for both). But I actually suspect, honestly, that the ESNET internal
> communication
> is really either a private network or an overlay.  If that's the case
> (and
> I could be way off here), the number of times these traffic markings
> will
> be evaluated against each other seems likely to be pretty small.  Maybe
> even 0 in some deployment scenarios.
> 
> >         Please let me know if I've misread what you meant to say.
> >
> >On this, I have two thoughts:
> >
> >#1 - that several vendors and SPs have already asked for this
> >namespace to be possible in their respective VSP products and service
> >offerings - and your implied solution blows that up.
> 
> Well, I think it's already blown up, as I think the chance of consensus
> on a customer-to-ESNET namespace seems likely to be slow to emerge.
> I'm trying to see if there is a way to get something out without
> waiting
> for that consensus.
> 
> >and
> >
> >#2 - that creating (in the future) a second namespace to map directly
> >to the esnet (and it's 5 priority-values) from the UAC or VSP seems
> >like it might be begging for a lack of interoperability waiting to
> >happen type of problem.
> 
> First, this presumes that there will be a second namespace.   Fair
> enough,
> you see a customer need here.  But I am not at all sure that it would
> be a one-to-one correspondence.  I think some folks might well argue
> that customer-to-ESNET should have only two values:  "not an emergency"
> and "emergency", to simplify the discussions of how big an emergency
> deserves to go higher than some other emergency.  But I think that's
> part of the discussion of this that makes customer-to-ESNET much harder
> to work through than ESNET where who gets to decide is crystal, crystal
> clear.
> 
> >I can definitely rewrite the text emphasizing the esnet namespace is
> >for the ESInet first, with the possibility of having it come in from
> >a reliable VSP, and even a reliable UAC/UE off that reliable VSP.
> 
> And here is where I think the same syntax is being used for two
> semantics.
> If the syntax of value 1 within intra-ESINET communications isn't
> exactly
> the same as value one in customer to-ESINET communications, we look
> to be in a very long discussion indeed.  And finding some way of
> satisfying
> everyone that this is the case seems long and drawn out indeed.
> 
> Maybe I just more conflict avoidant these days, but I'd like to get
> something out and tackle the more difficult things with a sense of
> accomplishment than to bog down.  But I'm not really coding this
> myself, so it's a suggestion from the sidelines.
> 
> 					Ted
> 
> 
> 
> 
> >
> >>                         regards,
> >>                                 Ted Hardie
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

From: [email-masked]
To: [email-masked]
Date: Thu, 19 Feb 2009 18:30:01 -0800 (PST)
Cc: [email-masked]
Subject: [Ecrit] I-D Action:draft-ietf-ecrit-local-emergency-rph-namespace-01.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF.

	Title           : IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications
	Author(s)       : J. Polk
	Filename        : draft-ietf-ecrit-local-emergency-rph-namespace-01.txt
	Pages           : 7
	Date            : 2009-02-19

This document creates and IANA registers the new Session Initiation 
Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for 
local emergency usage to a public safety answering point (PSAP), 
between PSAPs, and between a PSAP and first responders and their 
organizations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ecrit-local-emergency-rph-namespace-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Date: Thu, 19 Feb 2009 20:32:44 -0600
To: "'ECRIT'" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted

ECRIT

I've just submitted a rev of the "esnet" Resource-Prioriy header draft.

I've removed all mention of UAs from the draft, but leave in the 
possibility for adjacent VSPs to have a trust relationship with the 
local ESInet and mark these SIP requests accordingly through the 
VSP's domain.  I offer that the ESRP at the ESInet edge will be 
tasked with mapping the esnet.priority-values from outside the ESInet 
to the indications used inside the ESInet.  The ID gives no guidance 
on what the priority-values should be in either case - as that is a 
matter for other documents (and I'd argue - for other SDOs or 
consortia such as NENA and EENA, though I don't mention either 
organization in the ID).

Comments are welcome

James

>From: IETF I-D Submission Tool <[email-masked]>
>To: [email-masked]
>Subject: New Version Notification for
>          draft-ietf-ecrit-local-emergency-rph-namespace-01
>Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST)
>
>
>A new version of I-D, 
>draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been 
>successfuly submitted by James Polk and posted to the IETF repository.
>
>Filename:       draft-ietf-ecrit-local-emergency-rph-namespace
>Revision:       01
>Title:          IANA Registering a SIP Resource Priority Header 
>Namespace for Local Emergency Communications
>Creation_date:  2009-02-19
>WG ID:          ecrit
>Number_of_pages: 7
>
>Abstract:
>This document creates and IANA registers the new Session Initiation
>Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
>local emergency usage to a public safety answering point (PSAP),
>between PSAPs, and between a PSAP and first responders and their
>organizations.
> 
>
>
>
>The IETF Secretariat.

Date: Thu, 19 Feb 2009 20:34:34 -0600
To: "'ECRIT'" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Subject: [Ecrit] Fwd: I-D Action:draft-polk-ecrit-local-emergency-rph-namespace-04.txt

please ignore this ID announcement -- I uploaded the wrong file initially.

sorry

>From: [email-masked]
>To: [email-masked]
>Subject: I-D Action:draft-polk-ecrit-local-emergency-rph-namespace-04.txt
>Date: Thu, 19 Feb 2009 18:30:01 -0800 (PST)
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>         Title           : IANA Registering a SIP Resource Priority 
> Header Namespace for Local Emergency Communications
>         Author(s)       : J. Polk
>         Filename        : 
> draft-polk-ecrit-local-emergency-rph-namespace-04.txt
>         Pages           : 7
>         Date            : 2009-02-19
>
>This document creates and IANA registers the new Session Initiation
>Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
>local emergency usage to a public safety answering point (PSAP),
>between PSAPs, and between a PSAP and first responders and their
>organizations.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-namespace-04.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-namespace-04.txt>
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Date: Fri, 20 Feb 2009 07:08:07 -0800
To: Hannes Tschofenig <[email-masked]>, "'Edge, Stephen'" <[email-masked]>, "'ECRIT'" <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

At 11:18 AM +0200 2/5/09, Hannes Tschofenig wrote:

>  The framework document is the informative description where
>  http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.txt
>  provides the normative part.

As an aside, since the framework is informative and doesn't contain 
any normative language, maybe it should be Informational instead of 
Proposed Standard.

>  we are left with the situation that IMS emergency calling and emergency
>  calling for everything else works differently.
>
>  This is unfortunate. Your company was always a big fan of developing a
>  harmonized solution, right?
>
>  I doubt that the situation is improved by summarizing other standardization
>  efforts in this document nor by describing the content of this document in
>  3GPP, 3GPP2 or OMA documents.

Since the reality is that cellular emergency calling uses different 
protocols and procedures, in the interest of clarity and avoiding 
misunderstandings, it seems a good idea for this document to have an 
applicability statement that says, in effect, "Cellular networks work 
differently than what is described here"?  Doing so wouldn't in any 
way detract from, or be a demerit on, the solution described here, it 
would simply clarify reality.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
You see, wire telegraph is a kind of very, very long cat.  You
pull his tail in New York and his head is meowing in Los Angeles.
Do you understand this?  And radio operates in exactly the same
way: you send signals here, they receive them there.  The only
difference is that there is no cat.            --Albert Einstein

From: "Hannes Tschofenig" <[email-masked]>
To: "'Randall Gellens'" <[email-masked]>, "'Edge, Stephen'" <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Fri, 20 Feb 2009 18:08:20 +0200
Subject: Re: [Ecrit] Comments on Framework Draft

Hi Randy, 

>At 11:18 AM +0200 2/5/09, Hannes Tschofenig wrote:
>
>>  The framework document is the informative description where  
>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.txt
>>  provides the normative part.
>
>As an aside, since the framework is informative and doesn't 
>contain any normative language, maybe it should be 
>Informational instead of Proposed Standard.

Good catch. 
This is certainly a correct observation. 

>
>>  we are left with the situation that IMS emergency calling and 
>> emergency  calling for everything else works differently.
>>
>>  This is unfortunate. Your company was always a big fan of 
>developing 
>> a  harmonized solution, right?
>>
>>  I doubt that the situation is improved by summarizing other 
>> standardization  efforts in this document nor by describing the 
>> content of this document in  3GPP, 3GPP2 or OMA documents.
>
>Since the reality is that cellular emergency calling uses 
>different protocols and procedures, in the interest of clarity 
>and avoiding misunderstandings, it seems a good idea for this 
>document to have an applicability statement that says, in 
>effect, "Cellular networks work differently than what is 
>described here"?  Doing so wouldn't in any way detract from, 
>or be a demerit on, the solution described here, it would 
>simply clarify reality.

Some organizations think that cellular networks are different and hence they
need completely different protocols and procedures. Example: WAP
 
I am not sure that many folks in the RAI area share the same view. 

Ciao
Hannes

>Randall Gellens
>Opinions are personal;    facts are suspect;    I speak for myself only
>-------------- Randomly selected tag: --------------- You see, 
>wire telegraph is a kind of very, very long cat.  You pull his 
>tail in New York and his head is meowing in Los Angeles.
>Do you understand this?  And radio operates in exactly the same
>way: you send signals here, they receive them there.  The only
>difference is that there is no cat.            --Albert Einstein
>

Date: Fri, 20 Feb 2009 08:28:58 -0800
To: Hannes Tschofenig <[email-masked]>, "'Randall Gellens'" <[email-masked]>, "'Edge, Stephen'" <[email-masked]>, "'ECRIT'" <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

Hi Hannes,

At 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote:

>   >Since the reality is that cellular emergency calling uses
>>different protocols and procedures, in the interest of clarity
>>and avoiding misunderstandings, it seems a good idea for this
>>document to have an applicability statement that says, in
>>effect, "Cellular networks work differently than what is
>>described here"?  Doing so wouldn't in any way detract from,
>>or be a demerit on, the solution described here, it would
>>simply clarify reality.
>
>  Some organizations think that cellular networks are different and hence they
>  need completely different protocols and procedures. Example: WAP
>
>  I am not sure that many folks in the RAI area share the same view.

Putting aside the question of what cellular networks *should* use, 
the issue is: what *will* they use.  Given that there is a large 
installed base and momentum for current protocols, I think it's 
unreasonable to expect that cellular networks will ditch what they 
have in favor of what's here (especially in view of the specific 
issues that Stephen raised).  Hence, to avoid confusion, it makes 
sense for this document to say that cellular networks use different 
protocols and procedures.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Any given program, when running, is obsolete.

Content-class: urn:content-classes:message
Date: Fri, 20 Feb 2009 10:54:28 -0600
From: "Winterbottom, James" <[email-masked]>
To: "Randall Gellens" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>, "Edge, Stephen" <[email-masked]>, "ECRIT" <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

I actually don't see what benefit adding this statement does to the documen=
t.=0D=0AI do however see some harm in providing.=0D=0A=0D=0AIf as a potenti=
al 3G or 4G operator I wish to offer a broadband service and, rather than p=
roviding a SUPL service I wish to provide some other service so that it is =
compatible with ECRIT, then I can't, because ECRIT has a clear applicabilit=
y statement saying that it is not appropriate.=0D=0A=0D=0AIf operators of c=
ellular networks wish to continue to deploy networks based on 3GPP architec=
tures then are entitled to do so. It would however, be doing them a disserv=
ice to suggest that there is not a viable alternative.=0D=0A=0D=0ACheers=0D=
=0AJames=0D=0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounc=
[email-masked] on behalf of Randall Gellens=0D=0ASent: Fri 2/20/2009 10:28 AM=0D=
=0ATo: Hannes Tschofenig; 'Randall Gellens'; 'Edge, Stephen'; 'ECRIT'=0D=0A=
Subject: Re: [Ecrit] Comments on Framework Draft=0D=0A=20=0D=0AHi Hannes,=0D=
=0A=0D=0AAt 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote:=0D=0A=0D=0A>   =
>Since the reality is that cellular emergency calling uses=0D=0A>>different=
 protocols and procedures, in the interest of clarity=0D=0A>>and avoiding m=
isunderstandings, it seems a good idea for this=0D=0A>>document to have an =
applicability statement that says, in=0D=0A>>effect, "Cellular networks wor=
k differently than what is=0D=0A>>described here"=3F  Doing so wouldn't in =
any way detract from,=0D=0A>>or be a demerit on, the solution described her=
e, it would=0D=0A>>simply clarify reality.=0D=0A>=0D=0A>  Some organization=
s think that cellular networks are different and hence they=0D=0A>  need co=
mpletely different protocols and procedures. Example: WAP=0D=0A>=0D=0A>  I =
am not sure that many folks in the RAI area share the same view.=0D=0A=0D=0A=
Putting aside the question of what cellular networks *should* use,=20=0D=0A=
the issue is: what *will* they use.  Given that there is a large=20=0D=0Ain=
stalled base and momentum for current protocols, I think it's=20=0D=0Aunrea=
sonable to expect that cellular networks will ditch what they=20=0D=0Ahave =
in favor of what's here (especially in view of the specific=20=0D=0Aissues =
that Stephen raised).  Hence, to avoid confusion, it makes=20=0D=0Asense fo=
r this document to say that cellular networks use different=20=0D=0Aprotoco=
ls and procedures.=0D=0A=0D=0A--=20=0D=0ARandall Gellens=0D=0AOpinions are =
personal;    facts are suspect;    I speak for myself only=0D=0A-----------=
--- Randomly selected tag: ---------------=0D=0AAny given program, when run=
ning, is obsolete.=0D=0A_______________________________________________=0D=0A=
Ecrit mailing list=0D=[email-masked]=0D=0Ahttps://www.ietf.org/mailman/li=
stinfo/ecrit=0D=0A=0D=0A=0D=0A---------------------------------------------=
---------------------------------------------------=0D=0AThis message is fo=
r the designated recipient only and may=0D=0Acontain privileged, proprietar=
y, or otherwise private information. =20=0D=0AIf you have received it in er=
ror, please notify the sender=0D=0Aimmediately and delete the original.  An=
y unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----------------=
---------------------------------------------------------------------------=
----=0D=0A[mf2]=0D=0A

From: Henning Schulzrinne <[email-masked]>
To: Randall Gellens <[email-masked]>
Date: Fri, 20 Feb 2009 12:06:59 -0500
Cc: 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

>
> Putting aside the question of what cellular networks *should* use,  
> the issue is: what *will* they use.  Given that there is a large  
> installed base and momentum for current protocols, I think it's  
> unreasonable to expect that cellular networks will ditch what they  
> have in favor of what's here (especially in view of the specific  
> issues that Stephen raised).  Hence, to avoid confusion, it makes  
> sense for this document to say that cellular networks use different  
> protocols and procedures.
>

We're not trying to write survey papers here, and this information may  
well be incorrect a few years from now, so I don't see much value in  
adding a statement that may well be (and we hope to be) out of date  
soon. Plus, it is quite possible that cellular-like networks, such as  
WiMax, will use the framework mechanisms. In addition, VSPs operating  
over EVDO, HSPA or LTE may well also use these mechanisms, so the  
statement, unless heavily qualified, may be wrong almost from the day  
the RFC is published.

Henning

From: "Hannes Tschofenig" <[email-masked]>
To: "'Randall Gellens'" <[email-masked]>, "'Edge, Stephen'" <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Fri, 20 Feb 2009 19:21:12 +0200
Subject: Re: [Ecrit] Comments on Framework Draft

>>  Some organizations think that cellular networks are different and 
>> hence they  need completely different protocols and procedures. 
>> Example: WAP
>>
>>  I am not sure that many folks in the RAI area share the same view.
>
>Putting aside the question of what cellular networks *should* 
>use, the issue is: what *will* they use.

Nobody knows what the future will bring us. 

>Given that there is 
>a large installed base 

We are talking about future systems -- not about past systems. 

>and momentum for current protocols,

Momentum for what protocols in this context? 

> I 
>think it's unreasonable to expect that cellular networks will 
>ditch what they have in favor of what's here (especially in 
>view of the specific issues that Stephen raised).

I am not sure what they have to ditch.

>Hence, to 
>avoid confusion, it makes sense for this document to say that 
>cellular networks use different protocols and procedures.

I am sure you have your reason to make these claims but I don't understand
them. 

Ciao
Hannes

Date: Fri, 20 Feb 2009 13:39:15 -0500
From: Marc Linsner <[email-masked]>
To: Randall Gellens <[email-masked]>, "'ECRIT'" <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

Randy,

I'm curious if there are people that believe the IETF writes cellular
standards?

I'm not sure the confusion you are trying to correct exists...(but that's my
view, subject to change via more information).

-Marc-

On 2/20/09 11:28 AM, "Randall Gellens" <[email-masked]> wrote:

> Hi Hannes,
> 
> At 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote:
> 
>>> Since the reality is that cellular emergency calling uses
>>> different protocols and procedures, in the interest of clarity
>>> and avoiding misunderstandings, it seems a good idea for this
>>> document to have an applicability statement that says, in
>>> effect, "Cellular networks work differently than what is
>>> described here"?  Doing so wouldn't in any way detract from,
>>> or be a demerit on, the solution described here, it would
>>> simply clarify reality.
>> 
>>  Some organizations think that cellular networks are different and hence they
>>  need completely different protocols and procedures. Example: WAP
>> 
>>  I am not sure that many folks in the RAI area share the same view.
> 
> Putting aside the question of what cellular networks *should* use,
> the issue is: what *will* they use.  Given that there is a large
> installed base and momentum for current protocols, I think it's
> unreasonable to expect that cellular networks will ditch what they
> have in favor of what's here (especially in view of the specific
> issues that Stephen raised).  Hence, to avoid confusion, it makes
> sense for this document to say that cellular networks use different
> protocols and procedures.

Content-Class: urn:content-classes:message
Date: Fri, 20 Feb 2009 16:39:59 -0500
From: "Stark, Barbara" <[email-masked]>
To: "Randall Gellens" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>, "Edge, Stephen" <[email-masked]>, "ECRIT" <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

<sigh> My 2 cents.
Service Providers and vendors of all ilk (cellular or otherwise) will
always only implement an IETF RFC (or any other standard) because they
either want to or have to.

That goes without saying.
So why say it?
Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Randall Gellens
Sent: Friday, February 20, 2009 11:29 AM
To: Hannes Tschofenig; 'Randall Gellens'; 'Edge, Stephen'; 'ECRIT'
Subject: Re: [Ecrit] Comments on Framework Draft

Hi Hannes,

At 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote:

>   >Since the reality is that cellular emergency calling uses
>>different protocols and procedures, in the interest of clarity
>>and avoiding misunderstandings, it seems a good idea for this
>>document to have an applicability statement that says, in
>>effect, "Cellular networks work differently than what is
>>described here"?  Doing so wouldn't in any way detract from,
>>or be a demerit on, the solution described here, it would
>>simply clarify reality.
>
>  Some organizations think that cellular networks are different and
hence they
>  need completely different protocols and procedures. Example: WAP
>
>  I am not sure that many folks in the RAI area share the same view.

Putting aside the question of what cellular networks *should* use,=20
the issue is: what *will* they use.  Given that there is a large=20
installed base and momentum for current protocols, I think it's=20
unreasonable to expect that cellular networks will ditch what they=20
have in favor of what's here (especially in view of the specific=20
issues that Stephen raised).  Hence, to avoid confusion, it makes=20
sense for this document to say that cellular networks use different=20
protocols and procedures.

--=20
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Any given program, when running, is obsolete.
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

*****

The information transmitted is intended only for the person or entity to =
which it is addressed and may contain confidential, proprietary, and/or =
privileged material. Any review, retransmission, dissemination or other =
use of, or taking of any action in reliance upon this information by =
persons or entities other than the intended recipient is prohibited. If =
you received this in error, please contact the sender and delete the =
material from all computers. GA621

Content-class: urn:content-classes:message
Date: Fri, 20 Feb 2009 18:28:43 -0600
From: "Dawson, Martin" <[email-masked]>
To: "Randall Gellens" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>, "Edge, Stephen" <[email-masked]>, "ECRIT" <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

A very small qualification - related to the scope of the working group=0D=0A=
task, not its actual output - was used to put a statement in the NENA i2=0D=
=0Aspecification that it didn't address mobile networks. This was despite=0D=
=0Athe fact that the architecture works perfectly well for mobile networks.=0D=
=0A=0D=0AIt's been used deliberately or unconsciously ever since then to ma=
ke=0D=0Afallacious arguments about the applicability of that architecture f=
or=0D=0Amobile.=0D=0A=0D=0AThe problem with putting the requested statement=
 in the ECRIT documents=0D=0Ais that, again, it will be used to fallaciousl=
y argue that the ECRIT=0D=0Aarchitecture does not apply to mobile. Surely n=
ot=3F Yeah - right.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original=
 Message-----=0D=0AFrom: [email-masked] [mailto:ecrit-bounces@ietf.=
org] On Behalf=0D=0AOf Randall Gellens=0D=0ASent: Saturday, 21 February 200=
9 3:29 AM=0D=0ATo: Hannes Tschofenig; 'Randall Gellens'; 'Edge, Stephen'; '=
ECRIT'=0D=0ASubject: Re: [Ecrit] Comments on Framework Draft=0D=0A=0D=0AHi =
Hannes,=0D=0A=0D=0AAt 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote:=0D=0A=0D=
=0A>   >Since the reality is that cellular emergency calling uses=0D=0A>>di=
fferent protocols and procedures, in the interest of clarity=0D=0A>>and avo=
iding misunderstandings, it seems a good idea for this=0D=0A>>document to h=
ave an applicability statement that says, in=0D=0A>>effect, "Cellular netwo=
rks work differently than what is=0D=0A>>described here"=3F  Doing so would=
n't in any way detract from,=0D=0A>>or be a demerit on, the solution descri=
bed here, it would=0D=0A>>simply clarify reality.=0D=0A>=0D=0A>  Some organ=
izations think that cellular networks are different and=0D=0Ahence they=0D=0A=
>  need completely different protocols and procedures. Example: WAP=0D=0A>=0D=
=0A>  I am not sure that many folks in the RAI area share the same view.=0D=
=0A=0D=0APutting aside the question of what cellular networks *should* use,=
=20=0D=0Athe issue is: what *will* they use.  Given that there is a large =0D=
=0Ainstalled base and momentum for current protocols, I think it's=20=0D=0A=
unreasonable to expect that cellular networks will ditch what they=20=0D=0A=
have in favor of what's here (especially in view of the specific=20=0D=0Ais=
sues that Stephen raised).  Hence, to avoid confusion, it makes=20=0D=0Asen=
se for this document to say that cellular networks use different=20=0D=0Apr=
otocols and procedures.=0D=0A=0D=0A--=20=0D=0ARandall Gellens=0D=0AOpinions=
 are personal;    facts are suspect;    I speak for myself only=0D=0A------=
-------- Randomly selected tag: ---------------=0D=0AAny given program, whe=
n running, is obsolete.=0D=0A______________________________________________=
_=0D=0AEcrit mailing list=0D=[email-masked]=0D=0Ahttps://www.ietf.org/mai=
lman/listinfo/ecrit=0D=0A=0D=0A--------------------------------------------=
----------------------------------------------------=0D=0AThis message is f=
or the designated recipient only and may=0D=0Acontain privileged, proprieta=
ry, or otherwise private information. =20=0D=0AIf you have received it in e=
rror, please notify the sender=0D=0Aimmediately and delete the original.  A=
ny unauthorized use of=0D=0Athis email is prohibited.=0D=0A----------------=
---------------------------------------------------------------------------=
-----=0D=0A[mf2]=0D=0A

Date: Thu, 19 Feb 2009 15:57:04 +0200
From: Gonzalo Camarillo <[email-masked]>
To: [email-masked]
Subject: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt

Folks,

I have been asked to perform an expert review of the following draft:

http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt

The approach taken by the draft seems OK in general. I have a few 
comments though:

The requirement in Section 3 is too specific because it already assumes 
that the solution will be an indication in the SIP header fields. The 
requirement does not need to make that assumption. I would remove "by 
providing an appropriate indication in the SIP header fields".

In Section 5, the reference to RFC 2234 should be replaced with one to 
RFC 5234.

Also in Section 5, the formal syntax should be rewritten so that it is 
compatible with the ABNF in RFC 3261. RFC 3261 already defines 
uri-parameter as follows:

   uri-parameter   =  transport-param / user-param / method-param
                      / ttl-param / maddr-param / lr-param / other-param

   other-param       =  pname [ "=" pvalue ]
   pname             =  1*paramchar
   pvalue            =  1*paramchar

This document should simply define a new value for pname.

The document does not talk about backwards compatibility. What happens 
if the registrar does not understand the 'sos' parameter? Will it do the 
right thing? Will the UAC detect the failure? Is there a need to define 
an option tag?... the document should address these points.

Cheers,

Gonzalo

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: "Winterbottom, James" <[email-masked]>, Randall Gellens <[email-masked]>, Hannes Tschofenig <[email-masked]>, "Edge, Stephen" <[email-masked]>, ECRIT <[email-masked]>
Date: Mon, 23 Feb 2009 12:25:17 +0100
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Ecrit] Comments on Framework Draft

My understanding so far is that it is an IMS issue, rather than directly an=
 access technology one.

You wish to offer IMS according to 3GPP standards, whether you are DSL, 3G,=
 4G or whatever, then you follow the IMS standards which lays down a specif=
ic architecture for handling emergency calls.

If you want to offer SIP over 3G or 4G not in accordance with IMS, then you=
 can do what you like in terms of the emergency calling as well.=20

Further, I suspect that the operator does not have complete freedom of choi=
ce, because the operator will not be able to negotiate the appropriate roam=
ing agreements if they go the path you are suggesting. And roaming agreemen=
ts for some strange financial reason which I can well understand IETF faili=
ng to appreciate are important to these operators.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> On Behalf Of Winterbottom, James
> Sent: Friday, February 20, 2009 4:54 PM
> To: Randall Gellens; Hannes Tschofenig; Edge, Stephen; ECRIT
> Subject: Re: [Ecrit] Comments on Framework Draft
>=20
> I actually don't see what benefit adding this statement does=20
> to the document.
> I do however see some harm in providing.
>=20
> If as a potential 3G or 4G operator I wish to offer a=20
> broadband service and, rather than providing a SUPL service I=20
> wish to provide some other service so that it is compatible=20
> with ECRIT, then I can't, because ECRIT has a clear=20
> applicability statement saying that it is not appropriate.
>=20
> If operators of cellular networks wish to continue to deploy=20
> networks based on 3GPP architectures then are entitled to do=20
> so. It would however, be doing them a disservice to suggest=20
> that there is not a viable alternative.
>=20
> Cheers
> James
>=20
>=20
> -----Original Message-----
> From: [email-masked] on behalf of Randall Gellens
> Sent: Fri 2/20/2009 10:28 AM
> To: Hannes Tschofenig; 'Randall Gellens'; 'Edge, Stephen'; 'ECRIT'
> Subject: Re: [Ecrit] Comments on Framework Draft
> =20
> Hi Hannes,
>=20
> At 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote:
>=20
> >   >Since the reality is that cellular emergency calling uses
> >>different protocols and procedures, in the interest of clarity and=20
> >>avoiding misunderstandings, it seems a good idea for this=20
> document to=20
> >>have an applicability statement that says, in effect, "Cellular=20
> >>networks work differently than what is described here"?  Doing so=20
> >>wouldn't in any way detract from, or be a demerit on, the solution=20
> >>described here, it would simply clarify reality.
> >
> >  Some organizations think that cellular networks are different and=20
> > hence they  need completely different protocols and procedures.=20
> > Example: WAP
> >
> >  I am not sure that many folks in the RAI area share the same view.
>=20
> Putting aside the question of what cellular networks *should*=20
> use, the issue is: what *will* they use.  Given that there is=20
> a large installed base and momentum for current protocols, I=20
> think it's unreasonable to expect that cellular networks will=20
> ditch what they have in favor of what's here (especially in=20
> view of the specific issues that Stephen raised).  Hence, to=20
> avoid confusion, it makes sense for this document to say that=20
> cellular networks use different protocols and procedures.
>=20
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for=20
> myself only
> -------------- Randomly selected tag: --------------- Any=20
> given program, when running, is obsolete.
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>=20
>=20
> --------------------------------------------------------------
> ----------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information. =20
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------
> ----------------------------------
> [mf2]
>=20
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
> =

Content-class: urn:content-classes:message
Date: Mon, 23 Feb 2009 13:59:51 +0200
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
To: "ext DRAGE, Keith (Keith)" <[email-masked]>, "Winterbottom, James" <[email-masked]>, "Randall Gellens" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>, "Edge,Stephen" <[email-masked]>, "ECRIT" <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

Hi all,=20

I believe it does not make a lot of sense to use the ECRIT mailing list
to speculate about the success or failure of IMS.=20

What matters at this point is trying to figure out what Randy and
Stephen are actually trying to tell us. I suspect that it boils down to
a few issues but so far I was not able to capture them correctly.=20

I suspect that most of the discussion actually relates to location
rather than to the emergency services architecture as such. To me this
appears to be the SUPL vs. other location protocol story.

Ciao
Hannes

PS: Keith, I liked this statement:=20
"You wish to offer IMS ***according to 3GPP standards***, whether you=20
are DSL, 3G, 4G or whatever, then you follow ***the IMS standards***=20
which lays down a specific architecture for handling emergency calls.
"

This sounds like: "If you want to follow the 3GPP IMS standards then
follow the 3GPP IMS standards."

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]=20
>On Behalf Of ext DRAGE, Keith (Keith)
>Sent: 23 February, 2009 13:25
>To: Winterbottom, James; Randall Gellens; Hannes Tschofenig;=20
>Edge,Stephen; ECRIT
>Subject: Re: [Ecrit] Comments on Framework Draft
>
>My understanding so far is that it is an IMS issue, rather=20
>than directly an access technology one.
>
>You wish to offer IMS according to 3GPP standards, whether you=20
>are DSL, 3G, 4G or whatever, then you follow the IMS standards=20
>which lays down a specific architecture for handling emergency calls.
>
>If you want to offer SIP over 3G or 4G not in accordance with=20
>IMS, then you can do what you like in terms of the emergency=20
>calling as well.=20
>
>Further, I suspect that the operator does not have complete=20
>freedom of choice, because the operator will not be able to=20
>negotiate the appropriate roaming agreements if they go the=20
>path you are suggesting. And roaming agreements for some=20
>strange financial reason which I can well understand IETF=20
>failing to appreciate are important to these operators.
>
>regards
>
>Keith
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]=20
>On Behalf=20
>> Of Winterbottom, James
>> Sent: Friday, February 20, 2009 4:54 PM
>> To: Randall Gellens; Hannes Tschofenig; Edge, Stephen; ECRIT
>> Subject: Re: [Ecrit] Comments on Framework Draft
>>=20
>> I actually don't see what benefit adding this statement does to the=20
>> document.
>> I do however see some harm in providing.
>>=20
>> If as a potential 3G or 4G operator I wish to offer a broadband=20
>> service and, rather than providing a SUPL service I wish to provide=20
>> some other service so that it is compatible with ECRIT, then=20
>I can't,=20
>> because ECRIT has a clear applicability statement saying that it is=20
>> not appropriate.
>>=20
>> If operators of cellular networks wish to continue to deploy=20
>networks=20
>> based on 3GPP architectures then are entitled to do so. It would=20
>> however, be doing them a disservice to suggest that there is not a=20
>> viable alternative.
>>=20
>> Cheers
>> James
>>=20
>>=20
>> -----Original Message-----
>> From: [email-masked] on behalf of Randall Gellens
>> Sent: Fri 2/20/2009 10:28 AM
>> To: Hannes Tschofenig; 'Randall Gellens'; 'Edge, Stephen'; 'ECRIT'
>> Subject: Re: [Ecrit] Comments on Framework Draft
>> =20
>> Hi Hannes,
>>=20
>> At 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote:
>>=20
>> >   >Since the reality is that cellular emergency calling uses
>> >>different protocols and procedures, in the interest of clarity and=20
>> >>avoiding misunderstandings, it seems a good idea for this
>> document to
>> >>have an applicability statement that says, in effect, "Cellular=20
>> >>networks work differently than what is described here"?  Doing so=20
>> >>wouldn't in any way detract from, or be a demerit on, the solution=20
>> >>described here, it would simply clarify reality.
>> >
>> >  Some organizations think that cellular networks are different and=20
>> > hence they  need completely different protocols and procedures.
>> > Example: WAP
>> >
>> >  I am not sure that many folks in the RAI area share the same view.
>>=20
>> Putting aside the question of what cellular networks=20
>*should* use, the=20
>> issue is: what *will* they use.  Given that there is a large=20
>installed=20
>> base and momentum for current protocols, I think it's=20
>unreasonable to=20
>> expect that cellular networks will ditch what they have in favor of=20
>> what's here (especially in view of the specific issues that Stephen=20
>> raised).  Hence, to avoid confusion, it makes sense for this=20
>document=20
>> to say that cellular networks use different protocols and procedures.
>>=20
>> --
>> Randall Gellens
>> Opinions are personal;    facts are suspect;    I speak for=20
>> myself only
>> -------------- Randomly selected tag: --------------- Any given=20
>> program, when running, is obsolete.
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>=20
>>=20
>> --------------------------------------------------------------
>> ----------------------------------
>> This message is for the designated recipient only and may contain=20
>> privileged, proprietary, or otherwise private information.
>> If you have received it in error, please notify the sender=20
>immediately=20
>> and delete the original.  Any unauthorized use of this email is=20
>> prohibited.
>> --------------------------------------------------------------
>> ----------------------------------
>> [mf2]
>>=20
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>=20
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>

Content-class: urn:content-classes:message
Date: Mon, 23 Feb 2009 13:47:54 -0600
From: "Winterbottom, James" <[email-masked]>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>, "ext DRAGE, Keith (Keith)" <[email-masked]>, "Randall Gellens" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>, "Edge,Stephen" <[email-masked]>, "ECRIT" <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

Actually Hannes, I think it is an network architecture difference.=0D=0A=0D=
=0AIMS REQUIRES the access and service providers to have a direct business =
relationship in the form or a roaming agreement. This serves to provide con=
nectivity between the location function in the access network and the call =
server. This happens whether you are talking control-plane or user-plane.=0D=
=0A=0D=0AThe linkage between access and service in IMS is largely artificia=
l, as Keith points out, it is done for financial reasons rather than techni=
cal merit. So the real question that is being asked, is whether ECRIT is ap=
propriate to architectures that do not make a formal separation between acc=
ess and application. I would argue that yes, ECRIT will work in those envir=
onment but that the converse is likely not the case without considerable tr=
ouble.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A-----Original Message-=
----=0D=0AFrom: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofen=
[email-masked]]=0D=0ASent: Mon 2/23/2009 5:59 AM=0D=0ATo: ext DRAGE, Keith (Kei=
th); Winterbottom, James; Randall Gellens; Hannes Tschofenig; Edge,Stephen;=
 ECRIT=0D=0ASubject: RE: [Ecrit] Comments on Framework Draft=0D=0A=20=0D=0A=
Hi all,=20=0D=0A=0D=0AI believe it does not make a lot of sense to use the =
ECRIT mailing list=0D=0Ato speculate about the success or failure of IMS. =0D=
=0A=0D=0AWhat matters at this point is trying to figure out what Randy and=0D=
=0AStephen are actually trying to tell us. I suspect that it boils down to=0D=
=0Aa few issues but so far I was not able to capture them correctly.=20=0D=0A=0D=
=0AI suspect that most of the discussion actually relates to location=0D=0A=
rather than to the emergency services architecture as such. To me this=0D=0A=
appears to be the SUPL vs. other location protocol story.=0D=0A=0D=0ACiao=0D=
=0AHannes=0D=0A=0D=0APS: Keith, I liked this statement:=20=0D=0A"You wish t=
o offer IMS ***according to 3GPP standards***, whether you=20=0D=0Aare DSL,=
 3G, 4G or whatever, then you follow ***the IMS standards***=20=0D=0Awhich =
lays down a specific architecture for handling emergency calls.=0D=0A"=0D=0A=0D=
=0AThis sounds like: "If you want to follow the 3GPP IMS standards then=0D=0A=
follow the 3GPP IMS standards."=0D=0A=0D=0A=0D=0A>-----Original Message----=
-=0D=0A>From: [email-masked] [mailto:[email-masked]]=20=0D=0A=
>On Behalf Of ext DRAGE, Keith (Keith)=0D=0A>Sent: 23 February, 2009 13:25=0D=
=0A>To: Winterbottom, James; Randall Gellens; Hannes Tschofenig;=20=0D=0A>E=
dge,Stephen; ECRIT=0D=0A>Subject: Re: [Ecrit] Comments on Framework Draft=0D=
=0A>=0D=0A>My understanding so far is that it is an IMS issue, rather=20=0D=
=0A>than directly an access technology one.=0D=0A>=0D=0A>You wish to offer =
IMS according to 3GPP standards, whether you=20=0D=0A>are DSL, 3G, 4G or wh=
atever, then you follow the IMS standards=20=0D=0A>which lays down a specif=
ic architecture for handling emergency calls.=0D=0A>=0D=0A>If you want to o=
ffer SIP over 3G or 4G not in accordance with=20=0D=0A>IMS, then you can do=
 what you like in terms of the emergency=20=0D=0A>calling as well.=20=0D=0A=
>=0D=0A>Further, I suspect that the operator does not have complete=20=0D=0A=
>freedom of choice, because the operator will not be able to=20=0D=0A>negot=
iate the appropriate roaming agreements if they go the=20=0D=0A>path you ar=
e suggesting. And roaming agreements for some=20=0D=0A>strange financial re=
ason which I can well understand IETF=20=0D=0A>failing to appreciate are im=
portant to these operators.=0D=0A>=0D=0A>regards=0D=0A>=0D=0A>Keith=0D=0A>=0D=
=0A>> -----Original Message-----=0D=0A>> From: [email-masked] [mail=
to:[email-masked]]=20=0D=0A>On Behalf=20=0D=0A>> Of Winterbottom, J=
ames=0D=0A>> Sent: Friday, February 20, 2009 4:54 PM=0D=0A>> To: Randall Ge=
llens; Hannes Tschofenig; Edge, Stephen; ECRIT=0D=0A>> Subject: Re: [Ecrit]=
 Comments on Framework Draft=0D=0A>>=20=0D=0A>> I actually don't see what b=
enefit adding this statement does to the=20=0D=0A>> document.=0D=0A>> I do =
however see some harm in providing.=0D=0A>>=20=0D=0A>> If as a potential 3G=
 or 4G operator I wish to offer a broadband=20=0D=0A>> service and, rather =
than providing a SUPL service I wish to provide=20=0D=0A>> some other servi=
ce so that it is compatible with ECRIT, then=20=0D=0A>I can't,=20=0D=0A>> b=
ecause ECRIT has a clear applicability statement saying that it is=20=0D=0A=
>> not appropriate.=0D=0A>>=20=0D=0A>> If operators of cellular networks wi=
sh to continue to deploy=20=0D=0A>networks=20=0D=0A>> based on 3GPP archite=
ctures then are entitled to do so. It would=20=0D=0A>> however, be doing th=
em a disservice to suggest that there is not a=20=0D=0A>> viable alternativ=
e.=0D=0A>>=20=0D=0A>> Cheers=0D=0A>> James=0D=0A>>=20=0D=0A>>=20=0D=0A>> --=
---Original Message-----=0D=0A>> From: [email-masked] on behalf of =
Randall Gellens=0D=0A>> Sent: Fri 2/20/2009 10:28 AM=0D=0A>> To: Hannes Tsc=
hofenig; 'Randall Gellens'; 'Edge, Stephen'; 'ECRIT'=0D=0A>> Subject: Re: [=
Ecrit] Comments on Framework Draft=0D=0A>> =20=0D=0A>> Hi Hannes,=0D=0A>> =0D=
=0A>> At 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote:=0D=0A>>=20=0D=0A>>=
 >   >Since the reality is that cellular emergency calling uses=0D=0A>> >>d=
ifferent protocols and procedures, in the interest of clarity and=20=0D=0A>=
> >>avoiding misunderstandings, it seems a good idea for this=0D=0A>> docum=
ent to=0D=0A>> >>have an applicability statement that says, in effect, "Cel=
lular=20=0D=0A>> >>networks work differently than what is described here"=3F=
  Doing so=20=0D=0A>> >>wouldn't in any way detract from, or be a demerit o=
n, the solution=20=0D=0A>> >>described here, it would simply clarify realit=
y.=0D=0A>> >=0D=0A>> >  Some organizations think that cellular networks are=
 different and=20=0D=0A>> > hence they  need completely different protocols=
 and procedures.=0D=0A>> > Example: WAP=0D=0A>> >=0D=0A>> >  I am not sure =
that many folks in the RAI area share the same view.=0D=0A>>=20=0D=0A>> Put=
ting aside the question of what cellular networks=20=0D=0A>*should* use, th=
e=20=0D=0A>> issue is: what *will* they use.  Given that there is a large =0D=
=0A>installed=20=0D=0A>> base and momentum for current protocols, I think i=
t's=20=0D=0A>unreasonable to=20=0D=0A>> expect that cellular networks will =
ditch what they have in favor of=20=0D=0A>> what's here (especially in view=
 of the specific issues that Stephen=20=0D=0A>> raised).  Hence, to avoid c=
onfusion, it makes sense for this=20=0D=0A>document=20=0D=0A>> to say that =
cellular networks use different protocols and procedures.=0D=0A>>=20=0D=0A>=
> --=0D=0A>> Randall Gellens=0D=0A>> Opinions are personal;    facts are su=
spect;    I speak for=20=0D=0A>> myself only=0D=0A>> -------------- Randoml=
y selected tag: --------------- Any given=20=0D=0A>> program, when running,=
 is obsolete.=0D=0A>> _______________________________________________=0D=0A=
>> Ecrit mailing list=0D=0A>> [email-masked]=0D=0A>> https://www.ietf.org/m=
ailman/listinfo/ecrit=0D=0A>>=20=0D=0A>>=20=0D=0A>> -----------------------=
---------------------------------------=0D=0A>> ---------------------------=
-------=0D=0A>> This message is for the designated recipient only and may c=
ontain=20=0D=0A>> privileged, proprietary, or otherwise private information=
=2E=0D=0A>> If you have received it in error, please notify the sender=20=0D=
=0A>immediately=20=0D=0A>> and delete the original.  Any unauthorized use o=
f this email is=20=0D=0A>> prohibited.=0D=0A>> ----------------------------=
----------------------------------=0D=0A>> --------------------------------=
--=0D=0A>> [mf2]=0D=0A>>=20=0D=0A>> _______________________________________=
________=0D=0A>> Ecrit mailing list=0D=0A>> [email-masked]=0D=0A>> https://=
www.ietf.org/mailman/listinfo/ecrit=0D=0A>>=20=0D=0A>______________________=
_________________________=0D=0A>Ecrit mailing list=0D=0A>[email-masked]=0D=0A=
>https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>=0D=0A=0D=0A=0D=0A------=
---------------------------------------------------------------------------=
---------------=0D=0AThis message is for the designated recipient only and =
may=0D=0Acontain privileged, proprietary, or otherwise private information.=
 =20=0D=0AIf you have received it in error, please notify the sender=0D=0Ai=
mmediately and delete the original.  Any unauthorized use of=0D=0Athis emai=
l is prohibited.=0D=0A-----------------------------------------------------=
-------------------------------------------=0D=0A[mf2]=0D=0A

Content-class: urn:content-classes:message
Date: Tue, 24 Feb 2009 09:15:16 +0200
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
To: "ext Winterbottom, James" <[email-masked]>, "ext DRAGE, Keith (Keith)" <[email-masked]>, "Randall Gellens" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>, "Edge,Stephen" <[email-masked]>, "ECRIT" <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

I agree with your statement, James.=20

=20

>-----Original Message-----
>From: ext Winterbottom, James [mailto:[email-masked]]=20
>Sent: 23 February, 2009 21:48
>To: Tschofenig, Hannes (NSN - FI/Espoo); ext DRAGE, Keith=20
>(Keith); Randall Gellens; Hannes Tschofenig; Edge,Stephen; ECRIT
>Subject: RE: [Ecrit] Comments on Framework Draft
>
>Actually Hannes, I think it is an network architecture difference.
>
>IMS REQUIRES the access and service providers to have a direct=20
>business relationship in the form or a roaming agreement. This=20
>serves to provide connectivity between the location function=20
>in the access network and the call server. This happens=20
>whether you are talking control-plane or user-plane.
>
>The linkage between access and service in IMS is largely=20
>artificial, as Keith points out, it is done for financial=20
>reasons rather than technical merit. So the real question that=20
>is being asked, is whether ECRIT is appropriate to=20
>architectures that do not make a formal separation between=20
>access and application. I would argue that yes, ECRIT will=20
>work in those environment but that the converse is likely not=20
>the case without considerable trouble.
>
>Cheers
>James
>
>
>-----Original Message-----
>From: Tschofenig, Hannes (NSN - FI/Espoo)=20
>[mailto:[email-masked]]
>Sent: Mon 2/23/2009 5:59 AM
>To: ext DRAGE, Keith (Keith); Winterbottom, James; Randall=20
>Gellens; Hannes Tschofenig; Edge,Stephen; ECRIT
>Subject: RE: [Ecrit] Comments on Framework Draft
>=20
>Hi all,=20
>
>I believe it does not make a lot of sense to use the ECRIT=20
>mailing list to speculate about the success or failure of IMS.=20
>
>What matters at this point is trying to figure out what Randy=20
>and Stephen are actually trying to tell us. I suspect that it=20
>boils down to a few issues but so far I was not able to=20
>capture them correctly.=20
>
>I suspect that most of the discussion actually relates to=20
>location rather than to the emergency services architecture as=20
>such. To me this appears to be the SUPL vs. other location=20
>protocol story.
>
>Ciao
>Hannes
>
>PS: Keith, I liked this statement:=20
>"You wish to offer IMS ***according to 3GPP standards***,=20
>whether you are DSL, 3G, 4G or whatever, then you follow=20
>***the IMS standards*** which lays down a specific=20
>architecture for handling emergency calls.
>"
>
>This sounds like: "If you want to follow the 3GPP IMS=20
>standards then follow the 3GPP IMS standards."
>
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]=20
>On Behalf=20
>>Of ext DRAGE, Keith (Keith)
>>Sent: 23 February, 2009 13:25
>>To: Winterbottom, James; Randall Gellens; Hannes Tschofenig;=20
>>Edge,Stephen; ECRIT
>>Subject: Re: [Ecrit] Comments on Framework Draft
>>
>>My understanding so far is that it is an IMS issue, rather than=20
>>directly an access technology one.
>>
>>You wish to offer IMS according to 3GPP standards, whether=20
>you are DSL,=20
>>3G, 4G or whatever, then you follow the IMS standards which=20
>lays down a=20
>>specific architecture for handling emergency calls.
>>
>>If you want to offer SIP over 3G or 4G not in accordance with=20
>IMS, then=20
>>you can do what you like in terms of the emergency calling as well.
>>
>>Further, I suspect that the operator does not have complete=20
>freedom of=20
>>choice, because the operator will not be able to negotiate the=20
>>appropriate roaming agreements if they go the path you are=20
>suggesting.=20
>>And roaming agreements for some strange financial reason which I can=20
>>well understand IETF failing to appreciate are important to these=20
>>operators.
>>
>>regards
>>
>>Keith
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]]
>>On Behalf
>>> Of Winterbottom, James
>>> Sent: Friday, February 20, 2009 4:54 PM
>>> To: Randall Gellens; Hannes Tschofenig; Edge, Stephen; ECRIT
>>> Subject: Re: [Ecrit] Comments on Framework Draft
>>>=20
>>> I actually don't see what benefit adding this statement does to the=20
>>> document.
>>> I do however see some harm in providing.
>>>=20
>>> If as a potential 3G or 4G operator I wish to offer a broadband=20
>>> service and, rather than providing a SUPL service I wish to provide=20
>>> some other service so that it is compatible with ECRIT, then
>>I can't,
>>> because ECRIT has a clear applicability statement saying that it is=20
>>> not appropriate.
>>>=20
>>> If operators of cellular networks wish to continue to deploy
>>networks
>>> based on 3GPP architectures then are entitled to do so. It would=20
>>> however, be doing them a disservice to suggest that there is not a=20
>>> viable alternative.
>>>=20
>>> Cheers
>>> James
>>>=20
>>>=20
>>> -----Original Message-----
>>> From: [email-masked] on behalf of Randall Gellens
>>> Sent: Fri 2/20/2009 10:28 AM
>>> To: Hannes Tschofenig; 'Randall Gellens'; 'Edge, Stephen'; 'ECRIT'
>>> Subject: Re: [Ecrit] Comments on Framework Draft
>>> =20
>>> Hi Hannes,
>>>=20
>>> At 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote:
>>>=20
>>> >   >Since the reality is that cellular emergency calling uses
>>> >>different protocols and procedures, in the interest of=20
>clarity and=20
>>> >>avoiding misunderstandings, it seems a good idea for this
>>> document to
>>> >>have an applicability statement that says, in effect, "Cellular=20
>>> >>networks work differently than what is described here"?  Doing so=20
>>> >>wouldn't in any way detract from, or be a demerit on, the=20
>solution=20
>>> >>described here, it would simply clarify reality.
>>> >
>>> >  Some organizations think that cellular networks are=20
>different and=20
>>> > hence they  need completely different protocols and procedures.
>>> > Example: WAP
>>> >
>>> >  I am not sure that many folks in the RAI area share the=20
>same view.
>>>=20
>>> Putting aside the question of what cellular networks
>>*should* use, the
>>> issue is: what *will* they use.  Given that there is a large
>>installed
>>> base and momentum for current protocols, I think it's
>>unreasonable to
>>> expect that cellular networks will ditch what they have in favor of=20
>>> what's here (especially in view of the specific issues that Stephen=20
>>> raised).  Hence, to avoid confusion, it makes sense for this
>>document
>>> to say that cellular networks use different protocols and=20
>procedures.
>>>=20
>>> --
>>> Randall Gellens
>>> Opinions are personal;    facts are suspect;    I speak for=20
>>> myself only
>>> -------------- Randomly selected tag: --------------- Any given=20
>>> program, when running, is obsolete.
>>> _______________________________________________
>>> Ecrit mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>=20
>>>=20
>>> --------------------------------------------------------------
>>> ----------------------------------
>>> This message is for the designated recipient only and may contain=20
>>> privileged, proprietary, or otherwise private information.
>>> If you have received it in error, please notify the sender
>>immediately
>>> and delete the original.  Any unauthorized use of this email is=20
>>> prohibited.
>>> --------------------------------------------------------------
>>> ----------------------------------
>>> [mf2]
>>>=20
>>> _______________________________________________
>>> Ecrit mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>=20
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/ecrit
>>
>
>
>---------------------------------------------------------------
>---------------------------------
>This message is for the designated recipient only and may=20
>contain privileged, proprietary, or otherwise private information. =20
>If you have received it in error, please notify the sender=20
>immediately and delete the original.  Any unauthorized use of=20
>this email is prohibited.
>---------------------------------------------------------------
>---------------------------------
>[mf2]
>
>

Date: Tue, 24 Feb 2009 09:00:13 -0500
From: Richard Barnes <[email-masked]>
To: ECRIT <[email-masked]>
Subject: [Ecrit] [Fwd: New Version Notification for draft-barnes-ecrit-rough-loc-02]

In anticipation of the virtual interim, here's a new draft of rough-loc.

-- Added a requirement that the rough location MUST contain the precise 
location of the endpoint (when known)

-- Added considerations for civic addresses

-- Extended security considerations to note the necessity of URIs that 
allow PSAPs to access precise location

-- Fixed several editorial nits

-------- Original Message --------
Subject: New Version Notification for draft-barnes-ecrit-rough-loc-02
Date: Mon, 23 Feb 2009 19:22:51 -0800 (PST)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: [email-masked]

A new version of I-D, draft-barnes-ecrit-rough-loc-02.txt has been 
successfuly submitted by Richard Barnes and posted to the IETF repository.

Filename:	 draft-barnes-ecrit-rough-loc
Revision:	 02
Title:		 Using Imprecise Location for Emergency Context Resolution
Creation_date:	 2009-02-24
WG ID:		 Independent Submission
Number_of_pages: 14

Abstract:
Emergency calling works best when precise location is available for
emergency call routing.  However, there are situations in which a
location provider is unable or unwilling to provide precise location,
yet still wishes to enable subscribers to make emergency calls.  This
document describes the level of location accuracy that providers must
provide to enable emergency call routing.  In addition, we descibe
how emergency services and non-emergency services can be invoked by
an endpoint that does not have access to its precise location.

The IETF Secretariat.

To: "James M. Polk" <[email-masked]>
From: Janet P Gunn <[email-masked]>
Date: Tue, 24 Feb 2009 16:10:16 -0500
Cc: 'ECRIT' <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted

This is a multipart message in MIME format.
--=_alternative 00744BD985257567_=
Content-Type: text/plain; charset="US-ASCII"

James
Some of this is editorial, some is substantive and technical, and some 
repeats my comments on 00 that do not seem to have been addressed.

2nd paragraph of section 1, this sentence doesn't make sense.
"   Within controlled environments, such as an IMS infrastructure or 
   Emergency Services network (ESInet), where misuse can be reduced to 
   a minimum where possible, this namespace is to be to provide an 
   explicit priority indication facilitates treatment of emergency SIP 
   messages according to local policy."

Perhaps you mean
"   Within controlled environments, such as an IMS infrastructure or 
   Emergency Services network (ESInet), where misuse can be reduced to 
   a minimum, this namespace is expected to be used to provide an 
   explicit priority indication, facilitating treatment of emergency SIP 
   messages according to local policy."  But I am not sure if that is what 
you meant.

Same para
"This indication is used to 
   differentiate SIP requests, or dialogs, from other requests or 
   dialogs that do not have the need for priority treatment." 
sounds as if you are differentiating SIP requests form non-SIP requests. 
Perhaps what you mean is 
"This indication is used to 
   differentiate Emergency Services related  SIP requests, or dialogs, 
from other (non Emergency 
Services related) SIP requests or  dialogs.

Note that "do not have the need for priority treatment" is not correct. 
The esnet RPH would 
distinguish ES related messages from GETS related messages (ets and wps 
namespaces), but they 
would each get their own particular flavor of "priority treatment".

5th para of section 1

"From this fact about RFC 4412, and the possibility that within 
   emergency services networks, a Multilevel Precedence and Preemption 
   (MLPP)-like behavior can be achieved - ensuring more important calls
   are established or retained, the "esnet" namespace is given 5 
   priority-levels."
What is "this fact"?  Perhaps "Because we can't add new values later..."

I don't understand the "can be achieved".  Do you mean "MLPP-like behavior 
may be desired"?

I fully agree with assigning 5 levels, and the underlying logic. It is 
only the description that is problematic. 

Perhaps
"Because we can't add new values later, and because  Multilevel Precedence 
and Preemption 
   (MLPP)-like behavior may be desired the "esnet" namespace is given 5 
priority-levels."

2nd to last paragraph of section 1
"Within the ESINet, there will be emergency calls requiring different
   treatments, according to the type of call. "
We don't know if they will require different treatment or not.

I would prefer 
"Within the ESINet, there may be emergency calls requiring different
   treatments, according to the type of call. "

or if the use of "may" will be confused with normative language,
"Within the ESINet, there could be emergency calls requiring different
   treatments, according to the type of call. "

This sentence at the end of sec 1 doesn't quite work.
"This document IANA registers the "esnet"
   RPH namespace for use within emergency services networks, not just 
   of those from citizens to PSAPs." (no clear antecedent for "those")

Perhaps
"This document IANA registers the "esnet"
   RPH namespace for use within emergency services networks, not just for 
calls or sessions
    from citizens to PSAPs."
(same comment applied to 00)

Section 2  first para says
 "This document updates the behaviors of the SIP Resource Priority 
   header, defined in [RFC4412], during the treatment options 
   surrounding this new "esnet" namespace only. The usage of the 
   "esnet" namespace does not have a normal, or routine call level. 
   Every use of this namespace will be in times of an emergency, where 
   at least one end of the signaling is with a local emergency 
   organization."

I don't see this as an "update of the behavior of 4412".  Neither the ets 
namespace not the wps namespace have a "normal" or "routine" call level. 
Every use of the wps and ets namespaces will have priority over calls 
without RPH.

Suggest changing text to say
"   Like the ets and wps namespaces defined in [RFC4412], the 
   "esnet" namespace does not have a normal, or routine call level. 
    Every use of this namespace will be in times of an emergency, where 
   at least one end of the signaling is with a local emergency 
   organization."

Section 2, para immediately below Figure 1
"   Because the more important usage of the 
   "esnet" namespace occurs within the ESInet, the edge proxy, called 
   an Emergency Services Routing Proxy (ESRP) can modify or delete this
   namespace. This is a normative change to the allowed behavior within
   [RFC4412], but MUST only be considered valid in this usage at the 
   ESInet boundary for this one RP namespace (and associated 
   priority-value). "

I have major (content, not editorial) concerns with this, more for what it 
says about 4412 than about esnet

First of all, it is not clear to me why this is "a normative change to the 
allowed behavior within [RFC4412]". 

For one thing I see nothing in 4412 that would prohibit a "SIP actor that 
understands the name space" 
from modifying or deleting the namespace. 

It is certainly anticipated that at least some of the namespaces described 
in 4412 will be 
modified or deleted, (e.g., when there is reason to  believe it is 
unauthorized).

4412 says "Existing implementations of RFC 3261 that do not participate in 
the
   resource priority mechanism follow the normal rules of RFC 3261,
   Section 8.2.2: "If a UAS does not understand a header field in a
   request (that is, the header field is not defined in this
   specification or in any supported extension), the server MUST ignore
   that header field and continue processing the message". "

But I do not see anywhere that is says that a UAS that DOES understand the 
namespace is 
forbidden from deleting it.  For instance, sec 4.7.1 of 4412 says that 
"the UAC
   MAY attempt a subsequent request with the same or different resource
   value."  This certainly implies the ability to overwrite or delete an 
RPH namespace.  (See 
also, for instance the PTSC SAC document on the use of the ets and wps 
namespaces.)

I would suggest rewording this to say
"   Because the more important usage of the 
   "esnet" namespace occurs within the ESInet, the edge proxy, called 
   an Emergency Services Routing Proxy (ESRP) can modify or delete this
   namespace. This is consistent with [RFC4412]. "

Section 3.2,para after the relative priority order.

"  The "esnet" namespace will be assigned into the priority queuing 
   algorithm (Section 4.5.2 of [RFC4412]) from the public user to the 
   PSAP.  This does not limit its usage to only the priority queue 
   algorithm; meaning the preemption algorithm can be used where the 
   local jurisdiction preferred to preempt normal calls in lieu of 
   completing emergency calls.  This document is not RECOMMENDING this 
   usage, merely pointing out those behaviors are a matter of local 
   policy."

My concern here is the reference to "preempt normal calls".  Since you 
have already said that 
there is no "normal" level in the esnet priority value set, I have to 
assume that you mean 
"preempt calls with no RPH" (or perhaps "preempt calls  with a different 
RPH namespace").

This WOULD BE a normative change to 4412, which says in 4.7.2.1
"A UAS compliant with this specification MUST terminate a session
   established with a valid namespace and lower-priority value in favor
   of a new session set up with a valid namespace and higher relative
   priority value, unless local policy has some form of call-waiting
   capability enabled."

Note that the only sessions that can be preempted are ones "with a valid 
namespace and a lower 
priority value".  A "normal" call has neither a "valid namespace", nor a 
"priority value" 
(higher or lower), and thus cannot be preempted under 4412.

Furthermore, RFC4411 (which focuses on "preemption") repeatedly refers to 
the pre-empted 
call/session having an RPH with a lower priority value.

The circuit switched versions of preemption ( both MLPP for landlines, and 
3GPP e-MLPP for GSM) 
are even more restrictive.  In those schemes, a call can only preempt a 
lower priority call IN 
THE SAME PREEMPTION DOMAIN (there is a rough correspondence between 
"preemption domain" and "RPH 
namespace").

So I take serious objection to any suggestion of preempting "normal" 
calls.

If you want to have high priority esnet calls preempt low priority esnet 
calls, I don't object as 
strenuously. (But no preempting "normal" calls.)

Section 5, 3rd para
"  A simple means of preventing this usage is to not allow marked 
   traffic preferential treatment unless the destination is towards the
   local/regional ESInet. "

This seems to contradict the text in section 1
"This new namespace can 
   be used for inbound calls to PSAPs, between PSAPs, and between a 
   PSAP and first responders and their organizations."
and section 3
" This namespace will also be used 
   for communications between emergency authorities, and MAY be used 
   for emergency authorities calling public citizens.  An example of 
   the later is a PSAP operator calling back someone who previously 
   called 9111/112/999 and the communication was terminated before it 
   should have been (in the operator's judgment)."

Finally, at IETF 73 you assured me that you would insert strong language 
pointing to section 8 of 
RFC4412 addressing the relative priority of the different namespaces. This 
is to eliminate any 
possible suggestion (that some people - not me- read into the 00 version) 
that an esnet 
namespace would have higher priority than an ets namespace.  I find no 
such reference to section 
8 of 4412.

Thanks, and please note that I strongly support the creation of the esnet 
namespace.  None of my comment should be interpreted as being "against" 
esnet.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.

"James M. Polk" <[email-masked]> 
Sent by: [email-masked]
02/19/2009 09:32 PM

To
"'ECRIT'" <[email-masked]>
cc

Subject
[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted

ECRIT

I've just submitted a rev of the "esnet" Resource-Prioriy header draft.

I've removed all mention of UAs from the draft, but leave in the 
possibility for adjacent VSPs to have a trust relationship with the 
local ESInet and mark these SIP requests accordingly through the 
VSP's domain.  I offer that the ESRP at the ESInet edge will be 
tasked with mapping the esnet.priority-values from outside the ESInet 
to the indications used inside the ESInet.  The ID gives no guidance 
on what the priority-values should be in either case - as that is a 
matter for other documents (and I'd argue - for other SDOs or 
consortia such as NENA and EENA, though I don't mention either 
organization in the ID).

Comments are welcome

James

>From: IETF I-D Submission Tool <[email-masked]>
>To: [email-masked]
>Subject: New Version Notification for
>          draft-ietf-ecrit-local-emergency-rph-namespace-01
>Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST)
>
>
>A new version of I-D, 
>draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been 
>successfuly submitted by James Polk and posted to the IETF repository.
>
>Filename:       draft-ietf-ecrit-local-emergency-rph-namespace
>Revision:       01
>Title:          IANA Registering a SIP Resource Priority Header 
>Namespace for Local Emergency Communications
>Creation_date:  2009-02-19
>WG ID:          ecrit
>Number_of_pages: 7
>
>Abstract:
>This document creates and IANA registers the new Session Initiation
>Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
>local emergency usage to a public safety answering point (PSAP),
>between PSAPs, and between a PSAP and first responders and their
>organizations.
> 
>
>
>
>The IETF Secretariat.

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

--=_alternative 00744BD985257567_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">James</font>
<br><font size=2 face="sans-serif">Some of this is editorial, some is substantive
and technical, and some repeats my comments on 00 that do not seem to have
been addressed.</font>
<br>
<br><font size=2 face="sans-serif">2nd paragraph of section 1, this sentence
doesn't make sense.</font>
<br><font size=2 face="sans-serif">&quot; &nbsp; Within controlled environments,
such as an IMS infrastructure or </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;Emergency Services network
(ESInet), where misuse can be reduced to </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;a minimum where possible,
this namespace is to be to provide an </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;explicit priority indication
facilitates treatment of emergency SIP </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;messages according to local
policy.&quot;</font>
<br>
<br><font size=2 face="sans-serif">Perhaps you mean</font>
<br><font size=2 face="sans-serif">&quot; &nbsp; Within controlled environments,
such as an IMS infrastructure or </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;Emergency Services network
(ESInet), where misuse can be reduced to </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;a minimum, this namespace
is expected to be used to provide an </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;explicit priority indication,
facilitating treatment of emergency SIP </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;messages according to local
policy.&quot; &nbsp;But I am not sure if that is what you meant.</font>
<br>
<br>
<br><font size=2 face="sans-serif">Same para</font>
<br><font size=2 face="sans-serif">&quot;This indication is used to </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;differentiate SIP requests,
or dialogs, from other requests or </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;dialogs that do not have
the need for priority treatment.&quot; </font>
<br><font size=2 face="sans-serif">sounds as if you are differentiating
SIP requests form non-SIP requests. &nbsp;Perhaps what you mean is </font>
<br><font size=2 face="sans-serif">&quot;This indication is used to </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;differentiate Emergency
Services related &nbsp;SIP requests, or dialogs, from other (non Emergency
</font>
<br><font size=2 face="sans-serif">Services related) SIP requests or &nbsp;dialogs.</font>
<br>
<br><font size=2 face="sans-serif">Note that &quot;do not have the need
for priority treatment&quot; is not correct. &nbsp;The esnet RPH would
</font>
<br><font size=2 face="sans-serif">distinguish ES related messages from
GETS related messages (ets and wps namespaces), but they </font>
<br><font size=2 face="sans-serif">would each get their own particular
flavor of &quot;priority treatment&quot;.</font>
<br>
<br>
<br><font size=2 face="sans-serif">5th para of section 1</font>
<br>
<br><font size=2 face="sans-serif">&quot;From this fact about RFC 4412,
and the possibility that within </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;emergency services networks,
a Multilevel Precedence and Preemption </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;(MLPP)-like behavior can
be achieved - ensuring more important calls</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;are established or retained,
the &quot;esnet&quot; namespace is given 5 </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;priority-levels.&quot;</font>
<br><font size=2 face="sans-serif">What is &quot;this fact&quot;? &nbsp;Perhaps
&quot;Because we can't add new values later...&quot;</font>
<br>
<br><font size=2 face="sans-serif">I don't understand the &quot;can be
achieved&quot;. &nbsp;Do you mean &quot;MLPP-like behavior may be desired&quot;?</font>
<br>
<br><font size=2 face="sans-serif">I fully agree with assigning 5 levels,
and the underlying logic. It is only the description that is problematic.
</font>
<br>
<br><font size=2 face="sans-serif">Perhaps</font>
<br><font size=2 face="sans-serif">&quot;Because we can't add new values
later, and because &nbsp;Multilevel Precedence and Preemption </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;(MLPP)-like behavior may
be desired the &quot;esnet&quot; namespace is given 5 priority-levels.&quot;</font>
<br>
<br><font size=2 face="sans-serif">2nd to last paragraph of section 1</font>
<br><font size=2 face="sans-serif">&quot;Within the ESINet, there will
be emergency calls requiring different</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;treatments, according to
the type of call. &quot;</font>
<br><font size=2 face="sans-serif">We don't know if they will require different
treatment or not.</font>
<br>
<br><font size=2 face="sans-serif">I would prefer </font>
<br><font size=2 face="sans-serif">&quot;Within the ESINet, there may be
emergency calls requiring different</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;treatments, according to
the type of call. &quot;</font>
<br>
<br><font size=2 face="sans-serif">or if the use of &quot;may&quot; will
be confused with normative language,</font>
<br><font size=2 face="sans-serif">&quot;Within the ESINet, there could
be emergency calls requiring different</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;treatments, according to
the type of call. &quot;</font>
<br>
<br>
<br><font size=2 face="sans-serif">This sentence at the end of sec 1 doesn't
quite work.</font>
<br><font size=2 face="sans-serif">&quot;This document IANA registers the
&quot;esnet&quot;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;RPH namespace for use within
emergency services networks, not just </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;of those from citizens
to PSAPs.&quot; (no clear antecedent for &quot;those&quot;)</font>
<br>
<br><font size=2 face="sans-serif">Perhaps</font>
<br><font size=2 face="sans-serif">&quot;This document IANA registers the
&quot;esnet&quot;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;RPH namespace for use within
emergency services networks, not just for calls or sessions</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; from citizens to PSAPs.&quot;</font>
<br><font size=2 face="sans-serif">(same comment applied to 00)</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Section 2 &nbsp;first para says</font>
<br><font size=2 face="sans-serif">&nbsp;&quot;This document updates the
behaviors of the SIP Resource Priority </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;header, defined in [RFC4412],
during the treatment options </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;surrounding this new &quot;esnet&quot;
namespace only. The usage of the </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;&quot;esnet&quot; namespace
does not have a normal, or routine call level. &nbsp;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;Every use of this namespace
will be in times of an emergency, where </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;at least one end of the
signaling is with a local emergency </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;organization.&quot;</font>
<br>
<br><font size=2 face="sans-serif">I don't see this as an &quot;update
of the behavior of 4412&quot;. &nbsp;Neither the ets namespace not the
wps namespace have a &quot;normal&quot; or &quot;routine&quot; call level.
&nbsp;Every use of the wps and ets namespaces will have priority over calls
without RPH.</font>
<br>
<br><font size=2 face="sans-serif">Suggest changing text to say</font>
<br><font size=2 face="sans-serif">&quot; &nbsp; Like the ets and wps namespaces
defined in [RFC4412], the </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;&quot;esnet&quot; namespace
does not have a normal, or routine call level. </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; Every use of this namespace
will be in times of an emergency, where </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;at least one end of the
signaling is with a local emergency </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;organization.&quot;</font>
<br>
<br>
<br><font size=2 face="sans-serif">Section 2, para immediately below Figure
1</font>
<br><font size=2 face="sans-serif">&quot; &nbsp; Because the more important
usage of the </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;&quot;esnet&quot; namespace
occurs within the ESInet, the edge proxy, called </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;an Emergency Services Routing
Proxy (ESRP) can modify or delete this</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;namespace. This is a normative
change to the allowed behavior within</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;[RFC4412], but MUST only
be considered valid in this usage at the </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;ESInet boundary for this
one RP namespace (and associated </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;priority-value). &quot;</font>
<br>
<br><font size=2 face="sans-serif">I have major (content, not editorial)
concerns with this, more for what it says about 4412 than about esnet</font>
<br>
<br>
<br><font size=2 face="sans-serif">First of all, it is not clear to me
why this is &quot;a normative change to the allowed behavior within [RFC4412]&quot;.
</font>
<br>
<br><font size=2 face="sans-serif">For one thing I see nothing in 4412
that would prohibit a &quot;SIP actor that understands the name space&quot;
</font>
<br><font size=2 face="sans-serif">from modifying or deleting the namespace.
</font>
<br>
<br>
<br><font size=2 face="sans-serif">It is certainly anticipated that at
least some of the namespaces described in 4412 will be </font>
<br><font size=2 face="sans-serif">modified or deleted, (e.g., when there
is reason to &nbsp;believe it is unauthorized).</font>
<br>
<br><font size=2 face="sans-serif">4412 says &quot;Existing implementations
of RFC 3261 that do not participate in the</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;resource priority mechanism
follow the normal rules of RFC 3261,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;Section 8.2.2: &quot;If
a UAS does not understand a header field in a</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;request (that is, the header
field is not defined in this</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;specification or in any
supported extension), the server MUST ignore</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;that header field and continue
processing the message&quot;. &quot;</font>
<br>
<br><font size=2 face="sans-serif">But I do not see anywhere that is says
that a UAS that DOES understand the namespace is </font>
<br><font size=2 face="sans-serif">forbidden from deleting it. &nbsp;For
instance, sec 4.7.1 of 4412 says that &quot;the UAC</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;MAY attempt a subsequent
request with the same or different resource</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;value.&quot; &nbsp;This
certainly implies the ability to overwrite or delete an RPH namespace.
&nbsp;(See </font>
<br><font size=2 face="sans-serif">also, for instance the PTSC SAC document
on the use of the ets and wps namespaces.)</font>
<br>
<br><font size=2 face="sans-serif">I would suggest rewording this to say</font>
<br><font size=2 face="sans-serif">&quot; &nbsp; Because the more important
usage of the </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;&quot;esnet&quot; namespace
occurs within the ESInet, the edge proxy, called </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;an Emergency Services Routing
Proxy (ESRP) can modify or delete this</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;namespace. This is consistent
with [RFC4412]. &quot;</font>
<br>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Section 3.2,para after the relative
priority order.</font>
<br>
<br><font size=2 face="sans-serif">&quot; &nbsp;The &quot;esnet&quot; namespace
will be assigned into the priority queuing </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;algorithm (Section 4.5.2
of [RFC4412]) from the public user to the </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;PSAP. &nbsp;This does not
limit its usage to only the priority queue </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;algorithm; meaning the
preemption algorithm can be used where the </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;local jurisdiction preferred
to preempt normal calls in lieu of </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;completing emergency calls.
&nbsp;This document is not RECOMMENDING this </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;usage, merely pointing
out those behaviors are a matter of local </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;policy.&quot;</font>
<br>
<br><font size=2 face="sans-serif">My concern here is the reference to
&quot;preempt normal calls&quot;. &nbsp;Since you have already said that
</font>
<br><font size=2 face="sans-serif">there is no &quot;normal&quot; level
in the esnet priority value set, I have to assume that you mean </font>
<br><font size=2 face="sans-serif">&quot;preempt calls with no RPH&quot;
(or perhaps &quot;preempt calls &nbsp;with a different RPH namespace&quot;).</font>
<br>
<br><font size=2 face="sans-serif">This WOULD BE a normative change to
4412, which says in 4.7.2.1</font>
<br><font size=2 face="sans-serif">&quot;A UAS compliant with this specification
MUST terminate a session</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;established with a valid
namespace and lower-priority value in favor</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;of a new session set up
with a valid namespace and higher relative</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;priority value, unless
local policy has some form of call-waiting</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;capability enabled.&quot;</font>
<br>
<br><font size=2 face="sans-serif">Note that the only sessions that can
be preempted are ones &quot;with a valid namespace and a lower </font>
<br><font size=2 face="sans-serif">priority value&quot;. &nbsp;A &quot;normal&quot;
call has neither a &quot;valid namespace&quot;, nor a &quot;priority value&quot;
</font>
<br><font size=2 face="sans-serif">(higher or lower), and thus cannot be
preempted under 4412.</font>
<br>
<br><font size=2 face="sans-serif">Furthermore, RFC4411 (which focuses
on &quot;preemption&quot;) repeatedly refers to the pre-empted </font>
<br><font size=2 face="sans-serif">call/session having an RPH with a lower
priority value.</font>
<br>
<br><font size=2 face="sans-serif">The circuit switched versions of preemption
( both MLPP for landlines, and 3GPP e-MLPP for GSM) </font>
<br><font size=2 face="sans-serif">are even more restrictive. &nbsp;In
those schemes, a call can only preempt a lower priority call IN </font>
<br><font size=2 face="sans-serif">THE SAME PREEMPTION DOMAIN (there is
a rough correspondence between &quot;preemption domain&quot; and &quot;RPH
</font>
<br><font size=2 face="sans-serif">namespace&quot;).</font>
<br>
<br><font size=2 face="sans-serif">So I take serious objection to any suggestion
of preempting &quot;normal&quot; calls.</font>
<br>
<br><font size=2 face="sans-serif">If you want to have high priority esnet
calls preempt low priority esnet calls, I don't object as </font>
<br><font size=2 face="sans-serif">strenuously. (But no preempting &quot;normal&quot;
calls.)</font>
<br>
<br>
<br><font size=2 face="sans-serif">Section 5, 3rd para</font>
<br><font size=2 face="sans-serif">&quot; &nbsp;A simple means of preventing
this usage is to not allow marked </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;traffic preferential treatment
unless the destination is towards the</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;local/regional ESInet.
&quot;</font>
<br>
<br><font size=2 face="sans-serif">This seems to contradict the text in
section 1</font>
<br><font size=2 face="sans-serif">&quot;This new namespace can </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;be used for inbound calls
to PSAPs, between PSAPs, and between a </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;PSAP and first responders
and their organizations.&quot;</font>
<br><font size=2 face="sans-serif">and section 3</font>
<br><font size=2 face="sans-serif">&quot; This namespace will also be used
</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;for communications between
emergency authorities, and MAY be used </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;for emergency authorities
calling public citizens. &nbsp;An example of </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;the later is a PSAP operator
calling back someone who previously </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;called 9111/112/999 and
the communication was terminated before it </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;should have been (in the
operator's judgment).&quot;</font>
<br>
<br><font size=2 face="sans-serif">Finally, at IETF 73 you assured me that
you would insert strong language pointing to section 8 of </font>
<br><font size=2 face="sans-serif">RFC4412 addressing the relative priority
of the different namespaces. &nbsp;This is to eliminate any </font>
<br><font size=2 face="sans-serif">possible suggestion (that some people
- not me- read into the 00 version) that an esnet </font>
<br><font size=2 face="sans-serif">namespace would have higher priority
than an ets namespace. &nbsp;I find no such reference to section </font>
<br><font size=2 face="sans-serif">8 of 4412.</font>
<br>
<br><font size=2 face="sans-serif">Thanks, and please note that I strongly
support the creation of the esnet namespace. &nbsp;None of my comment should
be interpreted as being &quot;against&quot; esnet.</font>
<br>
<br><font size=2 face="sans-serif">Janet</font>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br><font size=2 face="sans-serif"><br>
<br>
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. <br>
NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>&quot;James M. Polk&quot;
&lt;[email-masked]&gt;</b> </font>
<br><font size=1 face="sans-serif">Sent by: [email-masked]</font>
<p><font size=1 face="sans-serif">02/19/2009 09:32 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">&quot;'ECRIT'&quot; &lt;[email-masked]&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01
submitted</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>ECRIT<br>
<br>
I've just submitted a rev of the &quot;esnet&quot; Resource-Prioriy header
draft.<br>
<br>
I've removed all mention of UAs from the draft, but leave in the <br>
possibility for adjacent VSPs to have a trust relationship with the <br>
local ESInet and mark these SIP requests accordingly through the <br>
VSP's domain. &nbsp;I offer that the ESRP at the ESInet edge will be <br>
tasked with mapping the esnet.priority-values from outside the ESInet <br>
to the indications used inside the ESInet. &nbsp;The ID gives no guidance
<br>
on what the priority-values should be in either case - as that is a <br>
matter for other documents (and I'd argue - for other SDOs or <br>
consortia such as NENA and EENA, though I don't mention either <br>
organization in the ID).<br>
<br>
Comments are welcome<br>
<br>
James<br>
<br>
&gt;From: IETF I-D Submission Tool &lt;[email-masked]&gt;<br>
&gt;To: [email-masked]<br>
&gt;Subject: New Version Notification for<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;draft-ietf-ecrit-local-emergency-rph-namespace-01<br>
&gt;Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST)<br>
&gt;<br>
&gt;<br>
&gt;A new version of I-D, <br>
&gt;draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been <br>
&gt;successfuly submitted by James Polk and posted to the IETF repository.<br>
&gt;<br>
&gt;Filename: &nbsp; &nbsp; &nbsp; draft-ietf-ecrit-local-emergency-rph-namespace<br>
&gt;Revision: &nbsp; &nbsp; &nbsp; 01<br>
&gt;Title: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;IANA Registering a SIP Resource
Priority Header <br>
&gt;Namespace for Local Emergency Communications<br>
&gt;Creation_date: &nbsp;2009-02-19<br>
&gt;WG ID: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ecrit<br>
&gt;Number_of_pages: 7<br>
&gt;<br>
&gt;Abstract:<br>
&gt;This document creates and IANA registers the new Session Initiation<br>
&gt;Protocol (SIP) Resource Priority header (RPH) namespace &quot;esnet&quot;
for<br>
&gt;local emergency usage to a public safety answering point (PSAP),<br>
&gt;between PSAPs, and between a PSAP and first responders and their<br>
&gt;organizations.<br>
&gt; <br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;The IETF Secretariat.<br>
<br>
_______________________________________________<br>
Ecrit mailing list<br>
[email-masked]<br>
https://www.ietf.org/mailman/listinfo/ecrit<br>
</tt></font>
<br>
--=_alternative 00744BD985257567_=--

Date: Wed, 25 Feb 2009 11:24:06 +0800
From: Robins George <[email-masked]>
To: ECRIT IETF <[email-masked]>
Organization: Huawei Technologies Co. Ltd
Subject: [Ecrit] draft-george-ecrit-lamp-post-00]
Reply-To: [email-masked]

Hi All,

I have submitted a draft which describes an extension to civic location 
format and
adds new element PN (pole number). PN carries utility and lamp post  number
information which can identify a civic location.

http://tools.ietf.org/html/draft-george-ecrit-lamp-post-00

Comments are appreciated.

Regards,
Robins.

-- 

Content-class: urn:content-classes:message
Date: Tue, 24 Feb 2009 21:56:48 -0600
From: "Winterbottom, James" <[email-masked]>
To: <[email-masked]>, "ECRIT IETF" <[email-masked]>
Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00]

A couple of things.=0D=0A=0D=0AFirst this should be posted to geopriv and e=
crit.=0D=0A=0D=0ASecondly, could these not be covered by the LOC and landma=
rk fields=3F=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A-----Original Message-=
----=0D=0AFrom: [email-masked] [mailto:[email-masked]] On B=
ehalf=0D=0AOf Robins George=0D=0ASent: Wednesday, 25 February 2009 2:24 PM=0D=
=0ATo: ECRIT IETF=0D=0ASubject: [Ecrit] draft-george-ecrit-lamp-post-00]=0D=
=0A=0D=0AHi All,=0D=0A=0D=0AI have submitted a draft which describes an ext=
ension to civic location=20=0D=0Aformat and=0D=0Aadds new element PN (pole =
number). PN carries utility and lamp post=0D=0Anumber=0D=0Ainformation whic=
h can identify a civic location.=0D=0A=0D=0Ahttp://tools.ietf.org/html/draf=
t-george-ecrit-lamp-post-00=0D=0A=0D=0AComments are appreciated.=0D=0A=0D=0A=
Regards,=0D=0ARobins.=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A                  =
    =20=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A--=20=0D=0A=0D=0A___=
____________________________________________=0D=0AEcrit mailing list=0D=0AE=
[email-masked]=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A-=
---------------------------------------------------------------------------=
--------------------=0D=0AThis message is for the designated recipient only=
 and may=0D=0Acontain privileged, proprietary, or otherwise private informa=
tion. =20=0D=0AIf you have received it in error, please notify the sender=0D=
=0Aimmediately and delete the original.  Any unauthorized use of=0D=0Athis =
email is prohibited.=0D=0A-------------------------------------------------=
-----------------------------------------------=0D=0A[mf2]=0D=0A

Content-class: urn:content-classes:message
Date: Tue, 24 Feb 2009 22:00:28 -0600
From: "Winterbottom, James" <[email-masked]>
To: <[email-masked]>, "ECRIT IETF" <[email-masked]>
Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00]

Further to that.=0D=0AIf you do require to have additional fields, then it =
would be much=0D=0Acleaner create a new namespace for the extra elements th=
at you require,=0D=0Aand then add this to your civic structure.=0D=0A=0D=0A=
I will send an example when I get a spare few minutes.=0D=0A=0D=0ACheers=0D=
=0AJames=0D=0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounc=
[email-masked] [mailto:[email-masked]] On Behalf=0D=0AOf Robins George=0D=
=0ASent: Wednesday, 25 February 2009 2:24 PM=0D=0ATo: ECRIT IETF=0D=0ASubje=
ct: [Ecrit] draft-george-ecrit-lamp-post-00]=0D=0A=0D=0AHi All,=0D=0A=0D=0A=
I have submitted a draft which describes an extension to civic location=20=0D=
=0Aformat and=0D=0Aadds new element PN (pole number). PN carries utility an=
d lamp post=0D=0Anumber=0D=0Ainformation which can identify a civic locatio=
n.=0D=0A=0D=0Ahttp://tools.ietf.org/html/draft-george-ecrit-lamp-post-00=0D=
=0A=0D=0AComments are appreciated.=0D=0A=0D=0ARegards,=0D=0ARobins.=0D=0A=0D=
=0A=0D=0A=0D=0A=0D=0A=0D=0A                      =20=0D=0A=0D=0A=0D=0A=0D=0A=0D=
=0A=0D=0A=0D=0A=0D=0A--=20=0D=0A=0D=0A_____________________________________=
__________=0D=0AEcrit mailing list=0D=[email-masked]=0D=0Ahttps://www.iet=
f.org/mailman/listinfo/ecrit=0D=0A=0D=0A-----------------------------------=
-------------------------------------------------------------=0D=0AThis mes=
sage is for the designated recipient only and may=0D=0Acontain privileged, =
proprietary, or otherwise private information. =20=0D=0AIf you have receive=
d it in error, please notify the sender=0D=0Aimmediately and delete the ori=
ginal.  Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------=
---------------------------------------------------------------------------=
--------------=0D=0A[mf2]=0D=0A

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: ECRIT <[email-masked]>
Date: Wed, 25 Feb 2009 18:16:17 +0100
Accept-Language: en-US
acceptlanguage: en-US
Subject: [Ecrit] ECRIT interim meeting

Can you put out an email that has all the details of this interim meeting i=
n the same message, i.e.

-	date and time
-	agenda
-	bridge details
-	any registration details

So far what I have seen seems to be split across multiple mails, and I don'=
t believe I have even seen direct confirmation it is actually happening.

Keith=

From: "Hannes Tschofenig" <[email-masked]>
To: "'DRAGE, Keith \(Keith\)'" <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Wed, 25 Feb 2009 19:26:36 +0200
Subject: [Ecrit] REMINDER: ECRIT interim meeting - 26th February, 2:00 PM EST

As distributed a while ago you can find information about the conference
call at the ECRIT WG Wiki: 
http://tools.ietf.org/wg/ecrit/trac/wiki

(conference bridge info, agenda, Webex)

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of DRAGE, Keith (Keith)
>Sent: 25 February, 2009 19:16
>To: ECRIT
>Subject: [Ecrit] ECRIT interim meeting
>
>Can you put out an email that has all the details of this 
>interim meeting in the same message, i.e.
>
>-	date and time
>-	agenda
>-	bridge details
>-	any registration details
>
>So far what I have seen seems to be split across multiple 
>mails, and I don't believe I have even seen direct 
>confirmation it is actually happening.
>
>Keith
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'ECRIT'" <[email-masked]>
Date: Wed, 25 Feb 2009 20:47:46 +0200
Subject: [Ecrit] Slides, Please

Please send me your slides for our phone conference so that I can upload
them to the ECRIT wiki page before the meeting starts. 

Thanks. 

Ciao
Hannes

Date: Wed, 25 Feb 2009 15:26:23 -0500
From: Karl Heinz Wolf <[email-masked]>
To: "Winterbottom, James" <[email-masked]>
Cc: ECRIT IETF <[email-masked]>
Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00]

Wouldn't the ADDCODE (Additional Code) element be a good place for the
lamp number code?

karl heinz

On Tue, Feb 24, 2009 at 10:56 PM, Winterbottom, James
<[email-masked]> wrote:
> A couple of things.
>
> First this should be posted to geopriv and ecrit.
>
> Secondly, could these not be covered by the LOC and landmark fields?
>
> Cheers
> James
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Robins George
> Sent: Wednesday, 25 February 2009 2:24 PM
> To: ECRIT IETF
> Subject: [Ecrit] draft-george-ecrit-lamp-post-00]
>
> Hi All,
>
> I have submitted a draft which describes an extension to civic location
> format and
> adds new element PN (pole number). PN carries utility and lamp post
> number
> information which can identify a civic location.
>
> http://tools.ietf.org/html/draft-george-ecrit-lamp-post-00
>
> Comments are appreciated.
>
> Regards,
> Robins.
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>
> -------------------------------------------------------------------------=
-----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. =A0Any unauthorized use of
> this email is prohibited.
> -------------------------------------------------------------------------=
-----------------------
> [mf2]
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

Date: Thu, 26 Feb 2009 08:40:30 +0800
From: Robins George <[email-masked]>
To: Karl Heinz Wolf <[email-masked]>
Organization: Huawei Technologies Co. Ltd
Cc: GEOPRIV <[email-masked]>, ECRIT IETF <[email-masked]>
Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00]
Reply-To: [email-masked]

I 'd prefer using the PIDF-LO IANA procedure for adding a new element 
for lamp posts.
I think that re-using the address code is probably not a particularly 
good idea.

-robins

Karl Heinz Wolf wrote:
> Wouldn't the ADDCODE (Additional Code) element be a good place for the
> lamp number code?
>
> karl heinz
>
> On Tue, Feb 24, 2009 at 10:56 PM, Winterbottom, James
> <[email-masked]> wrote:
>   
>> A couple of things.
>>
>> First this should be posted to geopriv and ecrit.
>>
>> Secondly, could these not be covered by the LOC and landmark fields?
>>
>> Cheers
>> James
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Robins George
>> Sent: Wednesday, 25 February 2009 2:24 PM
>> To: ECRIT IETF
>> Subject: [Ecrit] draft-george-ecrit-lamp-post-00]
>>
>> Hi All,
>>
>> I have submitted a draft which describes an extension to civic location
>> format and
>> adds new element PN (pole number). PN carries utility and lamp post
>> number
>> information which can identify a civic location.
>>
>> http://tools.ietf.org/html/draft-george-ecrit-lamp-post-00
>>
>> Comments are appreciated.
>>
>> Regards,
>> Robins.
>>
>>
>>
>>
>>     

Date: Wed, 25 Feb 2009 20:01:58 -0500
From: Richard Barnes <[email-masked]>
To: [email-masked]
Cc: GEOPRIV <[email-masked]>, ECRIT IETF <[email-masked]>
Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00]

Robins,

Given that your use case may be of a more local than global nature, I 
wonder if it would be appropriate to instead set a local standard that 
maps to the global (RFC 5139) standard.  We've been working on a 
document that has recommendations for how to do that:
<http://tools.ietf.org/html/draft-ietf-geopriv-civic-address-recommendations>

--Richard

Robins George wrote:
> 
> I 'd prefer using the PIDF-LO IANA procedure for adding a new element 
> for lamp posts.
> I think that re-using the address code is probably not a particularly 
> good idea.
> 
> -robins
> 
> Karl Heinz Wolf wrote:
>> Wouldn't the ADDCODE (Additional Code) element be a good place for the
>> lamp number code?
>>
>> karl heinz
>>
>> On Tue, Feb 24, 2009 at 10:56 PM, Winterbottom, James
>> <[email-masked]> wrote:
>>  
>>> A couple of things.
>>>
>>> First this should be posted to geopriv and ecrit.
>>>
>>> Secondly, could these not be covered by the LOC and landmark fields?
>>>
>>> Cheers
>>> James
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>> Of Robins George
>>> Sent: Wednesday, 25 February 2009 2:24 PM
>>> To: ECRIT IETF
>>> Subject: [Ecrit] draft-george-ecrit-lamp-post-00]
>>>
>>> Hi All,
>>>
>>> I have submitted a draft which describes an extension to civic location
>>> format and
>>> adds new element PN (pole number). PN carries utility and lamp post
>>> number
>>> information which can identify a civic location.
>>>
>>> http://tools.ietf.org/html/draft-george-ecrit-lamp-post-00
>>>
>>> Comments are appreciated.
>>>
>>> Regards,
>>> Robins.
>>>
>>>
>>>
>>>
>>>     
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
> 

From: "Edge, Stephen" <[email-masked]>
To: Brian Rosen <[email-masked]>, "'ECRIT'" <[email-masked]>
Date: Wed, 25 Feb 2009 18:10:51 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Ecrit] Comments on Framework Draft

Brian

First of all apologies for the likely lateness of this reply - I actually w=
rote it on 19 February in a 3GPP SA2 meeting in Budapest but it seems unlik=
ely that my VPN, Outlook server and WiFi access capability will cooperate t=
ogether to get it sent until I return to the office mid-next week.

Anyhow thanks for your comments. There have actually been a number of confe=
rence calls between IETF and 3GPP participants over the last couple of year=
s at which common features like support of IP emergency calls were discusse=
d and these could have been good forum for participants on either side to h=
ave raised the kinds of issues you elaborate on below. Given that seems not=
 so far to have happened, it could still be possible in future such calls.

But the issues we are raising are not directly to do with further aligning =
the 2 solutions or with the lack of this in the past. We are simply pointin=
g out that the solutions are currently different and that from a cellular w=
ireless perspective, the Ecrit solution is not seen as suitable in all resp=
ects (for support of IP emergency calls originating from such access types)=
. That is not just our point of view. 3GPP2 sent a liaison to Ecrit some mo=
nths ago pointing out the same issues.

So we are proposing that the Ecrit framework and phoneBCP spec.s include a =
statement acknowledging this - e.g. by referencing the alternative 3GPP/3GP=
P2 solution and indicating the IP access types for which the Ecrit solution=
 will work without limitation (or equivalently the access types where limit=
ations are not ruled out).

We are not proposing further modification and extension of the Ecrit soluti=
on - just pointing out that this would be needed (as with the 3GPP/3GPP2 so=
lution) to fully cover all types of access.

Kind Regards=20

Stephen
-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]=20
Sent: Wednesday, February 18, 2009 8:07 PM
To: Edge, Stephen; 'ECRIT'
Subject: RE: [Ecrit] Comments on Framework Draft

I have bit my tongue on this one for a long time.

Stephen, with respect, please go talk to 3GPP management and ask them  why
there has been no participation in the ecrit effort despite multiple YEARS
of begging them to get involved.  To put it frankly, 3GPP is quite willing
to bully IETF into doing its work on its schedule, but cannot be bothered t=
o
get work done it knows it will eventually have to do when the IETF asks it
to do so.

3GPP understands the mess that is being created by not participating.  They
know full well that when they finally get around to dealing with PS
terminated emergency calls, that there will be a lot of resistance to
changing fully specified and implemented standards to more closely align
with 3GPP standards.  I expect you will have several interworking functions
to define and build.

So, politely, please go away, we're finishing work we dearly wanted you all
to be involved with for years, but you refused to do anything.  It's too
late for this rev.

Now, having said that, there are quite a few people who have participated i=
n
the IETF work who are IMS aware and I believe that despite your fears,
everything you need is in the specs.  The mechanisms we have defined provid=
e
the ability for the network to insert location, recognize and mark emergenc=
y
calls, and route on behalf of endpoints.  An E-CSCF could quite
straightforwardly provide a SIP call towards an ecrit compatible PSAP.  The
only not-quite-nice interwork would be from SUPL to HELD (or SIP), but it's
pretty easy to do that.  I'll also note that we have tried to get OMA and
IETF to cooperate on location protocols, but we have been spectacularly
unsuccessful at that effort also.

Brian

 =20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Edge, Stephen
> Sent: Thursday, February 05, 2009 2:50 AM
> To: 'ECRIT'
> Subject: [Ecrit] Comments on Framework Draft
>=20
> All
>=20
> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative
> description of how terminals and networks should support emergency
> calls made over IP capable facilities to IP capable PSAPs. It appears
> intended to cover all types of access network - including fixed line,
> WiFi and cellular (e.g. examples involving each can be found throughout
> the draft).
>=20
> When we evaluated this with respect to support of wireless cellular
> access and WiFi access associated with a cellular operator (e.g. WLAN
> or Femto cells integrated into a cellular network), we found that
> certain portions of the draft exhibited one or more of the following
> characteristics:
>=20
> =A0=A0=A0 (A) Inconsistent with already standardized wireless solutions
>=20
> =A0=A0=A0 (B) Inconsistent with essential wireless requirements and
> conventions
>=20
> =A0=A0=A0 (C) Already part of wireless standards or potentially part of
> future standards
>=20
> (A) refers to all portions of the draft framework that differ from the
> requirements and procedures currently standardized for wireless
> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference of
> solution and could be resolved through support of both solutions by
> terminals (with each solution being used according to the type of
> access network and VSP) or could be resolved by supporting only one
> solution and accessing only the types of network supporting that
> solution. To acknowledge this category, the framework document could
> reference the applicable wireless standards and point out that these
> are valid alternatives for wireless cellular based access.
>=20
> (B) refers to portions of the draft that would be unsuitable for
> wireless networks even if no alternative solution existed together with
> other portions missing from the draft that would be needed to fully
> support wireless networks. Examples of the former include: (a) emphasis
> on endpoint derivation of location, performance of Lost query and
> receipt of local dial strings; (b) restriction of LCPs to protocols
> that require terminal initiation (not allowing for network initiation
> as far as we can tell) and that include two LCPs (DHCP and LLDP) that
> are not applicable to (not defined for) cellular access; and (c) the
> requirement that a terminal or at least a LIS will update the PSAP
> whenever location changes. (a) is impractical due to network and
> terminal loading consequences and failure to support non-IP capable
> PSAPs; (b) makes location verification and updated location provision
> to PSAPs difficult or impossible; while (c) is also incompatible with
> support of existing non-IP capable PSAPs besides increasing terminal
> load and possibly interfering with optimum maintenance of the RF
> connection (e.g. if a terminal has to tune away from the serving base
> station or WLAN periodically to make location measurements). Examples
> of the latter include (d) absence of support for access to non-IP
> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in the
> US); (e) no support for handover from the IP to the circuit domain when
> a terminal loses (e.g. moves out of) RF coverage in the IP domain; and
> (f) no allowance for limited access modes wherein a terminal may access
> a network only to place an emergency call with ensuing restrictions on
> (for example) location acquisition, PSAP callback and caller
> verification and identification to the PSAP. To resolve this category
> either significant changes to the framework document could be made or a
> disclaimer/applicability statement could be added stating that support
> of cellular wireless networks and their associated WLAN and Femto
> access points is not covered.
>=20
> Category (C) comprises concepts and capabilities in the draft that are
> either already part of the standardized solution for wireless networks
> or that might be added at a later time. Examples of the former include
> LoST, SIP location conveyance, general use of SIP, location for routing
> versus for dispatch, cellular positioning methods. Examples of the
> latter include use of location references and dereferencing and
> possible interworking between the current wireless network solutions
> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. The
> presence of this category could be acknowledged by following the
> disclaimer for (B) with a statement that certain portions of the
> solution are expected to be incorporated into wireless networks now
> and/or in the future.
>=20
> We hope that these comments will be seen to be a useful addition to
> this review in the sense of enabling a more precise scoping for the
> framework document and we are willing to assist in providing wording
> for any disclaimer/applicability statement that the Ecrit working group
> may now deem fit to include.
>=20
> Kind Regards
>=20
> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm
> 3GPP2 TSG-X and TSG-C participant)
>=20
> PS  this being sent on 2/4/09 at 11:50pm PST
>=20
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

Date: Wed, 25 Feb 2009 21:30:06 -0500
From: Richard Barnes <[email-masked]>
To: "Edge, Stephen" <[email-masked]>
Cc: 'ECRIT' <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

Hi Stephen,

I'm a little confused by the scope of what you're asking.  The framework 
and phonebcp documents exist in order to describe the ECRIT solution: 
They say, in effect, "SIP emergency calling works if all parties behave 
as specified in these documents."

As I understand what you're saying (and I'm by no means an expert in 
3GPP), 3GPP specifies that one or more elements of this system behave 
differently.  This simply means that 3GPP networks aren't complying with 
these specs.  Just like there's no disclaimer in RFC 791 (IPv4) that 
says "this doesn't work on X.25 networks", it's not clear to me that an 
analogous disclaimer is called for here.

I presume there are similar documents describing how emergency calling 
works in 3GPP networks.  Do they include notes saying that the 3GPP 
solution doesn't work in the broader Internet?

--Richard

Edge, Stephen wrote:
> Brian
> 
> First of all apologies for the likely lateness of this reply - I actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but it seems unlikely that my VPN, Outlook server and WiFi access capability will cooperate together to get it sent until I return to the office mid-next week.
> 
> Anyhow thanks for your comments. There have actually been a number of conference calls between IETF and 3GPP participants over the last couple of years at which common features like support of IP emergency calls were discussed and these could have been good forum for participants on either side to have raised the kinds of issues you elaborate on below. Given that seems not so far to have happened, it could still be possible in future such calls.
> 
> But the issues we are raising are not directly to do with further aligning the 2 solutions or with the lack of this in the past. We are simply pointing out that the solutions are currently different and that from a cellular wireless perspective, the Ecrit solution is not seen as suitable in all respects (for support of IP emergency calls originating from such access types). That is not just our point of view. 3GPP2 sent a liaison to Ecrit some months ago pointing out the same issues.
> 
> So we are proposing that the Ecrit framework and phoneBCP spec.s include a statement acknowledging this - e.g. by referencing the alternative 3GPP/3GPP2 solution and indicating the IP access types for which the Ecrit solution will work without limitation (or equivalently the access types where limitations are not ruled out).
> 
> We are not proposing further modification and extension of the Ecrit solution - just pointing out that this would be needed (as with the 3GPP/3GPP2 solution) to fully cover all types of access.
> 
> Kind Regards 
> 
> Stephen
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Wednesday, February 18, 2009 8:07 PM
> To: Edge, Stephen; 'ECRIT'
> Subject: RE: [Ecrit] Comments on Framework Draft
> 
> I have bit my tongue on this one for a long time.
> 
> Stephen, with respect, please go talk to 3GPP management and ask them  why
> there has been no participation in the ecrit effort despite multiple YEARS
> of begging them to get involved.  To put it frankly, 3GPP is quite willing
> to bully IETF into doing its work on its schedule, but cannot be bothered to
> get work done it knows it will eventually have to do when the IETF asks it
> to do so.
> 
> 3GPP understands the mess that is being created by not participating.  They
> know full well that when they finally get around to dealing with PS
> terminated emergency calls, that there will be a lot of resistance to
> changing fully specified and implemented standards to more closely align
> with 3GPP standards.  I expect you will have several interworking functions
> to define and build.
> 
> So, politely, please go away, we're finishing work we dearly wanted you all
> to be involved with for years, but you refused to do anything.  It's too
> late for this rev.
> 
> Now, having said that, there are quite a few people who have participated in
> the IETF work who are IMS aware and I believe that despite your fears,
> everything you need is in the specs.  The mechanisms we have defined provide
> the ability for the network to insert location, recognize and mark emergency
> calls, and route on behalf of endpoints.  An E-CSCF could quite
> straightforwardly provide a SIP call towards an ecrit compatible PSAP.  The
> only not-quite-nice interwork would be from SUPL to HELD (or SIP), but it's
> pretty easy to do that.  I'll also note that we have tried to get OMA and
> IETF to cooperate on location protocols, but we have been spectacularly
> unsuccessful at that effort also.
> 
> Brian
> 
>   
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Edge, Stephen
>> Sent: Thursday, February 05, 2009 2:50 AM
>> To: 'ECRIT'
>> Subject: [Ecrit] Comments on Framework Draft
>>
>> All
>>
>> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative
>> description of how terminals and networks should support emergency
>> calls made over IP capable facilities to IP capable PSAPs. It appears
>> intended to cover all types of access network - including fixed line,
>> WiFi and cellular (e.g. examples involving each can be found throughout
>> the draft).
>>
>> When we evaluated this with respect to support of wireless cellular
>> access and WiFi access associated with a cellular operator (e.g. WLAN
>> or Femto cells integrated into a cellular network), we found that
>> certain portions of the draft exhibited one or more of the following
>> characteristics:
>>
>>     (A) Inconsistent with already standardized wireless solutions
>>
>>     (B) Inconsistent with essential wireless requirements and
>> conventions
>>
>>     (C) Already part of wireless standards or potentially part of
>> future standards
>>
>> (A) refers to all portions of the draft framework that differ from the
>> requirements and procedures currently standardized for wireless
>> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference of
>> solution and could be resolved through support of both solutions by
>> terminals (with each solution being used according to the type of
>> access network and VSP) or could be resolved by supporting only one
>> solution and accessing only the types of network supporting that
>> solution. To acknowledge this category, the framework document could
>> reference the applicable wireless standards and point out that these
>> are valid alternatives for wireless cellular based access.
>>
>> (B) refers to portions of the draft that would be unsuitable for
>> wireless networks even if no alternative solution existed together with
>> other portions missing from the draft that would be needed to fully
>> support wireless networks. Examples of the former include: (a) emphasis
>> on endpoint derivation of location, performance of Lost query and
>> receipt of local dial strings; (b) restriction of LCPs to protocols
>> that require terminal initiation (not allowing for network initiation
>> as far as we can tell) and that include two LCPs (DHCP and LLDP) that
>> are not applicable to (not defined for) cellular access; and (c) the
>> requirement that a terminal or at least a LIS will update the PSAP
>> whenever location changes. (a) is impractical due to network and
>> terminal loading consequences and failure to support non-IP capable
>> PSAPs; (b) makes location verification and updated location provision
>> to PSAPs difficult or impossible; while (c) is also incompatible with
>> support of existing non-IP capable PSAPs besides increasing terminal
>> load and possibly interfering with optimum maintenance of the RF
>> connection (e.g. if a terminal has to tune away from the serving base
>> station or WLAN periodically to make location measurements). Examples
>> of the latter include (d) absence of support for access to non-IP
>> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in the
>> US); (e) no support for handover from the IP to the circuit domain when
>> a terminal loses (e.g. moves out of) RF coverage in the IP domain; and
>> (f) no allowance for limited access modes wherein a terminal may access
>> a network only to place an emergency call with ensuing restrictions on
>> (for example) location acquisition, PSAP callback and caller
>> verification and identification to the PSAP. To resolve this category
>> either significant changes to the framework document could be made or a
>> disclaimer/applicability statement could be added stating that support
>> of cellular wireless networks and their associated WLAN and Femto
>> access points is not covered.
>>
>> Category (C) comprises concepts and capabilities in the draft that are
>> either already part of the standardized solution for wireless networks
>> or that might be added at a later time. Examples of the former include
>> LoST, SIP location conveyance, general use of SIP, location for routing
>> versus for dispatch, cellular positioning methods. Examples of the
>> latter include use of location references and dereferencing and
>> possible interworking between the current wireless network solutions
>> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. The
>> presence of this category could be acknowledged by following the
>> disclaimer for (B) with a statement that certain portions of the
>> solution are expected to be incorporated into wireless networks now
>> and/or in the future.
>>
>> We hope that these comments will be seen to be a useful addition to
>> this review in the sense of enabling a more precise scoping for the
>> framework document and we are willing to assist in providing wording
>> for any disclaimer/applicability statement that the Ecrit working group
>> may now deem fit to include.
>>
>> Kind Regards
>>
>> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm
>> 3GPP2 TSG-X and TSG-C participant)
>>
>> PS  this being sent on 2/4/09 at 11:50pm PST
>>
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
> 

Content-class: urn:content-classes:message
Date: Wed, 25 Feb 2009 22:47:59 -0600
From: "Winterbottom, James" <[email-masked]>
To: "Edge, Stephen" <[email-masked]>, "Brian Rosen" <[email-masked]>, "ECRIT" <[email-masked]>
Subject: Re: [Ecrit] Comments on Framework Draft

Hi Stephen,=0D=0A=0D=0AIt is a pity that you were not in the NENA location =
WG meeting in Orlando last week, as we had a very pertinent example put for=
ward.=0D=0A=0D=0AThe example was a guy with a CDMA EVDO capable device, he =
is able to establish a VPN connection back into his corporate network and t=
hen make VoIP calls. The gentleman in question claims that he does this reg=
ularly. If he were to make an emergency call would it be following the ECRI=
T or 3GPP2 call flows=3F=0D=0A=0D=0AThe answer is that the call flow follow=
s the ECRIT flow but the access is CDMA EVDO, clearly 3GPP2, and clearly ce=
llular! Ipso facto ECRIT on cellular works!=0D=0A=0D=0AI don't believe that=
 anybody that understands the ECRIT architecture and has a notion of what p=
roducts are being sold and used today can seriously suggest that the ECRIT =
architecture doesn't work for a cellular network. The fact that home router=
s with 3G Internet connections are being sold is an indicator that the 3G s=
ervice is just another access to the Internet and that VoIP over 3G is bein=
g used and that ECRIT over 3G is quite possible.=0D=0A=0D=0APerhaps it woul=
d be pertinent at this time to ask precisely which bits of the ECRIT archit=
ecture you feel are unworkable in a 3GPP/2 network=3F=0D=0A=0D=0ACheers=0D=0A=
James=0D=0A=0D=0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bo=
[email-masked] [mailto:[email-masked]] On Behalf Of Edge, Stephen=0D=
=0ASent: Thursday, 26 February 2009 1:11 PM=0D=0ATo: Brian Rosen; 'ECRIT'=0D=
=0ASubject: Re: [Ecrit] Comments on Framework Draft=0D=0A=0D=0ABrian=0D=0A=0D=
=0AFirst of all apologies for the likely lateness of this reply - I actuall=
y wrote it on 19 February in a 3GPP SA2 meeting in Budapest but it seems un=
likely that my VPN, Outlook server and WiFi access capability will cooperat=
e together to get it sent until I return to the office mid-next week.=0D=0A=0D=
=0AAnyhow thanks for your comments. There have actually been a number of co=
nference calls between IETF and 3GPP participants over the last couple of y=
ears at which common features like support of IP emergency calls were discu=
ssed and these could have been good forum for participants on either side t=
o have raised the kinds of issues you elaborate on below. Given that seems =
not so far to have happened, it could still be possible in future such call=
s.=0D=0A=0D=0ABut the issues we are raising are not directly to do with fur=
ther aligning the 2 solutions or with the lack of this in the past. We are =
simply pointing out that the solutions are currently different and that fro=
m a cellular wireless perspective, the Ecrit solution is not seen as suitab=
le in all respects (for support of IP emergency calls originating from such=
 access types). That is not just our point of view. 3GPP2 sent a liaison to=
 Ecrit some months ago pointing out the same issues.=0D=0A=0D=0ASo we are p=
roposing that the Ecrit framework and phoneBCP spec.s include a statement a=
cknowledging this - e.g. by referencing the alternative 3GPP/3GPP2 solution=
 and indicating the IP access types for which the Ecrit solution will work =
without limitation (or equivalently the access types where limitations are =
not ruled out).=0D=0A=0D=0AWe are not proposing further modification and ex=
tension of the Ecrit solution - just pointing out that this would be needed=
 (as with the 3GPP/3GPP2 solution) to fully cover all types of access.=0D=0A=0D=
=0AKind Regards=20=0D=0A=0D=0AStephen=0D=0A-----Original Message-----=0D=0A=
From: Brian Rosen [mailto:[email-masked]]=20=0D=0ASent: Wednesday, Febru=
ary 18, 2009 8:07 PM=0D=0ATo: Edge, Stephen; 'ECRIT'=0D=0ASubject: RE: [Ecr=
it] Comments on Framework Draft=0D=0A=0D=0AI have bit my tongue on this one=
 for a long time.=0D=0A=0D=0AStephen, with respect, please go talk to 3GPP =
management and ask them  why=0D=0Athere has been no participation in the ec=
rit effort despite multiple YEARS=0D=0Aof begging them to get involved.  To=
 put it frankly, 3GPP is quite willing=0D=0Ato bully IETF into doing its wo=
rk on its schedule, but cannot be bothered to=0D=0Aget work done it knows i=
t will eventually have to do when the IETF asks it=0D=0Ato do so.=0D=0A=0D=0A=
3GPP understands the mess that is being created by not participating.  They=0D=
=0Aknow full well that when they finally get around to dealing with PS=0D=0A=
terminated emergency calls, that there will be a lot of resistance to=0D=0A=
changing fully specified and implemented standards to more closely align=0D=
=0Awith 3GPP standards.  I expect you will have several interworking functi=
ons=0D=0Ato define and build.=0D=0A=0D=0ASo, politely, please go away, we'r=
e finishing work we dearly wanted you all=0D=0Ato be involved with for year=
s, but you refused to do anything.  It's too=0D=0Alate for this rev.=0D=0A=0D=
=0ANow, having said that, there are quite a few people who have participate=
d in=0D=0Athe IETF work who are IMS aware and I believe that despite your f=
ears,=0D=0Aeverything you need is in the specs.  The mechanisms we have def=
ined provide=0D=0Athe ability for the network to insert location, recognize=
 and mark emergency=0D=0Acalls, and route on behalf of endpoints.  An E-CSC=
F could quite=0D=0Astraightforwardly provide a SIP call towards an ecrit co=
mpatible PSAP.  The=0D=0Aonly not-quite-nice interwork would be from SUPL t=
o HELD (or SIP), but it's=0D=0Apretty easy to do that.  I'll also note that=
 we have tried to get OMA and=0D=0AIETF to cooperate on location protocols,=
 but we have been spectacularly=0D=0Aunsuccessful at that effort also.=0D=0A=0D=
=0ABrian=0D=0A=0D=0A =20=0D=0A=0D=0A> -----Original Message-----=0D=0A> Fro=
m: [email-masked] [mailto:[email-masked]] On Behalf=0D=0A> =
Of Edge, Stephen=0D=0A> Sent: Thursday, February 05, 2009 2:50 AM=0D=0A> To=
: 'ECRIT'=0D=0A> Subject: [Ecrit] Comments on Framework Draft=0D=0A>=20=0D=0A=
> All=0D=0A>=20=0D=0A> draft-ietf-ecrit-framework-07 is (as we see it) a mo=
stly informative=0D=0A> description of how terminals and networks should su=
pport emergency=0D=0A> calls made over IP capable facilities to IP capable =
PSAPs. It appears=0D=0A> intended to cover all types of access network - in=
cluding fixed line,=0D=0A> WiFi and cellular (e.g. examples involving each =
can be found throughout=0D=0A> the draft).=0D=0A>=20=0D=0A> When we evaluat=
ed this with respect to support of wireless cellular=0D=0A> access and WiFi=
 access associated with a cellular operator (e.g. WLAN=0D=0A> or Femto cell=
s integrated into a cellular network), we found that=0D=0A> certain portion=
s of the draft exhibited one or more of the following=0D=0A> characteristic=
s:=0D=0A>=20=0D=0A> =A0=A0=A0 (A) Inconsistent with already standardized wi=
reless solutions=0D=0A>=20=0D=0A> =A0=A0=A0 (B) Inconsistent with essential=
 wireless requirements and=0D=0A> conventions=0D=0A>=20=0D=0A> =A0=A0=A0 (C=
) Already part of wireless standards or potentially part of=0D=0A> future s=
tandards=0D=0A>=20=0D=0A> (A) refers to all portions of the draft framework=
 that differ from the=0D=0A> requirements and procedures currently standard=
ized for wireless=0D=0A> emergency access by 3GPP, 3GPP2 and OMA. This is a=
 plain difference of=0D=0A> solution and could be resolved through support =
of both solutions by=0D=0A> terminals (with each solution being used accord=
ing to the type of=0D=0A> access network and VSP) or could be resolved by s=
upporting only one=0D=0A> solution and accessing only the types of network =
supporting that=0D=0A> solution. To acknowledge this category, the framewor=
k document could=0D=0A> reference the applicable wireless standards and poi=
nt out that these=0D=0A> are valid alternatives for wireless cellular based=
 access.=0D=0A>=20=0D=0A> (B) refers to portions of the draft that would be=
 unsuitable for=0D=0A> wireless networks even if no alternative solution ex=
isted together with=0D=0A> other portions missing from the draft that would=
 be needed to fully=0D=0A> support wireless networks. Examples of the forme=
r include: (a) emphasis=0D=0A> on endpoint derivation of location, performa=
nce of Lost query and=0D=0A> receipt of local dial strings; (b) restriction=
 of LCPs to protocols=0D=0A> that require terminal initiation (not allowing=
 for network initiation=0D=0A> as far as we can tell) and that include two =
LCPs (DHCP and LLDP) that=0D=0A> are not applicable to (not defined for) ce=
llular access; and (c) the=0D=0A> requirement that a terminal or at least a=
 LIS will update the PSAP=0D=0A> whenever location changes. (a) is impracti=
cal due to network and=0D=0A> terminal loading consequences and failure to =
support non-IP capable=0D=0A> PSAPs; (b) makes location verification and up=
dated location provision=0D=0A> to PSAPs difficult or impossible; while (c)=
 is also incompatible with=0D=0A> support of existing non-IP capable PSAPs =
besides increasing terminal=0D=0A> load and possibly interfering with optim=
um maintenance of the RF=0D=0A> connection (e.g. if a terminal has to tune =
away from the serving base=0D=0A> station or WLAN periodically to make loca=
tion measurements). Examples=0D=0A> of the latter include (d) absence of su=
pport for access to non-IP=0D=0A> capable PSAPs as already mentioned (e.g. =
to support E911 phase 2 in the=0D=0A> US); (e) no support for handover from=
 the IP to the circuit domain when=0D=0A> a terminal loses (e.g. moves out =
of) RF coverage in the IP domain; and=0D=0A> (f) no allowance for limited a=
ccess modes wherein a terminal may access=0D=0A> a network only to place an=
 emergency call with ensuing restrictions on=0D=0A> (for example) location =
acquisition, PSAP callback and caller=0D=0A> verification and identificatio=
n to the PSAP. To resolve this category=0D=0A> either significant changes t=
o the framework document could be made or a=0D=0A> disclaimer/applicability=
 statement could be added stating that support=0D=0A> of cellular wireless =
networks and their associated WLAN and Femto=0D=0A> access points is not co=
vered.=0D=0A>=20=0D=0A> Category (C) comprises concepts and capabilities in=
 the draft that are=0D=0A> either already part of the standardized solution=
 for wireless networks=0D=0A> or that might be added at a later time. Examp=
les of the former include=0D=0A> LoST, SIP location conveyance, general use=
 of SIP, location for routing=0D=0A> versus for dispatch, cellular position=
ing methods. Examples of the=0D=0A> latter include use of location referenc=
es and dereferencing and=0D=0A> possible interworking between the current w=
ireless network solutions=0D=0A> (in 3GPP, 3GPP2 and OMA) and the solution =
described in this draft. The=0D=0A> presence of this category could be ackn=
owledged by following the=0D=0A> disclaimer for (B) with a statement that c=
ertain portions of the=0D=0A> solution are expected to be incorporated into=
 wireless networks now=0D=0A> and/or in the future.=0D=0A>=20=0D=0A> We hop=
e that these comments will be seen to be a useful addition to=0D=0A> this r=
eview in the sense of enabling a more precise scoping for the=0D=0A> framew=
ork document and we are willing to assist in providing wording=0D=0A> for a=
ny disclaimer/applicability statement that the Ecrit working group=0D=0A> m=
ay now deem fit to include.=0D=0A>=20=0D=0A> Kind Regards=0D=0A>=20=0D=0A> =
Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm=0D=0A=
> 3GPP2 TSG-X and TSG-C participant)=0D=0A>=20=0D=0A> PS  this being sent o=
n 2/4/09 at 11:50pm PST=0D=0A>=20=0D=0A> __________________________________=
_____________=0D=0A> Ecrit mailing list=0D=0A> [email-masked]=0D=0A> https:=
//www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A__________________________=
_____________________=0D=0AEcrit mailing list=0D=[email-masked]=0D=0Ahttp=
s://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A------------------------=
------------------------------------------------------------------------=0D=
=0AThis message is for the designated recipient only and may=0D=0Acontain p=
rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h=
ave received it in error, please notify the sender=0D=0Aimmediately and del=
ete the original.  Any unauthorized use of=0D=0Athis email is prohibited.=0D=
=0A------------------------------------------------------------------------=
------------------------=0D=0A[mf2]=0D=0A

From: Henning Schulzrinne <[email-masked]>
To: Richard Barnes <[email-masked]>
Date: Thu, 26 Feb 2009 07:35:33 -0500
Cc: GEOPRIV <[email-masked]>, ECRIT IETF <[email-masked]>
Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00]

Richard,

pole numbers are actually fairly common and don't seem to be  
restricted to a particular country. For example, in New Jersey (where  
I live), towns are so close together that it is often difficult to  
tell which one you are in at the moment. The "insider" recommendation  
is to look at the nearest utility pole; the first two letters  
correspond to the town name (followed by a unique numeric identifier).

Henning

On Feb 25, 2009, at 8:01 PM, Richard Barnes wrote:

> Robins,
>
> Given that your use case may be of a more local than global nature,  
> I wonder if it would be appropriate to instead set a local standard  
> that maps to the global (RFC 5139) standard.  We've been working on  
> a document that has recommendations for how to do that:
> <http://tools.ietf.org/html/draft-ietf-geopriv-civic-address-recommendations 
> >
>
> --Richard
>
>
> Robins George wrote:
>> I 'd prefer using the PIDF-LO IANA procedure for adding a new  
>> element for lamp posts.
>> I think that re-using the address code is probably not a  
>> particularly good idea.
>> -robins
>> Karl Heinz Wolf wrote:
>>> Wouldn't the ADDCODE (Additional Code) element be a good place for  
>>> the
>>> lamp number code?
>>>
>>> karl heinz
>>>
>>> On Tue, Feb 24, 2009 at 10:56 PM, Winterbottom, James
>>> <[email-masked]> wrote:
>>>
>>>> A couple of things.
>>>>
>>>> First this should be posted to geopriv and ecrit.
>>>>
>>>> Secondly, could these not be covered by the LOC and landmark  
>>>> fields?
>>>>
>>>> Cheers
>>>> James
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On  
>>>> Behalf
>>>> Of Robins George
>>>> Sent: Wednesday, 25 February 2009 2:24 PM
>>>> To: ECRIT IETF
>>>> Subject: [Ecrit] draft-george-ecrit-lamp-post-00]
>>>>
>>>> Hi All,
>>>>
>>>> I have submitted a draft which describes an extension to civic  
>>>> location
>>>> format and
>>>> adds new element PN (pole number). PN carries utility and lamp post
>>>> number
>>>> information which can identify a civic location.
>>>>
>>>> http://tools.ietf.org/html/draft-george-ecrit-lamp-post-00
>>>>
>>>> Comments are appreciated.
>>>>
>>>> Regards,
>>>> Robins.
>>>>
>>>>
>>>>
>>>>
>>>>
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

Date: Thu, 26 Feb 2009 13:39:12 -0600
To: Janet P Gunn <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: 'ECRIT' <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted

At 03:10 PM 2/24/2009, Janet P Gunn wrote:

>James
>Some of this is editorial, some is substantive and technical, and 
>some repeats my comments on 00 that do not seem to have been addressed.
>
>2nd paragraph of section 1, this sentence doesn't make sense.
>"   Within controlled environments, such as an IMS infrastructure or
>    Emergency Services network (ESInet), where misuse can be reduced to
>    a minimum where possible, this namespace is to be to provide an
>    explicit priority indication facilitates treatment of emergency SIP
>    messages according to local policy."

I think this makes perfect sense as written

>Perhaps you mean
>"   Within controlled environments, such as an IMS infrastructure or
>    Emergency Services network (ESInet), where misuse can be reduced to
>    a minimum, this namespace is expected to be used to provide an
>    explicit priority indication, facilitating treatment of emergency SIP
>    messages according to local policy."  But I am not sure if that 
> is what you meant.

that's another way of saying the same thing

>Same para
>"This indication is used to
>    differentiate SIP requests, or dialogs, from other requests or
>    dialogs that do not have the need for priority treatment."
>sounds as if you are differentiating SIP requests form non-SIP 
>requests.  Perhaps what you mean is
>"This indication is used to
>    differentiate Emergency Services related  SIP requests, or 
> dialogs, from other (non Emergency
>Services related) SIP requests or  dialogs.

again -- this appears to be two ways of saying the same thing.

>Note that "do not have the need for priority treatment" is not correct.

it applies to other traffic that does not need priority treatment. In 
other words, the traffic that doesn't need priority treatment -- 
because there will be some traffic that does not need priority 
treatment within the ESInet (as well as an esnet namespace capable VSP)

>The esnet RPH would
>distinguish ES related messages from GETS related messages (ets and 
>wps namespaces), but they
>would each get their own particular flavor of "priority treatment".
>
>
>5th para of section 1
>
>"From this fact about RFC 4412, and the possibility that within
>    emergency services networks, a Multilevel Precedence and Preemption
>    (MLPP)-like behavior can be achieved - ensuring more important calls
>    are established or retained, the "esnet" namespace is given 5
>    priority-levels."
>What is "this fact"?  Perhaps "Because we can't add new values later..."

the fact is right above this sentence

>I don't understand the "can be achieved".  Do you mean "MLPP-like 
>behavior may be desired"?

it can be, which is all that I'm offering -- but I'm not recommending 
or stipulating or demanding or anything else... I'm just saying that 
with more than 2 levels, a natural hierarchy _can_ be configured.

>I fully agree with assigning 5 levels, and the underlying logic. It 
>is only the description that is problematic.
>
>Perhaps
>"Because we can't add new values later, and because  Multilevel 
>Precedence and Preemption
>    (MLPP)-like behavior may be desired the "esnet" namespace is 
> given 5 priority-levels."

that is within 4412

>2nd to last paragraph of section 1
>"Within the ESINet, there will be emergency calls requiring different
>    treatments, according to the type of call. "
>We don't know if they will require different treatment or not.
>
>I would prefer
>"Within the ESINet, there may be emergency calls requiring different
>    treatments, according to the type of call. "
>
>or if the use of "may" will be confused with normative language,
>"Within the ESINet, there could be emergency calls requiring different
>    treatments, according to the type of call. "

I'm ok with this

>This sentence at the end of sec 1 doesn't quite work.
>"This document IANA registers the "esnet"
>    RPH namespace for use within emergency services networks, not just
>    of those from citizens to PSAPs." (no clear antecedent for "those")

fair

>Perhaps
>"This document IANA registers the "esnet"
>    RPH namespace for use within emergency services networks, not 
> just for calls or sessions
>     from citizens to PSAPs."
>(same comment applied to 00)

I'll back off this even more - to

"This document IANA registers the "esnet"
   RPH namespace for use within emergency services networks, not just 
for calls or sessions
   towards PSAPs."

>Section 2  first para says
>  "This document updates the behaviors of the SIP Resource Priority
>    header, defined in [RFC4412], during the treatment options
>    surrounding this new "esnet" namespace only. The usage of the
>    "esnet" namespace does not have a normal, or routine call level.
>    Every use of this namespace will be in times of an emergency, where
>    at least one end of the signaling is with a local emergency
>    organization."
>
>I don't see this as an "update of the behavior of 4412".  Neither 
>the ets namespace not the wps namespace have a "normal" or "routine" 
>call level.

but either (ets or wps) can simply not be used. here there is no 
routine esnet calls, every one is an emergency call, and likely every 
call will be an emergency.

>Every use of the wps and ets namespaces will have priority over 
>calls without RPH.
>
>Suggest changing text to say
>"   Like the ets and wps namespaces defined in [RFC4412], the
>    "esnet" namespace does not have a normal, or routine call level.
>     Every use of this namespace will be in times of an emergency, where
>    at least one end of the signaling is with a local emergency
>    organization."

see comment above

>Section 2, para immediately below Figure 1
>"   Because the more important usage of the
>    "esnet" namespace occurs within the ESInet, the edge proxy, called
>    an Emergency Services Routing Proxy (ESRP) can modify or delete this
>    namespace. This is a normative change to the allowed behavior within
>    [RFC4412], but MUST only be considered valid in this usage at the
>    ESInet boundary for this one RP namespace (and associated
>    priority-value). "
>
>I have major (content, not editorial) concerns with this, more for 
>what it says about 4412 than about esnet
>
>
>First of all, it is not clear to me why this is "a normative change 
>to the allowed behavior within [RFC4412]".

because 4412 says "do not modify or delete, just ignore if you don't like it"

this doc changes that for esnet only.

>For one thing I see nothing in 4412 that would prohibit a "SIP actor 
>that understands the name space"
>from modifying or deleting the namespace.

4.6.2.  No Known Namespace or Priority Value

    If an RP actor does not understand any of the resource values in 
the request, the treatment depends on the presence of the Require 
'resource-priority' option tag:

    1.  Without the option tag, the RP actor treats the request as if 
it contained no 'Resource-Priority' header field and processes it 
with default priority.  Resource values that are not understood MUST 
NOT be modified or deleted.

so, evidence to the contrary (from your statement above)

>It is certainly anticipated that at least some of the namespaces 
>described in 4412 will be
>modified or deleted, (e.g., when there is reason to  believe it is 
>unauthorized).

no, just ignored

>4412 says "Existing implementations of RFC 3261 that do not 
>participate in the
>    resource priority mechanism follow the normal rules of RFC 3261,
>    Section 8.2.2: "If a UAS does not understand a header field in a
>    request (that is, the header field is not defined in this
>    specification or in any supported extension), the server MUST ignore
>    that header field and continue processing the message". "

What about SIP entities that not only understand RPH, but understand 
the "esnet" namespace - yet have an incorrect priority-value for that call?

That's a problem that needs to be fixed in the ESInet (with use of the esnet).

>But I do not see anywhere that is says that a UAS that DOES 
>understand the namespace is
>forbidden from deleting it.

see 4.6.2 (quoted above)

>For instance, sec 4.7.1 of 4412 says that "the UAC
>    MAY attempt a subsequent request with the same or different resource
>    value."  This certainly implies the ability to overwrite or 
> delete an RPH namespace.  (See
>also, for instance the PTSC SAC document on the use of the ets and 
>wps namespaces.)
>
>I would suggest rewording this to say
>"   Because the more important usage of the
>    "esnet" namespace occurs within the ESInet, the edge proxy, called
>    an Emergency Services Routing Proxy (ESRP) can modify or delete this
>    namespace. This is consistent with [RFC4412]. "
>
>
>
>
>Section 3.2,para after the relative priority order.
>
>"  The "esnet" namespace will be assigned into the priority queuing
>    algorithm (Section 4.5.2 of [RFC4412]) from the public user to the
>    PSAP.  This does not limit its usage to only the priority queue
>    algorithm; meaning the preemption algorithm can be used where the
>    local jurisdiction preferred to preempt normal calls in lieu of
>    completing emergency calls.  This document is not RECOMMENDING this
>    usage, merely pointing out those behaviors are a matter of local
>    policy."
>
>My concern here is the reference to "preempt normal calls".  Since 
>you have already said that
>there is no "normal" level in the esnet priority value set, I have 
>to assume that you mean
>"preempt calls with no RPH" (or perhaps "preempt calls  with a 
>different RPH namespace").

no, I'm leaving open the possibility that perhaps one local 
jurisdiction wants to use preemption -- kinda like the country of 
Japan does today (therefore... it needs to be possible, *and* mentioned).

>
>
>This WOULD BE a normative change to 4412, which says in 4.7.2.1
>"A UAS compliant with this specification MUST terminate a session
>    established with a valid namespace and lower-priority value in favor
>    of a new session set up with a valid namespace and higher relative
>    priority value, unless local policy has some form of call-waiting
>    capability enabled."
>
>Note that the only sessions that can be preempted are ones "with a 
>valid namespace and a lower
>priority value".  A "normal" call has neither a "valid namespace", 
>nor a "priority value"
>(higher or lower), and thus cannot be preempted under 4412.

we are not private ESInet network police -- and we shouldn't be so 
firm in deciding normal calls aren't preempted in one or more local 
configurations within jurisdictions.

>Furthermore, RFC4411 (which focuses on "preemption") repeatedly 
>refers to the pre-empted
>call/session having an RPH with a lower priority value.

4411 is how to indicate to a preempted caller their session has been 
preempted. I see no reason at this point to include any 4411 
reference. For example, if NENA wanted to allow preemption (which I 
am NOT suggesting), their docs should include this reference and usage of 4411.

>The circuit switched versions of preemption ( both MLPP for 
>landlines, and 3GPP e-MLPP for GSM)
>are even more restrictive.  In those schemes, a call can only 
>preempt a lower priority call IN
>THE SAME PREEMPTION DOMAIN (there is a rough correspondence between 
>"preemption domain" and "RPH namespace").
>
>So I take serious objection to any suggestion of preempting "normal" calls.

respectfully, that's a personal opinion that I question the universal 
applicability of. Especially given that Japan currently preempts 
normal calls in lieu of 911 calls.

Other jurisdictions *may* have similar or future plans

>If you want to have high priority esnet calls preempt low priority 
>esnet calls, I don't object as
>strenuously. (But no preempting "normal" calls.)
>
>
>Section 5, 3rd para
>"  A simple means of preventing this usage is to not allow marked
>    traffic preferential treatment unless the destination is towards the
>    local/regional ESInet. "

neither of the quotes below talk about granting preferential 
treatment across the ESInet ESRP boundary.  This comment does. But I 
can expand on this sentence to clarify this meaning.

>This seems to contradict the text in section 1
>"This new namespace can
>    be used for inbound calls to PSAPs, between PSAPs, and between a
>    PSAP and first responders and their organizations."
>and section 3
>" This namespace will also be used
>    for communications between emergency authorities, and MAY be used
>    for emergency authorities calling public citizens.  An example of
>    the later is a PSAP operator calling back someone who previously
>    called 9111/112/999 and the communication was terminated before it
>    should have been (in the operator's judgment)."
>
>Finally, at IETF 73 you assured me that you would insert strong 
>language pointing to section 8 of
>RFC4412 addressing the relative priority of the different 
>namespaces.  This is to eliminate any
>possible suggestion (that some people - not me- read into the 00 
>version) that an esnet
>namespace would have higher priority than an ets namespace.

well... I agree I haven't emphasized section 8 of 4412, and can 
mention this in a generic form when other namespaces are present.

Secondly, this document should never insist that esnet is above or 
below ets or wps. that's a matter of local policy, for example - to 
within NENA/APCO for whether they believe (and are going to implement 
to) this.  That's for an operational doc that this ID isn't.

>  I find no such reference to section
>8 of 4412.
>
>Thanks, and please note that I strongly support the creation of the 
>esnet namespace.  None of my comment should be interpreted as being 
>"against" esnet.
>
>Janet
>
>
>
>
>
>
>
>
>
>This is a PRIVATE message. If you are not the intended recipient, 
>please delete without copying and kindly advise us by e-mail of the 
>mistake in delivery.
>NOTE: Regardless of content, this e-mail shall not operate to bind 
>CSC to any order or other contract unless pursuant to explicit 
>written agreement or government initiative expressly permitting the 
>use of e-mail for such purpose.
>
>
>"James M. Polk" <[email-masked]>
>Sent by: [email-masked]
>
>02/19/2009 09:32 PM
>To
>"'ECRIT'" <[email-masked]>
>cc
>Subject
>[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted
>
>
>
>
>ECRIT
>
>I've just submitted a rev of the "esnet" Resource-Prioriy header draft.
>
>I've removed all mention of UAs from the draft, but leave in the
>possibility for adjacent VSPs to have a trust relationship with the
>local ESInet and mark these SIP requests accordingly through the
>VSP's domain.  I offer that the ESRP at the ESInet edge will be
>tasked with mapping the esnet.priority-values from outside the ESInet
>to the indications used inside the ESInet.  The ID gives no guidance
>on what the priority-values should be in either case - as that is a
>matter for other documents (and I'd argue - for other SDOs or
>consortia such as NENA and EENA, though I don't mention either
>organization in the ID).
>
>Comments are welcome
>
>James
>
> >From: IETF I-D Submission Tool <[email-masked]>
> >To: [email-masked]
> >Subject: New Version Notification for
> >          draft-ietf-ecrit-local-emergency-rph-namespace-01
> >Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST)
> >
> >
> >A new version of I-D,
> >draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been
> >successfuly submitted by James Polk and posted to the IETF repository.
> >
> >Filename:       draft-ietf-ecrit-local-emergency-rph-namespace
> >Revision:       01
> >Title:          IANA Registering a SIP Resource Priority Header
> >Namespace for Local Emergency Communications
> >Creation_date:  2009-02-19
> >WG ID:          ecrit
> >Number_of_pages: 7
> >
> >Abstract:
> >This document creates and IANA registers the new Session Initiation
> >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
> >local emergency usage to a public safety answering point (PSAP),
> >between PSAPs, and between a PSAP and first responders and their
> >organizations.
> >
> >
> >
> >
> >The IETF Secretariat.
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Date: Thu, 26 Feb 2009 13:00:14 -0800
Importance: Normal
Subject: [Ecrit] Comments on "Extensions for dealing with Unauthenticated and Unauthorized Devices"

--_4b5be22a-e6cb-49e0-8b6a-7db62790b04e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access

Section 2 summarizes the status of this document:

   At the time of writing there is no regulation in place that demands
   the functionality described in this memo.  SDOs have started their
   work on this subject in a proactive fashion in the anticipation that
   national regulation will demand it for a subset of network
   environments.

Not only is there no regulation that demands this functionality=2C but ther=
e
is potential legislation relating to authentication and record keeping that
could affect the viability of such a service:
http://news.cnet.com/8301-13578_3-10168114-38.html

In practice=2C some of these record keeping requirements are already in=20
effect=2C due to the implications of legislation such as Sarbanes Oxley
and HIPAA.=20

Given this=2C I'd suggest that the document needs to think more carefully
about the requirements for offering such a service.  This includes not
only the potential (conflicting) regulatory requirements=2C but also some
of the security issues.  For example=2C in its response to the IEEE 802.11u
liaison=2C EMU WG provided a number of questions that needed to be answered=
:
http://www.ietf.org/mail-archive/web/emu/current/msg00685.html =20

   In particular=2C the ISP MUST allow emergency callers to acquire an IP
   address and to reach a LoST server=2C either provided by the ISP or
   some third party.  It SHOULD also provide location information via
   one of the mechanisms specified in [I-D.ietf-ecrit-phonebcp] without
   requiring authorization unless it can safely assume that all nodes in
   the access network can determine their own location=2C e.g.=2C via GPS.

Given the current state of knowledge=2C and the capabilities of the ISP and
enterprise equipment in place=2C we also need to think carefully about=20
normative requirements.  For example=2C some of the older WLAN networks
may have limited abilities to actively advertise multiple networks
(e.g. they may not be able to beacon an Emergency Services network
with access restricted as recommended in the document).=20

Also=2C if this work is going to go forward=2C it should probably be
coordinated with other IETF WGs such as EMU=2C as well as=20
SDO efforts such as IEEE 802.11u and more
recently=2C IEEE 802.21.  For example=2C the IEEE 802.21 Emergency
Services charter can be found below:
https://mentor.ieee.org/802.21/file/08/21-08-0313-03-00es-emergency-service=
s-five-criteria.doc
=20

--_4b5be22a-e6cb-49e0-8b6a-7db62790b04e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access<b=
r><br>Section 2 summarizes the status of this document:<br><br>&nbsp=3B&nbs=
p=3B At the time of writing there is no regulation in place that demands<br=
>&nbsp=3B&nbsp=3B the functionality described in this memo.&nbsp=3B SDOs ha=
ve started their<br>&nbsp=3B&nbsp=3B work on this subject in a proactive fa=
shion in the anticipation that<br>&nbsp=3B&nbsp=3B national regulation will=
 demand it for a subset of network<br>&nbsp=3B&nbsp=3B environments.<br><br=
>Not only is there no regulation that demands this functionality=2C but the=
re<br>is potential legislation relating to authentication and record keepin=
g that<br>could affect the viability of such a service:<br>http://news.cnet=
.com/8301-13578_3-10168114-38.html<br><br>In practice=2C some of these reco=
rd keeping requirements are already in <br>effect=2C due to the implication=
s of legislation such as Sarbanes Oxley<br>and HIPAA. <br><br>Given this=2C=
 I'd suggest that the document needs to think more carefully<br>about the r=
equirements for offering such a service.&nbsp=3B This includes not<br>only =
the potential (conflicting) regulatory requirements=2C but also some<br>of =
the security issues.&nbsp=3B For example=2C in its response to the IEEE 802=
.11u<br>liaison=2C EMU WG provided a number of questions that needed to be =
answered:<br>http://www.ietf.org/mail-archive/web/emu/current/msg00685.html=
&nbsp=3B <br><br><pre class=3D"newpage">   In particular=2C the ISP MUST al=
low emergency callers to acquire an IP<br>   address and to reach a LoST se=
rver=2C either provided by the ISP or<br>   some third party.  It SHOULD al=
so provide location information via<br>   one of the mechanisms specified i=
n [<a href=3D"http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenti=
cated-access-04#ref-I-D.ietf-ecrit-phonebcp" title=3D"&quot=3BBest Current =
Practice for Communications Services in support of Emergency Calling&quot=
=3B">I-D.ietf-ecrit-phonebcp</a>] without<br>   requiring authorization unl=
ess it can safely assume that all nodes in<br>   the access network can det=
ermine their own location=2C e.g.=2C via GPS.<br></pre><br>Given the curren=
t state of knowledge=2C and the capabilities of the ISP and<br>enterprise e=
quipment in place=2C we also need to think carefully about <br>normative re=
quirements.&nbsp=3B For example=2C some of the older WLAN networks<br>may h=
ave limited abilities to actively advertise multiple networks<br>(e.g. they=
 may not be able to beacon an Emergency Services network<br>with access res=
tricted as recommended in the document). <br><br>Also=2C if this work is go=
ing to go forward=2C it should probably be<br>coordinated with other IETF W=
Gs such as EMU=2C as well as <br>SDO efforts such as IEEE 802.11u and more<=
br>recently=2C IEEE 802.21.&nbsp=3B For example=2C the IEEE 802.21 Emergenc=
y<br>Services charter can be found below:<br>https://mentor.ieee.org/802.21=
/file/08/21-08-0313-03-00es-emergency-services-five-criteria.doc<br>&nbsp=
=3B<br><br><table style=3D"border-top: 1px solid black=3B font-weight: bold=
=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=
=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" st=
yle=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: no=
ne=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=
=2C 181=2C 85)=3B text-decoration: underline=3B"></span></a></td></tr></tbo=
dy></table></body>
</html>=

--_4b5be22a-e6cb-49e0-8b6a-7db62790b04e_--

To: "James M. Polk" <[email-masked]>
From: Janet P Gunn <[email-masked]>
Date: Thu, 26 Feb 2009 16:52:20 -0500
Cc: 'ECRIT' <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted

This is a multipart message in MIME format.
--=_alternative 0078257E85257569_=
Content-Type: text/plain; charset="US-ASCII"

James,

Please go back and R E A D  S L O W L Y.   You have missed the point on 
many of my comments.

For instance -

1) Do you REALLY think 
"...this namespace is to be to provide an  explicit priority indication 
facilitates treatment..."
makes sense?  What is the subject of the verb "facilitates"?

2) I agree that 
4412 says "do not modify or delete, just ignore if you don't like it"
FOR SIP ACTORS THAT DO NOT UNDERSTAND THE NAMESPACE.

There is NO SUCH PROHIBITION in 4412 for SIP Actors that DO UNDERSTAND the 
namespace, which is what is being discussed here.

3) Yes, it is just my opinion that "preempting normal calls" is a bad 
idea.

But it is WRITTEN IN 4412 (not just my opinion) that only calls "with a 
valid namespace and a lower priority value" can be preempted.

And furthermore it is a fact that for both the MLPP and eMLPP , the 
protocol standards are very clear that you can't preempt calls that don't 
have a priority value, in the same preemption domain.  I have no idea how 
they do it in Japan, but if they are using MLPP, then the "normal" calls 
must be in the same preemption domain as the "911" calls, with a lower 
priority.    Hence not "normal calls" in the usual sense of the word

4) Your replies contradict each other.  When I say that "ets and wps don't 
have a 'routine' or 'normal' value", you say that esnet is different 
because "here there is no routine esnet calls, every one is an emergency 
call, and likely every 
call will be an emergency."

A- That is equally true of ets and wps.   There are no routine NS/EP 
calls. Every call with the ets or wps namespace is an NS/EP (hence 
special) call.

B - If you mean that the esnet namespace will ONLY be used in networks 
where EVERY relevant SIP message uses the esnet RPH, then
        -Yes, it is different from ets and wps
        -BUT if this is the case, there are no "normal" calls to preempt
        -If this is the case, you need to state clearly that esnet will 
only be used in networks where everything is marked esnet.

But I don't think that is what you mean (at least based on the diagram you 
presented today).

C -  I think you mean that esnet will be used in some networks where there 
are both esnet and non esnet messages (as well as some where all are 
marked esnet)
        - If this is the case, then it is EXACTLY the same as ets and wps, 
and no change from 4412

And so on.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.

"James M. Polk" <[email-masked]> 
02/26/2009 02:39 PM

To
Janet P Gunn/FED/CSC@CSC
cc
"'ECRIT'" <[email-masked]>, [email-masked]
Subject
Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01  submitted

At 03:10 PM 2/24/2009, Janet P Gunn wrote:

>James
>Some of this is editorial, some is substantive and technical, and 
>some repeats my comments on 00 that do not seem to have been addressed.
>
>2nd paragraph of section 1, this sentence doesn't make sense.
>"   Within controlled environments, such as an IMS infrastructure or
>    Emergency Services network (ESInet), where misuse can be reduced to
>    a minimum where possible, this namespace is to be to provide an
>    explicit priority indication facilitates treatment of emergency SIP
>    messages according to local policy."

I think this makes perfect sense as written

>Perhaps you mean
>"   Within controlled environments, such as an IMS infrastructure or
>    Emergency Services network (ESInet), where misuse can be reduced to
>    a minimum, this namespace is expected to be used to provide an
>    explicit priority indication, facilitating treatment of emergency SIP
>    messages according to local policy."  But I am not sure if that 
> is what you meant.

that's another way of saying the same thing

>Same para
>"This indication is used to
>    differentiate SIP requests, or dialogs, from other requests or
>    dialogs that do not have the need for priority treatment."
>sounds as if you are differentiating SIP requests form non-SIP 
>requests.  Perhaps what you mean is
>"This indication is used to
>    differentiate Emergency Services related  SIP requests, or 
> dialogs, from other (non Emergency
>Services related) SIP requests or  dialogs.

again -- this appears to be two ways of saying the same thing.

>Note that "do not have the need for priority treatment" is not correct.

it applies to other traffic that does not need priority treatment. In 
other words, the traffic that doesn't need priority treatment -- 
because there will be some traffic that does not need priority 
treatment within the ESInet (as well as an esnet namespace capable VSP)

>The esnet RPH would
>distinguish ES related messages from GETS related messages (ets and 
>wps namespaces), but they
>would each get their own particular flavor of "priority treatment".
>
>
>5th para of section 1
>
>"From this fact about RFC 4412, and the possibility that within
>    emergency services networks, a Multilevel Precedence and Preemption
>    (MLPP)-like behavior can be achieved - ensuring more important calls
>    are established or retained, the "esnet" namespace is given 5
>    priority-levels."
>What is "this fact"?  Perhaps "Because we can't add new values later..."

the fact is right above this sentence

>I don't understand the "can be achieved".  Do you mean "MLPP-like 
>behavior may be desired"?

it can be, which is all that I'm offering -- but I'm not recommending 
or stipulating or demanding or anything else... I'm just saying that 
with more than 2 levels, a natural hierarchy _can_ be configured.

>I fully agree with assigning 5 levels, and the underlying logic. It 
>is only the description that is problematic.
>
>Perhaps
>"Because we can't add new values later, and because  Multilevel 
>Precedence and Preemption
>    (MLPP)-like behavior may be desired the "esnet" namespace is 
> given 5 priority-levels."

that is within 4412

>2nd to last paragraph of section 1
>"Within the ESINet, there will be emergency calls requiring different
>    treatments, according to the type of call. "
>We don't know if they will require different treatment or not.
>
>I would prefer
>"Within the ESINet, there may be emergency calls requiring different
>    treatments, according to the type of call. "
>
>or if the use of "may" will be confused with normative language,
>"Within the ESINet, there could be emergency calls requiring different
>    treatments, according to the type of call. "

I'm ok with this

>This sentence at the end of sec 1 doesn't quite work.
>"This document IANA registers the "esnet"
>    RPH namespace for use within emergency services networks, not just
>    of those from citizens to PSAPs." (no clear antecedent for "those")

fair

>Perhaps
>"This document IANA registers the "esnet"
>    RPH namespace for use within emergency services networks, not 
> just for calls or sessions
>     from citizens to PSAPs."
>(same comment applied to 00)

I'll back off this even more - to

"This document IANA registers the "esnet"
   RPH namespace for use within emergency services networks, not just 
for calls or sessions
   towards PSAPs."

>Section 2  first para says
>  "This document updates the behaviors of the SIP Resource Priority
>    header, defined in [RFC4412], during the treatment options
>    surrounding this new "esnet" namespace only. The usage of the
>    "esnet" namespace does not have a normal, or routine call level.
>    Every use of this namespace will be in times of an emergency, where
>    at least one end of the signaling is with a local emergency
>    organization."
>
>I don't see this as an "update of the behavior of 4412".  Neither 
>the ets namespace not the wps namespace have a "normal" or "routine" 
>call level.

but either (ets or wps) can simply not be used. here there is no 
routine esnet calls, every one is an emergency call, and likely every 
call will be an emergency.

>Every use of the wps and ets namespaces will have priority over 
>calls without RPH.
>
>Suggest changing text to say
>"   Like the ets and wps namespaces defined in [RFC4412], the
>    "esnet" namespace does not have a normal, or routine call level.
>     Every use of this namespace will be in times of an emergency, where
>    at least one end of the signaling is with a local emergency
>    organization."

see comment above

>Section 2, para immediately below Figure 1
>"   Because the more important usage of the
>    "esnet" namespace occurs within the ESInet, the edge proxy, called
>    an Emergency Services Routing Proxy (ESRP) can modify or delete this
>    namespace. This is a normative change to the allowed behavior within
>    [RFC4412], but MUST only be considered valid in this usage at the
>    ESInet boundary for this one RP namespace (and associated
>    priority-value). "
>
>I have major (content, not editorial) concerns with this, more for 
>what it says about 4412 than about esnet
>
>
>First of all, it is not clear to me why this is "a normative change 
>to the allowed behavior within [RFC4412]".

because 4412 says "do not modify or delete, just ignore if you don't like 
it"

this doc changes that for esnet only.

>For one thing I see nothing in 4412 that would prohibit a "SIP actor 
>that understands the name space"
>from modifying or deleting the namespace.

4.6.2.  No Known Namespace or Priority Value

    If an RP actor does not understand any of the resource values in 
the request, the treatment depends on the presence of the Require 
'resource-priority' option tag:

    1.  Without the option tag, the RP actor treats the request as if 
it contained no 'Resource-Priority' header field and processes it 
with default priority.  Resource values that are not understood MUST 
NOT be modified or deleted.

so, evidence to the contrary (from your statement above)

>It is certainly anticipated that at least some of the namespaces 
>described in 4412 will be
>modified or deleted, (e.g., when there is reason to  believe it is 
>unauthorized).

no, just ignored

>4412 says "Existing implementations of RFC 3261 that do not 
>participate in the
>    resource priority mechanism follow the normal rules of RFC 3261,
>    Section 8.2.2: "If a UAS does not understand a header field in a
>    request (that is, the header field is not defined in this
>    specification or in any supported extension), the server MUST ignore
>    that header field and continue processing the message". "

What about SIP entities that not only understand RPH, but understand 
the "esnet" namespace - yet have an incorrect priority-value for that 
call?

That's a problem that needs to be fixed in the ESInet (with use of the 
esnet).

>But I do not see anywhere that is says that a UAS that DOES 
>understand the namespace is
>forbidden from deleting it.

see 4.6.2 (quoted above)

>For instance, sec 4.7.1 of 4412 says that "the UAC
>    MAY attempt a subsequent request with the same or different resource
>    value."  This certainly implies the ability to overwrite or 
> delete an RPH namespace.  (See
>also, for instance the PTSC SAC document on the use of the ets and 
>wps namespaces.)
>
>I would suggest rewording this to say
>"   Because the more important usage of the
>    "esnet" namespace occurs within the ESInet, the edge proxy, called
>    an Emergency Services Routing Proxy (ESRP) can modify or delete this
>    namespace. This is consistent with [RFC4412]. "
>
>
>
>
>Section 3.2,para after the relative priority order.
>
>"  The "esnet" namespace will be assigned into the priority queuing
>    algorithm (Section 4.5.2 of [RFC4412]) from the public user to the
>    PSAP.  This does not limit its usage to only the priority queue
>    algorithm; meaning the preemption algorithm can be used where the
>    local jurisdiction preferred to preempt normal calls in lieu of
>    completing emergency calls.  This document is not RECOMMENDING this
>    usage, merely pointing out those behaviors are a matter of local
>    policy."
>
>My concern here is the reference to "preempt normal calls".  Since 
>you have already said that
>there is no "normal" level in the esnet priority value set, I have 
>to assume that you mean
>"preempt calls with no RPH" (or perhaps "preempt calls  with a 
>different RPH namespace").

no, I'm leaving open the possibility that perhaps one local 
jurisdiction wants to use preemption -- kinda like the country of 
Japan does today (therefore... it needs to be possible, *and* mentioned).

>
>
>This WOULD BE a normative change to 4412, which says in 4.7.2.1
>"A UAS compliant with this specification MUST terminate a session
>    established with a valid namespace and lower-priority value in favor
>    of a new session set up with a valid namespace and higher relative
>    priority value, unless local policy has some form of call-waiting
>    capability enabled."
>
>Note that the only sessions that can be preempted are ones "with a 
>valid namespace and a lower
>priority value".  A "normal" call has neither a "valid namespace", 
>nor a "priority value"
>(higher or lower), and thus cannot be preempted under 4412.

we are not private ESInet network police -- and we shouldn't be so 
firm in deciding normal calls aren't preempted in one or more local 
configurations within jurisdictions.

>Furthermore, RFC4411 (which focuses on "preemption") repeatedly 
>refers to the pre-empted
>call/session having an RPH with a lower priority value.

4411 is how to indicate to a preempted caller their session has been 
preempted. I see no reason at this point to include any 4411 
reference. For example, if NENA wanted to allow preemption (which I 
am NOT suggesting), their docs should include this reference and usage of 
4411.

>The circuit switched versions of preemption ( both MLPP for 
>landlines, and 3GPP e-MLPP for GSM)
>are even more restrictive.  In those schemes, a call can only 
>preempt a lower priority call IN
>THE SAME PREEMPTION DOMAIN (there is a rough correspondence between 
>"preemption domain" and "RPH namespace").
>
>So I take serious objection to any suggestion of preempting "normal" 
calls.

respectfully, that's a personal opinion that I question the universal 
applicability of. Especially given that Japan currently preempts 
normal calls in lieu of 911 calls.

Other jurisdictions *may* have similar or future plans

>If you want to have high priority esnet calls preempt low priority 
>esnet calls, I don't object as
>strenuously. (But no preempting "normal" calls.)
>
>
>Section 5, 3rd para
>"  A simple means of preventing this usage is to not allow marked
>    traffic preferential treatment unless the destination is towards the
>    local/regional ESInet. "

neither of the quotes below talk about granting preferential 
treatment across the ESInet ESRP boundary.  This comment does. But I 
can expand on this sentence to clarify this meaning.

>This seems to contradict the text in section 1
>"This new namespace can
>    be used for inbound calls to PSAPs, between PSAPs, and between a
>    PSAP and first responders and their organizations."
>and section 3
>" This namespace will also be used
>    for communications between emergency authorities, and MAY be used
>    for emergency authorities calling public citizens.  An example of
>    the later is a PSAP operator calling back someone who previously
>    called 9111/112/999 and the communication was terminated before it
>    should have been (in the operator's judgment)."
>
>Finally, at IETF 73 you assured me that you would insert strong 
>language pointing to section 8 of
>RFC4412 addressing the relative priority of the different 
>namespaces.  This is to eliminate any
>possible suggestion (that some people - not me- read into the 00 
>version) that an esnet
>namespace would have higher priority than an ets namespace.

well... I agree I haven't emphasized section 8 of 4412, and can 
mention this in a generic form when other namespaces are present.

Secondly, this document should never insist that esnet is above or 
below ets or wps. that's a matter of local policy, for example - to 
within NENA/APCO for whether they believe (and are going to implement 
to) this.  That's for an operational doc that this ID isn't.

>  I find no such reference to section
>8 of 4412.
>
>Thanks, and please note that I strongly support the creation of the 
>esnet namespace.  None of my comment should be interpreted as being 
>"against" esnet.
>
>Janet
>
>
>
>
>
>
>
>
>
>This is a PRIVATE message. If you are not the intended recipient, 
>please delete without copying and kindly advise us by e-mail of the 
>mistake in delivery.
>NOTE: Regardless of content, this e-mail shall not operate to bind 
>CSC to any order or other contract unless pursuant to explicit 
>written agreement or government initiative expressly permitting the 
>use of e-mail for such purpose.
>
>
>"James M. Polk" <[email-masked]>
>Sent by: [email-masked]
>
>02/19/2009 09:32 PM
>To
>"'ECRIT'" <[email-masked]>
>cc
>Subject
>[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted
>
>
>
>
>ECRIT
>
>I've just submitted a rev of the "esnet" Resource-Prioriy header draft.
>
>I've removed all mention of UAs from the draft, but leave in the
>possibility for adjacent VSPs to have a trust relationship with the
>local ESInet and mark these SIP requests accordingly through the
>VSP's domain.  I offer that the ESRP at the ESInet edge will be
>tasked with mapping the esnet.priority-values from outside the ESInet
>to the indications used inside the ESInet.  The ID gives no guidance
>on what the priority-values should be in either case - as that is a
>matter for other documents (and I'd argue - for other SDOs or
>consortia such as NENA and EENA, though I don't mention either
>organization in the ID).
>
>Comments are welcome
>
>James
>
> >From: IETF I-D Submission Tool <[email-masked]>
> >To: [email-masked]
> >Subject: New Version Notification for
> >          draft-ietf-ecrit-local-emergency-rph-namespace-01
> >Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST)
> >
> >
> >A new version of I-D,
> >draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been
> >successfuly submitted by James Polk and posted to the IETF repository.
> >
> >Filename:       draft-ietf-ecrit-local-emergency-rph-namespace
> >Revision:       01
> >Title:          IANA Registering a SIP Resource Priority Header
> >Namespace for Local Emergency Communications
> >Creation_date:  2009-02-19
> >WG ID:          ecrit
> >Number_of_pages: 7
> >
> >Abstract:
> >This document creates and IANA registers the new Session Initiation
> >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
> >local emergency usage to a public safety answering point (PSAP),
> >between PSAPs, and between a PSAP and first responders and their
> >organizations.
> >
> >
> >
> >
> >The IETF Secretariat.
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

--=_alternative 0078257E85257569_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">James,</font>
<br>
<br><font size=2 face="sans-serif">Please go back and R E A D &nbsp;S L
O W L Y. &nbsp; You have missed the point on many of my comments.</font>
<br>
<br><font size=2 face="sans-serif">For instance -</font>
<br>
<br><font size=2 face="sans-serif">1) Do you REALLY think </font>
<br><font size=2 face="sans-serif">&quot;</font><font size=2><tt>...this
namespace is to be to provide an &nbsp;explicit priority indication facilitates
treatment</tt></font><font size=2 face="sans-serif">...&quot;</font>
<br><font size=2 face="sans-serif">makes sense? &nbsp;What is the subject
of the verb &quot;facilitates&quot;?</font>
<br>
<br><font size=2 face="sans-serif">2) I agree that &nbsp;</font>
<br><font size=2><tt>4412 says &quot;do not modify or delete, just ignore
if you don't like it&quot;</tt></font>
<br><font size=2 face="sans-serif">FOR SIP ACTORS THAT DO NOT UNDERSTAND
THE NAMESPACE.</font>
<br>
<br><font size=2 face="sans-serif">There is NO SUCH PROHIBITION in 4412
for SIP Actors that DO UNDERSTAND the namespace, which is what is being
discussed here.<br>
</font>
<br><font size=2 face="sans-serif">3) Yes, it is just my opinion that &quot;preempting
normal calls&quot; is a bad idea.</font>
<br>
<br><font size=2 face="sans-serif">But it is WRITTEN IN 4412 (not just
my opinion) that only calls &quot;with a valid namespace and a lower priority
value&quot; can be preempted.</font>
<br>
<br><font size=2 face="sans-serif">And furthermore it is a fact that for
both the MLPP and eMLPP , the protocol standards are very clear that you
can't preempt calls that don't have a priority value, in the same preemption
domain. &nbsp;I have no idea how they do it in Japan, but if they are using
MLPP, then the &quot;normal&quot; calls must be in the same preemption
domain as the &quot;911&quot; calls, with a lower priority. &nbsp; &nbsp;Hence
not &quot;normal calls&quot; in the usual sense of the word</font>
<br>
<br><font size=2 face="sans-serif">4) Your replies contradict each other.
&nbsp;When I say that &quot;ets and wps don't have a 'routine' or 'normal'
value&quot;, you say that esnet is different because &quot;</font><font size=2><tt>here
there is no routine esnet calls, every one is an emergency call, and likely
every <br>
call will be an emergency.&quot;</tt></font>
<br>
<br><font size=2><tt>A- That is equally true of ets and wps. &nbsp; There
are no routine NS/EP calls. Every call with the ets or wps namespace is
an NS/EP (hence special) call.</tt></font>
<br>
<br><font size=2><tt>B - If you mean that the esnet namespace will ONLY
be used in networks where EVERY relevant SIP message uses the esnet RPH,
then</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; -Yes, it is different
from ets and wps</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; -BUT if this is
the case, there are no &quot;normal&quot; calls to preempt</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; -If this is the
case, you need to state clearly that esnet will only be used in networks
where everything is marked esnet.</tt></font>
<br>
<br><font size=2><tt>But I don't think that is what you mean (at least
based on the diagram you presented today).</tt></font>
<br>
<br><font size=2><tt>C - &nbsp;I think you mean that esnet will be used
in some networks where there are both esnet and non esnet messages (as
well as some where all are marked esnet)</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; - If this is the
case, then it is EXACTLY the same as ets and wps, and no change from 4412</tt></font>
<br>
<br><font size=2><tt>And so on.</tt></font>
<br>
<br><font size=2><tt>Janet</tt></font>
<br>
<br><font size=2 face="sans-serif"><br>
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. <br>
NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>&quot;James M. Polk&quot;
&lt;[email-masked]&gt;</b> </font>
<p><font size=1 face="sans-serif">02/26/2009 02:39 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Janet P Gunn/FED/CSC@CSC</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">&quot;'ECRIT'&quot; &lt;[email-masked]&gt;,
[email-masked]</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01
&nbsp;submitted</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>At 03:10 PM 2/24/2009, Janet P Gunn wrote:<br>
<br>
&gt;James<br>
&gt;Some of this is editorial, some is substantive and technical, and <br>
&gt;some repeats my comments on 00 that do not seem to have been addressed.<br>
&gt;<br>
&gt;2nd paragraph of section 1, this sentence doesn't make sense.<br>
&gt;&quot; &nbsp; Within controlled environments, such as an IMS infrastructure
or<br>
&gt; &nbsp; &nbsp;Emergency Services network (ESInet), where misuse can
be reduced to<br>
&gt; &nbsp; &nbsp;a minimum where possible, this namespace is to be to
provide an<br>
&gt; &nbsp; &nbsp;explicit priority indication facilitates treatment of
emergency SIP<br>
&gt; &nbsp; &nbsp;messages according to local policy.&quot;<br>
<br>
I think this makes perfect sense as written<br>
<br>
<br>
&gt;Perhaps you mean<br>
&gt;&quot; &nbsp; Within controlled environments, such as an IMS infrastructure
or<br>
&gt; &nbsp; &nbsp;Emergency Services network (ESInet), where misuse can
be reduced to<br>
&gt; &nbsp; &nbsp;a minimum, this namespace is expected to be used to provide
an<br>
&gt; &nbsp; &nbsp;explicit priority indication, facilitating treatment
of emergency SIP<br>
&gt; &nbsp; &nbsp;messages according to local policy.&quot; &nbsp;But I
am not sure if that <br>
&gt; is what you meant.<br>
<br>
that's another way of saying the same thing<br>
<br>
<br>
&gt;Same para<br>
&gt;&quot;This indication is used to<br>
&gt; &nbsp; &nbsp;differentiate SIP requests, or dialogs, from other requests
or<br>
&gt; &nbsp; &nbsp;dialogs that do not have the need for priority treatment.&quot;<br>
&gt;sounds as if you are differentiating SIP requests form non-SIP <br>
&gt;requests. &nbsp;Perhaps what you mean is<br>
&gt;&quot;This indication is used to<br>
&gt; &nbsp; &nbsp;differentiate Emergency Services related &nbsp;SIP requests,
or <br>
&gt; dialogs, from other (non Emergency<br>
&gt;Services related) SIP requests or &nbsp;dialogs.<br>
<br>
again -- this appears to be two ways of saying the same thing.<br>
<br>
<br>
&gt;Note that &quot;do not have the need for priority treatment&quot; is
not correct.<br>
<br>
it applies to other traffic that does not need priority treatment. In <br>
other words, the traffic that doesn't need priority treatment -- <br>
because there will be some traffic that does not need priority <br>
treatment within the ESInet (as well as an esnet namespace capable VSP)<br>
<br>
&gt;The esnet RPH would<br>
&gt;distinguish ES related messages from GETS related messages (ets and
<br>
&gt;wps namespaces), but they<br>
&gt;would each get their own particular flavor of &quot;priority treatment&quot;.<br>
&gt;<br>
&gt;<br>
&gt;5th para of section 1<br>
&gt;<br>
&gt;&quot;From this fact about RFC 4412, and the possibility that within<br>
&gt; &nbsp; &nbsp;emergency services networks, a Multilevel Precedence
and Preemption<br>
&gt; &nbsp; &nbsp;(MLPP)-like behavior can be achieved - ensuring more
important calls<br>
&gt; &nbsp; &nbsp;are established or retained, the &quot;esnet&quot; namespace
is given 5<br>
&gt; &nbsp; &nbsp;priority-levels.&quot;<br>
&gt;What is &quot;this fact&quot;? &nbsp;Perhaps &quot;Because we can't
add new values later...&quot;<br>
<br>
the fact is right above this sentence<br>
<br>
<br>
&gt;I don't understand the &quot;can be achieved&quot;. &nbsp;Do you mean
&quot;MLPP-like <br>
&gt;behavior may be desired&quot;?<br>
<br>
it can be, which is all that I'm offering -- but I'm not recommending <br>
or stipulating or demanding or anything else... I'm just saying that <br>
with more than 2 levels, a natural hierarchy _can_ be configured.<br>
<br>
<br>
&gt;I fully agree with assigning 5 levels, and the underlying logic. It
<br>
&gt;is only the description that is problematic.<br>
&gt;<br>
&gt;Perhaps<br>
&gt;&quot;Because we can't add new values later, and because &nbsp;Multilevel
<br>
&gt;Precedence and Preemption<br>
&gt; &nbsp; &nbsp;(MLPP)-like behavior may be desired the &quot;esnet&quot;
namespace is <br>
&gt; given 5 priority-levels.&quot;<br>
<br>
that is within 4412<br>
<br>
<br>
&gt;2nd to last paragraph of section 1<br>
&gt;&quot;Within the ESINet, there will be emergency calls requiring different<br>
&gt; &nbsp; &nbsp;treatments, according to the type of call. &quot;<br>
&gt;We don't know if they will require different treatment or not.<br>
&gt;<br>
&gt;I would prefer<br>
&gt;&quot;Within the ESINet, there may be emergency calls requiring different<br>
&gt; &nbsp; &nbsp;treatments, according to the type of call. &quot;<br>
&gt;<br>
&gt;or if the use of &quot;may&quot; will be confused with normative language,<br>
&gt;&quot;Within the ESINet, there could be emergency calls requiring different<br>
&gt; &nbsp; &nbsp;treatments, according to the type of call. &quot;<br>
<br>
I'm ok with this<br>
<br>
&gt;This sentence at the end of sec 1 doesn't quite work.<br>
&gt;&quot;This document IANA registers the &quot;esnet&quot;<br>
&gt; &nbsp; &nbsp;RPH namespace for use within emergency services networks,
not just<br>
&gt; &nbsp; &nbsp;of those from citizens to PSAPs.&quot; (no clear antecedent
for &quot;those&quot;)<br>
<br>
fair<br>
<br>
<br>
&gt;Perhaps<br>
&gt;&quot;This document IANA registers the &quot;esnet&quot;<br>
&gt; &nbsp; &nbsp;RPH namespace for use within emergency services networks,
not <br>
&gt; just for calls or sessions<br>
&gt; &nbsp; &nbsp; from citizens to PSAPs.&quot;<br>
&gt;(same comment applied to 00)<br>
<br>
I'll back off this even more - to<br>
<br>
&quot;This document IANA registers the &quot;esnet&quot;<br>
 &nbsp; RPH namespace for use within emergency services networks, not just
<br>
for calls or sessions<br>
 &nbsp; towards PSAPs.&quot;<br>
<br>
<br>
<br>
<br>
&gt;Section 2 &nbsp;first para says<br>
&gt; &nbsp;&quot;This document updates the behaviors of the SIP Resource
Priority<br>
&gt; &nbsp; &nbsp;header, defined in [RFC4412], during the treatment options<br>
&gt; &nbsp; &nbsp;surrounding this new &quot;esnet&quot; namespace only.
The usage of the<br>
&gt; &nbsp; &nbsp;&quot;esnet&quot; namespace does not have a normal, or
routine call level.<br>
&gt; &nbsp; &nbsp;Every use of this namespace will be in times of an emergency,
where<br>
&gt; &nbsp; &nbsp;at least one end of the signaling is with a local emergency<br>
&gt; &nbsp; &nbsp;organization.&quot;<br>
&gt;<br>
&gt;I don't see this as an &quot;update of the behavior of 4412&quot;.
&nbsp;Neither <br>
&gt;the ets namespace not the wps namespace have a &quot;normal&quot; or
&quot;routine&quot; <br>
&gt;call level.<br>
<br>
but either (ets or wps) can simply not be used. here there is no <br>
routine esnet calls, every one is an emergency call, and likely every <br>
call will be an emergency.<br>
<br>
&gt;Every use of the wps and ets namespaces will have priority over <br>
&gt;calls without RPH.<br>
&gt;<br>
&gt;Suggest changing text to say<br>
&gt;&quot; &nbsp; Like the ets and wps namespaces defined in [RFC4412],
the<br>
&gt; &nbsp; &nbsp;&quot;esnet&quot; namespace does not have a normal, or
routine call level.<br>
&gt; &nbsp; &nbsp; Every use of this namespace will be in times of an emergency,
where<br>
&gt; &nbsp; &nbsp;at least one end of the signaling is with a local emergency<br>
&gt; &nbsp; &nbsp;organization.&quot;<br>
<br>
see comment above<br>
<br>
<br>
<br>
&gt;Section 2, para immediately below Figure 1<br>
&gt;&quot; &nbsp; Because the more important usage of the<br>
&gt; &nbsp; &nbsp;&quot;esnet&quot; namespace occurs within the ESInet,
the edge proxy, called<br>
&gt; &nbsp; &nbsp;an Emergency Services Routing Proxy (ESRP) can modify
or delete this<br>
&gt; &nbsp; &nbsp;namespace. This is a normative change to the allowed
behavior within<br>
&gt; &nbsp; &nbsp;[RFC4412], but MUST only be considered valid in this
usage at the<br>
&gt; &nbsp; &nbsp;ESInet boundary for this one RP namespace (and associated<br>
&gt; &nbsp; &nbsp;priority-value). &quot;<br>
&gt;<br>
&gt;I have major (content, not editorial) concerns with this, more for
<br>
&gt;what it says about 4412 than about esnet<br>
&gt;<br>
&gt;<br>
&gt;First of all, it is not clear to me why this is &quot;a normative change
<br>
&gt;to the allowed behavior within [RFC4412]&quot;.<br>
<br>
because 4412 says &quot;do not modify or delete, just ignore if you don't
like it&quot;<br>
<br>
this doc changes that for esnet only.<br>
<br>
<br>
&gt;For one thing I see nothing in 4412 that would prohibit a &quot;SIP
actor <br>
&gt;that understands the name space&quot;<br>
&gt;from modifying or deleting the namespace.<br>
<br>
<br>
<br>
4.6.2. &nbsp;No Known Namespace or Priority Value<br>
<br>
 &nbsp; &nbsp;If an RP actor does not understand any of the resource values
in <br>
the request, the treatment depends on the presence of the Require <br>
'resource-priority' option tag:<br>
<br>
 &nbsp; &nbsp;1. &nbsp;Without the option tag, the RP actor treats the
request as if <br>
it contained no 'Resource-Priority' header field and processes it <br>
with default priority. &nbsp;Resource values that are not understood MUST
<br>
NOT be modified or deleted.<br>
<br>
<br>
so, evidence to the contrary (from your statement above)<br>
<br>
&gt;It is certainly anticipated that at least some of the namespaces <br>
&gt;described in 4412 will be<br>
&gt;modified or deleted, (e.g., when there is reason to &nbsp;believe it
is <br>
&gt;unauthorized).<br>
<br>
no, just ignored<br>
<br>
<br>
&gt;4412 says &quot;Existing implementations of RFC 3261 that do not <br>
&gt;participate in the<br>
&gt; &nbsp; &nbsp;resource priority mechanism follow the normal rules of
RFC 3261,<br>
&gt; &nbsp; &nbsp;Section 8.2.2: &quot;If a UAS does not understand a header
field in a<br>
&gt; &nbsp; &nbsp;request (that is, the header field is not defined in
this<br>
&gt; &nbsp; &nbsp;specification or in any supported extension), the server
MUST ignore<br>
&gt; &nbsp; &nbsp;that header field and continue processing the message&quot;.
&quot;<br>
<br>
What about SIP entities that not only understand RPH, but understand <br>
the &quot;esnet&quot; namespace - yet have an incorrect priority-value
for that call?<br>
<br>
That's a problem that needs to be fixed in the ESInet (with use of the
esnet).<br>
<br>
<br>
&gt;But I do not see anywhere that is says that a UAS that DOES <br>
&gt;understand the namespace is<br>
&gt;forbidden from deleting it.<br>
<br>
see 4.6.2 (quoted above)<br>
<br>
&gt;For instance, sec 4.7.1 of 4412 says that &quot;the UAC<br>
&gt; &nbsp; &nbsp;MAY attempt a subsequent request with the same or different
resource<br>
&gt; &nbsp; &nbsp;value.&quot; &nbsp;This certainly implies the ability
to overwrite or <br>
&gt; delete an RPH namespace. &nbsp;(See<br>
&gt;also, for instance the PTSC SAC document on the use of the ets and
<br>
&gt;wps namespaces.)<br>
&gt;<br>
&gt;I would suggest rewording this to say<br>
&gt;&quot; &nbsp; Because the more important usage of the<br>
&gt; &nbsp; &nbsp;&quot;esnet&quot; namespace occurs within the ESInet,
the edge proxy, called<br>
&gt; &nbsp; &nbsp;an Emergency Services Routing Proxy (ESRP) can modify
or delete this<br>
&gt; &nbsp; &nbsp;namespace. This is consistent with [RFC4412]. &quot;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;Section 3.2,para after the relative priority order.<br>
&gt;<br>
&gt;&quot; &nbsp;The &quot;esnet&quot; namespace will be assigned into
the priority queuing<br>
&gt; &nbsp; &nbsp;algorithm (Section 4.5.2 of [RFC4412]) from the public
user to the<br>
&gt; &nbsp; &nbsp;PSAP. &nbsp;This does not limit its usage to only the
priority queue<br>
&gt; &nbsp; &nbsp;algorithm; meaning the preemption algorithm can be used
where the<br>
&gt; &nbsp; &nbsp;local jurisdiction preferred to preempt normal calls
in lieu of<br>
&gt; &nbsp; &nbsp;completing emergency calls. &nbsp;This document is not
RECOMMENDING this<br>
&gt; &nbsp; &nbsp;usage, merely pointing out those behaviors are a matter
of local<br>
&gt; &nbsp; &nbsp;policy.&quot;<br>
&gt;<br>
&gt;My concern here is the reference to &quot;preempt normal calls&quot;.
&nbsp;Since <br>
&gt;you have already said that<br>
&gt;there is no &quot;normal&quot; level in the esnet priority value set,
I have <br>
&gt;to assume that you mean<br>
&gt;&quot;preempt calls with no RPH&quot; (or perhaps &quot;preempt calls
&nbsp;with a <br>
&gt;different RPH namespace&quot;).<br>
<br>
no, I'm leaving open the possibility that perhaps one local <br>
jurisdiction wants to use preemption -- kinda like the country of <br>
Japan does today (therefore... it needs to be possible, *and* mentioned).<br>
<br>
&gt;<br>
&gt;<br>
&gt;This WOULD BE a normative change to 4412, which says in 4.7.2.1<br>
&gt;&quot;A UAS compliant with this specification MUST terminate a session<br>
&gt; &nbsp; &nbsp;established with a valid namespace and lower-priority
value in favor<br>
&gt; &nbsp; &nbsp;of a new session set up with a valid namespace and higher
relative<br>
&gt; &nbsp; &nbsp;priority value, unless local policy has some form of
call-waiting<br>
&gt; &nbsp; &nbsp;capability enabled.&quot;<br>
&gt;<br>
&gt;Note that the only sessions that can be preempted are ones &quot;with
a <br>
&gt;valid namespace and a lower<br>
&gt;priority value&quot;. &nbsp;A &quot;normal&quot; call has neither a
&quot;valid namespace&quot;, <br>
&gt;nor a &quot;priority value&quot;<br>
&gt;(higher or lower), and thus cannot be preempted under 4412.<br>
<br>
we are not private ESInet network police -- and we shouldn't be so <br>
firm in deciding normal calls aren't preempted in one or more local <br>
configurations within jurisdictions.<br>
<br>
<br>
&gt;Furthermore, RFC4411 (which focuses on &quot;preemption&quot;) repeatedly
<br>
&gt;refers to the pre-empted<br>
&gt;call/session having an RPH with a lower priority value.<br>
<br>
4411 is how to indicate to a preempted caller their session has been <br>
preempted. I see no reason at this point to include any 4411 <br>
reference. For example, if NENA wanted to allow preemption (which I <br>
am NOT suggesting), their docs should include this reference and usage
of 4411.<br>
<br>
<br>
&gt;The circuit switched versions of preemption ( both MLPP for <br>
&gt;landlines, and 3GPP e-MLPP for GSM)<br>
&gt;are even more restrictive. &nbsp;In those schemes, a call can only
<br>
&gt;preempt a lower priority call IN<br>
&gt;THE SAME PREEMPTION DOMAIN (there is a rough correspondence between
<br>
&gt;&quot;preemption domain&quot; and &quot;RPH namespace&quot;).<br>
&gt;<br>
&gt;So I take serious objection to any suggestion of preempting &quot;normal&quot;
calls.<br>
<br>
respectfully, that's a personal opinion that I question the universal <br>
applicability of. Especially given that Japan currently preempts <br>
normal calls in lieu of 911 calls.<br>
<br>
Other jurisdictions *may* have similar or future plans<br>
<br>
&gt;If you want to have high priority esnet calls preempt low priority
<br>
&gt;esnet calls, I don't object as<br>
&gt;strenuously. (But no preempting &quot;normal&quot; calls.)<br>
&gt;<br>
&gt;<br>
&gt;Section 5, 3rd para<br>
&gt;&quot; &nbsp;A simple means of preventing this usage is to not allow
marked<br>
&gt; &nbsp; &nbsp;traffic preferential treatment unless the destination
is towards the<br>
&gt; &nbsp; &nbsp;local/regional ESInet. &quot;<br>
<br>
neither of the quotes below talk about granting preferential <br>
treatment across the ESInet ESRP boundary. &nbsp;This comment does. But
I <br>
can expand on this sentence to clarify this meaning.<br>
<br>
<br>
&gt;This seems to contradict the text in section 1<br>
&gt;&quot;This new namespace can<br>
&gt; &nbsp; &nbsp;be used for inbound calls to PSAPs, between PSAPs, and
between a<br>
&gt; &nbsp; &nbsp;PSAP and first responders and their organizations.&quot;<br>
&gt;and section 3<br>
&gt;&quot; This namespace will also be used<br>
&gt; &nbsp; &nbsp;for communications between emergency authorities, and
MAY be used<br>
&gt; &nbsp; &nbsp;for emergency authorities calling public citizens. &nbsp;An
example of<br>
&gt; &nbsp; &nbsp;the later is a PSAP operator calling back someone who
previously<br>
&gt; &nbsp; &nbsp;called 9111/112/999 and the communication was terminated
before it<br>
&gt; &nbsp; &nbsp;should have been (in the operator's judgment).&quot;<br>
&gt;<br>
&gt;Finally, at IETF 73 you assured me that you would insert strong <br>
&gt;language pointing to section 8 of<br>
&gt;RFC4412 addressing the relative priority of the different <br>
&gt;namespaces. &nbsp;This is to eliminate any<br>
&gt;possible suggestion (that some people - not me- read into the 00 <br>
&gt;version) that an esnet<br>
&gt;namespace would have higher priority than an ets namespace.<br>
<br>
well... I agree I haven't emphasized section 8 of 4412, and can <br>
mention this in a generic form when other namespaces are present.<br>
<br>
Secondly, this document should never insist that esnet is above or <br>
below ets or wps. that's a matter of local policy, for example - to <br>
within NENA/APCO for whether they believe (and are going to implement <br>
to) this. &nbsp;That's for an operational doc that this ID isn't.<br>
<br>
&gt; &nbsp;I find no such reference to section<br>
&gt;8 of 4412.<br>
&gt;<br>
&gt;Thanks, and please note that I strongly support the creation of the
<br>
&gt;esnet namespace. &nbsp;None of my comment should be interpreted as
being <br>
&gt;&quot;against&quot; esnet.<br>
&gt;<br>
&gt;Janet<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;This is a PRIVATE message. If you are not the intended recipient, <br>
&gt;please delete without copying and kindly advise us by e-mail of the
<br>
&gt;mistake in delivery.<br>
&gt;NOTE: Regardless of content, this e-mail shall not operate to bind
<br>
&gt;CSC to any order or other contract unless pursuant to explicit <br>
&gt;written agreement or government initiative expressly permitting the
<br>
&gt;use of e-mail for such purpose.<br>
&gt;<br>
&gt;<br>
&gt;&quot;James M. Polk&quot; &lt;[email-masked]&gt;<br>
&gt;Sent by: [email-masked]<br>
&gt;<br>
&gt;02/19/2009 09:32 PM<br>
&gt;To<br>
&gt;&quot;'ECRIT'&quot; &lt;[email-masked]&gt;<br>
&gt;cc<br>
&gt;Subject<br>
&gt;[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;ECRIT<br>
&gt;<br>
&gt;I've just submitted a rev of the &quot;esnet&quot; Resource-Prioriy
header draft.<br>
&gt;<br>
&gt;I've removed all mention of UAs from the draft, but leave in the<br>
&gt;possibility for adjacent VSPs to have a trust relationship with the<br>
&gt;local ESInet and mark these SIP requests accordingly through the<br>
&gt;VSP's domain. &nbsp;I offer that the ESRP at the ESInet edge will be<br>
&gt;tasked with mapping the esnet.priority-values from outside the ESInet<br>
&gt;to the indications used inside the ESInet. &nbsp;The ID gives no guidance<br>
&gt;on what the priority-values should be in either case - as that is a<br>
&gt;matter for other documents (and I'd argue - for other SDOs or<br>
&gt;consortia such as NENA and EENA, though I don't mention either<br>
&gt;organization in the ID).<br>
&gt;<br>
&gt;Comments are welcome<br>
&gt;<br>
&gt;James<br>
&gt;<br>
&gt; &gt;From: IETF I-D Submission Tool &lt;[email-masked]&gt;<br>
&gt; &gt;To: [email-masked]<br>
&gt; &gt;Subject: New Version Notification for<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;draft-ietf-ecrit-local-emergency-rph-namespace-01<br>
&gt; &gt;Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST)<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;A new version of I-D,<br>
&gt; &gt;draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been<br>
&gt; &gt;successfuly submitted by James Polk and posted to the IETF repository.<br>
&gt; &gt;<br>
&gt; &gt;Filename: &nbsp; &nbsp; &nbsp; draft-ietf-ecrit-local-emergency-rph-namespace<br>
&gt; &gt;Revision: &nbsp; &nbsp; &nbsp; 01<br>
&gt; &gt;Title: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;IANA Registering a SIP
Resource Priority Header<br>
&gt; &gt;Namespace for Local Emergency Communications<br>
&gt; &gt;Creation_date: &nbsp;2009-02-19<br>
&gt; &gt;WG ID: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ecrit<br>
&gt; &gt;Number_of_pages: 7<br>
&gt; &gt;<br>
&gt; &gt;Abstract:<br>
&gt; &gt;This document creates and IANA registers the new Session Initiation<br>
&gt; &gt;Protocol (SIP) Resource Priority header (RPH) namespace &quot;esnet&quot;
for<br>
&gt; &gt;local emergency usage to a public safety answering point (PSAP),<br>
&gt; &gt;between PSAPs, and between a PSAP and first responders and their<br>
&gt; &gt;organizations.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;The IETF Secretariat.<br>
&gt;<br>
&gt;_______________________________________________<br>
&gt;Ecrit mailing list<br>
&gt;[email-masked]<br>
&gt;https://www.ietf.org/mailman/listinfo/ecrit<br>
<br>
</tt></font>
<br>
--=_alternative 0078257E85257569_=--

Date: Thu, 26 Feb 2009 17:00:20 -0600
To: Janet P Gunn <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: 'ECRIT' <[email-masked]>, [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted

At 03:52 PM 2/26/2009, Janet P Gunn wrote:

>James,
>
>Please go back and R E A D  S L O W L Y.   You have missed the point 
>on many of my comments.
>
>For instance -
>
>1) Do you REALLY think
>"...this namespace is to be to provide an  explicit priority 
>indication facilitates treatment..."
>makes sense?  What is the subject of the verb "facilitates"?

the indication

perhaps I can put a "that" in front of "facilitates" to make it easier to read.

>2) I agree that
>4412 says "do not modify or delete, just ignore if you don't like it"
>FOR SIP ACTORS THAT DO NOT UNDERSTAND THE NAMESPACE.
>
>There is NO SUCH PROHIBITION in 4412 for SIP Actors that DO 
>UNDERSTAND the namespace, which is what is being discussed here.

what's being discussed here is your point that ESInet behaviors are 
exactly how 4412 says, which they are not.

This ID is officially updating 4412 to allow SIP actors that 
understand RPH and a particular namespace to modify, delete or just 
ignore *just the esnet* namespace. This doesn't apply to any other 
namespaces but esnet.

>3) Yes, it is just my opinion that "preempting normal calls" is a bad idea.

what do you say to a country that does do this, they're wrong?

>But it is WRITTEN IN 4412 (not just my opinion) that only calls 
>"with a valid namespace and a lower priority value" can be preempted.

the text you are referring to is not normative - and is left to local 
policy, but it can happen (as it does in Japan), and I think that 
makes it worth mentioning.

>And furthermore it is a fact that for both the MLPP and eMLPP , the 
>protocol standards are very clear that you can't preempt calls that 
>don't have a priority value, in the same preemption domain.

well, those are individual domain policies - they are not uniformly 
SIP wide, to be taken as from God across the planet.

>I have no idea how they do it in Japan, but if they are using MLPP, 
>then the "normal" calls must be in the same preemption domain as the 
>"911" calls, with a lower priority.    Hence not "normal calls" in 
>the usual sense of the word

this is semantics only

>4) Your replies contradict each other.  When I say that "ets and wps 
>don't have a 'routine' or 'normal' value", you say that esnet is 
>different because "here there is no routine esnet calls, every one 
>is an emergency call, and likely every
>call will be an emergency."
>
>A- That is equally true of ets and wps.

no it is not, because nowhere will ets or wps be wholly within "a 
single domain" that is only ets or wps.

It is more likely the case that esnet will be in a similar network 
situation to MLPP domains (that are typically government run networks).

>  There are no routine NS/EP calls. Every call with the ets or wps 
> namespace is an NS/EP (hence special) call.

but the two situations are not comparable (esnet to ets or wps).

>B - If you mean that the esnet namespace will ONLY be used in 
>networks where EVERY relevant SIP message uses the esnet RPH, then
>         -Yes, it is different from ets and wps

see above - we agree finally then

>         -BUT if this is the case, there are no "normal" calls to preempt

but there very well may be ESInet calls with no RPH that are 
considered to have no priority -- which is different than MLPP type 
environments where the lowest priority calls are the regular 
normal/routine calls.

The thing is here, that SIP can signal so much nowadays -- that there 
may be non-calls (involving something other than voice or video, such 
as IM or Presence, or data transfer or something else) that doesn't 
need to be marked at all.  Where I believe you firmly are in the camp 
that everything SIP has to be a "call", whether it's voice or 
video.  I'm saying that's not true.  Think of a subscription 
establishment. That can be a dialog (i.e., long lasting), yet doesn't 
need any priority treatment - therefore can be a SIP request without 
RPH and be perfectly normal.

>         -If this is the case, you need to state clearly that esnet 
> will only be used in networks where everything is marked esnet.

see above, I clearly do not believe that to be the case.

>But I don't think that is what you mean (at least based on the 
>diagram you presented today).

that diagram covers real-time communications -- but did not discuss 
all the SIP requests that are not real-time that will still be 
present within the ESInet.

>C -  I think you mean that esnet will be used in some networks where 
>there are both esnet and non esnet messages (as well as some where 
>all are marked esnet)

no, there will be a mix always

>         - If this is the case, then it is EXACTLY the same as ets 
> and wps, and no change from 4412

no it isn't, because it is still within the boundaries of a single 
administrator -- who gets to choose which traffic is marked (and at 
what level) and what traffic is not marked... this is not the same.

>And so on.
>
>Janet
>
>
>This is a PRIVATE message. If you are not the intended recipient, 
>please delete without copying and kindly advise us by e-mail of the 
>mistake in delivery.
>NOTE: Regardless of content, this e-mail shall not operate to bind 
>CSC to any order or other contract unless pursuant to explicit 
>written agreement or government initiative expressly permitting the 
>use of e-mail for such purpose.
>
>
>"James M. Polk" <[email-masked]>
>
>02/26/2009 02:39 PM
>To
>Janet P Gunn/FED/CSC@CSC
>cc
>"'ECRIT'" <[email-masked]>, [email-masked]
>Subject
>Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01  submitted
>
>
>
>
>At 03:10 PM 2/24/2009, Janet P Gunn wrote:
>
> >James
> >Some of this is editorial, some is substantive and technical, and
> >some repeats my comments on 00 that do not seem to have been addressed.
> >
> >2nd paragraph of section 1, this sentence doesn't make sense.
> >"   Within controlled environments, such as an IMS infrastructure or
> >    Emergency Services network (ESInet), where misuse can be reduced to
> >    a minimum where possible, this namespace is to be to provide an
> >    explicit priority indication facilitates treatment of emergency SIP
> >    messages according to local policy."
>
>I think this makes perfect sense as written
>
>
> >Perhaps you mean
> >"   Within controlled environments, such as an IMS infrastructure or
> >    Emergency Services network (ESInet), where misuse can be reduced to
> >    a minimum, this namespace is expected to be used to provide an
> >    explicit priority indication, facilitating treatment of emergency SIP
> >    messages according to local policy."  But I am not sure if that
> > is what you meant.
>
>that's another way of saying the same thing
>
>
> >Same para
> >"This indication is used to
> >    differentiate SIP requests, or dialogs, from other requests or
> >    dialogs that do not have the need for priority treatment."
> >sounds as if you are differentiating SIP requests form non-SIP
> >requests.  Perhaps what you mean is
> >"This indication is used to
> >    differentiate Emergency Services related  SIP requests, or
> > dialogs, from other (non Emergency
> >Services related) SIP requests or  dialogs.
>
>again -- this appears to be two ways of saying the same thing.
>
>
> >Note that "do not have the need for priority treatment" is not correct.
>
>it applies to other traffic that does not need priority treatment. In
>other words, the traffic that doesn't need priority treatment --
>because there will be some traffic that does not need priority
>treatment within the ESInet (as well as an esnet namespace capable VSP)
>
> >The esnet RPH would
> >distinguish ES related messages from GETS related messages (ets and
> >wps namespaces), but they
> >would each get their own particular flavor of "priority treatment".
> >
> >
> >5th para of section 1
> >
> >"From this fact about RFC 4412, and the possibility that within
> >    emergency services networks, a Multilevel Precedence and Preemption
> >    (MLPP)-like behavior can be achieved - ensuring more important calls
> >    are established or retained, the "esnet" namespace is given 5
> >    priority-levels."
> >What is "this fact"?  Perhaps "Because we can't add new values later..."
>
>the fact is right above this sentence
>
>
> >I don't understand the "can be achieved".  Do you mean "MLPP-like
> >behavior may be desired"?
>
>it can be, which is all that I'm offering -- but I'm not recommending
>or stipulating or demanding or anything else... I'm just saying that
>with more than 2 levels, a natural hierarchy _can_ be configured.
>
>
> >I fully agree with assigning 5 levels, and the underlying logic. It
> >is only the description that is problematic.
> >
> >Perhaps
> >"Because we can't add new values later, and because  Multilevel
> >Precedence and Preemption
> >    (MLPP)-like behavior may be desired the "esnet" namespace is
> > given 5 priority-levels."
>
>that is within 4412
>
>
> >2nd to last paragraph of section 1
> >"Within the ESINet, there will be emergency calls requiring different
> >    treatments, according to the type of call. "
> >We don't know if they will require different treatment or not.
> >
> >I would prefer
> >"Within the ESINet, there may be emergency calls requiring different
> >    treatments, according to the type of call. "
> >
> >or if the use of "may" will be confused with normative language,
> >"Within the ESINet, there could be emergency calls requiring different
> >    treatments, according to the type of call. "
>
>I'm ok with this
>
> >This sentence at the end of sec 1 doesn't quite work.
> >"This document IANA registers the "esnet"
> >    RPH namespace for use within emergency services networks, not just
> >    of those from citizens to PSAPs." (no clear antecedent for "those")
>
>fair
>
>
> >Perhaps
> >"This document IANA registers the "esnet"
> >    RPH namespace for use within emergency services networks, not
> > just for calls or sessions
> >     from citizens to PSAPs."
> >(same comment applied to 00)
>
>I'll back off this even more - to
>
>"This document IANA registers the "esnet"
>   RPH namespace for use within emergency services networks, not just
>for calls or sessions
>   towards PSAPs."
>
>
>
>
> >Section 2  first para says
> >  "This document updates the behaviors of the SIP Resource Priority
> >    header, defined in [RFC4412], during the treatment options
> >    surrounding this new "esnet" namespace only. The usage of the
> >    "esnet" namespace does not have a normal, or routine call level.
> >    Every use of this namespace will be in times of an emergency, where
> >    at least one end of the signaling is with a local emergency
> >    organization."
> >
> >I don't see this as an "update of the behavior of 4412".  Neither
> >the ets namespace not the wps namespace have a "normal" or "routine"
> >call level.
>
>but either (ets or wps) can simply not be used. here there is no
>routine esnet calls, every one is an emergency call, and likely every
>call will be an emergency.
>
> >Every use of the wps and ets namespaces will have priority over
> >calls without RPH.
> >
> >Suggest changing text to say
> >"   Like the ets and wps namespaces defined in [RFC4412], the
> >    "esnet" namespace does not have a normal, or routine call level.
> >     Every use of this namespace will be in times of an emergency, where
> >    at least one end of the signaling is with a local emergency
> >    organization."
>
>see comment above
>
>
>
> >Section 2, para immediately below Figure 1
> >"   Because the more important usage of the
> >    "esnet" namespace occurs within the ESInet, the edge proxy, called
> >    an Emergency Services Routing Proxy (ESRP) can modify or delete this
> >    namespace. This is a normative change to the allowed behavior within
> >    [RFC4412], but MUST only be considered valid in this usage at the
> >    ESInet boundary for this one RP namespace (and associated
> >    priority-value). "
> >
> >I have major (content, not editorial) concerns with this, more for
> >what it says about 4412 than about esnet
> >
> >
> >First of all, it is not clear to me why this is "a normative change
> >to the allowed behavior within [RFC4412]".
>
>because 4412 says "do not modify or delete, just ignore if you don't like it"
>
>this doc changes that for esnet only.
>
>
> >For one thing I see nothing in 4412 that would prohibit a "SIP actor
> >that understands the name space"
> >from modifying or deleting the namespace.
>
>
>
>4.6.2.  No Known Namespace or Priority Value
>
>    If an RP actor does not understand any of the resource values in
>the request, the treatment depends on the presence of the Require
>'resource-priority' option tag:
>
>    1.  Without the option tag, the RP actor treats the request as if
>it contained no 'Resource-Priority' header field and processes it
>with default priority.  Resource values that are not understood MUST
>NOT be modified or deleted.
>
>
>so, evidence to the contrary (from your statement above)
>
> >It is certainly anticipated that at least some of the namespaces
> >described in 4412 will be
> >modified or deleted, (e.g., when there is reason to  believe it is
> >unauthorized).
>
>no, just ignored
>
>
> >4412 says "Existing implementations of RFC 3261 that do not
> >participate in the
> >    resource priority mechanism follow the normal rules of RFC 3261,
> >    Section 8.2.2: "If a UAS does not understand a header field in a
> >    request (that is, the header field is not defined in this
> >    specification or in any supported extension), the server MUST ignore
> >    that header field and continue processing the message". "
>
>What about SIP entities that not only understand RPH, but understand
>the "esnet" namespace - yet have an incorrect priority-value for that call?
>
>That's a problem that needs to be fixed in the ESInet (with use of the esnet).
>
>
> >But I do not see anywhere that is says that a UAS that DOES
> >understand the namespace is
> >forbidden from deleting it.
>
>see 4.6.2 (quoted above)
>
> >For instance, sec 4.7.1 of 4412 says that "the UAC
> >    MAY attempt a subsequent request with the same or different resource
> >    value."  This certainly implies the ability to overwrite or
> > delete an RPH namespace.  (See
> >also, for instance the PTSC SAC document on the use of the ets and
> >wps namespaces.)
> >
> >I would suggest rewording this to say
> >"   Because the more important usage of the
> >    "esnet" namespace occurs within the ESInet, the edge proxy, called
> >    an Emergency Services Routing Proxy (ESRP) can modify or delete this
> >    namespace. This is consistent with [RFC4412]. "
> >
> >
> >
> >
> >Section 3.2,para after the relative priority order.
> >
> >"  The "esnet" namespace will be assigned into the priority queuing
> >    algorithm (Section 4.5.2 of [RFC4412]) from the public user to the
> >    PSAP.  This does not limit its usage to only the priority queue
> >    algorithm; meaning the preemption algorithm can be used where the
> >    local jurisdiction preferred to preempt normal calls in lieu of
> >    completing emergency calls.  This document is not RECOMMENDING this
> >    usage, merely pointing out those behaviors are a matter of local
> >    policy."
> >
> >My concern here is the reference to "preempt normal calls".  Since
> >you have already said that
> >there is no "normal" level in the esnet priority value set, I have
> >to assume that you mean
> >"preempt calls with no RPH" (or perhaps "preempt calls  with a
> >different RPH namespace").
>
>no, I'm leaving open the possibility that perhaps one local
>jurisdiction wants to use preemption -- kinda like the country of
>Japan does today (therefore... it needs to be possible, *and* mentioned).
>
> >
> >
> >This WOULD BE a normative change to 4412, which says in 4.7.2.1
> >"A UAS compliant with this specification MUST terminate a session
> >    established with a valid namespace and lower-priority value in favor
> >    of a new session set up with a valid namespace and higher relative
> >    priority value, unless local policy has some form of call-waiting
> >    capability enabled."
> >
> >Note that the only sessions that can be preempted are ones "with a
> >valid namespace and a lower
> >priority value".  A "normal" call has neither a "valid namespace",
> >nor a "priority value"
> >(higher or lower), and thus cannot be preempted under 4412.
>
>we are not private ESInet network police -- and we shouldn't be so
>firm in deciding normal calls aren't preempted in one or more local
>configurations within jurisdictions.
>
>
> >Furthermore, RFC4411 (which focuses on "preemption") repeatedly
> >refers to the pre-empted
> >call/session having an RPH with a lower priority value.
>
>4411 is how to indicate to a preempted caller their session has been
>preempted. I see no reason at this point to include any 4411
>reference. For example, if NENA wanted to allow preemption (which I
>am NOT suggesting), their docs should include this reference and 
>usage of 4411.
>
>
> >The circuit switched versions of preemption ( both MLPP for
> >landlines, and 3GPP e-MLPP for GSM)
> >are even more restrictive.  In those schemes, a call can only
> >preempt a lower priority call IN
> >THE SAME PREEMPTION DOMAIN (there is a rough correspondence between
> >"preemption domain" and "RPH namespace").
> >
> >So I take serious objection to any suggestion of preempting "normal" calls.
>
>respectfully, that's a personal opinion that I question the universal
>applicability of. Especially given that Japan currently preempts
>normal calls in lieu of 911 calls.
>
>Other jurisdictions *may* have similar or future plans
>
> >If you want to have high priority esnet calls preempt low priority
> >esnet calls, I don't object as
> >strenuously. (But no preempting "normal" calls.)
> >
> >
> >Section 5, 3rd para
> >"  A simple means of preventing this usage is to not allow marked
> >    traffic preferential treatment unless the destination is towards the
> >    local/regional ESInet. "
>
>neither of the quotes below talk about granting preferential
>treatment across the ESInet ESRP boundary.  This comment does. But I
>can expand on this sentence to clarify this meaning.
>
>
> >This seems to contradict the text in section 1
> >"This new namespace can
> >    be used for inbound calls to PSAPs, between PSAPs, and between a
> >    PSAP and first responders and their organizations."
> >and section 3
> >" This namespace will also be used
> >    for communications between emergency authorities, and MAY be used
> >    for emergency authorities calling public citizens.  An example of
> >    the later is a PSAP operator calling back someone who previously
> >    called 9111/112/999 and the communication was terminated before it
> >    should have been (in the operator's judgment)."
> >
> >Finally, at IETF 73 you assured me that you would insert strong
> >language pointing to section 8 of
> >RFC4412 addressing the relative priority of the different
> >namespaces.  This is to eliminate any
> >possible suggestion (that some people - not me- read into the 00
> >version) that an esnet
> >namespace would have higher priority than an ets namespace.
>
>well... I agree I haven't emphasized section 8 of 4412, and can
>mention this in a generic form when other namespaces are present.
>
>Secondly, this document should never insist that esnet is above or
>below ets or wps. that's a matter of local policy, for example - to
>within NENA/APCO for whether they believe (and are going to implement
>to) this.  That's for an operational doc that this ID isn't.
>
> >  I find no such reference to section
> >8 of 4412.
> >
> >Thanks, and please note that I strongly support the creation of the
> >esnet namespace.  None of my comment should be interpreted as being
> >"against" esnet.
> >
> >Janet
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >This is a PRIVATE message. If you are not the intended recipient,
> >please delete without copying and kindly advise us by e-mail of the
> >mistake in delivery.
> >NOTE: Regardless of content, this e-mail shall not operate to bind
> >CSC to any order or other contract unless pursuant to explicit
> >written agreement or government initiative expressly permitting the
> >use of e-mail for such purpose.
> >
> >
> >"James M. Polk" <[email-masked]>
> >Sent by: [email-masked]
> >
> >02/19/2009 09:32 PM
> >To
> >"'ECRIT'" <[email-masked]>
> >cc
> >Subject
> >[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted
> >
> >
> >
> >
> >ECRIT
> >
> >I've just submitted a rev of the "esnet" Resource-Prioriy header draft.
> >
> >I've removed all mention of UAs from the draft, but leave in the
> >possibility for adjacent VSPs to have a trust relationship with the
> >local ESInet and mark these SIP requests accordingly through the
> >VSP's domain.  I offer that the ESRP at the ESInet edge will be
> >tasked with mapping the esnet.priority-values from outside the ESInet
> >to the indications used inside the ESInet.  The ID gives no guidance
> >on what the priority-values should be in either case - as that is a
> >matter for other documents (and I'd argue - for other SDOs or
> >consortia such as NENA and EENA, though I don't mention either
> >organization in the ID).
> >
> >Comments are welcome
> >
> >James
> >
> > >From: IETF I-D Submission Tool <[email-masked]>
> > >To: [email-masked]
> > >Subject: New Version Notification for
> > >          draft-ietf-ecrit-local-emergency-rph-namespace-01
> > >Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST)
> > >
> > >
> > >A new version of I-D,
> > >draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been
> > >successfuly submitted by James Polk and posted to the IETF repository.
> > >
> > >Filename:       draft-ietf-ecrit-local-emergency-rph-namespace
> > >Revision:       01
> > >Title:          IANA Registering a SIP Resource Priority Header
> > >Namespace for Local Emergency Communications
> > >Creation_date:  2009-02-19
> > >WG ID:          ecrit
> > >Number_of_pages: 7
> > >
> > >Abstract:
> > >This document creates and IANA registers the new Session Initiation
> > >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
> > >local emergency usage to a public safety answering point (PSAP),
> > >between PSAPs, and between a PSAP and first responders and their
> > >organizations.
> > >
> > >
> > >
> > >
> > >The IETF Secretariat.
> >
> >_______________________________________________
> >Ecrit mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/ecrit
>