Re: [Ecrit] Comments on phonebcp-07

["Brian Rosen" <[e-mail]>]

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

Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B50E3A6B3B for <[e-mail]>; Wed,  4 Feb 2009 07:29:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.945
X-Spam-Level: 
X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_66=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNcRCdZt1-il for <[e-mail]>; Wed,  4 Feb 2009 07:29:52 -0800 (PST)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id B7E8B3A6837 for <[e-mail]>; Wed,  4 Feb 2009 07:29:51 -0800 (PST)
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <[e-mail]> for [e-mail]; Wed, 04 Feb 2009 15:29:31 +0000 (GMT)
Date: Wed, 04 Feb 2009 15:29:33 +0000
From: "Elwell, John" <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: Comments on phonebcp-07
Thread-Index: AcmG2TzrX1PZDoMaQaWKnk3BwoYIIQ==
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Subject: [Ecrit] Comments on phonebcp-07
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 15:29:53 -0000

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






Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5C43A6B92 for <[e-mail]>; Wed,  4 Feb 2009 09:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.356
X-Spam-Level: 
X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itgJkfm+1Txj for <[e-mail]>; Wed,  4 Feb 2009 09:28:15 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D206C3A6AFF for <[e-mail]>; Wed,  4 Feb 2009 09:28:14 -0800 (PST)
Received: (qmail invoked by alias); 04 Feb 2009 17:27:54 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp040) with SMTP; 04 Feb 2009 18:27:54 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/5GhQzQWL5dtgbs2Sq+NCwMt5sFk/VyC49Risvbt 9247Gk7nnj5Z64
From: "Hannes Tschofenig" <[e-mail]>
To: "'Richard Barnes'" <[e-mail]>, "'ECRIT'" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Date: Wed, 4 Feb 2009 19:28:40 +0200
Message-ID: <000101c986ee$05c75de0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcmB1gCc7Rx3IeywQ36KJ2K9r3YMoAEZ7Mew
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.55
Subject: Re: [Ecrit] Review of draft-ietf-lost-sync-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 17:28:16 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A015B3A6920 for <[e-mail]>; Wed,  4 Feb 2009 09:54:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.51
X-Spam-Level: 
X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWXJPD6gX+V6 for <[e-mail]>; Wed,  4 Feb 2009 09:54:14 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B5B8B3A6843 for <[e-mail]>; Wed,  4 Feb 2009 09:54:14 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,380,1231113600"; d="scan'208";a="242930340"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 04 Feb 2009 17:53:55 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n14HrtxZ014856;  Wed, 4 Feb 2009 09:53:55 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n14HrtdP022341; Wed, 4 Feb 2009 17:53:55 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 4 Feb 2009 09:53:55 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.19.69]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 4 Feb 2009 09:53:54 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 04 Feb 2009 11:53:53 -0600
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>, "ext Hannes Tschofenig" <[e-mail]>, "ECRIT" <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <[e-mail]-intr a.net>
References: <003301c97e00$ac955f60$[e-mail]> <013501c97ec9$5cc04300$[e-mail]> <045801c983ef$3c4643b0$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 04 Feb 2009 17:53:54.0757 (UTC) FILETIME=[8BCE6750:01C986F1]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=504; t=1233770035; x=1234634035; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20ECRIT=20Virtual=20Interim=20M eeting=3A=20Agenda |Sender:=20; bh=cPe3AD8nj1AOXOo1sDEBV37W/gu9C7+cZvFGiWyKcdg=; b=IsAIk4fvGhJB3SFliWTAkD14HMOO0njc+STrNjuGS6t2NrUg9QG9uXGZQS ethmE/Hc92S38fHWJp02eHK5hkM/u2/ZtIW91Q+ndp/Hvcb7L5Jx1KZHziC0 KYzKTvZ9Qw;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 17:54:15 -0000

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




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251863A6A3D for <[e-mail]>; Wed,  4 Feb 2009 09:58:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.514
X-Spam-Level: 
X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf98z0n5LCXq for <[e-mail]>; Wed,  4 Feb 2009 09:58:57 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0F21E3A6A98 for <[e-mail]>; Wed,  4 Feb 2009 09:58:57 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,380,1231113600"; d="scan'208";a="137802436"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 04 Feb 2009 17:58:37 +0000
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n14Hwb6A025842;  Wed, 4 Feb 2009 09:58:37 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n14HwbOg029788; Wed, 4 Feb 2009 17:58:37 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 4 Feb 2009 09:58:37 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.19.69]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 4 Feb 2009 09:58:36 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 04 Feb 2009 11:58:35 -0600
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>, "ext Hannes Tschofenig" <[e-mail]>, "ECRIT" <[e-mail]>
From: "James M. Polk" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 04 Feb 2009 17:58:37.0049 (UTC) FILETIME=[3410BE90:01C986F2]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1171; t=1233770317; x=1234634317; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Fwd=3A=20Re=3A=20[Ecrit]=20ECRIT=20Virtual=20In terim=20Meeting=3A=20Agenda=20(my=0A=20=20mistake) |Sender:=20; bh=wuQ7jq4jpUjEEgDd6BL8BnpgM7FibSk93XB8zbdXWJI=; b=uR6fN3iwdukKqYAyIYkmjRukfru7/sIPSB9h0qNpb1YQUVEb1bchHRSoQN VxbM8bLZ79q0hFq4pGES33qWgVGgjuJwGiEv+nQ6qjRDFls18ZRQ8PmD84gB yPVjCwTUp6axOXkdoaILkTAg7QvU9sN9USSf7+HlKoJ1jjlvLi4uQ=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Subject: [Ecrit] Fwd: Re: ECRIT Virtual Interim Meeting: Agenda (my mistake)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 17:58:58 -0000

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)" 
><[e-mail]>, "ext Hannes Tschofenig" 
><[e-mail]>, "ECRIT" <[e-mail]>
>From: "James M. Polk" <[e-mail]>
>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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C5928C228 for <[e-mail]>; Wed,  4 Feb 2009 09:59:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.517
X-Spam-Level: 
X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiOmhqxsy4lg for <[e-mail]>; Wed,  4 Feb 2009 09:59:55 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C53883A6A3D for <[e-mail]>; Wed,  4 Feb 2009 09:59:55 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,380,1231113600"; d="scan'208";a="137803196"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 04 Feb 2009 17:59:36 +0000
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n14HxaA5027443;  Wed, 4 Feb 2009 09:59:36 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n14HxaiS000366; Wed, 4 Feb 2009 17:59:36 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 4 Feb 2009 09:59:36 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.19.69]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 4 Feb 2009 09:59:35 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 04 Feb 2009 11:59:34 -0600
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>, "ext Hannes Tschofenig" <[e-mail]>, "ECRIT" <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <[e-mail]-intr a.net>
References: <003301c97e00$ac955f60$[e-mail]> <013501c97ec9$5cc04300$[e-mail]> <045801c983ef$3c4643b0$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 04 Feb 2009 17:59:35.0786 (UTC) FILETIME=[57134CA0:01C986F2]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1986; t=1233770376; x=1234634376; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20ECRIT=20Virtual=20Interim=20M eeting=3A=20Agenda=20(timing?) |Sender:=20; bh=ROt4rLJal0CknenZP78gZqkZaujLqATmJK2OnIW/WfM=; b=kxpHq0c+kcs68zCFzbwc8ci6ZL/MRK6zTfKHyHN+ONI20FDUpwYho4+86c R2l32secvCC2PDpQ1Bqays4CK29uG6SQjLOVfbo79T6b9wU//qXnMSVML8E2 9c3A22fNfE;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (timing?)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 17:59:56 -0000

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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1173A63CB for <[e-mail]>; Wed,  4 Feb 2009 12:37:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.358
X-Spam-Level: 
X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqLZMHfYHRuu for <[e-mail]>; Wed,  4 Feb 2009 12:37:03 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BAFDB28C225 for <[e-mail]>; Wed,  4 Feb 2009 12:36:42 -0800 (PST)
Received: (qmail invoked by alias); 04 Feb 2009 20:36:21 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp023) with SMTP; 04 Feb 2009 21:36:21 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+HgLNPqDCHqMpECTmarFkOLhgTxxDN6JTppL4A3z bT98MH8sWxBzaZ
From: "Hannes Tschofenig" <[e-mail]>
To: "'James M. Polk'" <[e-mail]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, "'ECRIT'" <[e-mail]>
References: <[e-mail]>
Date: Wed, 4 Feb 2009 22:37:07 +0200
Message-ID: <000801c98708$5973f6f0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcmG8jShcSXkM0tcS9mgKe5GPc11ywAFPa+w
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.71
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my  mistake)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 20:37:03 -0000

> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D910E28C11F for <[e-mail]>; Wed,  4 Feb 2009 12:42:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.051
X-Spam-Level: 
X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=0.548,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FydwZxDXNUwK for <[e-mail]>; Wed,  4 Feb 2009 12:42:25 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C6AE83A683D for <[e-mail]>; Wed,  4 Feb 2009 12:42:24 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,381,1231113600"; d="scan'208";a="35965628"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Feb 2009 20:41:58 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n14KfwoA024391;  Wed, 4 Feb 2009 15:41:58 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n14Kfw5p007818; Wed, 4 Feb 2009 20:41:58 GMT
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 4 Feb 2009 15:41:58 -0500
Received: from [10.116.195.119] ([10.116.195.119]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 4 Feb 2009 15:41:42 -0500
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Wed, 04 Feb 2009 15:41:40 -0500
From: Marc Linsner <[e-mail]>
To: Hannes Tschofenig <[e-mail]>, James Polk <[e-mail]>, "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>, "'ECRIT'" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my  mistake)
Thread-Index: AcmG8jShcSXkM0tcS9mgKe5GPc11ywAFPa+wAABz8h8=
In-Reply-To: <000801c98708$5973f6f0$[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 04 Feb 2009 20:41:42.0764 (UTC) FILETIME=[FCCE5AC0:01C98708]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1069; t=1233780118; x=1234644118; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Marc=20Linsner=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20ECRIT=20Virtual=20Interim=20M eeting=3A=20Agenda=20(my=20=20mistake) |Sender:=20 |To:=20Hannes=20Tschofenig=20<[e-mail]>,=0 A=20=20=20=20=20=20=20=20James=20Polk=20<[e-mail]>,= 0A=20=20=20=20=20=20=20=20=22Tschofenig,=20Hannes=20(NSN=20- =20FI/Espoo)=22=20<[e-mail]>,=0A=20=20=20=2 0=20=20=20=20=22'ECRIT'=22=20<[e-mail]>; bh=mYnuDNAvna4n/CaVw3lPSbhVBJkBlDZ1b4kAiL8V6J0=; b=g9EKhyoL0m2TQ9bkJ+mB5uKcHPYfsVmtN0eYgjwtAqih8t+lLhHWsKuQUo 1SbdivyWyGcd3oVo29DPXb54sr8oLdBovqomjSjfy4STT0OsS9iuIOmLfj7i bDIUafF1Ml;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); 
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my  mistake)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 20:42:25 -0000

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" <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C88C28C135 for <[e-mail]>; Wed,  4 Feb 2009 12:53:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.36
X-Spam-Level: 
X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QM-ONTDsNUlU for <[e-mail]>; Wed,  4 Feb 2009 12:53:46 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EC43E3A68F7 for <[e-mail]>; Wed,  4 Feb 2009 12:53:45 -0800 (PST)
Received: (qmail invoked by alias); 04 Feb 2009 20:53:20 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp071) with SMTP; 04 Feb 2009 21:53:20 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18FcVhVH1UFHduY+qK9qDiSLqm47jHqEmEpLWibi9 tmmxGDukY0xO6O
From: "Hannes Tschofenig" <[e-mail]>
To: "'James M. Polk'" <[e-mail]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, "'ECRIT'" <[e-mail]>
References: <003301c97e00$ac955f60$[e-mail]> <013501c97ec9$5cc04300$[e-mail]> <045801c983ef$3c4643b0$[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 4 Feb 2009 22:54:06 +0200
Message-ID: <001201c9870a$b8a5b4e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcmG8lfM1bBVYdCVRlWREfv2a0OCRgAEpIAg
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.54
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (timing?)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 20:53:47 -0000

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:[e-mail]] 
>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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ecrit
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A623A6B1C for <[e-mail]>; Wed,  4 Feb 2009 12:56:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.362
X-Spam-Level: 
X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzmU1P0m9GW8 for <[e-mail]>; Wed,  4 Feb 2009 12:56:21 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E9CA63A68F7 for <[e-mail]>; Wed,  4 Feb 2009 12:56:20 -0800 (PST)
Received: (qmail invoked by alias); 04 Feb 2009 20:56:00 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp022) with SMTP; 04 Feb 2009 21:56:00 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+b924UP0abaxVLjfUrtJ29ggr5xfuuZMZzdSZV96 etJeP7fb/vFcHp
From: "Hannes Tschofenig" <[e-mail]>
To: "'Marc Linsner'" <[e-mail]>, "'James Polk'" <[e-mail]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, "'ECRIT'" <[e-mail]>
References: <000801c98708$5973f6f0$[e-mail]> <[e-mail]>
Date: Wed, 4 Feb 2009 22:56:46 +0200
Message-ID: <001301c9870b$17dfe930$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcmG8jShcSXkM0tcS9mgKe5GPc11ywAFPa+wAABz8h8AAHUmgA==
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.5600000000000001
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my  mistake)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 20:56:22 -0000

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

>-----Original Message-----
>From: Marc Linsner [mailto:[e-mail]] 
>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" 
><[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
>
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FC8A3A6B53 for <[e-mail]>; Wed,  4 Feb 2009 13:00:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.064
X-Spam-Level: 
X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=-1.065, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEFgZKHHLhgm for <[e-mail]>; Wed,  4 Feb 2009 13:00:53 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 163C53A6B4F for <[e-mail]>; Wed,  4 Feb 2009 13:00:52 -0800 (PST)
Received: (qmail invoked by alias); 04 Feb 2009 21:00:32 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp043) with SMTP; 04 Feb 2009 22:00:32 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18zBaI/j8Yz8Ur3wzND3sujECbHFSQujUu8Gj+eD4 qPhAIgZ7lIQZsY
From: "Hannes Tschofenig" <[e-mail]>
To: "'ECRIT'" <[e-mail]>
Date: Wed, 4 Feb 2009 23:01:18 +0200
Message-ID: <001401c9870b$ba0bdf20$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcmHC7lzdgVRu4QcQuuHFBkg/a8uOA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.78
Subject: [Ecrit] ECRIT Virtual Interim Meeting: Conference Bridge
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 21:00:54 -0000

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





Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D79728C12A for <[e-mail]>; Wed,  4 Feb 2009 13:01:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.52
X-Spam-Level: 
X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjEZT7SKVnRS for <[e-mail]>; Wed,  4 Feb 2009 13:01:22 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0EE9628C11F for <[e-mail]>; Wed,  4 Feb 2009 13:01:22 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,381,1231113600"; d="scan'208";a="128731724"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 04 Feb 2009 21:01:02 +0000
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n14L12LR014311;  Wed, 4 Feb 2009 13:01:02 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n14L12fC025857; Wed, 4 Feb 2009 21:01:02 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 4 Feb 2009 13:01:02 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.19.69]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 4 Feb 2009 13:01:01 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 04 Feb 2009 15:01:00 -0600
To: "Hannes Tschofenig" <[e-mail]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, "'ECRIT'" <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <000801c98708$5973f6f0$[e-mail]>
References: <[e-mail]> <000801c98708$5973f6f0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 04 Feb 2009 21:01:01.0994 (UTC) FILETIME=[AFC2D0A0:01C9870B]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2882; t=1233781262; x=1234645262; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20RE=3A=20Re=3A=20[Ecrit]=20ECRIT=20Virtual=20Int erim=20Meeting=3A=20Agenda=20(my=20=0A=20=20mistake) |Sender:=20; bh=VR3m7h6uahgQ8WPCvQotUZYZIEw7d6xiOS8I1SSVLII=; b=b2pB0MAkEywWdRn8UFvXE7nVjC1h3WZADzCagoFOIQQwmU+r3nr/AdC9nx irunK/ToTr1JAA36K9AToiPXwHK2S0kIcS5v4SM6pIYCau+KHRqJvsNyyyLW eEvZ8KSQiLltnr6bN3b8UKXM+dqrlPuQKOAAKakwho99RNNGGyJ/Y=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 21:01:23 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9BA3A694E for <[e-mail]>; Wed,  4 Feb 2009 13:49:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.425
X-Spam-Level: 
X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJk4ARAREcHg for <[e-mail]>; Wed,  4 Feb 2009 13:49:18 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E6B3E28C16B for <[e-mail]>; Wed,  4 Feb 2009 13:49:17 -0800 (PST)
Received: (qmail invoked by alias); 04 Feb 2009 21:48:55 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp005) with SMTP; 04 Feb 2009 22:48:55 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18Km9k7Eq8KA1rUG7OH6KSgUAvHJzdXrrLJN/SQfF aDlcYatLgV/JDm
From: "Hannes Tschofenig" <[e-mail]>
To: "'ECRIT'" <[e-mail]>
Date: Wed, 4 Feb 2009 23:49:41 +0200
Message-ID: <001501c98712$7c5c13a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcmHEnt+EwoFhfoQTzmAmtEnXhladQ==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.64
Subject: [Ecrit] draft-ietf-ecrit-mapping-arch: DISCUSS by Cullen
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 21:49:19 -0000

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




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5974B3A6A3A for <[e-mail]>; Wed,  4 Feb 2009 14:03:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.483
X-Spam-Level: 
X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0slJqTIFNo0W for <[e-mail]>; Wed,  4 Feb 2009 14:03:52 -0800 (PST)
Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 68C193A68D7 for <[e-mail]>; Wed,  4 Feb 2009 14:03:52 -0800 (PST)
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1LUpq4-0003vj-Ke; Wed, 04 Feb 2009 16:03:20 -0600
From: "Brian Rosen" <[e-mail]>
To: "'James M. Polk'" <[e-mail]>, "'Hannes Tschofenig'" <[e-mail]>, "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" <[e-mail]>,  "'ECRIT'" <[e-mail]>
References: <[e-mail]>	<000801c98708$5973f6f0$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 4 Feb 2009 17:03:28 -0500
Message-ID: <09fe01c98714$6acc7650$406562f0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmHC6zIdbOQB6JfQPiKYW9Ra7nZyQACHzIw
Content-Language: en-us
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 22:03:53 -0000

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: [e-mail] [mailto:[e-mail]] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24CF63A6A3A for <[e-mail]>; Wed,  4 Feb 2009 14:08:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.36
X-Spam-Level: 
X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOH5PbaQdxvx for <[e-mail]>; Wed,  4 Feb 2009 14:08:52 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A26153A68D7 for <[e-mail]>; Wed,  4 Feb 2009 14:08:51 -0800 (PST)
Received: (qmail invoked by alias); 04 Feb 2009 22:08:31 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp016) with SMTP; 04 Feb 2009 23:08:31 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+lbFUrio6lRMBeKF+tz+HN/N6ex7MVxl0FlzkX5K Eupo+pypXd1wbX
From: "Hannes Tschofenig" <[e-mail]>
To: "'Brian Rosen'" <[e-mail]>, "'James M. Polk'" <[e-mail]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, "'ECRIT'" <[e-mail]>
References: <[e-mail]>	<000801c98708$5973f6f0$[e-mail]> <[e-mail]> <09fe01c98714$6acc7650$406562f0$@net>
Date: Thu, 5 Feb 2009 00:09:16 +0200
Message-ID: <001c01c98715$3900b360$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcmHC6zIdbOQB6JfQPiKYW9Ra7nZyQACHzIwAAA6PeA=
In-Reply-To: <09fe01c98714$6acc7650$406562f0$@net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.53
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 22:08:53 -0000

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:[e-mail]] 
>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: [e-mail] [mailto:[e-mail]] 
>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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82073A6B6E for <[e-mail]>; Wed,  4 Feb 2009 14:11:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.085
X-Spam-Level: 
X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=0.514,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcrIuOAJK68r for <[e-mail]>; Wed,  4 Feb 2009 14:11:06 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 346CC3A6A3A for <[e-mail]>; Wed,  4 Feb 2009 14:11:06 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,381,1231113600"; d="scan'208";a="35980181"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Feb 2009 22:10:31 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n14MAVY9005636;  Wed, 4 Feb 2009 17:10:31 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n14MAVf5011579; Wed, 4 Feb 2009 22:10:31 GMT
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 4 Feb 2009 17:10:31 -0500
Received: from [10.116.195.119] ([10.116.195.119]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 4 Feb 2009 17:10:06 -0500
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Wed, 04 Feb 2009 17:10:04 -0500
From: Marc Linsner <[e-mail]>
To: Hannes Tschofenig <[e-mail]>, James Polk <[e-mail]>, "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>, "'ECRIT'" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my  mistake)
Thread-Index: AcmG8jShcSXkM0tcS9mgKe5GPc11ywAFPa+wAABz8h8AAHUmgAACoTYl
In-Reply-To: <001301c9870b$17dfe930$[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 04 Feb 2009 22:10:06.0225 (UTC) FILETIME=[55EA4810:01C98715]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1655; t=1233785431; x=1234649431; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Marc=20Linsner=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20ECRIT=20Virtual=20Interim=20M eeting=3A=20Agenda=20(my=20=20mistake) |Sender:=20 |To:=20Hannes=20Tschofenig=20<[e-mail]>,=0 A=20=20=20=20=20=20=20=20James=20Polk=20<[e-mail]>,= 0A=20=20=20=20=20=20=20=20=22Tschofenig,=20Hannes=20(NSN=20- =20FI/Espoo)=22=20<[e-mail]>,=0A=20=20=20=2 0=20=20=20=20=22'ECRIT'=22=20<[e-mail]>; bh=nQ3C0pTpF3BdC49xE5Xw9VfIfMQukVxVZDZR2d+VafA=; b=BunVUIsokbfovcJOEtgrtAdPLSewpKibIvOKd1HcQ2pjigefDmQq+TlGSg xh6OmR0p40c32w8BqpWEUFbF5rknQCNJS8H5YcIlFpXMBD533mgSkRs3ExtK RCUCALaEkQ;
Authentication-Results: rtp-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); 
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my  mistake)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 22:11:07 -0000

Hannes,

What if there is no proxy?

-Marc-


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

> I only don't want to let the end host todo the marking.
> 
>> -----Original Message-----
>> From: Marc Linsner [mailto:[e-mail]]
>> 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"
>> <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
>> 
> 




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4243A685A for <[e-mail]>; Wed,  4 Feb 2009 14:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level: 
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK7-NlPD8Txp for <[e-mail]>; Wed,  4 Feb 2009 14:19:15 -0800 (PST)
Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 460FD3A6934 for <[e-mail]>; Wed,  4 Feb 2009 14:19:15 -0800 (PST)
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1LUq4x-0004uc-EF; Wed, 04 Feb 2009 16:18:43 -0600
From: "Brian Rosen" <[e-mail]>
To: "'Hannes Tschofenig'" <[e-mail]>, "'James M. Polk'" <[e-mail]>, "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" <[e-mail]>,  "'ECRIT'" <[e-mail]>
References: <[e-mail]>	<000801c98708$5973f6f0$[e-mail]> <[e-mail]> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$[e-mail]>
In-Reply-To: <001c01c98715$3900b360$[e-mail]>
Date: Wed, 4 Feb 2009 17:18:51 -0500
Message-ID: <0a1101c98716$91287db0$b3797910$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmHC6zIdbOQB6JfQPiKYW9Ra7nZyQACHzIwAAA6PeAAAC77kA==
Content-Language: en-us
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 22:19:16 -0000

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:[e-mail]]
> 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:[e-mail]]
> >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: [e-mail] [mailto:[e-mail]]
> >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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507813A685E; Wed,  4 Feb 2009 14:37:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.023
X-Spam-Level: 
X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.575,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ewihXzXWasH; Wed,  4 Feb 2009 14:37:40 -0800 (PST)
Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by core3.amsl.com (Postfix) with ESMTP id A90B53A67E4; Wed,  4 Feb 2009 14:37:39 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-4.tower-171.messagelabs.com!1233787035!22357708!2
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 5871 invoked from network); 4 Feb 2009 22:37:18 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-4.tower-171.messagelabs.com with AES256-SHA encrypted SMTP; 4 Feb 2009 22:37:18 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n14MbENQ000666; Wed, 4 Feb 2009 17:37:18 -0500
In-Reply-To: <001c01c98715$3900b360$[e-mail]>
To: "Hannes Tschofenig" <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 4 Feb 2009 17:37:17 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/04/2009 05:39:40 PM, Serialize complete at 02/04/2009 05:39:40 PM
Content-Type: multipart/alternative; boundary="=_alternative 007C40DC85257553_="
Cc: [e-mail], "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 22:37:44 -0000

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

[e-mail] 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:[e-mail]] 
> >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: [e-mail] [mailto:[e-mail]] 
> >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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> 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>[e-mail] 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:[e-mail]] <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: [e-mail] [mailto:[e-mail]]
<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; [e-mail]<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; [e-mail]<br>
&gt; https://www.ietf.org/mailman/listinfo/ecrit<br>
</tt></font>
--=_alternative 007C40DC85257553_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008EB3A6972 for <[e-mail]>; Wed,  4 Feb 2009 23:49:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoNfRy8sGXOX for <[e-mail]>; Wed,  4 Feb 2009 23:49:53 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B9BAD3A686A for <[e-mail]>; Wed,  4 Feb 2009 23:49:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[e-mail]; q=dns/txt; s=qcdkim; t=1233820174; x=1265356174; h=from:to:date:subject:thread-topic:thread-index: message-id: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<[e-mail]>|To:=20" 'ECRIT'"=20<[e-mail]>|Date:=20Wed,=204=20Feb=202009 =2023:49:30=20-0800|Subject:=20Comments=20on=20Framework =20Draft|Thread-Topic:=20Comments=20on=20Framework=20Draf t|Thread-Index:=20AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXw=3D=3D |Message-ID:=20<1288E74A73964940B132A0B9EA8D8ABC535F0305@ NASANEXMB04.na.qualcomm.com>|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"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5516"=3B=20a=3D"15241325"; bh=CGsYapsln3Kc2JFLopa1S4fS0/tQHuytlxn5GQoF9u4=; b=F1sQgicdNRAVQBTJqYCgJjl0SiarzCnS9bJQjvJ3LxCTFwHq+F0ET3jk DscD4eMnnYUyOFM/gmKZ53OsbCLsSg9+5Xmxek/UfkOUNXKIcwJeRvlEh WoVADOhdgQc+UuoKu2FP50TBJ26GhtOqQRrKCZjbdpsFEglQxCeL2q1Wi I=;
X-IronPort-AV: E=McAfee;i="5300,2777,5516"; a="15241325"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Feb 2009 23:49:34 -0800
Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n157nXbn010900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 4 Feb 2009 23:49:33 -0800
Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n157nX7r018684 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Wed, 4 Feb 2009 23:49:33 -0800 (PST)
Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Wed, 4 Feb 2009 23:49:33 -0800
From: "Edge, Stephen" <[e-mail]>
To: "'ECRIT'" <[e-mail]>
Date: Wed, 4 Feb 2009 23:49:30 -0800
Thread-Topic: Comments on Framework Draft
Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXw==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 07:49:55 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2DAD3A6782 for <[e-mail]>; Thu,  5 Feb 2009 00:11:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level: 
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9KpsE0d+x5k for <[e-mail]>; Thu,  5 Feb 2009 00:11:41 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id C315B3A686A for <[e-mail]>; Thu,  5 Feb 2009 00:11:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[e-mail]; q=dns/txt; s=qcdkim; t=1233821482; x=1265357482; h=from:to:date:subject:thread-topic:thread-index: message-id: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<[e-mail]>|To:=20" 'ECRIT'"=20<[e-mail]>|Date:=20Thu,=205=20Feb=202009 =2000:11:19=20-0800|Subject:=20Comments=20on=20BCP=20Draf t|Thread-Topic:=20Comments=20on=20BCP=20Draft |Thread-Index:=20AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAhPDw |Message-ID:=20<1288E74A73964940B132A0B9EA8D8ABC535F0306@ NASANEXMB04.na.qualcomm.com>|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-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5516"=3B=20a=3D"15222186"; bh=UKMWIVjF2EWScKv2c7TzmzqMX6E03ANC8XO6c33VtDQ=; b=jw+iVho7RpOF+4rVr3kI3B/vZt1LgUmwYKfVg1kjRHXaXMhrLyaYR4ug H29oErB0LeHZKIQzYdwz9LJ6A9U+daANXE+yAiIW63KY1nOcpsu4IVyFf k1Tfw6lcRFw/n1fZnIQKGqeQ/hPRg5P+vffHqO1o2Tof8sQYU8rQll8sJ g=;
X-IronPort-AV: E=McAfee;i="5100,188,5516"; a="15222186"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Feb 2009 00:11:21 -0800
Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n158BL7S017676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 5 Feb 2009 00:11:21 -0800
Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n158BL6B011652 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Thu, 5 Feb 2009 00:11:21 -0800
Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Thu, 5 Feb 2009 00:11:20 -0800
From: "Edge, Stephen" <[e-mail]>
To: "'ECRIT'" <[e-mail]>
Date: Thu, 5 Feb 2009 00:11:19 -0800
Thread-Topic: Comments on BCP Draft
Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAhPDw
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [Ecrit] Comments on BCP Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 08:11:43 -0000

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)



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E993A67AF for <[e-mail]>; Thu,  5 Feb 2009 01:18:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.271
X-Spam-Level: 
X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.328,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHfQ-4nmz21N for <[e-mail]>; Thu,  5 Feb 2009 01:18:02 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2DAB53A6A43 for <[e-mail]>; Thu,  5 Feb 2009 01:18:02 -0800 (PST)
Received: (qmail invoked by alias); 05 Feb 2009 09:17:41 -0000
Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp067) with SMTP; 05 Feb 2009 10:17:41 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+/gF1k2Jm/TJPBp5nnd/dkW+6evXSutdsYzvq3MU ileMDpkkRfYXJW
From: "Hannes Tschofenig" <[e-mail]>
To: "'Edge, Stephen'" <[e-mail]>, "'ECRIT'" <[e-mail]>
References: <[e-mail]>
Date: Thu, 5 Feb 2009 11:18:27 +0200
Message-ID: <003901c98772$b4cc7710$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAnQ6g
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.57
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 09:18:04 -0000

Hi Stephen,=20

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

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]=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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B423A6927 for <[e-mail]>; Thu,  5 Feb 2009 04:55:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.139
X-Spam-Level: 
X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=0.110,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWokIp0K0wZI for <[e-mail]>; Thu,  5 Feb 2009 04:55:42 -0800 (PST)
Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 5873A3A6AA2 for <[e-mail]>; Thu,  5 Feb 2009 04:55:42 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n15CtA0v004008 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Feb 2009 13:55:11 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 5 Feb 2009 13:55:09 +0100
From: "DRAGE, Keith (Keith)" <[e-mail]>
To: Brian Rosen <[e-mail]>, "'Hannes Tschofenig'" <[e-mail]>, "'James M. Polk'" <[e-mail]>, "'Tschofenig, Hannes (NSN - FI/Espoo)'" <[e-mail]>, "'ECRIT'" <[e-mail]>
Date: Thu, 5 Feb 2009 13:55:09 +0100
Thread-Topic: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)
Thread-Index: AcmHC6zIdbOQB6JfQPiKYW9Ra7nZyQACHzIwAAA6PeAAAC77kAAHa6OA
Message-ID: <[e-mail]>
References: <[e-mail]> <000801c98708$5973f6f0$[e-mail]> <[e-mail]> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$[e-mail]> <0a1101c98716$91287db0$b3797910$@net>
In-Reply-To: <0a1101c98716$91287db0$b3797910$@net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 12:55:44 -0000

Which is exactly what RFC 4412 specifies for all namespaces.

regards

Keith=20

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]=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:[e-mail]]
> > 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:[e-mail]]
> > >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: [e-mail] [mailto:[e-mail]]
> > >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
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/ecrit
> > >
>=20
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
> =


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4573A6849 for <[e-mail]>; Thu,  5 Feb 2009 11:05:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.362
X-Spam-Level: 
X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOrG03DSv7jd for <[e-mail]>; Thu,  5 Feb 2009 11:05:08 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 73AD43A67F0 for <[e-mail]>; Thu,  5 Feb 2009 11:05:04 -0800 (PST)
Received: (qmail invoked by alias); 05 Feb 2009 19:05:03 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp007) with SMTP; 05 Feb 2009 20:05:03 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1879u8+Csc76tpMXeNWY+JB2nxAmsmgDD3FhIDdAR kMRpbW9BNBKIUN
From: "Hannes Tschofenig" <[e-mail]>
To: "'DRAGE, Keith \(Keith\)'" <[e-mail]>, "'Brian Rosen'" <[e-mail]>, "'James M. Polk'" <[e-mail]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, "'ECRIT'" <[e-mail]>
References: <[e-mail]><000801c98708$5973f6f0$[e-mail]><[e-mail]><09fe01c98714$6acc7650$406562f0$@net><001c01c98715$3900b360$[e-mail]> <0a1101c98716$91287db0$b3797910$@net> <[e-mail]>
Date: Thu, 5 Feb 2009 21:05:47 +0200
Message-ID: <009701c987c4$c3cb7340$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: AcmHC6zIdbOQB6JfQPiKYW9Ra7nZyQACHzIwAAA6PeAAAC77kAAHa6OAACRAgtA=
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.5
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 19:05:09 -0000

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:[e-mail]] 
>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: [e-mail] [mailto:[e-mail]] 
>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:[e-mail]]
>> > 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:[e-mail]]
>> > >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: [e-mail] [mailto:[e-mail]]
>> > >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
>> > >> [e-mail]
>> > >> https://www.ietf.org/mailman/listinfo/ecrit
>> > >
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD723A69FB for <[e-mail]>; Thu,  5 Feb 2009 15:35:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.51
X-Spam-Level: 
X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi9c3UwUeyZA for <[e-mail]>; Thu,  5 Feb 2009 15:35:38 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D8D353A69B4 for <[e-mail]>; Thu,  5 Feb 2009 15:35:38 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,388,1231113600"; d="scan'208";a="243881667"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 05 Feb 2009 23:35:40 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n15NZepT013184;  Thu, 5 Feb 2009 15:35:40 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n15NZeC5020741; Thu, 5 Feb 2009 23:35:40 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 5 Feb 2009 15:35:40 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.21.185]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 5 Feb 2009 15:35:39 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 05 Feb 2009 17:35:39 -0600
To: "Hannes Tschofenig" <[e-mail]>, "'DRAGE, Keith \(Keith\)'" <[e-mail]>, "'Brian Rosen'" <[e-mail]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, "'ECRIT'" <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <009701c987c4$c3cb7340$[e-mail]>
References: <[e-mail]> <000801c98708$5973f6f0$[e-mail]> <[e-mail]> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$[e-mail]> <0a1101c98716$91287db0$b3797910$@net> <[e-mail]> <009701c987c4$c3cb7340$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 05 Feb 2009 23:35:39.0808 (UTC) FILETIME=[742EA200:01C987EA]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9792; t=1233876940; x=1234740940; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20ECRIT=20Virtual=20Interim=20Meeting=3A=20Agenda =20(RPH) |Sender:=20; bh=kfZfeRdow+mJ3/N0d4jHs7juucRkc+0JyWbHICF6udo=; b=PlG6xtJp/Jde3F57kXqt0wmNE/tBtMKmseRR9ZGpxF91aBYd1jN5O231sT lJvcXYTJPCReQ0BWsgK4YxDjhAOWf3bs/ObV0/pRU9XLmc58Bpi4cMmI2ZlZ gbB+lu1Q6wJTShIlgplev2VAwqKzGSa3qklNDQ79EyeAVw+sqA4Ew=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Subject: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 23:35:41 -0000

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:[e-mail]]
> >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: [e-mail] [mailto:[e-mail]]
> >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:[e-mail]]
> >> > 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:[e-mail]]
> >> > >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: [e-mail] [mailto:[e-mail]]
> >> > >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
> >> > >> [e-mail]
> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> > >
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3833A6AD0 for <[e-mail]>; Thu,  5 Feb 2009 17:51:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.147
X-Spam-Level: 
X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=0.102,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exUVQ7MU1jXM for <[e-mail]>; Thu,  5 Feb 2009 17:51:46 -0800 (PST)
Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id D60463A67B6 for <[e-mail]>; Thu,  5 Feb 2009 17:51:44 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n161pX4c007529 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Feb 2009 02:51:33 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 6 Feb 2009 02:51:33 +0100
From: "DRAGE, Keith (Keith)" <[e-mail]>
To: Hannes Tschofenig <[e-mail]>, "'Brian Rosen'" <[e-mail]>, "'James M. Polk'" <[e-mail]>, "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>, "'ECRIT'" <[e-mail]>
Date: Fri, 6 Feb 2009 02:51:33 +0100
Thread-Topic: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)
Thread-Index: AcmHC6zIdbOQB6JfQPiKYW9Ra7nZyQACHzIwAAA6PeAAAC77kAAHa6OAACRAgtAADBcUcA==
Message-ID: <[e-mail]>
References: <[e-mail]><000801c98708$5973f6f0$[e-mail]><[e-mail]><09fe01c98714$6acc7650$406562f0$@net><001c01c98715$3900b360$[e-mail]> <0a1101c98716$91287db0$b3797910$@net> <[e-mail]> <009701c987c4$c3cb7340$[e-mail]>
In-Reply-To: <009701c987c4$c3cb7340$[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 01:51:47 -0000

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:[e-mail]]=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:[e-mail]]
> >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: [e-mail] [mailto:[e-mail]]
> >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:[e-mail]]
> >> > 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:[e-mail]]
> >> > >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: [e-mail] [mailto:[e-mail]]
> >> > >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
> >> > >> [e-mail]
> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> > >
> >>=20
> >> _______________________________________________
> >> Ecrit mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>=20
> >
>=20
> =


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4C53A6B80 for <[e-mail]>; Fri,  6 Feb 2009 01:21:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.141
X-Spam-Level: 
X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, MANGLED_EMRG=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW1T8A3sEKl6 for <[e-mail]>; Fri,  6 Feb 2009 01:21:06 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BDD943A6AAF for <[e-mail]>; Fri,  6 Feb 2009 01:21:05 -0800 (PST)
Received: (qmail invoked by alias); 06 Feb 2009 09:21:06 -0000
Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp005) with SMTP; 06 Feb 2009 10:21:06 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+4nXgnSVa49Xu37j9pPNBaJPh5rDrgOHMiRMqzS9 lyqIH3phYSzVqy
From: "Hannes Tschofenig" <[e-mail]>
To: "'James M. Polk'" <[e-mail]>, "'DRAGE, Keith \(Keith\)'" <[e-mail]>, "'Brian Rosen'" <[e-mail]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, "'ECRIT'" <[e-mail]>
References: <[e-mail]> <000801c98708$5973f6f0$[e-mail]> <[e-mail]> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$[e-mail]> <0a1101c98716$91287db0$b3797910$@net> <[e-mail]> <009701c987c4$c3cb7340$[e-mail]> <[e-mail]>
Date: Fri, 6 Feb 2009 11:21:51 +0200
Message-ID: <000701c9883c$59b095d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
Thread-Index: AcmH6nV9SIaxjsjZSBKpW3CnAousqgATEoUg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.52
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 09:21:07 -0000

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:[e-mail]]
>> >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: [e-mail] [mailto:[e-mail]]
>> >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:[e-mail]]
>> >> > 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:[e-mail]]
>> >> > >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: [e-mail] [mailto:[e-mail]]
>> >> > >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
>> >> > >> [e-mail]
>> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> > >
>> >>
>> >> _______________________________________________
>> >> Ecrit mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >>
>> >
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802143A6BA0 for <[e-mail]>; Fri,  6 Feb 2009 01:22:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.242
X-Spam-Level: 
X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwuUuiX282qk for <[e-mail]>; Fri,  6 Feb 2009 01:22:51 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C51D73A6B8A for <[e-mail]>; Fri,  6 Feb 2009 01:22:50 -0800 (PST)
Received: (qmail invoked by alias); 06 Feb 2009 09:22:51 -0000
Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp026) with SMTP; 06 Feb 2009 10:22:51 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19KZdtMhrxKqQwVu8OAKsvb6NVqTHIaWb9BmKHiLW DN5EiY2huUqbzo
From: "Hannes Tschofenig" <[e-mail]>
To: "'DRAGE, Keith \(Keith\)'" <[e-mail]>, "'Brian Rosen'" <[e-mail]>, "'James M. Polk'" <[e-mail]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, "'ECRIT'" <[e-mail]>
References: <[e-mail]><000801c98708$5973f6f0$[e-mail]><[e-mail]><09fe01c98714$6acc7650$406562f0$@net><001c01c98715$3900b360$[e-mail]> <0a1101c98716$91287db0$b3797910$@net> <[e-mail]> <009701c987c4$c3cb7340$[e-mail]> <[e-mail]>
Date: Fri, 6 Feb 2009 11:23:38 +0200
Message-ID: <000901c9883c$989e8270$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
Thread-Index: AcmHC6zIdbOQB6JfQPiKYW9Ra7nZyQACHzIwAAA6PeAAAC77kAAHa6OAACRAgtAADBcUcAAR6zqA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.52
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my   mistake)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 09:22:52 -0000

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

>-----Original Message-----
>From: DRAGE, Keith (Keith) [mailto:[e-mail]] 
>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:[e-mail]]
>> 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:[e-mail]]
>> >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: [e-mail] [mailto:[e-mail]]
>> >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:[e-mail]]
>> >> > 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:[e-mail]]
>> >> > >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: [e-mail] [mailto:[e-mail]]
>> >> > >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
>> >> > >> [e-mail]
>> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> > >
>> >> 
>> >> _______________________________________________
>> >> Ecrit mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> 
>> >
>> 
>> 
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46D7328C104; Fri,  6 Feb 2009 04:11:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.955
X-Spam-Level: 
X-Spam-Status: No, score=-4.955 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_EMRG=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id traesnLZ3ZTJ; Fri,  6 Feb 2009 04:11:13 -0800 (PST)
Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id 5451D28C15C; Fri,  6 Feb 2009 04:11:13 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-9.tower-164.messagelabs.com!1233922271!19997187!2
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 20316 invoked from network); 6 Feb 2009 12:11:13 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-9.tower-164.messagelabs.com with AES256-SHA encrypted SMTP; 6 Feb 2009 12:11:13 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n16CBAj6007094; Fri, 6 Feb 2009 07:11:12 -0500
In-Reply-To: <000701c9883c$59b095d0$[e-mail]>
To: "Hannes Tschofenig" <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 6 Feb 2009 07:11:11 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/06/2009 07:13:34 AM, Serialize complete at 02/06/2009 07:13:34 AM
Content-Type: multipart/alternative; boundary="=_alternative 0042EC5F85257555_="
Cc: 'ECRIT' <[e-mail]>, [e-mail], "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 12:11:16 -0000

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.

[e-mail] 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:[e-mail]]
> >> >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: [e-mail] [mailto:[e-mail]]
> >> >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:[e-mail]]
> >> >> > 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:[e-mail]]
> >> >> > >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: [e-mail] [mailto:[e-mail]]
> >> >> > >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
> >> >> > >> [e-mail]
> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> > >
> >> >>
> >> >> _______________________________________________
> >> >> Ecrit mailing list
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>
> >> >
> >
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> 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>[e-mail] 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:[e-mail]]<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: [e-mail] [mailto:[e-mail]]<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:[e-mail]]<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:[e-mail]]<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: [e-mail] [mailto:[e-mail]]<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; [e-mail]<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; [e-mail]<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; [e-mail]<br>
&gt; https://www.ietf.org/mailman/listinfo/ecrit<br>
</tt></font>
--=_alternative 0042EC5F85257555_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB9028C1B1 for <[e-mail]>; Fri,  6 Feb 2009 05:06:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.111
X-Spam-Level: 
X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_00=-2.599, MANGLED_EMRG=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfLBpd3mMEaf for <[e-mail]>; Fri,  6 Feb 2009 05:06:29 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3D5EB28C10D for <[e-mail]>; Fri,  6 Feb 2009 05:06:29 -0800 (PST)
Received: (qmail invoked by alias); 06 Feb 2009 13:06:29 -0000
Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp025) with SMTP; 06 Feb 2009 14:06:29 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+vK4YNeKOvZ7io7Po99ho8RS9Q1m+rqO3S2qKUIh ama/lVPkv47o/q
From: "Hannes Tschofenig" <[e-mail]>
To: "'Janet P Gunn'" <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]> <[e-mail]>
Date: Fri, 6 Feb 2009 15:07:15 +0200
Message-ID: <001d01c9885b$d5d705d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
Thread-Index: AcmIVAF3NI3DU70UTkON98fIFS1CsgAB6cFg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.00
Cc: 'ECRIT' <[e-mail]>, [e-mail], "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 13:06:31 -0000

Who would define something that could prevent DoS problems? 

________________________________

	From: Janet P Gunn [mailto:[e-mail]] 
	Sent: 06 February, 2009 14:11
	To: Hannes Tschofenig
	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
[e-mail]; 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. 
	
	[e-mail] 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:[e-mail]]
	> >> >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: [e-mail] [mailto:[e-mail]]
	> >> >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:[e-mail]]
	> >> >> > 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:[e-mail]]
	> >> >> > >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: [e-mail]
[mailto:[e-mail]]
	> >> >> > >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
	> >> >> > >> [e-mail]
	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
	> >> >> > >
	> >> >>
	> >> >> _______________________________________________
	> >> >> Ecrit mailing list
	> >> >> [e-mail]
	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
	> >> >>
	> >> >
	> >
	> 
	> _______________________________________________
	> Ecrit mailing list
	> [e-mail]
	> https://www.ietf.org/mailman/listinfo/ecrit
	




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E763A6ACE for <[e-mail]>; Fri,  6 Feb 2009 05:47:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.769
X-Spam-Level: 
X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MANGLED_EMRG=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z37v8C7q6oUd for <[e-mail]>; Fri,  6 Feb 2009 05:47:02 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D7D933A6BA0 for <[e-mail]>; Fri,  6 Feb 2009 05:47:01 -0800 (PST)
Received: (qmail invoked by alias); 06 Feb 2009 13:40:21 -0000
Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp058) with SMTP; 06 Feb 2009 14:40:21 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+5zWBuKIC5TSq3BmyZUaFw20oO1NHcbz+/z9bLlq /wpG0UdersQBUa
From: "Hannes Tschofenig" <[e-mail]>
To: "'Hannes Tschofenig'" <[e-mail]>, "'Janet P Gunn'" <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]> <001d01c9885b$d5d705d0$[e-mail]>
Date: Fri, 6 Feb 2009 15:41:06 +0200
Message-ID: <001f01c98860$910658c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <001d01c9885b$d5d705d0$[e-mail]>
Thread-Index: AcmIVAF3NI3DU70UTkON98fIFS1CsgAB6cFgAAA2fKA=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.5
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, 'ECRIT' <[e-mail]>, [e-mail]
Subject: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 13:47:02 -0000

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: [e-mail] [mailto:[e-mail]] 
>On Behalf Of Hannes Tschofenig
>Sent: 06 February, 2009 15:07
>To: 'Janet P Gunn'
>Cc: 'ECRIT'; [e-mail]; 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:[e-mail]] 
>	Sent: 06 February, 2009 14:11
>	To: Hannes Tschofenig
>	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; 
>[e-mail]; 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. 
>	
>	[e-mail] 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:[e-mail]]
>	> >> >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: [e-mail] 
>[mailto:[e-mail]]
>	> >> >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:[e-mail]]
>	> >> >> > 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:[e-mail]]
>	> >> >> > >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: [e-mail] 
>[mailto:[e-mail]]
>	> >> >> > >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
>	> >> >> > >> [e-mail]
>	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>	> >> >> > >
>	> >> >>
>	> >> >> _______________________________________________
>	> >> >> Ecrit mailing list
>	> >> >> [e-mail]
>	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>	> >> >>
>	> >> >
>	> >
>	> 
>	> _______________________________________________
>	> Ecrit mailing list
>	> [e-mail]
>	> https://www.ietf.org/mailman/listinfo/ecrit
>	
>
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F653A6952; Fri,  6 Feb 2009 06:59:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.038
X-Spam-Level: 
X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=-1.339, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MANGLED_EMRG=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlqH5AEm5MFw; Fri,  6 Feb 2009 06:59:55 -0800 (PST)
Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id B09D93A63EB; Fri,  6 Feb 2009 06:59:55 -0800 (PST)
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1LVSBI-0004lo-V1; Fri, 06 Feb 2009 08:59:50 -0600
From: "Brian Rosen" <[e-mail]>
To: "'Hannes Tschofenig'" <[e-mail]>, "'Janet P Gunn'" <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]>	<001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]>
In-Reply-To: <001f01c98860$910658c0$[e-mail]>
Date: Fri, 6 Feb 2009 09:58:47 -0500
Message-ID: <0d6901c9886b$6c9bfc50$45d3f4f0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmIVAF3NI3DU70UTkON98fIFS1CsgAB6cFgAAA2fKAAAyK5gA==
Content-Language: en-us
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" <[e-mail]>, 'ECRIT' <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 14:59:58 -0000

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: [e-mail] [mailto:[e-mail]] 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-
> [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> >On Behalf Of Hannes Tschofenig
> >Sent: 06 February, 2009 15:07
> >To: 'Janet P Gunn'
> >Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
> >	Sent: 06 February, 2009 14:11
> >	To: Hannes Tschofenig
> >	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >[e-mail]; 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.
> >
> >	[e-mail] 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:[e-mail]]
> >	> >> >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: [e-mail]
> >[mailto:[e-mail]]
> >	> >> >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:[e-mail]]
> >	> >> >> > 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:[e-mail]]
> >	> >> >> > >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: [e-mail]
> >[mailto:[e-mail]]
> >	> >> >> > >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
> >	> >> >> > >> [e-mail]
> >	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >	> >> >> > >
> >	> >> >>
> >	> >> >> _______________________________________________
> >	> >> >> Ecrit mailing list
> >	> >> >> [e-mail]
> >	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >	> >> >>
> >	> >> >
> >	> >
> >	>
> >	> _______________________________________________
> >	> Ecrit mailing list
> >	> [e-mail]
> >	> https://www.ietf.org/mailman/listinfo/ecrit
> >
> >
> >
> >_______________________________________________
> >Ecrit mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ecrit
> >
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E12628C244 for <[e-mail]>; Fri,  6 Feb 2009 07:20:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.916
X-Spam-Level: 
X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MANGLED_EMRG=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEivgLPr816d for <[e-mail]>; Fri,  6 Feb 2009 07:20:00 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CA28928C23E for <[e-mail]>; Fri,  6 Feb 2009 07:19:59 -0800 (PST)
Received: (qmail invoked by alias); 06 Feb 2009 15:20:00 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp015) with SMTP; 06 Feb 2009 16:20:00 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19fgg8Xf9dfRqd8yGSdCxL/mJ6nsw9MJyc2KkD0Z2 eIiQg2WbgEIES8
From: "Hannes Tschofenig" <[e-mail]>
To: "'Brian Rosen'" <[e-mail]>, "'Janet P Gunn'" <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]>	<001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net>
Date: Fri, 6 Feb 2009 17:20:47 +0200
Message-ID: <003001c9886e$7d133280$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <0d6901c9886b$6c9bfc50$45d3f4f0$@net>
Thread-Index: AcmIVAF3NI3DU70UTkON98fIFS1CsgAB6cFgAAA2fKAAAyK5gAAA8CeQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.5
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 15:20:02 -0000

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: [e-mail] [mailto:[e-mail]] 
>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- 
>> [e-mail]
>> 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: [e-mail] [mailto:[e-mail]] On 
>> >Behalf Of Hannes Tschofenig
>> >Sent: 06 February, 2009 15:07
>> >To: 'Janet P Gunn'
>> >Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
>> >	Sent: 06 February, 2009 14:11
>> >	To: Hannes Tschofenig
>> >	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; 
>> >[e-mail]; 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.
>> >
>> >	[e-mail] 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:[e-mail]]
>> >	> >> >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: [e-mail] 
>[mailto:[e-mail]]
>> >	> >> >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:[e-mail]]
>> >	> >> >> > 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:[e-mail]]
>> >	> >> >> > >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: [e-mail] 
>> >[mailto:[e-mail]]
>> >	> >> >> > >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
>> >	> >> >> > >> [e-mail]
>> >	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>> >	> >> >> > >
>> >	> >> >>
>> >	> >> >> _______________________________________________
>> >	> >> >> Ecrit mailing list
>> >	> >> >> [e-mail]
>> >	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >	> >> >>
>> >	> >> >
>> >	> >
>> >	>
>> >	> _______________________________________________
>> >	> Ecrit mailing list
>> >	> [e-mail]
>> >	> https://www.ietf.org/mailman/listinfo/ecrit
>> >
>> >
>> >
>> >_______________________________________________
>> >Ecrit mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/ecrit
>> >
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6462A3A69BB for <[e-mail]>; Fri,  6 Feb 2009 07:33:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level: 
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HujnSDzAR6AL for <[e-mail]>; Fri,  6 Feb 2009 07:33:38 -0800 (PST)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 23B3528C138 for <[e-mail]>; Fri,  6 Feb 2009 07:33:38 -0800 (PST)
Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n16FXSO3016622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Feb 2009 10:33:28 -0500 (EST)
Message-Id: <[e-mail]>
From: Henning Schulzrinne <[e-mail]>
To: "Hannes Tschofenig" <[e-mail]>
In-Reply-To: <003001c9886e$7d133280$[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 6 Feb 2009 10:33:28 -0500
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]>	<001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 15:33:40 -0000

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: [e-mail] [mailto:[e-mail]]
>> 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-
>>> [e-mail]
>>> 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: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Hannes Tschofenig
>>>> Sent: 06 February, 2009 15:07
>>>> To: 'Janet P Gunn'
>>>> Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
>>>> 	Sent: 06 February, 2009 14:11
>>>> 	To: Hannes Tschofenig
>>>> 	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
>>>> [e-mail]; 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.
>>>>
>>>> 	[e-mail] 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:[e-mail]]
>>>> 	> >> >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: [e-mail]
>> [mailto:[e-mail]]
>>>> 	> >> >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:[e-mail]]
>>>> 	> >> >> > 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:[e-mail]]
>>>> 	> >> >> > >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: [e-mail]
>>>> [mailto:[e-mail]]
>>>> 	> >> >> > >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
>>>> 	> >> >> > >> [e-mail]
>>>> 	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>>>> 	> >> >> > >
>>>> 	> >> >>
>>>> 	> >> >> _______________________________________________
>>>> 	> >> >> Ecrit mailing list
>>>> 	> >> >> [e-mail]
>>>> 	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>>>> 	> >> >>
>>>> 	> >> >
>>>> 	> >
>>>> 	>
>>>> 	> _______________________________________________
>>>> 	> Ecrit mailing list
>>>> 	> [e-mail]
>>>> 	> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>
>>> _______________________________________________
>>> Ecrit mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DE828C22F for <[e-mail]>; Fri,  6 Feb 2009 07:50:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.159
X-Spam-Level: 
X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-MjRBuqvX49 for <[e-mail]>; Fri,  6 Feb 2009 07:50:38 -0800 (PST)
Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id F0F2528C0FF for <[e-mail]>; Fri,  6 Feb 2009 07:50:37 -0800 (PST)
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1LVSyN-0008NS-FX; Fri, 06 Feb 2009 09:50:32 -0600
From: "Brian Rosen" <[e-mail]>
To: "'Henning Schulzrinne'" <[e-mail]>, "'Hannes Tschofenig'" <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]>	<001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 6 Feb 2009 10:49:19 -0500
Message-ID: <0d9101c98872$7b2129b0$71637d10$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmIcEMWynRMTvqBQWy4A3ghfLDfOQAALFXw
Content-Language: en-us
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" <[e-mail]>, 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 15:50:40 -0000

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:[e-mail]]
> 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: [e-mail] [mailto:[e-mail]]
> >> 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-
> >>> [e-mail]
> >>> 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: [e-mail] [mailto:[e-mail]] On
> >>>> Behalf Of Hannes Tschofenig
> >>>> Sent: 06 February, 2009 15:07
> >>>> To: 'Janet P Gunn'
> >>>> Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
> >>>> 	Sent: 06 February, 2009 14:11
> >>>> 	To: Hannes Tschofenig
> >>>> 	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >>>> [e-mail]; 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.
> >>>>
> >>>> 	[e-mail] 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:[e-mail]]
> >>>> 	> >> >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: [e-mail]
> >> [mailto:[e-mail]]
> >>>> 	> >> >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:[e-mail]]
> >>>> 	> >> >> > 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:[e-mail]]
> >>>> 	> >> >> > >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: [e-mail]
> >>>> [mailto:[e-mail]]
> >>>> 	> >> >> > >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
> >>>> 	> >> >> > >> [e-mail]
> >>>> 	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>> 	> >> >> > >
> >>>> 	> >> >>
> >>>> 	> >> >> _______________________________________________
> >>>> 	> >> >> Ecrit mailing list
> >>>> 	> >> >> [e-mail]
> >>>> 	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>> 	> >> >>
> >>>> 	> >> >
> >>>> 	> >
> >>>> 	>
> >>>> 	> _______________________________________________
> >>>> 	> Ecrit mailing list
> >>>> 	> [e-mail]
> >>>> 	> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Ecrit mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>
> >>>
> >>> _______________________________________________
> >>> Ecrit mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >
> > _______________________________________________
> > Ecrit mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ecrit
> >



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC0928C112 for <[e-mail]>; Fri,  6 Feb 2009 07:58:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.851
X-Spam-Level: 
X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+dZwqxOceqz for <[e-mail]>; Fri,  6 Feb 2009 07:58:21 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 3358728C0FB for <[e-mail]>; Fri,  6 Feb 2009 07:58:02 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n16FvnM7031701 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Feb 2009 16:57:49 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 6 Feb 2009 16:57:49 +0100
From: "DRAGE, Keith (Keith)" <[e-mail]>
To: Henning Schulzrinne <[e-mail]>, Hannes Tschofenig <[e-mail]>
Date: Fri, 6 Feb 2009 16:57:47 +0100
Thread-Topic: [Ecrit] RPH
Thread-Index: AcmIcFpkoHyDmBXoS2CnsbC/fahubQAAEjQg
Message-ID: <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]> <001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 15:58:23 -0000

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: [e-mail] [mailto:[e-mail]]
> 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: [e-mail] [mailto:[e-mail]]
> >> 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-
> >>> [e-mail]
> >>> 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: [e-mail] [mailto:[e-mail]] On
> >>>> Behalf Of Hannes Tschofenig
> >>>> Sent: 06 February, 2009 15:07
> >>>> To: 'Janet P Gunn'
> >>>> Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
> >>>>  Sent: 06 February, 2009 14:11
> >>>>  To: Hannes Tschofenig
> >>>>  Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >>>> [e-mail]; 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.
> >>>>
> >>>>  [e-mail] 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:[e-mail]]
> >>>>  > >> >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: [e-mail]
> >> [mailto:[e-mail]]
> >>>>  > >> >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:[e-mail]]
> >>>>  > >> >> > 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:[e-mail]]
> >>>>  > >> >> > >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: [e-mail]
> >>>> [mailto:[e-mail]]
> >>>>  > >> >> > >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
> >>>>  > >> >> > >> [e-mail]
> >>>>  > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>  > >> >> > >
> >>>>  > >> >>
> >>>>  > >> >> _______________________________________________
> >>>>  > >> >> Ecrit mailing list
> >>>>  > >> >> [e-mail]
> >>>>  > >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>  > >> >>
> >>>>  > >> >
> >>>>  > >
> >>>>  >
> >>>>  > _______________________________________________
> >>>>  > Ecrit mailing list
> >>>>  > [e-mail]
> >>>>  > https://www.ietf.org/mailman/listinfo/ecrit
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Ecrit mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>
> >>>
> >>> _______________________________________________
> >>> Ecrit mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >
> > _______________________________________________
> > Ecrit mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ecrit
> >
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183333A6BB5 for <[e-mail]>; Fri,  6 Feb 2009 10:32:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.056
X-Spam-Level: 
X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE3dgLKgBcxG for <[e-mail]>; Fri,  6 Feb 2009 10:32:38 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EFCAB3A69C0 for <[e-mail]>; Fri,  6 Feb 2009 10:32:37 -0800 (PST)
Received: (qmail invoked by alias); 06 Feb 2009 18:32:38 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp052) with SMTP; 06 Feb 2009 19:32:38 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX181n4QKXas1czwaLgTRJDO9Gkx56Sq9ppUAOLz+uV 9os9mbjs9GOWCT
From: "Hannes Tschofenig" <[e-mail]>
To: "'Brian Rosen'" <[e-mail]>, "'Henning Schulzrinne'" <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]>	<001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]> <0d9101c98872$7b2129b0$71637d10$@net>
Date: Fri, 6 Feb 2009 20:33:25 +0200
Message-ID: <003d01c98889$666c23f0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <0d9101c98872$7b2129b0$71637d10$@net>
Thread-Index: AcmIcEMWynRMTvqBQWy4A3ghfLDfOQAALFXwAAXxMbA=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.49
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 18:32:41 -0000

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:[e-mail]] 
>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:[e-mail]]
>> 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: [e-mail] [mailto:[e-mail]]
>> >> 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- 
>> >>> [e-mail]
>> >>> 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: [e-mail] [mailto:[e-mail]] On 
>> >>>> Behalf Of Hannes Tschofenig
>> >>>> Sent: 06 February, 2009 15:07
>> >>>> To: 'Janet P Gunn'
>> >>>> Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
>> >>>> 	Sent: 06 February, 2009 14:11
>> >>>> 	To: Hannes Tschofenig
>> >>>> 	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; 
>> >>>> [e-mail]; 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.
>> >>>>
>> >>>> 	[e-mail] 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:[e-mail]]
>> >>>> 	> >> >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: [e-mail]
>> >> [mailto:[e-mail]]
>> >>>> 	> >> >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:[e-mail]]
>> >>>> 	> >> >> > 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:[e-mail]]
>> >>>> 	> >> >> > >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: [e-mail] 
>> >>>> [mailto:[e-mail]]
>> >>>> 	> >> >> > >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
>> >>>> 	> >> >> > >> [e-mail]
>> >>>> 	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>> >>>> 	> >> >> > >
>> >>>> 	> >> >>
>> >>>> 	> >> >> _______________________________________________
>> >>>> 	> >> >> Ecrit mailing list
>> >>>> 	> >> >> [e-mail]
>> >>>> 	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >>>> 	> >> >>
>> >>>> 	> >> >
>> >>>> 	> >
>> >>>> 	>
>> >>>> 	> _______________________________________________
>> >>>> 	> Ecrit mailing list
>> >>>> 	> [e-mail]
>> >>>> 	> https://www.ietf.org/mailman/listinfo/ecrit
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Ecrit mailing list
>> >>>> [e-mail]
>> >>>> https://www.ietf.org/mailman/listinfo/ecrit
>> >>>>
>> >>>
>> >>> _______________________________________________
>> >>> Ecrit mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/ecrit
>> >>
>> >
>> > _______________________________________________
>> > Ecrit mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ecrit
>> >
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A10C3A68F9 for <[e-mail]>; Fri,  6 Feb 2009 12:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.903
X-Spam-Level: 
X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mankdJmhyBkg for <[e-mail]>; Fri,  6 Feb 2009 12:03:40 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 2B8A33A67D6 for <[e-mail]>; Fri,  6 Feb 2009 12:01:58 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2009_02_06_14_21_10
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 06 Feb 2009 14:21:10 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 14:01:58 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 6 Feb 2009 14:01:37 -0600
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] RPH
Thread-Index: AcmIcEMWynRMTvqBQWy4A3ghfLDfOQAALFXwAAXxMbAAAz+/Jg==
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]>	<001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$[e-mail]>
From: "Winterbottom, James" <[e-mail]>
To: "Hannes Tschofenig" <[e-mail]>, "Brian Rosen" <[e-mail]>, "Henning Schulzrinne" <[e-mail]>
X-OriginalArrivalTime: 06 Feb 2009 20:01:58.0812 (UTC) FILETIME=[C4AFA5C0:01C98895]
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 20:03:43 -0000

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: [e-mail] 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:[e-mail]]=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:[e-mail]]=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: [e-mail] [mailto:[e-mail]]=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>> >>> [e-mail]=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=
[e-mail] [mailto:[e-mail]] 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'; [e-mail]; =
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:[e-mail]]=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=
[e-mail] 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:[e-mail]]=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: [e-mail]=0D=
=0A>> >> [mailto:[e-mail]]=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:[e-mail]]=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:[e-mail]]=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: [e-mail]=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> >> >> > >> [e-mail]=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> >> >>=
 [e-mail]=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> [e-mail]=
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>> >>>> [e-mail]=0D=
=0A>> >>>> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>> >>>>=0D=0A>>=
 >>>=0D=0A>> >>> _______________________________________________=0D=0A>> >>=
> Ecrit mailing list=0D=0A>> >>> [e-mail]=0D=0A>> >>> https://www.iet=
f.org/mailman/listinfo/ecrit=0D=0A>> >>=0D=0A>> >=0D=0A>> > _______________=
________________________________=0D=0A>> > Ecrit mailing list=0D=0A>> > Ecr=
[e-mail]=0D=0A>> > https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>> >=0D=
=0A>=0D=0A=0D=0A_______________________________________________=0D=0AEcrit =
mailing list=0D=[e-mail]=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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5353A672F for <[e-mail]>; Fri,  6 Feb 2009 13:05:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHW27wzsManm for <[e-mail]>; Fri,  6 Feb 2009 13:05:16 -0800 (PST)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id CD1293A6C18 for <[e-mail]>; Fri,  6 Feb 2009 13:05:15 -0800 (PST)
Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n16L572d001433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Feb 2009 16:05:08 -0500 (EST)
Message-Id: <[e-mail]>
From: Henning Schulzrinne <[e-mail]>
To: "Winterbottom, James" <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 6 Feb 2009 16:05:07 -0500
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]>	<001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 21:05:18 -0000

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: [e-mail] 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:[e-mail]]
>> 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:[e-mail]]
>>> 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: [e-mail] [mailto:[e-mail]]
>>>>> 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-
>>>>>> [e-mail]
>>>>>> 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: [e-mail] [mailto:[e-mail]] On
>>>>>>> Behalf Of Hannes Tschofenig
>>>>>>> Sent: 06 February, 2009 15:07
>>>>>>> To: 'Janet P Gunn'
>>>>>>> Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
>>>>>>> 	Sent: 06 February, 2009 14:11
>>>>>>> 	To: Hannes Tschofenig
>>>>>>> 	Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
>>>>>>> [e-mail]; 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.
>>>>>>>
>>>>>>> 	[e-mail] 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:[e-mail]]
>>>>>>> 	> >> >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: [e-mail]
>>>>> [mailto:[e-mail]]
>>>>>>> 	> >> >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:[e-mail]]
>>>>>>> 	> >> >> > 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:[e-mail]]
>>>>>>> 	> >> >> > >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: [e-mail]
>>>>>>> [mailto:[e-mail]]
>>>>>>> 	> >> >> > >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
>>>>>>> 	> >> >> > >> [e-mail]
>>>>>>> 	> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>> 	> >> >> > >
>>>>>>> 	> >> >>
>>>>>>> 	> >> >> _______________________________________________
>>>>>>> 	> >> >> Ecrit mailing list
>>>>>>> 	> >> >> [e-mail]
>>>>>>> 	> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>> 	> >> >>
>>>>>>> 	> >> >
>>>>>>> 	> >
>>>>>>> 	>
>>>>>>> 	> _______________________________________________
>>>>>>> 	> Ecrit mailing list
>>>>>>> 	> [e-mail]
>>>>>>> 	> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ecrit mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ecrit mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> 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]
>
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCB53A6830 for <[e-mail]>; Fri,  6 Feb 2009 13:27:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.897
X-Spam-Level: 
X-Spam-Status: No, score=-102.897 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahgz6SFXSdai for <[e-mail]>; Fri,  6 Feb 2009 13:27:55 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BD6873A6BF1 for <[e-mail]>; Fri,  6 Feb 2009 13:27:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[e-mail]; q=dns/txt; s=qcdkim; t=1233955678; x=1265491678; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20<p0624080ac5b25a5b6f64 @[10.227.68.59]>|In-Reply-To:=20<28F08C20-0FCC-4E0D-953D- [e-mail]>|References:=20<000701c9883c $59b095d0$[e-mail]><OFB3ABC009.AA6A83E9-ON85 257=0D=0A=[e-mail]>=0D=0A =20<001d01c9885b$d5d705d0$[e-mail]>=0D=0A=20 <001f01c98860$910658c0$[e-mail]>=0D=0A=20<0d 6901c9886b$6c9bfc50$45d3f4f0$@net>=0D=0A=20<003001c9886e$ 7d133280$[e-mail]>=0D=0A=20<1CC6E7BB-98D9-4D [e-mail]>=0D=0A=20<0d9101c988 72$7b2129b0$71637d10$@net>=0D=0A=20<003d01c98889$666c23f0 $[e-mail]>=0D=0A=20<E51D5B15BFDEFD448F90BDD1 [e-mail]>=0D=0A=20<28F08C20-0FC [e-mail]>|Date:=20Fri,=20 6=20Feb=202009=2013:27:54=20-0800|To:=20Henning=20Schulzr inne=20<[e-mail]>,=0D=0A=20=20=20=20=20=20=20 =20"Winterbottom,=20James"=0D=0A=09<James.Winterbottom@an drew.com>|From:=20Ted=20Hardie=20<[e-mail]> |Subject:=20Re:=20[Ecrit]=20RPH|CC:=20"Tschofenig,=20Hann es=20(NSN=20-=20FI/Espoo)"=20<[e-mail]>, =0D=0A=20=20=20=20=20=20=20=20ECRIT=0D=0A=09<ecrit@ietf.o rg>|Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5518"=3B=20a =3D"15283026"; bh=dI6hFXVYKK8jVWL6Z2F5EWYMSkXcsNAGExiDIiGP6JE=; b=Qi9F/0nPS9by6bUjCvRpPTLzqZTByU69yBepCeqe13bMQnMd1s0TjPdF 6r0Fej54KQPz42o8G+kczn5AuDDkNounMLVGE9vKk2E+JBbSiRsNbRfDq CoSWxBW/miI+aRmkIBVOUfweH8pkrNO9XYNUnnvNBjW6R7Cj6F7NMGDwI E=;
X-IronPort-AV: E=McAfee;i="5100,188,5518"; a="15283026"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Feb 2009 13:27:58 -0800
Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n16LRvUG024349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Feb 2009 13:27:58 -0800
Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n16LRvR8014564 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Feb 2009 13:27:57 -0800
Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 6 Feb 2009 13:27:56 -0800
Received: from [10.227.68.59] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 6 Feb 2009 13:27:56 -0800
MIME-Version: 1.0
Message-ID: <p0624080ac5b25a5b6f64@[10.227.68.59]>
In-Reply-To: <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]><OFB3ABC009.AA6A83E9-ON85257 [e-mail]> <001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 6 Feb 2009 13:27:54 -0800
To: Henning Schulzrinne <[e-mail]>, "Winterbottom, James" <[e-mail]>
From: Ted Hardie <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 21:27:58 -0000

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: [e-mail] 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:[e-mail]]
>>> 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:[e-mail]]
>>>> 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: [e-mail] [mailto:[e-mail]]
>>>>>> 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-
>>>>>>> [e-mail]
>>>>>>> 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: [e-mail] [mailto:[e-mail]] On
>>>>>>>> Behalf Of Hannes Tschofenig
>>>>>>>> Sent: 06 February, 2009 15:07
>>>>>>>> To: 'Janet P Gunn'
>>>>>>>> Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
>>>>>>>>         Sent: 06 February, 2009 14:11
>>>>>>>>         To: Hannes Tschofenig
>>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
>>>>>>>> [e-mail]; 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.
>>>>>>>>
>>>>>>>>         [e-mail] 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:[e-mail]]
>>>>>>>>         > >> >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: [e-mail]
>>>>>> [mailto:[e-mail]]
>>>>>>>>         > >> >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:[e-mail]]
>>>>>>>>         > >> >> > 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:[e-mail]]
>>>>>>>>         > >> >> > >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: [e-mail]
>>>>>>>> [mailto:[e-mail]]
>>>>>>>>         > >> >> > >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
>>>>>>>>         > >> >> > >> [e-mail]
>>>>>>>>         > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>         > >> >> > >
>>>>>>>>         > >> >>
>>>>>>>>         > >> >> _______________________________________________
>>>>>>>>         > >> >> Ecrit mailing list
>>>>>>>>         > >> >> [e-mail]
>>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>         > >> >>
>>>>>>>>         > >> >
>>>>>>>>         > >
>>>>>>>>         >
>>>>>>>>         > _______________________________________________
>>>>>>>>         > Ecrit mailing list
>>>>>>>>         > [e-mail]
>>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Ecrit mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ecrit mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 822B73A6C99 for <[e-mail]>; Fri,  6 Feb 2009 13:45:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.213
X-Spam-Level: 
X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EuuXmKTeZSl for <[e-mail]>; Fri,  6 Feb 2009 13:45:31 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 984963A6C98 for <[e-mail]>; Fri,  6 Feb 2009 13:45:31 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,393,1231113600"; d="scan'208";a="244561666"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 06 Feb 2009 21:45:34 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n16LjYiP012326;  Fri, 6 Feb 2009 13:45:34 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n16LjYdk018704; Fri, 6 Feb 2009 21:45:34 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 13:45:34 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 13:45:33 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 06 Feb 2009 15:45:31 -0600
To: "Winterbottom, James" <[e-mail]>, "Hannes Tschofenig" <[e-mail]>, "Brian Rosen" <[e-mail]>, "Henning Schulzrinne" <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <[e-mail] >
References: <000701c9883c$59b095d0$[e-mail]> <[e-mail]> <001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 06 Feb 2009 21:45:33.0083 (UTC) FILETIME=[3CAE26B0:01C988A4]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=39306; t=1233956734; x=1234820734; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=rpZz1nwFoCX2w4go9/8q0n6vY+EknWVMTPU8wXBfK6s=; b=TMtJQZYIEbTZooafjPZGBq68X18bK/bjoCWTFZzwHyCVdNhxvPaC5eDBPA 83sFTyv07UNYUT62pZk3t4xvDKTnp7yZd63nqIxHbQwzOf26+NsybWpX0vlP Sn3d9XnR3O;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 21:45:34 -0000

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: [e-mail] 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:[e-mail]]
> >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:[e-mail]]
> >> 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: [e-mail] [mailto:[e-mail]]
> >> >> 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-
> >> >>> [e-mail]
> >> >>> 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: [e-mail] [mailto:[e-mail]] On
> >> >>>> Behalf Of Hannes Tschofenig
> >> >>>> Sent: 06 February, 2009 15:07
> >> >>>> To: 'Janet P Gunn'
> >> >>>> Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
> >> >>>>         Sent: 06 February, 2009 14:11
> >> >>>>         To: Hannes Tschofenig
> >> >>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >> >>>> [e-mail]; 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.
> >> >>>>
> >> >>>>         [e-mail] 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:[e-mail]]
> >> >>>>         > >> >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: [e-mail]
> >> >> [mailto:[e-mail]]
> >> >>>>         > >> >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:[e-mail]]
> >> >>>>         > >> >> > 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:[e-mail]]
> >> >>>>         > >> >> > >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: [e-mail]
> >> >>>> [mailto:[e-mail]]
> >> >>>>         > >> >> > >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
> >> >>>>         > >> >> > >> [e-mail]
> >> >>>>         > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>         > >> >> > >
> >> >>>>         > >> >>
> >> >>>>         > >> >> _______________________________________________
> >> >>>>         > >> >> Ecrit mailing list
> >> >>>>         > >> >> [e-mail]
> >> >>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>         > >> >>
> >> >>>>         > >> >
> >> >>>>         > >
> >> >>>>         >
> >> >>>>         > _______________________________________________
> >> >>>>         > Ecrit mailing list
> >> >>>>         > [e-mail]
> >> >>>>         > https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> Ecrit mailing list
> >> >>>> [e-mail]
> >> >>>> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> Ecrit mailing list
> >> >>> [e-mail]
> >> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>
> >> >
> >> > _______________________________________________
> >> > Ecrit mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/ecrit
> >> >
> >
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E8B93A6BE7 for <[e-mail]>; Fri,  6 Feb 2009 14:02:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.357
X-Spam-Level: 
X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_00=-2.599, MANGLED_EMRG=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrFIJHIDCMig for <[e-mail]>; Fri,  6 Feb 2009 14:02:12 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7F8263A6B3A for <[e-mail]>; Fri,  6 Feb 2009 14:02:12 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,393,1231113600"; d="scan'208";a="244570757"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Feb 2009 22:02:15 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n16M2F8I020926;  Fri, 6 Feb 2009 14:02:15 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n16M2CWr003346; Fri, 6 Feb 2009 22:02:15 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 14:02:05 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 14:02:04 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 06 Feb 2009 16:02:03 -0600
To: "Hannes Tschofenig" <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <000701c9883c$59b095d0$[e-mail]>
References: <[e-mail]> <000801c98708$5973f6f0$[e-mail]> <[e-mail]> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$[e-mail]> <0a1101c98716$91287db0$b3797910$@net> <[e-mail]> <009701c987c4$c3cb7340$[e-mail]> <[e-mail]> <000701c9883c$59b095d0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 06 Feb 2009 22:02:04.0218 (UTC) FILETIME=[8B7159A0:01C988A6]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15988; t=1233957735; x=1234821735; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20RE=3A=20ECRIT=20Virtual=20Interim=20Meeting=3A= 20Agenda=20(RPH=20&=20GETS) |Sender:=20; bh=HJStnRQiVuDODg7u1VphD2K/NazdySUsYyry+cclws0=; b=kZXyEJwiuNDzcIa/WXUzyKJ0EXna7TmK+Rfw3695a/cEh/lubSTOEh2fqf KQAt5gaXkq+CTpTWZKDPXKLIx8zqRl1Rh5BWFVd0CpvaUz3HM8xsN7ppfxhy sFYu6A+Zkc;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 22:02:14 -0000

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:[e-mail]]
> >> >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: [e-mail] [mailto:[e-mail]]
> >> >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:[e-mail]]
> >> >> > 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:[e-mail]]
> >> >> > >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: [e-mail] [mailto:[e-mail]]
> >> >> > >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
> >> >> > >> [e-mail]
> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> > >
> >> >>
> >> >> _______________________________________________
> >> >> Ecrit mailing list
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>
> >> >
> >



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FC833A6BBF for <[e-mail]>; Fri,  6 Feb 2009 14:05:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhiYMYsvNnLx for <[e-mail]>; Fri,  6 Feb 2009 14:05:30 -0800 (PST)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id BFC4E3A680C for <[e-mail]>; Fri,  6 Feb 2009 14:05:26 -0800 (PST)
Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n16M5L8i018882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Feb 2009 17:05:22 -0500 (EST)
Message-Id: <[e-mail]>
From: Henning Schulzrinne <[e-mail]>
To: "James M. Polk" <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 6 Feb 2009 17:05:21 -0500
References: <000701c9883c$59b095d0$[e-mail]> <[e-mail]> <001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 22:05:31 -0000

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
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9ECC3A68C5 for <[e-mail]>; Fri,  6 Feb 2009 14:10:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.176
X-Spam-Level: 
X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svcc3a577S2e for <[e-mail]>; Fri,  6 Feb 2009 14:10:08 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BAAC13A6C98 for <[e-mail]>; Fri,  6 Feb 2009 14:10:08 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,393,1231113600"; d="scan'208";a="62595908"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 06 Feb 2009 22:10:10 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n16MAAn1009610;  Fri, 6 Feb 2009 14:10:10 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n16MAAYm002873; Fri, 6 Feb 2009 22:10:10 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 14:10:10 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 14:10:09 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 06 Feb 2009 16:10:08 -0600
To: Henning Schulzrinne <[e-mail]>, "Winterbottom, James" <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]> <[e-mail]> <001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 06 Feb 2009 22:10:09.0545 (UTC) FILETIME=[ACB85F90:01C988A7]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=38659; t=1233958210; x=1234822210; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=+SWbe6rJ2FfVHQVmJJlsblVAbZ6D6LBZwahNyO4OaaQ=; b=gPS3YlsvXA++rh51sJqhfjidCiCy47vcFCiX6Qh9kwm/WihTGYkJ2Ts7rM lA6xFjZ99XCraen5cxYfQLdOhAw9wTyKmzyvIeYolq8MveO+qX51Wzvl1909 86PLlU0YYr;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 22:10:13 -0000

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: [e-mail] 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:[e-mail]]
>>>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:[e-mail]]
>>>>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: [e-mail] [mailto:[e-mail]]
>>>>>>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-
>>>>>>>[e-mail]
>>>>>>>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: [e-mail] [mailto:[e-mail]] On
>>>>>>>>Behalf Of Hannes Tschofenig
>>>>>>>>Sent: 06 February, 2009 15:07
>>>>>>>>To: 'Janet P Gunn'
>>>>>>>>Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
>>>>>>>>         Sent: 06 February, 2009 14:11
>>>>>>>>         To: Hannes Tschofenig
>>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
>>>>>>>>[e-mail]; 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.
>>>>>>>>
>>>>>>>>         [e-mail] 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:[e-mail]]
>>>>>>>>         > >> >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: [e-mail]
>>>>>>[mailto:[e-mail]]
>>>>>>>>         > >> >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:[e-mail]]
>>>>>>>>         > >> >> > 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:[e-mail]]
>>>>>>>>         > >> >> > >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: [e-mail]
>>>>>>>>[mailto:[e-mail]]
>>>>>>>>         > >> >> > >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
>>>>>>>>         > >> >> > >> [e-mail]
>>>>>>>>         > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>         > >> >> > >
>>>>>>>>         > >> >>
>>>>>>>>         > >> >> _______________________________________________
>>>>>>>>         > >> >> Ecrit mailing list
>>>>>>>>         > >> >> [e-mail]
>>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>         > >> >>
>>>>>>>>         > >> >
>>>>>>>>         > >
>>>>>>>>         >
>>>>>>>>         > _______________________________________________
>>>>>>>>         > Ecrit mailing list
>>>>>>>>         > [e-mail]
>>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>_______________________________________________
>>>>>>>>Ecrit mailing list
>>>>>>>>[e-mail]
>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>Ecrit mailing list
>>>>>>>[e-mail]
>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>>>_______________________________________________
>>>>>Ecrit mailing list
>>>>>[e-mail]
>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>
>>_______________________________________________
>>Ecrit mailing list
>>[e-mail]
>>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789B03A6C3B for <[e-mail]>; Fri,  6 Feb 2009 14:14:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level: 
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O18MdrwZwQ28 for <[e-mail]>; Fri,  6 Feb 2009 14:14:50 -0800 (PST)
Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id E869A3A6B08 for <[e-mail]>; Fri,  6 Feb 2009 14:14:49 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-129.messagelabs.com!1233958490!26260472!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 27894 invoked from network); 6 Feb 2009 22:14:50 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-3.tower-129.messagelabs.com with AES256-SHA encrypted SMTP; 6 Feb 2009 22:14:50 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n16MEnI0006482; Fri, 6 Feb 2009 17:14:49 -0500
Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n16MEl0r006470; Fri, 6 Feb 2009 17:14:47 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Fri, 6 Feb 2009 17:14:46 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] RPH
Thread-Index: AcmIp7cDTjOFrFzQSeSaJoip38DOVgAAJrgu
From: "DOLLY, MARTIN C, ATTLABS" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 22:14:53 -0000

WW91IGNhbiBub3QgZGlzYWxsb3cgdGhpcyBmcm9tIGFuIFVFLiBUaGUgdHJ1c3QgcmVsYXRpb25z
aGlwIHdpbGwgZGljdGF0ZSB3aGV0aGVyIGl0IGlzIGFjY2VwdGVkIG9yIG5vdA0KDQotLS0tLSBP
cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIDxlY3Jp
dC1ib3VuY2VzQGlldGYub3JnPg0KVG86IEhlbm5pbmcgU2NodWx6cmlubmUgPGhnc0Bjcy5jb2x1
bWJpYS5lZHU+OyBXaW50ZXJib3R0b20sIEphbWVzIDxKYW1lcy5XaW50ZXJib3R0b21AYW5kcmV3
LmNvbT4NCkNjOiBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0VzcG9vKSA8aGFubmVzLnRz
Y2hvZmVuaWdAbnNuLmNvbT47IEVDUklUIDxlY3JpdEBpZXRmLm9yZz4NClNlbnQ6IEZyaSBGZWIg
MDYgMTc6MTA6MDggMjAwOQ0KU3ViamVjdDogUmU6IFtFY3JpdF0gUlBIDQoNCkF0IDAzOjA1IFBN
IDIvNi8yMDA5LCBIZW5uaW5nIFNjaHVsenJpbm5lIHdyb3RlOg0KPlRoZXJlJ3MgYW5vdGhlciBw
cm9ibGVtIHdpdGggdGhlICJpdCBkb2Vzbid0IGh1cnQgYXJndW1lbnQiLiBBc3N1bWUNCj5mb3Ig
YSBtb21lbnQgd2UgaGF2ZSBhICJVQSBNQVkgaW5jbHVkZSBSUEgiIHdvcmRpbmcuIFRoZXJlIGFy
ZSBub3cgdHdvDQo+Y2FzZXM6DQo+DQo+KDEpIEFsbCBVQXMgaW1wbGVtZW50IGl0Lg0KPg0KPigy
KSBPbmx5IHNvbWUgVUFzIGltcGxlbWVudCBpdC4NCj4NCj4oMSkgc2VlbXMgdW5saWtlbHkgZm9y
IGEgTUFZLiBJZiAoMikgb2NjdXJzLCB3ZSBoYXZlIHRoZSBjaG9pY2UNCj5iZXR3ZWVuIHR3byB1
bmRlc2lyYWJsZSBvdXRjb21lczoNCj4NCj4oYSkgc29tZSBVQXMgdGhhdCBhcmUgb3RoZXJ3aXNl
IGNvbXBsaWFudCBnZXQgd29yc2Ugc2VydmljZSBqdXN0DQo+YmVjYXVzZSB0aGV5IGRpZG4ndCBp
bmNsdWRlIHRoZSBSUEg7DQoNCmFtIEkgcmVhZGluZyB0aGlzIGNvcnJlY3RseSAtIHRoYXQgdW5s
ZXNzIGFsbCBVQXMgaW1wbGVtZW50IHRoaXMgDQpjYXBhYmlsaXR5IHRoaXMgc2hvdWxkIG5ldmVy
IGJlIGltcGxlbWVudGVkIGJ5IGFueSBVQXM/DQoNClRoaXMgZmxpZXMgaW4gdGhlIGZhY2Ugb2Yg
dmVuZG9ycyBzb2x2aW5nIGZvciB0aGVpciBjdXN0b21lcidzIHJlcXVpcmVtZW50cy4NCg0KSSB3
aWxsIGFkbWl0IHRoYXQgYXQgdGhpcyB0aW1lLCBJIGtub3cgb2Ygbm8gQ2lzY28gY3VzdG9tZXJz
IHRoYXQgDQp3YW50IHRoaXMgY2FwYWJpbGl0eSwgc28gSSdtIG5vdCBhbmdsaW5nIGZvciBhbnkg
b2Ygb3VyIHJldmVudWUgDQpoZXJlLiAgSSdtIHNheWluZyB0aGF0IEkgdGhpbmsgSSBoZWFyIHlv
dSBzYXlpbmcgdGhpcyBJRCBzaG91bGQgc2F5IA0Kc29tZXRoaW5nIGxpa2UNCg0KICAgICAgICAg
VUFzIGFyZSBwcmV2ZW50ZWQgZnJvbSBpbXBsZW1lbnRpbmcgdGhlIFJQIG5hbWVzcGFjZSBlc25l
dA0KDQpJJ20gZmlnaHRpbmcgYWdhaW5zdCB0aGF0LCBiZWNhdXNlIGN1c3RvbWVycyBhcmUgYWx3
YXlzIGNvbWluZyB0byANCmV2ZXJ5IHZlbmRvciB3aXRoIG5ldyByZXF1aXJlbWVudHMsIHNvbWUg
b2YgdGhlbSB1bmlxdWUgYXQgdGhlIA0KdGltZS4gIFRoaXMgcHJldmVudGlvbiB0ZXh0IHdvdWxk
IHByZXZlbnQgYSB2ZW5kb3IgZnJvbSBjb21wbHlpbmcgDQp3aXRoIHRoaXMgc3BlY2lmaWNhdGlv
biBhbmQgc3RpbGwgbWVldCB0aGUgY3VzdG9tZXIncyBuZWVkcy4NCg0KSSBiZWxpZXZlIHRoYXQg
dGhpcyBJRCBuZWVkcyB0byByZXRhaW4gdGhlIGVuZHBvaW50cyBNQVkgaW5zZXJ0IA0KZXNuZXQs
IGFuZCBoYXZlIGFwcHJvcHJpYXRlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRleHQgdGhhdCAN
CmhpZ2hsaWdodHMgdGhlIGNvbmNlcm5zIGV4cHJlc3NlZCBoZXJlLg0KDQpTb21lIGZ1dHVyZSBJ
RCBjYW4gdGhlbiB1cGRhdGUgdGhpcyBjdXJyZW50IFJGQyAodG8tYmUpIHdpdGhpbiB0aGUgDQoy
MTE5IHJ1bGVzIG9mIHRoZSB1c2Ugb2YgTUFZIGhlcmUuDQoNCg0KPk9SDQo+DQo+KGIpIHRoZSBw
cm94eSBoYXMgdG8gbG9vayBmb3IgdGhlIHNlcnZpY2UgVVJOIHRvIGdpdmUgdGhlIGNhbGwgdGhl
DQo+YXBwcm9wcmlhdGUgdHJlYXRtZW50LCB0aHVzIG9idmlhdGluZyBhbnkgYWR2YW50YWdlIG9m
IGhhdmluZyB0aGUNCj5oZWFkZXIsIHlldCBpbmN1cnJpbmcgbW9yZSBjb21wbGljYXRlZCBwcm9j
ZXNzaW5nIGxvZ2ljLg0KPg0KPg0KPkkgaGF2ZSBubyBvYmplY3Rpb24gdG8gd2hhdGV2ZXIgbWFy
a2luZ3MgcGVvcGxlIHdhbnQgdG8gYXBwbHkgdG8gY2FsbHMNCj53aXRoaW4gYW4gRVNOIC0gdGhh
dCdzIGxhcmdlbHkgYSBwcml2YXRlIG1hdHRlci4NCj4NCj5IZW5uaW5nDQo+DQo+T24gRmViIDYs
IDIwMDksIGF0IDM6MDEgUE0sIFdpbnRlcmJvdHRvbSwgSmFtZXMgd3JvdGU6DQo+DQo+PkhpIEFs
bCwNCj4+DQo+PkkgaGF2ZSBmb2xsb3dlZCB0aGkgdGhyZWFkIHdpdGggc29tZSBpbnRlcmVzdCBh
bmQgSSBzdHJ1Z2dsaW5nIHRvDQo+PnNlZSBhIHVzZSBjYXNlIGZvciB0aGUNCj4+cHJvdmlkaW5n
IFJQSCBmb3IgZW1lcmdlbmN5IGNhbGxzIGZyb20gdGhlIGVuZC1wb2ludC4NCj4+DQo+PlRoZSBy
ZWZlcmVuY2UtbW9kZWwgY2FsbCBpbiBFQ1JJVCwgZm9yIGJldHRlciBvciB3b3JzZSwgaXMgZm9y
IGFsbA0KPj5jYWxscyB0byBnbyBiYWNrIHRocm91Z2ggYSBob21lLVZTUC4NCj4+V2UgcGxhY2Vk
IHF1aXRlIGEgbG90IG9mIGVtcGhhc2lzLCBsYXJnZWx5IGZvciB0cmFmZmluZyByZWFzb25zLCBm
b3INCj4+dGhlIFZTUCB0byBiZSBhYmxlIHRvIHZlcmlmeSB0aGF0DQo+PmEgY2FsbCBpcyBpbiBm
YWN0IGFuIGVtZXJnZW5jeSBjYWxsLiBUaGlzIGlzIGRvbmUgYnkgdGhlIHByb3h5DQo+PnRha2lu
ZyB0aGUgaW5iYW5kIGxvY2F0aW9uLCBkb2luZyBhIExvU1QNCj4+cXVlcnkgd2l0aCB0aGUgcHJv
dmlkZWQgVVJOLCBhbmQgdmVyaWZ5aW5nIHRoYXQgdGhlIHJlc3VsdGluZw0KPj5kZXN0aW5hdGlv
biBVUkkgaXMgdGhlIHNhbWUgYXMgdGhlIGRlc3RpbmF0aW9uDQo+PlVSSSBwcm92aWRlIGluIHRo
ZSBTSVAgSU5WSVRFLiBNeSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IFZTUHMgd291bGQNCj4+YWx3
YXlzIGRvIHRoaXMgY2hlY2sgc28gdGhleSBjb3VsZA0KPj50ZWxsIGlmIHRoZXkgY291bGQgYmls
bCBmb3IgdGhlIGNhbGwgb3Igbm90LCBhbmQgYmVjYXVzZSB0aGUgVlNQIGNhbg0KPj5iZSB1c2Ug
dGhhdCB0aGUgY2FsbCBpcyBhbiBlbWVyZ2VuY3kgY2FsbA0KPj5pdCBjYW4gYXBwbHkgYW55IHNw
ZWNpYWwgcHJpb3JpdGllcyB0aGF0IG1heSBiZSBhcHBsaWNhYmxlLiBUaGlzDQo+Pm9idmlhdGVz
IHRoZSBuZWVkIGZvciBSUEggZnJvbSB0aGUgZW5kLXBvaW50DQo+PnRvIHRoZSBuZXR3b3JrLg0K
Pj4NCj4+VGhpcyBsZWF2ZXMgdXMgd2l0aCB0aGUgYXJndW1lbnQgb2YgIml0IGRvZXNuJ3QgaHVy
dCB0byBpdCIsIHdoaWNoDQo+PmlzIG5vdCBhIGdvb2QgcmVhc29uIHRvIHdyaXRlIGEgc3BlY2lm
aWNhdGlvbi4NCj4+SXQgd2FzIGludGltYXRlZCBvbiB0aGUgZ2VvcHJpdiBtYWlsaW5nIGxpc3Qg
bGFzdCB5ZWFyIHRoYXQgZ3JlYXQNCj4+cGFpbnMgaGFkIGJlZW4gdGFrZW4gdG8ga2VlcCBTSVAg
d2l0aCBpbiB0aGUNCj4+TVRVIGxpbWl0cyBvZiBVRFAgb3ZlciBFdGhlcm5ldCANCj4+KGh0dHA6
Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9nZW9wcml2L2N1cnJlbnQvbXNnMDYxMjAu
aHRtbCApLiBBc3N1bWluZw0KPj50aGF0IHRoaXMgaXMgdGhlIGNhc2UsIHBlcmhhcHMgdGhlcmUg
aXMgaGFybSBpbiBpbmNsdWRpbmcNCj4+aW5mb3JtYXRpb24gdGhhdCB3ZSBrbm93IHdpbGwgYmUg
aWdub3JlZC4NCj4+DQo+PkNoZWVycw0KPj5KYW1lcw0KPj4NCj4+DQo+Pg0KPj4tLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs
ZiBvZiBIYW5uZXMgVHNjaG9mZW5pZw0KPj5TZW50OiBGcmkgMi82LzIwMDkgMTI6MzMgUE0NCj4+
VG86ICdCcmlhbiBSb3Nlbic7ICdIZW5uaW5nIFNjaHVsenJpbm5lJw0KPj5DYzogVHNjaG9mZW5p
ZywgSGFubmVzIChOU04gLSBGSS9Fc3Bvbyk7ICdFQ1JJVCcNCj4+U3ViamVjdDogUmU6IFtFY3Jp
dF0gUlBIDQo+Pg0KPj5UbyB0aGUgc3Rvcnkgc2hvcnQgaGVyZSBpcyB0aGUgY29kZSBmb3IgdGhl
IHByb3h5Og0KPj4NCj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0KPj5JRiBlbWVyZ2VuY3kg
Y2FsbCB3YXMgcmVjb2duaXplZCBUSEVODQo+PiAgICBleGVjdXRlIGVtZXJnZW5jeSBjYWxsIHNw
ZWNpZmljIHByb2NlZHVyZXMgKHByaW9yaXR5IHF1ZXVpbmcsDQo+PnByZWVtcHRpb24sIGZldGNo
IGxvY2F0aW9uLCBkZXRlcm1pbmUgcm91dGluZywgZG8gZnVubnkgUW9TIHRoaW5ncyAmDQo+PmNv
KQ0KPj5FTFNFDQo+PiAgICBub3JtYWwgY2FsbCBoYW5kbGluZyBwcm9jZWR1cmVzLg0KPj4NCj4+
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0KPj5JZiB5b3UgY2FuIG1ha2UgdGhpcyBkaWZmZXJl
bnRpYXRpb24gYmV0d2VlbiBhbiBlbWVyZ2VuY3kgY2FsbCBhbmQgYQ0KPj5yZWd1bGFyDQo+PmNh
bGwgdGhlbiB5b3UgY2FuIGFsc28gZG8gZXZlcnl0aGluZyB0aGF0IGlzIG5lY2Vzc2FyeSBmb3Ig
ZW1lcmdlbmN5DQo+PmNhbGwNCj4+aGFuZGxpbmcuDQo+Pg0KPj5CcmlhbiArIEtlaXRoOiBQbGVh
c2UgdGVsbCBtZSB0aGF0IHdlIGNhbm5vdCBkbyB0aGUgYWJvdmUgd2l0aCBvdXINCj4+Y3VycmVu
dGx5DQo+PnNwZWNpZmllZCBtZWNoYW5pc21zLg0KPj4NCj4+Q2lhbw0KPj5IYW5uZXMNCj4+DQo+
Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogQnJpYW4gUm9zZW4gW21haWx0
bzpickBicmlhbnJvc2VuLm5ldF0NCj4+PlNlbnQ6IDA2IEZlYnJ1YXJ5LCAyMDA5IDE3OjQ5DQo+
Pj5UbzogJ0hlbm5pbmcgU2NodWx6cmlubmUnOyAnSGFubmVzIFRzY2hvZmVuaWcnDQo+Pj5DYzog
J1RzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pJzsgJ0VDUklUJw0KPj4+U3ViamVj
dDogUkU6IFtFY3JpdF0gUlBIDQo+Pj4NCj4+PkkgYWdyZWUgdGhhdCBub3QgYWxsIG5ldHdvcmtz
IHdpbGwgcGVybWl0IChvciBwYXkgYXR0ZW50aW9uDQo+Pj50bykgYSBwcmlvcml0eSByZXF1ZXN0
IGZyb20gYW4gZW5kIGRldmljZS4NCj4+Pg0KPj4+Tm8gb25lIGhhcyBhc2tlZCBmb3IgdGhhdC4N
Cj4+Pg0KPj4+VGhlIG5hbWVzcGFjZSByZXF1ZXN0IGhhcyBzZXZlcmFsIHVzZXMsIG9uZSBvZiB3
aGljaCBpcyB3aXRoaW4NCj4+PmFuIGVtZXJnZW5jeSBzZXJ2aWNlcyBJUCBuZXR3b3JrLCBvbmUg
b2Ygd2hpY2ggaXMgYmV0d2Vlbg0KPj4+ZWxlbWVudHMgd2l0aGluIGEgcHVibGljIG5ldHdvcmsg
Y29udHJvbGxlZCBieSB0aGUgb3BlcmF0b3IsDQo+Pj5hbmQgb25lIG9mIHdoaWNoIGlzIGFuIGVu
ZHBvaW50IHJlcXVlc3QgZm9yIHJlc291cmNlIHByaW9yaXR5Lg0KPj4+DQo+Pj5UaG9zZSBvZiB1
cyByZXF1ZXN0aW5nIHRoaXMgd29yayBwcm9jZWVkIGFyZSBoYXBweSBpZiB0aGUNCj4+PmVuZHBv
aW50IHBhcnQgaXMgc2ltcGx5IGxlZnQgYXMgcG9zc2libGUgKE1BWSksIGFuZCwgc3BlYWtpbmcN
Cj4+PmZvciBteXNlbGYsIGhhdmluZyB0aGUgZHJhZnQgZGlzY3VzcyB0aGUgc2VjdXJpdHkgaW1w
bGljYXRpb25zDQo+Pj5vZiBlbmRwb2ludCBtYXJraW5nIGlzIHJlYXNvbmFibGUuDQo+Pj4NCj4+
PkhhdmluZyBkaXNjdXNzZWQgdGhpcyBpc3N1ZSB3aXRoIGFuIGltcGxlbWVudGF0aW9uIHRlYW0g
d2hvDQo+Pj53b3JrZWQgb24gTUxQUCBzeXN0ZW1zLCBJIGFtIGNvbmZpZGVudCBJIGtub3cgd2hh
dCBJJ20gdGFsa2luZw0KPj4+YWJvdXQsIGJ1dCBZTU1WLiAgVGhlIGZhY3QgdGhhdCB5b3UgY291
bGQsIGlmIHlvdSB3YW50ZWQgdG8sDQo+Pj5naXZlIHJlc291cmNlIHByaW9yaXR5IHRvIGEgY2Fs
bCB5b3UgZGVjaWRlZCwgaG93ZXZlciB5b3UNCj4+PmRlY2lkZWQsIHdhcyBhbiBlbWVyZ2VuY3kg
Y2FsbCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbiwNCj4+PmFuZCBub3Qgc3ViamVjdCB0
byBzdGFuZGFyZGl6YXRpb24uDQo+Pj4NCj4+PlJQSCBpcyB0aGUgSUVURiBzdGFuZGFyZCB3YXkg
Zm9yIG9uZSBlbnRpdHkgdG8gcmVxdWVzdA0KPj4+cmVzb3VyY2UgcHJpb3JpdHkgb2YgYW5vdGhl
ciBlbnRpdHkgaW4gYSBTSVAgc3lzdGVtLiAgV2UncmUNCj4+PmFza2luZyBmb3IgYSBuYW1lc3Bh
Y2UgdG8gdXNlIHRoYXQgd2l0aGluIHRoZSBkb21haW4gb2YNCj4+PmVtZXJnZW5jeSBjYWxscy4g
IFRoYXQgaXMsIEkgdGhpbmssIGEgVkVSWSByZWFzb25hYmxlIHJlcXVlc3QuDQo+Pj4NCj4+PkJy
aWFuDQo+Pj4NCj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PkZyb206IEhlbm5p
bmcgU2NodWx6cmlubmUgW21haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1XQ0KPj4+PlNlbnQ6IEZy
aWRheSwgRmVicnVhcnkgMDYsIDIwMDkgMTA6MzMgQU0NCj4+Pj5UbzogSGFubmVzIFRzY2hvZmVu
aWcNCj4+Pj5DYzogQnJpYW4gUm9zZW47IFRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNw
b28pOyBFQ1JJVA0KPj4+PlN1YmplY3Q6IFJlOiBbRWNyaXRdIFJQSA0KPj4+Pg0KPj4+PlRvIGNo
aW1lIGluIGhlcmU6DQo+Pj4+DQo+Pj4+SSBkb24ndCB0aGluayBpdCdzIHByb2R1Y3RpdmUgdG8g
c2ltcGx5IHN0YXRlIHRoYXQgNDQxMg0KPj4+ZG9lc24ndCB3b3JyeQ0KPj4+PmFib3V0IGF1dGhv
cml6YXRpb24sIHNvIHdlIHNob3VsZG4ndCBlaXRoZXIgKHNpbXBsaWZ5aW5nIGEgYml0KS4NCj4+
Pj5BdXRob3JpemF0aW9uIHdhcyBkaXNjdXNzZWQgcmVwZWF0ZWRseSwgYW5kIHRoZSBnZW5lcmFs
DQo+Pj5hc3N1bXB0aW9uIHdhcw0KPj4+PnRoYXQgdGhlcmUgd2VyZSB0d28gY29uZGl0aW9uczog
RWl0aGVyIHRoZSB1c2VyIGludm9raW5nIHJlc291cmNlLQ0KPj4+PnByaW9yaXR5IHdhcyB3ZWxs
IGtub3duIGFuZCBoYWQgYSBzZXQgb2YgcGVybWlzc2lvbnMgdGhhdCBjb3VsZCBiZQ0KPj4+PmNo
ZWNrZWQgaW4gcmVhbCB0aW1lIG9yIHRoZXJlIGFyZSB3YXlzIHRvIGRlYWwgd2l0aCBhYnVzZSBh
ZnRlciB0aGUNCj4+Pj5mYWN0IGluIHdheXMgdGhhdCBkZXRlciBhYnVzZSAodGhlIGNvdXJ0LW1h
cnRpYWwga2luZCBvZiB0aGluZyBpbiBhDQo+Pj4+bWlsaXRhcnkgY29udGV4dCkuDQo+Pj4+DQo+
Pj4+VGhlIFJGQyA0NDEyIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gKDExLjIpIGNhbGwgdGhpcyBv
dXQgaW4gcHJldHR5DQo+Pj4+c3Ryb25nIGxhbmd1YWdlOg0KPj4+Pg0KPj4+PiAgUHJpb3JpdGl6
ZWQgYWNjZXNzIHRvIG5ldHdvcmsgYW5kIGVuZC1zeXN0ZW0gcmVzb3VyY2VzIGltcG9zZXMNCj4+
Pj4gICAgcGFydGljdWxhcmx5IHN0cmluZ2VudCByZXF1aXJlbWVudHMgb24gYXV0aGVudGljYXRp
b24gYW5kDQo+Pj4+ICAgIGF1dGhvcml6YXRpb24gbWVjaGFuaXNtcywgc2luY2UgYWNjZXNzIHRv
IHByaW9yaXRpemVkDQo+Pj5yZXNvdXJjZXMgbWF5DQo+Pj4+ICAgIGltcGFjdCBvdmVyYWxsIHN5
c3RlbSBzdGFiaWxpdHkgYW5kIHBlcmZvcm1hbmNlIGFuZCBub3QNCj4+Pmp1c3QgcmVzdWx0DQo+
Pj4+ICAgIGluIHRoZWZ0IG9mLCBzYXksIGEgc2luZ2xlIHBob25lIGNhbGwuDQo+Pj4+VGh1cywg
dGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2UgaGF2ZSBzdWNoIHN0cm9uZyBhdXRoZW50aWNhdGlv
biBpbg0KPj4+PmVtZXJnZW5jeSBjYWxsaW5nLiBJbiBzb21lIGNhc2VzLCBzdWNoIGFzIHJlc2lk
ZW50aWFsIGZpeGVkIGxpbmUNCj4+Pj5kZXBsb3ltZW50cyB3aGVyZSBJU1AgPSBWU1AsIHdlJ3Jl
IHByb2JhYmx5IHByZXR0eSBjbG9zZSwgaW4gb3RoZXJzLA0KPj4+PnN1Y2ggYXMgcHJlcGFpZCBj
ZWxsIHBob25lcyBvciBob3Qgc3BvdHMgb3IgVlNQLW9ubHkgcHJvdmlkZXJzLCB3ZQ0KPj4+PmFy
ZW4ndC4NCj4+Pj4NCj4+Pj5UaGUgb3RoZXIgcG9pbnQgdGhhdCBJIHRoaW5rIEhhbm5lcyBpcyBt
YWtpbmcgaXMgdGhhdCB0aGUNCj4+PmluZm9ybWF0aW9uDQo+Pj4+aXMgZWl0aGVyIHJlZHVuZGFu
dCBvciBkYW5nZXJvdXMuIElmIGEgcHJvY2Vzc2luZyBlbGVtZW50IHJlY29nbml6ZXMNCj4+Pj50
aGUgY2FsbCBhcyBiZWluZyBhbiBlbWVyZ2VuY3kgY2FsbCwgaXQgY2FuIGFwcGx5IHdoYXRldmVy
IHRyZWF0bWVudA0KPj4+Pml0IGRlZW1zIGFwcHJvcHJpYXRlIGFuZCBkb2Vzbid0IG5lZWQgYWRk
aXRpb25hbCBpbmZvcm1hdGlvbi4gSWYgaXQNCj4+Pj5kb2Vzbid0IG9yIGNhbid0LCB1c2luZyBq
dXN0IHRoZSBSUEggY2FuIGJlIHJhdGhlciBkYW5nZXJvdXMgdW5sZXNzDQo+Pj4+dGhhdCBlbGVt
ZW50IGNhbiBiZSByZWFzb25hYmx5IGNlcnRhaW4gdGhhdCB0aGVyZSBpcyBzdHJvbmcNCj4+Pj5h
dXRoZW50aWNhdGlvbiBhbmQgcmVjb3Vyc2UuDQo+Pj4+DQo+Pj4+SSBkb24ndCBidXkgdGhlIGFy
Z3VtZW50IHRoYXQgc29tZWhvdyBmaW5kaW5nIHRoZSBSUEggaXMgZmFzdGVyIHRoYW4NCj4+Pj5q
dXN0IGxvb2tpbmcgZm9yIHRoZSBpZGVudGlmaWVyLiBUaHVzLCBnaXZlbiB0aGF0IHRoZSBpbmZv
cm1hdGlvbiBpcw0KPj4+PmVpdGhlciByZWR1bmRhbnQgb3IgZGFuZ2Vyb3VzLCBJIGZhaWwgdG8g
c2VlIHRoZSBhZHZhbnRhZ2UuDQo+Pj4+DQo+Pj4+SGVubmluZw0KPj4+Pg0KPj4+Pg0KPj4+Pk9u
IEZlYiA2LCAyMDA5LCBhdCAxMDoyMCBBTSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+Pj4+
DQo+Pj4+PkRvbid0IGdldCBodW5nIHVwIG9uIHRoZSBkZXRhaWxzLiBUaGVyZSBhcmUgd2F5cyB0
byBvcHRpbWl6ZSBpdC4NCj4+Pj4+VGhhdCB3YXMNCj4+Pj4+bm90IHRoZSBwb2ludCBvZiB0aGUg
Y29kZSBleGFtcGxlLg0KPj4+Pj4NCj4+Pj4+VGhlIHByb2JsZW0gdGhhdCBteSBwc2V1ZG8gY29k
ZSBzaG91bGQgaGF2ZSBzaG93biB5b3UgaXMgdGhhdCB5b3UNCj4+Pj4+KiBkb24ndCBnYWluIGFu
eXRoaW5nIHdpdGggUlBIIG1hcmtpbmcgZm9yIHRoZSBlbWVyZ2VuY3kgY2FsbCBjYXNlDQo+Pj4+
PmZyb20gdGhlIFNJUCBVQSB0b3dhcmRzIHRoZSBvdXRib3VuZCBwcm94eSBzaW5jZSB0aGUgZnVu
Y3Rpb25hbGl0eQ0KPj4+Pj5pcyBhbHJlYWR5IHByb3ZpZGUgb3RoZXJ3aXNlLiBIb3cgb2Z0ZW4g
ZG9lcyB0aGUgcHJveHkgbmVlZCB0byBnZXQNCj4+Pj4+dG9sZCB0aGF0IHRoaXMgaXMgYW4gZW1l
cmdlbmN5IGNhbGwgdG9kbyB3aGF0ZXZlciBlbWVyZ2VuY3kgY2FsbA0KPj4+Pj5oYW5kbGluZyBw
cm9jZWR1cmVzIGFyZSBuZWNlc3Nhcnk/DQo+Pj4+PiogeW91IG9ubHkgaW50cm9kdWNlIGZyYXVk
IHByb2JsZW1zIChpZiB5b3UgYXJlIG5vdA0KPj4+Y2FyZWZ1bCBhbmQgeW91DQo+Pj4+PnVuZGVy
c3RhbmQgdGhlIHNlY3VyaXR5IHN0dWZmIHdlbGwgZW5vdWdoKQ0KPj4+Pj4NCj4+Pj4+SWYgeW91
IGNhbiBwb2ludCBtZSB0byBwZW9wbGUgd2hvIGltcGxlbWVudCB0aGUgUlBIIGVtZXJnZW5jeSBj
YWxsDQo+Pj4+PmNhc2UgcGxlYXNlIGRvIHNvLiBJIHdvdWxkIGxvdmUgdG8gdGFsayB0byB0aGVt
Lg0KPj4+Pj4NCj4+Pj4+Q2lhbw0KPj4+Pj5IYW5uZXMNCj4+Pj4+DQo+Pj4+PlBTOiBZb3UgbmVl
ZCB0byBwYXJzZSBpbmNvbWluZyBtZXNzYWdlcyB0byBzb21lIGV4dGVuZCBzbyB0aGF0IHlvdQ0K
Pj4+Pj5rbm93IHdoYXQgaXQgY29udGFpbnMgOi0pIE9ubHkgbG9va2luZyBmb3IgdGhlIGVtZXJn
ZW5jeQ0KPj4+UlBIIGhlYWRlcg0KPj4+Pj4oYW5kIG5vdCBmb3IgdGhlIFNlcnZpY2UgVVJOL2Rp
YWwNCj4+Pj4+c3RyaW5nKSB3b3VsZCBleGFjdGx5IGJlIHRoZSBEb1MvZnJhdWQgYXR0YWNrIEkg
YW0gd29ycmllZCBhYm91dC4NCj4+Pj4+VGhhdCdzIHRoZSB0aGluZyBIZW5uaW5nIHdhcyB3b3Jy
aWVkIGFib3V0IChnbyBhbmQgbGlzdGVuIHRvIHRoZQ0KPj4+Pj5wYXN0IG1lZXRpbmcgbWludXRl
cykuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+Pkhhbm5lcw0KPj4+Pj4+DQo+Pj4+Pj5Zb3UgbmVlZCB0
byB0YWxrIHRvIHBlb3BsZSB3aG8gcmVhbGx5IGltcGxlbWVudCB0aGlzIGtpbmQNCj4+Pm9mIHRo
aW5nLg0KPj4+Pj4+WW91IGFyZSB3YXkgb2ZmLg0KPj4+Pj4+DQo+Pj4+Pj5XaGVuIHlvdSBpbXBs
ZW1lbnQgYSByZXNvdXJjZSBwcmlvcml0eSBzeXN0ZW0sIHRoZSBwb2ludCBvZiBkb2luZw0KPj4+
Pj4+dGhhdCBpcyB0byBsb29rIHRob3VnaCB0aGUgcXVldWUgb2Ygd29yayBhbmQgcGljayBvdXQg
dGhlDQo+Pj5vbmVzIHdpdGgNCj4+Pj4+PnByaW9yaXR5LCBoYW5kbGluZyB0aGVtIGZpcnN0LiAg
WW91IGRvbid0IGRvIGFsbCB0aGUgcGFyc2luZywgeW91DQo+Pj4+Pj5kb24ndCBkbyBhIGxvdCBv
ZiBkZWNpc2lvbiB0cmVlLg0KPj4+Pj4+DQo+Pj4+Pj5UeXBpY2FsbHk6DQo+Pj4+Pj5DaGVjayBm
b3IgRG9TIHRoaW5ncywgbGlrZSB0b28gYmlnIG1lc3NhZ2VzLCBldGMgRG8gYSBxdWljayBzY2Fu
DQo+Pj4+Pj5mb3IgdGhlIFJQSCBtZXNzYWdlIGhlYWRlciBJZiBmb3VuZDoNCj4+Pj4+PlBhcnNl
IHRoZSBtZXNzYWdlDQo+Pj4+Pj5EZXRlcm1pbmUgdmFsaWRpdHkNCj4+Pj4+PkRldGVybWluZSBw
cmlvcml0eQ0KPj4+Pj4+UXVldWUgb24gdGhlIGNvcnJlY3Qgd29yayBxdWV1ZQ0KPj4+Pj4+DQo+
Pj4+Pj5UaGUgZmlyc3QgdHdvIGFjdGlvbnMgaGF2ZSB0byBiZSB2ZXJ5IGZhc3QuICBBbnlvbmUg
d2hvIGJ1aWxkcyBhDQo+Pj4+Pj5TSVAgdGhpbmdpZSB3aWxsIHRlbGwgeW91IHRoYXQgcGFyc2lu
ZyBpcyBvbmUgb2YgdGhlIGJpZyBjeWNsZQ0KPj4+Pj4+Y29uc3VtZXJzOiBpZiB5b3UgaGF2ZSB0
byBwYXJzZSBldmVyeSBtZXNzYWdlIEJFRk9SRSB5b3UNCj4+PmRldGVybWluZQ0KPj4+Pj4+cHJp
b3JpdHksIHlvdSBjYW4ndCBnaXZlIG11Y2ggcmVzb3VyY2UgcHJpb3JpdHkuDQo+Pj4+Pj5PbmNl
IHlvdSBnZXQgdGhlIHdob2xlIG1lc3NhZ2UgcGFyc2VkLCB5b3UgbWlnaHQgYXMgd2VsbCBmaW5p
c2gNCj4+Pj4+Pndvcmtpbmcgb24gaXQsIGJlY2F1c2UgeW91J3ZlIGRvbmUgc28gbXVjaCBvZiB0
aGUgd29yay4NCj4+Pj4+Pk9USE9ILCBmaW5kaW5nIHRoZSBlbmQtb2YtbWVzc2FnZSBkZWxpbWl0
ZXIgYW5kIGRvaW5nIGEgcXVpY2sNCj4+Pj4+PnN0cmluZyBzZWFyY2ggZm9yIFJQSCBpcyBmYXN0
LiAgSWYgeW91IGFyZSBkb2luZw0KPj4+cHJpb3JpdHksIHlvdSBuZWVkDQo+Pj4+Pj50byBrZWVw
IGFsbCB0aGUgcHJpb3JpdHkgcHJvY2Vzc2luZyBwcmV0dHkgdW5pZm9ybSwgYW5kIHByZXR0eQ0K
Pj4+Pj4+c2ltcGxlLCBvciB5b3UgdGVuZCB0byBzcGVuZCB0b28gbXVjaCB0aW1lIGZ1dHppbmcg
YXJvdW5kDQo+Pj5maWd1cmluZw0KPj4+Pj4+b3V0IHdoYXQgdG8gZG8uICBZb3UgcHV0IGFsbCB0
aGUgcHJpb3JpdHkgcmVsYXRlZCBzdHVmZiB0b2dldGhlciwNCj4+Pj4+PmFuZCB1c2UgYXMgbXVj
aCBjb21tb24gY29kZSBhcyBwb3NzaWJsZS4NCj4+Pj4+Pg0KPj4+Pj4+QnJpYW4NCj4+Pj4+Pg0K
Pj4+Pj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+RnJvbTogZWNyaXQtYm91
bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddDQo+Pj4+Pj5PbiBC
ZWhhbGYNCj4+Pj4+Pj5PZiBIYW5uZXMgVHNjaG9mZW5pZw0KPj4+Pj4+PlNlbnQ6IEZyaWRheSwg
RmVicnVhcnkgMDYsIDIwMDkgODo0MSBBTQ0KPj4+Pj4+PlRvOiAnSGFubmVzIFRzY2hvZmVuaWcn
OyAnSmFuZXQgUCBHdW5uJw0KPj4+Pj4+PkNjOiBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJ
L0VzcG9vKTsgJ0VDUklUJzsgZWNyaXQtDQo+Pj4+Pj4+Ym91bmNlc0BpZXRmLm9yZw0KPj4+Pj4+
PlN1YmplY3Q6IFtFY3JpdF0gUlBIDQo+Pj4+Pj4+DQo+Pj4+Pj4+T3ZlciBsdW5jaCBJIHdhcyBh
bHNvIHRoaW5raW5nIGhvdyBhbiBvdXRib3VuZCBwcm94eSB3b3VsZA0KPj4+PmltcGxlbWVudA0K
Pj4+Pj4+PnNvbWUgb2YgdGhlIGVtZXJnZW5jeSBwcm9jZWR1cmVzLiBIZXJlIGFyZSBzb21lIHRo
b3VnaHRzOg0KPj4+Pj4+Pg0KPj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pg0KPj4+Pj4+Pi8vIFByb2Nlc3MgaW5jb21pbmcg
bWVzc2FnZQ0KPj4+Pj4+PlBhcnNlKG1zZyk7DQo+Pj4+Pj4+DQo+Pj4+Pj4+Ly8gU0lQIElOVklU
RSB3aXRob3V0IFNlcnZpY2UgVVJODQo+Pj4+Pj4+Ly8gbGVnYWN5IGRldmljZXMNCj4+Pj4+Pj5J
ZiAocmVjb2duaXplLWRpYWxzdHJpbmcobXNnKT09VFJVRSkgeyAgLy8gd2UgZ290IGFuIGVtZXJn
ZW5jeQ0KPj4+Pj4+PmNhbGwgZ29pbmcgb24gIGVtZXJnZW5jeT1UUlVFOyAgaWYgKGRpYWxzdHJp
bmcobXNnKSA9PSA5MTEpDQo+Pj4+Pj4+c2VydmljZVVSTj11cm46c2VydmljZTpzb3M7IH0gZWxz
ZSBpZg0KPj4+Pj4+PihyZWNvZ25pemUtc2VydmljZVVSTihtc2cpPT1UUlVFKSB7ICAvLyBvaC4g
QSB1cGRhdGVkDQo+Pj5kZXZpY2UgdGhhdA0KPj4+Pj4+PmhhcyBhIHNlcnZpY2UgVVJOIGF0dGFj
aGVkIHRvIHRoZQ0KPj4+PmNhbGwNCj4+Pj4+Pj5zZXJ2aWNlVVJOPXJldHJpZXZlX1NlcnZpY2VV
Uk4obXNnKTsNCj4+Pj4+Pj5lbWVyZ2VuY3k9VFJVRTsNCj4+Pj4+Pj59IGVsc2Ugew0KPj4+Pj4+
Pi8vIHN0YW5kYXJkIFNJUCBtZXNzYWdlDQo+Pj4+Pj4+Ly8gcmVndWxhciBwcm9jZXNzaW5nDQo+
Pj4+Pj4+cHJvY2Vzcyhtc2cpOw0KPj4+Pj4+PmVtZXJnZW5jeT1GQUxTRTsNCj4+Pj4+Pj59DQo+
Pj4+Pj4+DQo+Pj4+Pj4+SWYgKGVtZXJnZW5jeSA9PSBUUlVFKSB7DQo+Pj4+Pj4+ICAvLyBtYWtl
IHN1cmUgdGhhdCB0aGUgZW1lcmdlbmN5IGNhbGwgZG9lcyBub3QgZ2V0DQo+Pj5kcm9wcGVkIG9u
IHRoZQ0KPj4+Pj4+PmZsb29yDQo+Pj4+Pj4+ICAvLyBza2lwIGF1dGhvcml6YXRpb24gZmFpbHVy
ZXMNCj4+Pj4+Pj4gIC8vIGdpdmUgdGhlIGNhbGwgYSBzcGVjaWFsIHRyZWF0bWVudA0KPj4+Pj4+
PiAgbG90cy1vZi1jb2RlLWhlcmUoKTsNCj4+Pj4+Pj4NCj4+Pj4+Pj4gIC8vIHRyaWdnZXIgYWxs
IHRoZSBRb1Mgc2lnbmFsaW5nIHlvdSBoYXZlIGluIHRoZQ0KPj4+bmV0d29yayB0byBtYWtlDQo+
Pj4+Pj4+SmFtZXMgaGFwcHkNCj4+Pj4+Pj4gIHRyaWdnZXItcW9zKCk7DQo+Pj4+Pj4+DQo+Pj4+
Pj4+ICAvLyBxdWVyeSBsb2NhdGlvbg0KPj4+Pj4+PiAgbG9jYXRpb249cmV0cmlldmUtbG9jYXRp
b24oKTsNCj4+Pj4+Pj4NCj4+Pj4+Pj4gIC8vIGRldGVybWluZSBuZXh0IGhvcA0KPj4+Pj4+PiAg
bmV4dC1ob3A9bG9zdChsb2NhdGlvbiwgc2VydmljZVVSTikNCj4+Pj4+Pj4NCj4+Pj4+Pj4gIC8v
IGF0dGFjaCBSUEggbWFya2luZyB0byBvdXRnb2luZyBtc2cgdG8gbWFrZSBKYW1lcyBhbmQNCj4+
Pj4+PktlaXRoIGhhcHB5DQo+Pj4+Pj4+ICBtc2c9YWRkKG1zZywgUlBIKTsNCj4+Pj4+Pj4NCj4+
Pj4+Pj4gIHNlbmQobXNnLCBuZXh0LWhvcCk7DQo+Pj4+Pj4+fQ0KPj4+Pj4+Pg0KPj4+Pj4+Pklm
ICgocnBoLXByZXNlbnQobXNnKSA9PSBUUlVFKSAmJiAoZW1lcmdlbmN5ID09IFRSVUUpKSB7DQo+
Pj4+Pj4+ICAvLyBhbGwgdGhlIGVtZXJnZW5jeSByZWxhdGVkIHByb2Nlc3NpbmcgZG9uZSBhbHJl
YWR5IHVwZnJvbnQNCj4+Pj4+Pj4gIC8vIGhlbmNlIEkgbG9nIHNvbWV0aGluZy4NCj4+Pj4+Pj4g
IGxvZyhSUEhfV0FTX1BSRVNFTlRfSlVIVSk7DQo+Pj4+Pj4+fSBlbHNlIGlmICgocnBoLXByZXNl
bnQobXNnKSA9PSBUUlVFKSAmJiAoZW1lcmdlbmN5ID09DQo+Pj5GQUxTRSkpIHsNCj4+Pj4+Pj4v
LyB0aGlzIGlzIG5vdCBhbiBlbWVyZ2VuY3kgY2FsbCAgLy8gdGhpcyBpcyBzb21ldGhpbmcNCj4+
Pmxpa2UgR0VUUw0KPj4+Pj4+PnJlc3VsdD1zcGVjaWFsLWF1dGhvcml6YXRpb24tcHJvY2VkdXJl
KHVzZXIpOw0KPj4+Pj4+Pg0KPj4+Pj4+PmlmIChyZXN1bHQgPT0gQVVUSE9SSVpFRCkgew0KPj4+
Pj4+PiAgIC8vIGRvIHNvbWUgcHJpb3JpdHkgJiBwcmVlbXB0aW9uIHRoaW5nIGhlcmUuDQo+Pj4+
Pj4+ICAgLy8gdHJpZ2dlciBhbGwgdGhlIFFvUyB5b3UgaGF2ZQ0KPj4+Pj4+PiAgIGxvdHMtb2Yt
Y29kZS1oZXJlKCk7DQo+Pj4+Pj4+fSBlbHNlIHsNCj4+Pj4+Pj4gICBsb2coIk5PVCBBVVRIT1JJ
WkVEOyBkb24ndCBEb1MgbXkgbmV0d29yayIpOyAgfSB9IGVsc2UgeyAgLy8NCj4+Pj4+Pj5kb24n
dCBuZWVkIHRvZG8gYW55IFJQSCBwcm9jZXNzaW5nICAvLyB0aGlzIGluY2x1ZGVzIHRoZSBjYXNl
DQo+Pj4+Pj4+d2hlcmUgdGhlIGNhbGwgd2FzIGFuIGVtZXJnZW5jeSBjYWxsIGJ1dCB0aGUgUlBI
DQo+Pj4+Pj4+DQo+Pj4+Pj4+Ly8gbWFya2luZyB3YXMgbm90IHRoZXJlLg0KPj4+Pj4+Pm5vdGhp
bmcoKTsNCj4+Pj4+Pj59DQo+Pj4+Pj4+DQo+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+Q2lh
bw0KPj4+Pj4+Pkhhbm5lcw0KPj4+Pj4+Pg0KPj4+Pj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPj4+Pj4+Pj5Gcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNyaXQt
Ym91bmNlc0BpZXRmLm9yZ10gT24NCj4+Pj4+Pj4+QmVoYWxmIE9mIEhhbm5lcyBUc2Nob2Zlbmln
DQo+Pj4+Pj4+PlNlbnQ6IDA2IEZlYnJ1YXJ5LCAyMDA5IDE1OjA3DQo+Pj4+Pj4+PlRvOiAnSmFu
ZXQgUCBHdW5uJw0KPj4+Pj4+Pj5DYzogJ0VDUklUJzsgZWNyaXQtYm91bmNlc0BpZXRmLm9yZzsg
VHNjaG9mZW5pZyxIYW5uZXMgKE5TTiAtDQo+Pj4+Pj4+RkkvRXNwb28pDQo+Pj4+Pj4+PlN1Ympl
Y3Q6IFJlOiBbRWNyaXRdIEVDUklUIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nOiBBZ2VuZGEgKFJQ
SCkNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PldobyB3b3VsZCBkZWZpbmUgc29tZXRoaW5nIHRoYXQgY291
bGQgcHJldmVudCBEb1MgcHJvYmxlbXM/DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj5fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgICAgICAgRnJvbTogSmFu
ZXQgUCBHdW5uIFttYWlsdG86amd1bm42QGNzYy5jb21dDQo+Pj4+Pj4+PiAgICAgICAgIFNlbnQ6
IDA2IEZlYnJ1YXJ5LCAyMDA5IDE0OjExDQo+Pj4+Pj4+PiAgICAgICAgIFRvOiBIYW5uZXMgVHNj
aG9mZW5pZw0KPj4+Pj4+Pj4gICAgICAgICBDYzogJ0JyaWFuIFJvc2VuJzsgJ0RSQUdFLCBLZWl0
aCAoS2VpdGgpJzsgJ0VDUklUJzsNCj4+Pj4+Pj4+ZWNyaXQtYm91bmNlc0BpZXRmLm9yZzsgVHNj
aG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3Bvbyk7DQo+Pj4+J0phbWVzDQo+Pj4+Pj4+Pk0u
IFBvbGsnDQo+Pj4+Pj4+PiAgICAgICAgIFN1YmplY3Q6IFJlOiBbRWNyaXRdIEVDUklUIFZpcnR1
YWwgSW50ZXJpbQ0KPj4+TWVldGluZzogQWdlbmRhIChSUEgpDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4N
Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAgICAgIEJ1dCB0aGVyZSBpcyBub3RoaW5nIElOIFJGQzQ0
MTIgdGhhdCBzcGVjaWZpY2FsbHkNCj4+Pj4+PmFkZHJlc3NlcyBob3cgdG8NCj4+Pj4+Pj4+cHJl
dmVudCBhbnkgcGFydGljdWxhciBuYW1lc3BhY2UgYmVpbmcgdXNlZCBmb3IgRG9TLiAgQW55b25l
L2FueQ0KPj4+PlVBDQo+Pj4+Pj4+PmNhbiBBVFRFTVBUIHRvIGludm9rZSBwcmlvcml0eSB0cmVh
dG1lbnQgYnkgYXR0YWNoaW5nIFJQSC4gIEZvcg0KPj4+PmFsbA0KPj4+Pj4+Pj5vZiB0aGUgNDQx
MiBuYW1lc3BhY2VzLCBhcyB3aXRoIHRoZSBuZXcgcHJvcG9zZWQgbmFtZXNwYWNlLCB0aGUNCj4+
Pj4+Pj4+bWVjaGFuaXNtcyBmb3IgcHJldmVudGluZyBEb1MgYXJlIG5vdCBzcGVjaWZpZWQgaW4g
dGhlDQo+Pj4+Pj5kb2N1bWVudCB0aGF0DQo+Pj4+Pj4+PmRlZmluZXMgdGhlIG5hbWVzcGFjZS4N
Cj4+Pj4+Pj4+VGhleSBhcmUvd2lsbCBiZSBzcGVjaWZpZWQgZWxzZXdoZXJlLg0KPj4+Pj4+Pj4N
Cj4+Pj4+Pj4+ICAgICAgICAgSmFuZXQNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAgICAgIFRoaXMg
aXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPj4+Pj4+
cmVjaXBpZW50LA0KPj4+Pj4+Pj5wbGVhc2UgZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2lu
ZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YNCj4+Pj50aGUNCj4+Pj4+Pj4+bWlzdGFrZSBpbiBk
ZWxpdmVyeS4NCj4+Pj4+Pj4+ICAgICAgICAgTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0
aGlzIGUtbWFpbCBzaGFsbCBub3QNCj4+Pj4+Pm9wZXJhdGUgdG8gYmluZA0KPj4+Pj4+Pj5DU0Mg
dG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNp
dA0KPj4+Pj4+Pj53cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhw
cmVzc2x5IHBlcm1pdHRpbmcNCj4+Pj50aGUNCj4+Pj4+Pj4+dXNlIG9mIGUtbWFpbCBmb3Igc3Vj
aCBwdXJwb3NlLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgICAgICAgZWNyaXQtYm91bmNlc0BpZXRm
Lm9yZyB3cm90ZSBvbiAwMi8wNi8yMDA5IDA0OjIxOjUxIEFNOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+
ICAgICAgICAgPiBIaSBKYW1lcywNCj4+Pj4+Pj4+ICAgICAgICAgPg0KPj4+Pj4+Pj4gICAgICAg
ICA+IEkgaGF2ZSByZWFkIFJGQyA0NDEyIGFuZCBhbHNvIHRoZSBHRVRTL01MUFAgSUVURg0KPj4+
Pj4+ZG9jdW1lbnRzLiBXaGF0IEkNCj4+Pj4+Pj4+d291bGQNCj4+Pj4+Pj4+ICAgICAgICAgPiBs
aWtlIHRvIHBvaW50IG91dCBpcyB0aGF0IHRoZXJlIGlzIG1vcmUgdGhhbiBqdXN0IGENCj4+Pj4+
PmhlYWRlciBhbmQNCj4+Pj4+Pj4+dmFsdWVzIHdpdGhpbg0KPj4+Pj4+Pj4gICAgICAgICA+IHRo
ZSBoZWFkZXIgdGhhdCBoYXZlIHRvIGJlIGNvbnNpZGVyZWQgaW4gb3JkZXIgdG8NCj4+Pj4+Pm1h
a2UgYSBqdWRnZW1lbnQNCj4+Pj4+Pj4+b2Ygd2hhdA0KPj4+Pj4+Pj4gICAgICAgICA+IGlzIGFw
cHJvcHJpYXRlIGFuZCB3aGF0IGlzbid0LiBUaGVyZSBpcyBhbg0KPj4+Pj4+YXJjaGl0ZWN0dXJh
bCBxdWVzdGlvbg0KPj4+Pj4+Pj5hbmQNCj4+Pj4+Pj4+ICAgICAgICAgPiB3aGV0aGVyIHRoZSBl
bnZpcm9ubWVudCB3ZSBhcmUgdXNpbmcgdGhlIHN0dWZmIGlzDQo+Pj4+Pj5pbmRlZWQgcHJvdmlk
aW5nDQo+Pj4+Pj4+PnRoZQ0KPj4+Pj4+Pj4gICAgICAgICA+IHByb3BlcnRpZXMgeW91IG5lZWQg
Zm9yIHRoZSBzb2x1dGlvbiB0byBiZQ0KPj4+YXBwcm9wcmlhdGUuDQo+Pj4+Pj4+PiAgICAgICAg
ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiBMZXQgbWUgZGVzY3JpYmUgaW4gbW9yZSBkZXRhaWwgd2hh
dCBJIG1lYW50IChhbmQNCj4+Pj4+PnBsZWFzZSBjb3JyZWN0IG1lDQo+Pj4+Pj4+PmlmIEkgYW0N
Cj4+Pj4+Pj4+ICAgICAgICAgPiB3cm9uZykuDQo+Pj4+Pj4+PiAgICAgICAgID4NCj4+Pj4+Pj4+
ICAgICAgICAgPiBHZXR0aW5nIHByaW9yaXR5IGZvciBTSVAgcmVxdWVzdHMgd2hlbiB1c2luZyBh
IEdFVFMNCj4+Pj4+PmFsaWtlIHNjZW5hcmlvDQo+Pj4+Pj4+Pm1lYW5zDQo+Pj4+Pj4+PiAgICAg
ICAgID4gdGhhdCB0aGUgZW50aXR5IHRoYXQgaXNzdWVzIHRoZSByZXF1ZXN0IGlzIHNwZWNpYWxs
eQ0KPj4+Pj4+YXV0aG9yaXplZA0KPj4+Pj4+Pj5zaW5jZQ0KPj4+Pj4+Pj4gICAgICAgICA+IG90
aGVyd2lzZSB5b3UgaW50cm9kdWNlIGEgbmljZSBkZW5pYWwgb2YNCj4+PnNlcnZpY2UgYXR0YWNr
LiBUaGlzDQo+Pj4+Pj4+PmF1dGhvcml6YXRpb24NCj4+Pj4+Pj4+ICAgICAgICAgPiBpcyB0aWVk
IHRvIHRoZSBlbnRpdHkgdGhhdCBtYWtlcyB0aGUgcmVxdWVzdC4gRm9yDQo+Pj4+Pj5leGFtcGxl
LCB0aGUNCj4+Pj4+Pj4+cGVyc29uIGlzDQo+Pj4+Pj4+PiAgICAgICAgID4gd29ya2luZyBmb3Ig
dGhlIGdvdmVybm1lbnQgYW5kIGhhcyBzcGVjaWFsIHJpZ2h0cy4NCj4+Pj4+Pj4+SmFtZXMgQm9u
ZCBhcyBhIChub3Qgc28pDQo+Pj4+Pj4+PiAgICAgICAgID4gc2VjcmV0IGFnZW50IG1pZ2h0IGhh
dmUgdGhlc2UgcmlnaHRzLg0KPj4+Pj4+Pj4gICAgICAgICA+DQo+Pj4+Pj4+PiAgICAgICAgID4g
VGhlIGVtZXJnZW5jeSBzZXJ2aWNlcyBjYXNlDQo+Pj4oY2l0aXplbi10by1hdXRob3JpdHkpIGlz
IGEgYml0DQo+Pj4+Pj4+PmRpZmZlcmVudCBhcw0KPj4+Pj4+Pj4gICAgICAgICA+IHRoZXJlIGFy
ZW4ndCByZWFsbHkgc3BlY2lhbCByaWdodHMgd2l0aCByZXNwZWN0IHRvDQo+Pj4+Pj5hdXRob3Jp
emF0aW9uDQo+Pj4+Pj4+PnRpZWQgdG8NCj4+Pj4+Pj4+ICAgICAgICAgPiBpbmRpdmlkdWFscy4g
SW5zdGVhZCwgdGhlIGZhY3QgdGhhdCBzb21ldGhpbmcgaXMgYW4NCj4+Pj4+PmVtZXJnZW5jeSBp
cw0KPj4+Pj4+Pj5wdXJlbHkgYQ0KPj4+Pj4+Pj4gICAgICAgICA+IGp1ZGdlbWVudCBvZiB0aGUg
aHVtYW4gdGhhdCBkaWFscyBhIHNwZWNpYWwgbnVtYmVyLg0KPj4+Pj4+Pj5UbyBkZWFsIHdpdGgg
ZnJhdWQsIHdlDQo+Pj4+Pj4+PiAgICAgICAgID4gZGlzY3Vzc2VkIGluIHRoZSBncm91cCBvbiB3
aGF0IHdlIGNhbiBhY3R1YWxseSBkbyB0bw0KPj4+Pj4+ZW5zdXJlIHRoYXQNCj4+Pj4+Pj4+ZW5k
IHVzZXJzDQo+Pj4+Pj4+PiAgICAgICAgID4gZG8gbm90IGJ5cGFzcyBzZWN1cml0eSBwcm9jZWR1
cmVzIChzdWNoIGFzDQo+Pj4+Pj5hdXRob3JpemF0aW9uIGNoZWNrcywNCj4+Pj4+Pj4+Y2hhcmdp
bmcNCj4+Pj4+Pj4+ICAgICAgICAgPiBhbmQgc28gb24pLiBQYXJ0IG9mIHRoaXMgaW52ZXN0aWdh
dGlvbiB3YXMNCj4+PnRoZSBwdWJsaWNhdGlvbiBvZg0KPj4+Pj4+Pj4gICAgICAgICA+IGh0dHA6
Ly93d3cuaWV0Zi5vcmcvcmZjL3JmYzUwNjkudHh0IHRoYXQgYWxzbw0KPj4+ZGVzY3JpYmVzIHRo
aXMNCj4+Pj4+Pj4+aXNzdWUuDQo+Pj4+Pj4+PiAgICAgICAgID4NCj4+Pj4+Pj4+ICAgICAgICAg
PiBTbywgaW1hZ2luZSB0aGUgaW1wbGVtZW50YXRpb24gb2YgYSBTSVAgcHJveHkgKGFuZCB3ZQ0K
Pj4+Pj4+aW1wbGVtZW50ZWQNCj4+Pj4+Pj4+dGhhdA0KPj4+Pj4+Pj4gICAgICAgICA+IHN0dWZm
KSB0aGF0IHJlY2VpdmVzIGEgY2FsbCB0aGF0IGNvbnRhaW5zIGEgU2VydmljZQ0KPj4+Pj4+VVJO
LiBUaGUgY29kZQ0KPj4+Pj4+Pj5icmFuY2hlcw0KPj4+Pj4+Pj4gICAgICAgICA+IGludG8gYSBz
cGVjaWFsIG1vZGUgd2hlcmUgZXZlcnl0aGluZyBpcyBkb25lDQo+Pj5zbyB0aGF0IHRoZSBjYWxs
DQo+Pj4+Pj4+PnJlY2VpdmVzDQo+Pj4+Pj4+PiAgICAgICAgID4gYXBwcm9wcmlhdGUgdHJlYXRt
ZW50IGFuZCBkb2VzIG5vdCBnZXQgZHJvcHBlZCBvbiB0aGUNCj4+Pj4+PmZsb29yLiBUaGUNCj4+
Pj4+Pj4+d2F5IGhvdyB0aGUNCj4+Pj4+Pj4+ICAgICAgICAgPiBTZXJ2aWNlIFVSTiBpcyBwbGFj
ZWQgaW4gdGhlIG1lc3NhZ2UgZW5zdXJlcyB0aGF0IHRoZQ0KPj4+Pj4+Y2FsbCBjYW5ub3QNCj4+
Pj4+Pj4+Z28gdG8gbXkNCj4+Pj4+Pj4+ICAgICAgICAgPiBmcmllbmQgKGluc3RlYWQgb2YgdGhl
IFBTQVApIHVubGVzcyB0aGUgZW5kIGhvc3QgcmFuDQo+Pj4+Pj5Mb1NUIGFscmVhZHkuDQo+Pj4+
Pj4+PkluIHRoZQ0KPj4+Pj4+Pj4gICAgICAgICA+IGxhdHRlciBjYXNlLCB3ZSBkaXNjdXNzZWQg
dGhpcyBhbHNvIG9uIHRoZSBsaXN0IGZvciBhDQo+Pj4+Pj53aGlsZSBhbmQNCj4+Pj4+Pj4+Umlj
aGFyZCBldmVuDQo+Pj4+Pj4+PiAgICAgICAgID4gd3JvdGUgYSBkcmFmdCBhYm91dCBpdCBpbiB0
aGUgY29udGV4dCBvZiB0aGUNCj4+PmxvY2F0aW9uIGhpZGluZw0KPj4+Pj4+Pj50b3BpYywgd2Ug
c2FpZA0KPj4+Pj4+Pj4gICAgICAgICA+IHRoYXQgdGhlIHByb3h5IHdvdWxkIGhhdmUgdG8gcnVu
IExvU1QgaWYgaGUNCj4+PmNhcmVzIGFib3V0IGENCj4+Pj4+Pj4+cG90ZW50aWFsDQo+Pj4+Pj4+
PiAgICAgICAgID4gZnJhdWR1bGVudCB1c2FnZS4NCj4+Pj4+Pj4+ICAgICAgICAgPg0KPj4+Pj4+
Pj4gICAgICAgICA+IFNvLCB3aGF0IGRvIHdlIG5lZWQgdG9kbyBpbiBvcmRlciB0byBwcm92aWRl
DQo+Pj5zZWN1cmUgUkZDIDQ0MTINCj4+Pj4+Pj4+ZnVuY3Rpb25hbGl0eQ0KPj4+Pj4+Pj4gICAg
ICAgICA+IGluIG91ciBjb250ZXh0Pw0KPj4+Pj4+Pj4gICAgICAgICA+DQo+Pj4+Pj4+PiAgICAg
ICAgID4gRG8geW91IHRoaW5rIHRoYXQgdGhlIGN1cnJlbnQgdGV4dCBpbg0KPj4+Pj4+Pj4gICAg
ICAgICA+DQo+Pj4+Pj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0
LWlldGYtZWNyaXQtbG9jYWwtZW1lcg0KPj4+Pj4+Pj5nZW5jeS1ycGgtbmFtDQo+Pj4+Pj4+PiAg
ICAgICAgID4gZXNwYWNlLTAwLnR4dCByZWZsZWN0cyBhbnkgb2YgdGhlDQo+Pj5hYm92ZS1kZXNj
cmliZWQgaXNzdWVzOg0KPj4+Pj4+Pj4gICAgICAgICA+ICINCj4+Pj4+Pj4+ICAgICAgICAgPiAg
ICBUaGUgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGhhdCBhcHBseSB0byBSRkMgNDQxMg0KPj4+
Pj4+Pj5bUkZDNDQxMl0NCj4+Pj4+Pj4+YXBwbHkNCj4+Pj4+Pj4+ICAgICAgICAgPiAgICBoZXJl
LiAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIG5vIG5ldyBzZWN1cml0eQ0KPj4+Pj4+Pj5pc3N1
ZXMgcmVsYXRpdmUNCj4+Pj4+Pj4+dG8NCj4+Pj4+Pj4+ICAgICAgICAgPiAgICBSRkMgNDQxMi4N
Cj4+Pj4+Pj4+ICAgICAgICAgPiAiDQo+Pj4+Pj4+PiAgICAgICAgID4NCj4+Pj4+Pj4+ICAgICAg
ICAgPiBGcm9tIHZhcmlvdXMgZGlzY3Vzc2lvbnMgaW4gR0VPUFJJViBJIHJlY2FsbA0KPj4+dGhh
dCB5b3UgYXJlDQo+Pj4+Pj4+PnN1cGVyLXNlbnNpdGl2ZQ0KPj4+Pj4+Pj4gICAgICAgICA+IHJl
Z2FyZGluZyBzZWN1cml0eSBhbmQgcHJpdmFjeS4gRm9yIHNvbWUgcmVhc29ucyB5b3UNCj4+Pj4+
PmRvbid0IHNlZW0gdG8NCj4+Pj4+Pj4+aGF2ZSB0aGUNCj4+Pj4+Pj4+ICAgICAgICAgPiBzYW1l
IGNvbmNlcm5zIGhlcmUuIEkgd291bGQgbGlrZSB0bw0KPj4+dW5kZXJzdGFuZCB5b3VyIHJlYXNv
bmluZy4NCj4+Pj4+Pj4+ICAgICAgICAgPg0KPj4+Pj4+Pj4gICAgICAgICA+IFBsZWFzZSBhbHNv
IGRvIG1lIGFub3RoZXIgZmF2b3I6IERvbid0IGFsd2F5cyBzYXkNCj4+Pj4+PnRoYXQgSSBkb24n
dA0KPj4+Pj4+Pj51bmRlcnN0YW5kDQo+Pj4+Pj4+PiAgICAgICAgID4gdGhlIHN1YmplY3QuIEV2
ZW4gaWYgdGhhdCB3b3VsZCBiZSB0aGUgY2FzZSBpdCBpc24ndA0KPj4+Pj4+cGFydGljdWxhcg0K
Pj4+Pj4+Pj5mYWlyIGdpdmVuDQo+Pj4+Pj4+PiAgICAgICAgID4gdGhhdCBkaWZmZXJlbnQgZm9s
a3MgaGFkIHRvIGVkdWNhdGUgeW91IG9uIG90aGVyDQo+Pj4+Pj50b3BpY3MgaW4gdGhlDQo+Pj4+
Pj4+PnBhc3QgYXMgd2VsbC4NCj4+Pj4+Pj4+ICAgICAgICAgPiBBZGRpdGlvbmFsbHksIGlmIHlv
dSBsaXN0ZW4gdG8gdGhlIGF1ZGlvIHJlY29yZGluZ3MNCj4+Pj4+PnRoZW4geW91IHdpbGwNCj4+
Pj4+Pj4+bm90aWNlDQo+Pj4+Pj4+PiAgICAgICAgID4gdGhhdCBIZW5uaW5nLCBUZWQsIGFuZCBK
b24gZG8gbm90IHNlZW0gdG8gdW5kZXJzdGFuZA0KPj4+Pj4+dGhlIGlzc3VlDQo+Pj4+Pj4+PmVp
dGhlciBhcw0KPj4+Pj4+Pj4gICAgICAgICA+IHRoZXkgaGF2ZSByYWlzZWQgc2ltaWxhciBpc3N1
ZXMgZHVyaW5nIHRoZQ0KPj4+RjJGIG1lZXRpbmdzLg0KPj4+Pj4+Pj4gICAgICAgICA+DQo+Pj4+
Pj4+PiAgICAgICAgID4gQ2lhbw0KPj4+Pj4+Pj4gICAgICAgICA+IEhhbm5lcw0KPj4+Pj4+Pj4g
ICAgICAgICA+DQo+Pj4+Pj4+PiAgICAgICAgID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+SGFubmVz
IC0gSSBiZWxpZXZlIGl0IGlzIHlvdSB3aG8gZG8gbm90IHVuZGVyc3RhbmQNCj4+Pj4+PlJGQyA0
NDEyIC0tDQo+Pj4+Pj4+PiAgICAgICAgID4gPmFuZCBtYW55IG9mIHVzIGFyZSB0cnlpbmcgdG8g
Z2V0IHRoYXQNCj4+PnRocm91Z2ggdG8geW91LCBidXQgeW91DQo+Pj4+Pj4+PiAgICAgICAgID4g
PmRvbid0IHNlZW0gdG8gd2FudCB0byBsaXN0ZW4vcmVhZC4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+
DQo+Pj4+Pj4+PiAgICAgICAgID4gPlJGQyA0NDEyIGlzICpmb3IqIHByaW9yaXR5IG1hcmtpbmcg
U0lQIHJlcXVlc3RzLA0KPj4+Pj4+Pj4gICAgICAgICA+ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+
T25lIHVzZSBpcyBHRVRTLg0KPj4+Pj4+Pj4gICAgICAgICA+ID4NCj4+Pj4+Pj4+ICAgICAgICAg
PiA+T25lIHVzZSBpcyBNTFBQLg0KPj4+Pj4+Pj4gICAgICAgICA+ID4NCj4+Pj4+Pj4+ICAgICAg
ICAgPiA+VGhlc2UgZXhhbXBsZXMgYXJlIGluIFJGQyA0NDEyIGJlY2F1c2UgdGhlcmUNCj4+Pndl
cmUgc3BlY2lmaWMNCj4+Pj4+Pj4+ICAgICAgICAgPiA+bmFtZXNwYWNlcyBiZWluZyBjcmVhdGVk
IGZvciB0aGUgSUFOQSBzZWN0aW9uIG9mDQo+Pj4+Pj50aGF0IGRvY3VtZW50Lg0KPj4+Pj4+Pj4g
ICAgICAgICA+ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+UmVhZGluZyB0aGUgd2hvbGUgZG9jdW1l
bnQsIHlvdSB3aWxsIHNlZQ0KPj4+dGhhdCBSUEggY2FuIGJlDQo+Pj4+Pj4+PiAgICAgICAgID4g
PnNwZWNpZmllZCBmb3Igb3RoZXIgdXNlcyB0aGFuIEdFVFMgb3IgTUxQUA0KPj4+c3BlY2lmaWNh
bGx5Lg0KPj4+Pj4+Pj4gICAgICAgICA+ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+SSBrbmV3IHdo
ZW4gSSB3cm90ZSBSRkMgNDQxMiB0aGF0IG9uZSBkYXkgd2UNCj4+PndvdWxkIHNwZWNpZnkgYQ0K
Pj4+Pj4+Pj4gICAgICAgICA+ID5uYW1lc3BhY2UgZm9yIEVDUklUICh0aGUgImVzbmV0IiBuYW1l
c3BhY2UNCj4+Pm5vdykgLS0gYnV0IEkgYWxzbw0KPj4+Pj4+Pj4gICAgICAgICA+ID5rbmV3IGl0
IHdhcyBwcmVtYXR1cmUgZm9yIFJGQyA0NDEyIHRvDQo+Pj5pbmNvcnBvcmF0ZSB0aGF0DQo+Pj4+
Pj4+PiAgICAgICAgID4gPm5hbWVzcGFjZSwgdGhhdCBhIGZ1dHVyZSBkb2MgdG8gUkZDIDQ0MTIN
Cj4+PndvdWxkIGhhdmUgdG8gYmUNCj4+Pj4+Pj4+ICAgICAgICAgPiA+d3JpdHRlbiB0byBkbyB0
aGlzLiBCcmlhbiBhbmQgSSB0YWxrZWQgYWJvdXQNCj4+PnRoaXMgYXQgdGhlDQo+Pj4+Pj4+PiAg
ICAgICAgID4gPm9yaWdpbmFsIE5FTkEgbWVldGluZyB0aGF0IGNyZWF0ZWQgdGhlIElQIFdHcyB0
aGVyZQ0KPj4+Pj4+KGluIEF1Z3VzdA0KPj4+Pj4+Pj4gICAgICAgICA+ID5vZiAwMykuICBXZSBi
b3RoIGFncmVlZCB3ZSBzaG91bGQgd2FpdCB1bnRpbCBpdCB3YXMNCj4+Pj4+Pj4+ICAgICAgICAg
PiA+YXBwcm9wcmlhdGUgdG8gdGhlIHdvcmsgaW4gdGhlIElFVEYgdG8NCj4+PnN1Ym1pdCB0aGlz
IGRvY3VtZW50DQo+Pj4+Pj4+PiAgICAgICAgID4gPnRoYXQgaXMgbm93DQo+Pj4+Pj4+PiAgICAg
ICAgID4NCj4+Pj4+Pj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0
LWlldGYtZWNyaXQtbG9jYWwtZW1lcg0KPj4+Pj4+Pj4gICAgICAgICA+ID5nZW5jeS1ycGgtbmFt
ZXNwYWNlLTAwLnR4dA0KPj4+Pj4+Pj4gICAgICAgICA+ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+
WWV0LCB5b3Ugc2VlbSB0byB3YW50IHRvIHVzZSBzb21lIGFkZGl0aW9uYWwNCj4+Pm1lY2hhbmlz
bSB0bw0KPj4+Pj4+Pj4gICAgICAgICA+ID5pbmRpY2F0ZSBwcmlvcml0eSBvZiBhIGNhbGwgaW4g
U0lQLiAgVGhhdA0KPj4+bWVhbnMgeW91IHdhbnQgdG8NCj4+Pj4+Pj4+ICAgICAgICAgPiA+aW50
cm9kdWNlIGEgc2Vjb25kIHdheSB0byBhY2NvbXBsaXNoIHRoaXMgaW4gU0lQLg0KPj4+Pj4+Pj5X
aHkgZG8geW91DQo+Pj4+Pj4+PiAgICAgICAgID4gPndhbnQgdG8gcHJvbW90ZSBhIHNlcGFyYXRl
IHdheSB0byBkbyBzb21ldGhpbmcgU0lQDQo+Pj4+Pj5oYXMgYWxyZWFkeQ0KPj4+Pj4+Pj4gICAg
ICAgICA+ID5kZWZpbmVkPyBUaGF0IHdpbGwgY2F1c2UgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMg
YW5kDQo+Pj4+Pj53ZSBib3RoIGtub3cNCj4+Pj4+Pj4+dGhhdC4NCj4+Pj4+Pj4+ICAgICAgICAg
PiA+DQo+Pj4+Pj4+PiAgICAgICAgID4gPllvdSd2ZSBzYWlkIHRvIG1lIChhbmQgb3RoZXJzKSB0
aGF0IHlvdQ0KPj4+YmVsaWV2ZSBSUEggaXMganVzdA0KPj4+Pj4+Pj4gICAgICAgICA+ID5hbm90
aGVyIHdheSB0byBhY2NvbXBsaXNoIHdoYXQgc29zIG9yIGEgVVJJIGNhbg0KPj4+Pj4+aW5kaWNh
dGUgLSBhbmQNCj4+Pj4+Pj4+ICAgICAgICAgPiA+eW91J3JlIHdyb25nLiAgWW91ciB3YXkgd291
bGQgYmUNCj4+Pl90aGVfc2Vjb25kX3dheV90b19kb19pdCwNCj4+Pj4+Pj4+ICAgICAgICAgPiA+
YmVjYXVzZSBTSVAgYWxyZWFkeSBjb25zaWRlcnMgUlBIIHRvIGJlDQo+Pj4qdGhlKndheSogdG8g
cHJpb3JpdHkNCj4+Pj4+Pj4+ICAgICAgICAgPiA+bWFyayBTSVAgcmVxdWVzdHMuDQo+Pj4+Pj4+
PiAgICAgICAgID4gPg0KPj4+Pj4+Pj4gICAgICAgICA+ID5JZiB5b3UgZG9uJ3QgYmVsaWV2ZSBt
ZSAobm8gY29tbWVudCksIHRoZW4NCj4+PndoeSBkbyB5b3Ugbm90DQo+Pj4+Pj4+PiAgICAgICAg
ID4gPmJlbGlldmUgdGhlIFNJUCBXRyBjaGFpciAod2hvIGtub3dzIG1vcmUNCj4+PmFib3V0IFNJ
UCB0aGFuIGJvdGgNCj4+Pj4+Pj4+ICAgICAgICAgPiA+b2YgdXMpIC0gd2hvLCBvbiB0aGlzIHRo
cmVhZCwgaGFzIGFnYWluIHNhaWQNCj4+PnRvIHlvdSAiUkZDIDQ0MTINCj4+Pj4+Pj4+ICAgICAg
ICAgPiA+KFJQSCkgaXMgdGhlIFNJUCBtZWNoYW5pc20gdG8gcHJpb3JpdHkgbWFyaw0KPj4+U0lQ
IHJlcXVlc3RzIj8NCj4+Pj4+Pj4+ICAgICAgICAgPiA+DQo+Pj4+Pj4+PiAgICAgICAgID4gPkZ1
cnRoZXIsIEkgYmVsaWV2ZSBpdCBpcyBpbmFwcHJvcHJpYXRlIHRvDQo+Pj5wcm9oaWJpdCBlbmRw
b2ludHMNCj4+Pj4+Pj4+ICAgICAgICAgPiA+ZnJvbSBiZWluZyBhYmxlIHRvIHNldCB0aGUgZXNu
ZXQgbmFtZXNwYWNlLg0KPj4+SSBhYnNvbHV0ZWx5DQo+Pj4+Pj4+PiAgICAgICAgID4gPmJlbGll
dmUgaXQgd2lsbCBub3QgYmUgbmVlZGVkIG1vc3Qgb2YgdGhlDQo+Pj50aW1lLCBidXQgSSBiZWxp
ZXZlDQo+Pj4+Pj4+PiAgICAgICAgID4gPmlmIHNvbWVvbmUgZG9lcyBmaW5kIGEgdmFsaWQgdXNl
IGZvcg0KPj4+ZW5kcG9pbnRzIHRvIG1hcmsNCj4+Pj4+Pj4+ICAgICAgICAgPiA+cHJpb3JpdHkg
aW4gU0lQLCB0aGlzIElEIC0gb25jZSBpdCBoYXMNCj4+PmJlY29tZSBhbiBSRkMgLS0gd2lsbA0K
Pj4+Pj4+Pj4gICAgICAgICA+ID5oYXZlIHRvIGJlIG9ic29sZXRlZCB3aXRoIGEgbmV3IFJGQyBz
YXlpbmcgdGhlIGV4YWN0DQo+Pj4+Pj5vcHBvc2l0ZS4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+DQo+
Pj4+Pj4+PiAgICAgICAgID4gPihjb2xvciBtZSBjb25mdXNlZCAuLi4gb3ZlciBhbmQgb3ZlciBh
Z2FpbikNCj4+Pj4+Pj4+ICAgICAgICAgPiA+DQo+Pj4+Pj4+PiAgICAgICAgID4gPkphbWVzDQo+
Pj4+Pj4+PiAgICAgICAgID4gPg0KPj4+Pj4+Pj4gICAgICAgICA+ID5BdCAwMTowNSBQTSAyLzUv
MjAwOSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+Pj4+Pj4+PiAgICAgICAgID4gPj5LZWl0
aCwgcGxlYXNlIHVuZGVyc3RhbmQgdGhhdCB0aGUgdXNhZ2Ugb2YgUkZDIDQ0MTINCj4+Pj4+PmZv
ciBHRVRTIGFuZA0KPj4+Pj4+Pj5mb3INCj4+Pj4+Pj4+ICAgICAgICAgPiA+PnRoZSB0eXBlIG9m
IGVtZXJnZW5jeSBjYWxsIHdlIGRpc2N1c3MgaGVyZSBpcw0KPj4+Pj4+ZGlmZmVyZW50LiBKdXN0
DQo+Pj4+Pj4+Pmxvb2tpbmcNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PmF0IHRoZSBoZWFkZXIgYW5k
IHRoZSBuYW1lIG9mIHRoZSBuYW1lc3BhY2UgaXMgYSBiaXQNCj4+Pj4+Pj4+ICAgICAgICAgPiA+
YXJ0aWZpY2lhbC4gSSBob3BlDQo+Pj4+Pj4+PiAgICAgICAgID4gPj55b3UgdW5kZXJzdGFuZCB0
aGF0Lg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPkZyb206IERSQUdF
LCBLZWl0aCAoS2VpdGgpDQo+Pj4+Pj4+PlttYWlsdG86ZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29t
XQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID5TZW50OiAwNSBGZWJydWFyeSwgMjAwOSAxNDo1NQ0K
Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID5UbzogQnJpYW4gUm9zZW47ICdIYW5uZXMgVHNjaG9mZW5p
Zyc7ICdKYW1lcyBNLg0KPj4+Pj4+Pj5Qb2xrJzsgJ1RzY2hvZmVuaWcsDQo+Pj4+Pj4+PiAgICAg
ICAgID4gPj4gPkhhbm5lcyAoTlNOIC0gRkkvRXNwb28pJzsgJ0VDUklUJw0KPj4+Pj4+Pj4gICAg
ICAgICA+ID4+ID5TdWJqZWN0OiBSRTogW0Vjcml0XSBFQ1JJVCBWaXJ0dWFsIEludGVyaW0NCj4+
Pj4+Pj4+TWVldGluZzogQWdlbmRhIChteQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+
PiA+bWlzdGFrZSkNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+DQo+Pj4+Pj4+PiAgICAgICAgID4g
Pj4gPldoaWNoIGlzIGV4YWN0bHkgd2hhdCBSRkMgNDQxMiBzcGVjaWZpZXMgZm9yIGFsbA0KPj4+
Pj4+bmFtZXNwYWNlcy4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+DQo+Pj4+Pj4+PiAgICAgICAg
ID4gPj4gPnJlZ2FyZHMNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+DQo+Pj4+Pj4+PiAgICAgICAg
ID4gPj4gPktlaXRoDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPg0KPj4+Pj4+Pj4gICAgICAgICA+
ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4g
Pj4gRnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZw0KPj4+Pj4+W21haWx0bzplY3JpdC1ib3Vu
Y2VzQGlldGYub3JnXQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID5PbiBCZWhhbGYNCj4+Pj4+Pj4+
ICAgICAgICAgPiA+PiA+PiBPZiBCcmlhbiBSb3Nlbg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+
IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDQsIDIwMDkgMTA6MTkgUE0NCj4+Pj4+Pj4+ICAg
ICAgICAgPiA+PiA+PiBUbzogJ0hhbm5lcyBUc2Nob2ZlbmlnJzsgJ0phbWVzIE0uDQo+Pj5Qb2xr
JzsgJ1RzY2hvZmVuaWcsDQo+Pj4+Pj4+PiAgICAgICAgID4gPkhhbm5lcyAoTlNODQo+Pj4+Pj4+
PiAgICAgICAgID4gPj4gPj4gLSBGSS9Fc3BvbyknOyAnRUNSSVQnDQo+Pj4+Pj4+PiAgICAgICAg
ID4gPj4gPj4gU3ViamVjdDogUmU6IFtFY3JpdF0gRUNSSVQgVmlydHVhbCBJbnRlcmltDQo+Pj4+
Pj4+Pk1lZXRpbmc6IEFnZW5kYSAobXkNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBtaXN0YWtl
KQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gVGhl
IHZhbHVlIGlzIHRoYXQgaW4gc29tZSBuZXR3b3Jrcw0KPj4+d2hlcmUgcHJpb3JpdHkgZm9yDQo+
Pj4+Pj4+PiAgICAgICAgID4gPj4gPmVtZXJnZW5jeSBjYWxscw0KPj4+Pj4+Pj4gICAgICAgICA+
ID4+ID4+IGlzIGFwcHJvcHJpYXRlLCBhbmQgYXBwcm9wcmlhdGUNCj4+PnBvbGljaW5nIG9mIG1h
cmtpbmcgaXMNCj4+Pj4+Pj4+ICAgICAgICAgPiA+aW1wbGVtZW50ZWQsDQo+Pj4+Pj4+PiAgICAg
ICAgID4gPj4gPj4gZW1lcmdlbmN5IGNhbGxzIHdpbGwgcmVjZWl2ZSByZXNvdXJjZSBwcmlvcml0
eS4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+Pg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IE5v
dCBhbGwgbmV0d29ya3Mgd291bGQgbmVlZCBwb2xpY2luZy4gIFNvbWUNCj4+Pj4+PndpbGwuICBQ
b2xpY2luZw0KPj4+Pj4+Pj5jb3VsZA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IGJlIHRvIFJv
dXRlIGhlYWRlci9SLVVSSSBjb250ZW50LCBidXQgb3RoZXINCj4+Pj4+PmNyaXRlcmlhIGFyZQ0K
Pj4+Pj4+Pj5wb3NzaWJsZS4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+Pg0KPj4+Pj4+Pj4gICAg
ICAgICA+ID4+ID4+IE5vdCBhbGwgbmV0d29ya3Mgd2lsbCBuZWVkIHJlc291cmNlIHByaW9yaXR5
DQo+Pj4+Pj5mb3IgZW1lcmdlbmN5DQo+Pj4+Pj4+PmNhbGxzLg0KPj4+Pj4+Pj4gICAgICAgICA+
ID4+ID4+IEZpbmUsIGlnbm9yZSB0aGlzIG1hcmtpbmcvbmFtZXNwYWNlLg0KPj4+Pj4+Pj4gICAg
ICAgICA+ID4+ID4+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gQnJpYW4NCj4+Pj4+Pj4+ICAg
ICAgICAgPiA+PiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+PiAgICAg
ICAgID4gPj4gPj4gPiBGcm9tOiBIYW5uZXMgVHNjaG9mZW5pZw0KPj4+Pj4+Pj5bbWFpbHRvOkhh
bm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXRdDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiBTZW50
OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDA5IDU6MDkgUE0NCj4+Pj4+Pj4+ICAgICAgICAg
PiA+PiA+PiA+IFRvOiAnQnJpYW4gUm9zZW4nOyAnSmFtZXMgTS4gUG9sayc7DQo+Pj4+Pj5Uc2No
b2ZlbmlnLCBIYW5uZXMNCj4+Pj4+Pj4+KE5TTiAtDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4g
PiBGSS9Fc3Bvbyk7ICdFQ1JJVCcNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+IFN1YmplY3Q6
IFJFOiBbRWNyaXRdIEVDUklUIFZpcnR1YWwgSW50ZXJpbQ0KPj4+Pj4+Pj5NZWV0aW5nOiBBZ2Vu
ZGEgKG15DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiBtaXN0YWtlKQ0KPj4+Pj4+Pj4gICAg
ICAgICA+ID4+ID4+ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+IEkgZG9uJ3QgZXZlbiBz
ZWUgdGhlIHZhbHVlIGluIHBlcm1pdHRpbmcgdGhlDQo+Pj4+Pj5lbmRwb2ludCB0b2RvDQo+Pj4+
Pj4+PnRoZQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gUlBIIG1hcmtpbmcuDQo+Pj4+Pj4+
PiAgICAgICAgID4gPj4gPj4gPiBJbiBhZGRpdGlvbiB0byB0aGUgc2VjdXJpdHkgY29uY2VybnMN
Cj4+PnRoZXJlIGlzIGFsc28gdGhlDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPnByb2JsZW0gdGhh
dA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gdGhlcmUgYXJlIG1vcmUgb3B0aW9ucyB0byBp
bXBsZW1lbnQgd2l0aG91dA0KPj4+Pj4+YW4gYWRkaXRpb25hbA0KPj4+Pj4+Pj52YWx1ZS4NCj4+
Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+LS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID5Gcm9t
OiBCcmlhbiBSb3NlbiBbbWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0XQ0KPj4+Pj4+Pj4gICAgICAg
ICA+ID4+ID4+ID4gPlNlbnQ6IDA1IEZlYnJ1YXJ5LCAyMDA5IDAwOjAzDQo+Pj4+Pj4+PiAgICAg
ICAgID4gPj4gPj4gPiA+VG86ICdKYW1lcyBNLiBQb2xrJzsgJ0hhbm5lcyBUc2Nob2ZlbmlnJzsN
Cj4+Pj4+PidUc2Nob2ZlbmlnLA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IEhhbm5lcyAoTlNO
IC0NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID5GSS9Fc3BvbyknOyAnRUNSSVQnDQo+Pj4+
Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+U3ViamVjdDogUkU6IFtFY3JpdF0gRUNSSVQgVmlydHVh
bA0KPj4+SW50ZXJpbSBNZWV0aW5nOg0KPj4+Pj4+Pj5BZ2VuZGEgKG15DQo+Pj4+Pj4+PiAgICAg
ICAgID4gPj4gPj4gPiBtaXN0YWtlKQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPg0KPj4+
Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPkhhbm5lcw0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+
ID4gPg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPlRoaXMgbWF0Y2hlcyBteSB1bmRlcnN0
YW5kaW5nDQo+Pj5wcmVjaXNlbHkuICBXZSB3aXNoIHRvDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4g
Pj4gcGVybWl0IGVuZHBvaW50cw0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPnRvIG1hcmsu
IFdlIGRvIG5vdCByZXF1aXJlIGl0LCBhbmQNCj4+PmRvbid0IG5lY2Vzc2FyaWx5DQo+Pj4+Pj4+
PmV4cGVjdCBpdA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPmluIG1hbnkgKGV2ZW4NCj4+
Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID5tb3N0KSBjYXNlcy4gIFdlIGRvbid0IHdpc2ggdG8g
c2VlIHRoZQ0KPj4+Pj4+ZG9jdW1lbnQgcHJvaGliaXQNCj4+Pj4+Pj4+aXQuDQo+Pj4+Pj4+PiAg
ICAgICAgID4gPj4gPj4gPiA+V2UgYWxsIHNlZW0gdG8gYWdyZWUgaXQgaGFzIHZhbHVlIHdpdGhp
biB0aGUNCj4+Pj4+PkVtZXJnZW5jeQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID5TZXJ2aWNlcyBJ
UA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPk5ldHdvcmtzLg0KPj4+Pj4+Pj4gICAgICAg
ICA+ID4+ID4+ID4gPg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPkJyaWFuDQo+Pj4+Pj4+
PiAgICAgICAgID4gPj4gPj4gPiA+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gRnJv
bTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZw0KPj4+Pj4+Pj5bbWFpbHRvOmVjcml0LWJvdW5jZXNA
aWV0Zi5vcmddDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+T24gQmVoYWxmDQo+Pj4+Pj4+
PiAgICAgICAgID4gPj4gPj4gPiA+PiBPZiBKYW1lcyBNLiBQb2xrDQo+Pj4+Pj4+PiAgICAgICAg
ID4gPj4gPj4gPiA+PiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDA5IDQ6MDEgUE0N
Cj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IFRvOiBIYW5uZXMgVHNjaG9mZW5pZzsgVHNj
aG9mZW5pZywNCj4+Pkhhbm5lcyAoTlNOIC0NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBGSS9F
c3Bvbyk7ICdFQ1JJVCcNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IFN1YmplY3Q6IFJl
OiBbRWNyaXRdIEVDUklUIFZpcnR1YWwgSW50ZXJpbQ0KPj4+Pj4+Pj5NZWV0aW5nOg0KPj4+Pj4+
Pj4gICAgICAgICA+ID5BZ2VuZGEgKG15DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBt
aXN0YWtlKQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4NCj4+Pj4+Pj4+ICAgICAgICAg
PiA+PiA+PiA+ID4+IEF0IDAyOjM3IFBNIDIvNC8yMDA5LCBIYW5uZXMNCj4+PlRzY2hvZmVuaWcg
d3JvdGU6DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiA+ID4gSmFtZXMgd3JvdGU6DQo+
Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiA+ID4+IHlvdSBhcmUgdGhlIF9sb25lXyB2b2lj
ZSBub3QNCj4+Pj4+PnN1cHBvcnRpbmcgdGhpcyBJRCwNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+
PiA+ID4+ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID5MaXN0ZW5pbmcgdG8gdGhl
IGF1ZGlvIHJlY29yZGluZyBvZiBwYXN0DQo+Pj4+Pj5tZWV0aW5ncyBJDQo+Pj4+Pj4+PmhhdmUg
dG8NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID5zYXkgdGhhdA0KPj4+Pj4+Pj4gICAgICAg
ICA+ID4+ID4+ID4gPj4gPkkNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHdhcw0KPj4+
Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gPm5vdCB0aGUgb25seSBwZXJzb25zIHJhaXNpbmcN
Cj4+PmNvbmNlcm5zIGFib3V0IHRoZQ0KPj4+Pj4+Pj5kb2N1bWVudC4NCj4+Pj4+Pj4+ICAgICAg
ICAgPiA+PiA+PiA+ID4+ID5UaGF0IHdhcyBwcm9iYWJseSB0aGUgcmVhc29uIHdoeSB5b3UNCj4+
Pj4+PmFncmVlZCB0byBsaW1pdA0KPj4+Pj4+Pj50aGUNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+
PiA+ID5zY29wZSBvZiB0aGUNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID5kb2N1bWVu
dCAod2hpY2ggeW91IGRpZG4ndCBsYXRlciBkbykgdG8NCj4+Pj4+PmdldCBmb2xrcyB0bw0KPj4+
Pj4+Pj5hZ3JlZQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPnRvIG1ha2UgaXQNCj4+Pj4+
Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IGEgV0cNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+
ID4+ID5pdGVtLg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4NCj4+Pj4+Pj4+ICAgICAg
ICAgPiA+PiA+PiA+ID4+IHJlLWxpc3RlbiB0byB0aGUgYXVkaW8gcGxlYXNlDQo+Pj4+Pj4+PiAg
ICAgICAgID4gPj4gPj4gPiA+Pg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gVGVkJ3Mg
Y29uY2VybnMgd2VyZSBjb25zaXN0ZW50IHdpdGggbW9zdA0KPj4+Pj4+Pj4oYWxsPykgb3RoZXIN
Cj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBjb25jZXJucyAtLQ0KPj4+Pj4+Pj4gICAgICAgICA+
ID4+ID4+ID4gPj4gd2hpY2ggd2VyZSBiYXNlZCBvbiB0aGUgcHJlbWlzZSBvZiB3aGV0aGVyDQo+
Pj4+Pj5vciBub3QgdGhlDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gVUFDIHNob3VsZCBiZQ0K
Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gdHJ1c3RlZCB0byBpbml0aWF0ZSB0aGUgbWFy
a2luZyBvbiB0aGUNCj4+Pj4+PklOVklURS4gIFRoZQ0KPj4+Pj4+Pj5tb3N0DQo+Pj4+Pj4+PiAg
ICAgICAgID4gPj4gPj4gPiA+PiByZWNlbnQgdmVyc2lvbiBoYXMgYmFja2VkIG9mZiB0aGlzDQo+
Pj50byBhICJjYW4iIC0tDQo+Pj4+Pj4+Pm1lYW5pbmcgbm90DQo+Pj4+Pj4+PiAgICAgICAgID4g
Pj4gPnByb2hpYml0ZWQNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IChpLmUuLCBubyAy
MTE5IHRleHQpLiAgSSBhbHNvIGJhY2tlZCBvZmYNCj4+Pj4+PnRoZSB0ZXh0IGluDQo+Pj4+Pj4+
PnRoZQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IFNQIGRvbWFpbg0KPj4+Pj4+Pj4gICAgICAg
ICA+ID4+ID4+ID4gPj4gcGFydCB0byAiY2FuIiwgc3VjaCB0aGF0IHRoZXJlIGlzDQo+Pj5ubyAy
MTE5IHRleHQNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+bWFuZGF0aW5nIG9yIGV2ZW4NCj4+Pj4+
Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHJlY29tbWVuZGluZyBpdHMgdXNhZ2UgdGhlcmUuIEkg
YWxzbyBkbw0KPj4+Pj4+bm90IHByb2hpYml0DQo+Pj4+Pj4+Pml0cw0KPj4+Pj4+Pj4gICAgICAg
ICA+ID4+ID4+ID4gPnVzZSwgYmFzZWQgb24NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+
IGxvY2FsIHBvbGljeS4gIEtlaXRoIGhhcyBjb21lIGZvcndhcmQgd2l0aA0KPj4+Pj4+dGhlIHNw
ZWNpZmljDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gcmVxdWVzdCB0
aGF0IG5vbi1FU0luZXQgbmV0d29ya3MgYmUNCj4+Pj4+PmFsbG93ZWQgdG8gbWFyayBhbmQNCj4+
Pj4+Pj4+cGF5DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPmF0dGVudGlvbiB0bw0KPj4+Pj4+Pj4g
ICAgICAgICA+ID4+ID4+ID4gPj4gdGhpcyBwcmlvcml0eSBpbmRpY2F0aW9uIC0tIHdpdGggSU1T
IGFzDQo+Pj4+Pj50aGUgc3BlY2lmaWMNCj4+Pj4+Pj4+ZXhhbXBsZQ0KPj4+Pj4+Pj4gICAgICAg
ICA+ID4+ID4+ID4gPj4gaGUgd2lzaGVzIHRvIGhhdmUgdGhpcyB2YWxpZCBmb3IuDQo+Pj4+Pj4+
PiAgICAgICAgID4gPj4gPj4gPiA+Pg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gV2hl
cmUgdGhlcmUgaXMgbm8gZGlzYWdyZWVtZW50LCBzYXZlIGZvcg0KPj4+Pj4+eW91ciByZWNlbnQN
Cj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID5wdXNoYmFjayAtIGlzIGluDQo+Pj4+Pj4+PiAg
ICAgICAgID4gPj4gPj4gPiA+PiB0aGUgRVNJbmV0LCB3aGljaCBpcyB3aGVyZSBCcmlhbg0KPj4+
aGFzIHJlcXVlc3RlZCBpdCdzDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+ZGVmaW5pdGlv
biBpbiB0aGUNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IElFVEYgb24gYmVoYWxmIG9m
IE5FTkEuICBIZSdzIHRoZSBpMyBXRw0KPj4+Pj4+Y2hhaXIgd2l0aGluDQo+Pj4+Pj4+PiAgICAg
ICAgID4gPj4gPj4gTkVOQSwgYW5kIGlmDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBo
ZSBhc2tzIGZvciBpdCwgYXJlIHlvdSBnb2luZyB0byBzYXkgeW91DQo+Pj4+Pj5rbm93IGJldHRl
cg0KPj4+Pj4+Pj50aGFuIGhlPw0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4NCj4+Pj4+
Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiA+
QnR3LCBJIG5vdCBkaXNhZ3JlZWluZyB3aXRoIHRoZSBkb2N1bWVudA0KPj4+Pj4+YXMgc3VjaC4g
SQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID5qdXN0IHdhbnQgdG8NCj4+Pj4+Pj4+ICAgICAgICAg
PiA+PiA+PiA+IHRoZQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gc2NvcGUNCj4+Pj4+
Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID50byBjaGFuZ2UuIFRoZSB1c2FnZSBvZiBSUEgNCj4+
PndpdGhpbiB0aGUgZW1lcmdlbmN5DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gc2VydmljZXMg
bmV0d29yaw0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gaXMNCj4+Pj4+Pj4+ICAgICAgICAg
PiA+PiA+PiA+ID4+IGZpbmUNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID5mb3IgbWUu
IEkgbWF5IGdldCBjb252aW5jZWQgdG8gc3RhcnQgdGhlDQo+Pj4+Pj5SUEggbWFya2luZw0KPj4+
Pj4+Pj5mcm9tDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+dGhlIHRoZSBWU1ANCj4+Pj4+
Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID50b3dhcmRzIHRoZSBQU0FQLiBJIGZlZWwgdW5lYXN5
IGFib3V0IHRoZQ0KPj4+Pj4+ZW5kIGhvc3QNCj4+Pj4+Pj4+ZG9pbmcNCj4+Pj4+Pj4+ICAgICAg
ICAgPiA+PiA+PiA+ID50aGUgbWFya2luZy4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+
DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBwbGVhc2UgcmVhZCB3aGF0IEkgd3JvdGUg
YWJvdmUsIGFuZCB0aGVuDQo+Pj4+Pj5yZS1yZWFkIHRoZQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+
ID5tb3N0IHJlY2VudA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gdmVyc2lvbiBvZiB0
aGUgSUQuIEkgZG9uJ3QgaGF2ZSBlbmRwb2ludHMNCj4+Pj4+PnRoYXQgU0hPVUxEDQo+Pj4+Pj4+
Pm9yDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gTVVTVCBtYXJrDQo+Pj4+Pj4+PiAgICAgICAg
ID4gPj4gPj4gPiA+PiBhbnl0aGluZyB3cnQgUlBILiAgSSBhbHNvIGRvbid0IHdhbnQgdG8NCj4+
Pj4+PnByb2hpYml0IGl0LA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IGJlY2F1c2UgdGhlcmUN
Cj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IG1pZ2h0IGJlIGNhc2VzICh0aGF0IEkgZG9u
J3Qga25vdw0KPj4+b2YpIG9mIHZhbGlkIHVzZXMNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiB1
bmRlciBjZXJ0YWluDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBjaXJjdW1zdGFuY2Vz
LiAgRmlndXJlIDEgaXMgdmVyeSBjbGVhcg0KPj4+Pj4+dGhhdCB0aGVyZSBhcmUgMw0KPj4+Pj4+
Pj4gICAgICAgICA+ID4+ID4+IG5ldHdvcmtpbmcNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+
ID4+IHBhcnRzIHRvIGNvbnNpZGVyDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+Pg0KPj4+
Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gIzEgLSBmcm9tIHRoZSBlbmRwb2ludA0KPj4+Pj4+
Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gIzIgLSB3aXRoaW4gdGhlIFZTUA0KPj4+Pj4+Pj4gICAg
ICAgICA+ID4+ID4+ID4gPj4gIzMgLSB3aXRoaW4gdGhlIEVTSW5ldA0KPj4+Pj4+Pj4gICAgICAg
ICA+ID4+ID4+ID4gPj4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHRoZSBtb3N0IHJl
Y2VudCBJRCB2ZXJzaW9uIGhhcyAiY2FuIiBmb3INCj4+Pj4+PiNzIDEgYW5kIDIsDQo+Pj4+Pj4+
PmFuZA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPjIxMTkgbGFuZ3VhZ2UNCj4+Pj4+Pj4+
ICAgICAgICAgPiA+PiA+PiA+ID4+IG9mZmVyaW5nIHRob3NlIHN1cHBvcnRpbmcgdGhpcw0KPj4+
Pj4+c3BlY2lmaWNhdGlvbiB3aWxsIGhhdmUNCj4+Pj4+Pj4+UlBIDQo+Pj4+Pj4+PiAgICAgICAg
ID4gPj4gPj4gPiA+PiBhZGhlcmVuY2Ugd2l0aGluICMzICh0aGUgRVNJbmV0KS4NCj4+Pj4+Pj4+
ICAgICAgICAgPiA+PiA+PiA+ID4+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBXaGF0
IG90aGVyIHNjb3BlIGNoYW5nZXMgZG8geW91IHdhbnQsDQo+Pj4+Pj5iZWNhdXNlIEkgaGF2ZW4n
dA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IGhlYXJkIHRoZW0uDQo+Pj4+Pj4+PiAgICAgICAg
ID4gPj4gPj4gPiA+Pg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gSSBvbmx5IGhlYXJk
IHlvdSBjbGFpbSBpbiBlbWFpbCBkdXJpbmcgdGhlDQo+Pj4+Pj5sYXN0IElFVEYNCj4+Pj4+Pj4+
YW5kIGluDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+dGhlIEVDUklUDQo+Pj4+Pj4+PiAg
ICAgICAgID4gPj4gPj4gPiA+PiBzZXNzaW9uIHRoYXQgUlBIIHNob3VsZCBub3QgYmUNCj4+PnVz
ZWQgZm9yIHByaW9yaXR5DQo+Pj4+Pj4+Pm1hcmtpbmcNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+
PiByZXF1ZXN0cy4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IFRoaXMgaXMgc29tZXRo
aW5nIEtlaXRoIChTSVAgV0cNCj4+PmNoYWlyKSB2b2ljZWQgaGlzDQo+Pj4+Pj4+Pm9wcG9zaXRp
b24NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHRvIHlvdXIgdmlld3MgcmVnYXJkaW5n
IGNyZWF0aW5nIGEgc2Vjb25kDQo+Pj4+Pj5tZWFucyBmb3IgU0lQDQo+Pj4+Pj4+PnRvDQo+Pj4+
Pj4+PiAgICAgICAgID4gPj4gPnByaW9yaXR5DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+
PiBtYXJrIHJlcXVlc3QgIndoZW4gU0lQIGFscmVhZHkgaGFzIG9uZQ0KPj4+Pj4+aW50ZXJvcGVy
YWJsZQ0KPj4+Pj4+Pj53YXkgdG8NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IGFjY29t
cGxpc2ggdGhpcy4uLiBpdCdzIGNhbGwgdGhlIFJQIGhlYWRlcg0KPj4+Pj4+bWVjaGFuaXNtIi4N
Cj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4g
PiA+PiA+SSBkb24ndCBzZWUgYWR2YW50YWdlcyAtLSBvbmx5DQo+Pj5kaXNhZHZhbnRhZ2VzLg0K
Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gPg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+
ID4gPj4gPkNpYW8NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID5IYW5uZXMNCj4+Pj4+
Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+Pg0K
Pj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+
Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IEVjcml0IG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4gICAg
ICAgICA+ID4+ID4+ID4gPj4gRWNyaXRAaWV0Zi5vcmcNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+
PiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+Pj4+
Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+Pg0KPj4+Pj4+
Pj4gICAgICAgICA+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+
Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gRWNyaXRAaWV0Zi5vcmcNCj4+Pj4+Pj4+ICAgICAgICAg
PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+Pj4+
Pj4+PiAgICAgICAgID4gPj4gPj4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+DQo+Pj4+Pj4+PiAg
ICAgICAgID4gPg0KPj4+Pj4+Pj4gICAgICAgICA+DQo+Pj4+Pj4+PiAgICAgICAgID4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+ICAgICAg
ICAgPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+ICAgICAgICAgPiBFY3JpdEBpZXRmLm9y
Zw0KPj4+Pj4+Pj4gICAgICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vZWNyaXQNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+RWNyaXQgbWFp
bGluZyBsaXN0DQo+Pj4+Pj4+PkVjcml0QGlldGYub3JnDQo+Pj4+Pj4+Pmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+Pj4+Pj4NCj4+Pj4+Pj5fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PkVjcml0IG1haWxp
bmcgbGlzdA0KPj4+Pj4+PkVjcml0QGlldGYub3JnDQo+Pj4+Pj4+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPj4+Pj4NCj4+Pj4+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+RWNyaXQgbWFpbGluZyBsaXN0DQo+
Pj4+PkVjcml0QGlldGYub3JnDQo+Pj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZWNyaXQNCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+PkVjcml0IG1haWxpbmcgbGlzdA0KPj5FY3JpdEBpZXRmLm9yZw0KPj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+Pg0KPj4NCj4+LS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PlRoaXMgbWVzc2FnZSBpcyBmb3Ig
dGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KPj5jb250YWluIHByaXZpbGVn
ZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4NCj4+SWYg
eW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0K
Pj5pbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQg
dXNlIG9mDQo+PnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCj4+LS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PlttZjJdDQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+RWNyaXQgbWFpbGluZyBsaXN0DQo+RWNy
aXRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0
DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFY3Jp
dCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2Vjcml0DQo=


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B817E3A6C96 for <[e-mail]>; Fri,  6 Feb 2009 14:15:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.17
X-Spam-Level: 
X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=-0.171,  BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLq5RyjmWx7d for <[e-mail]>; Fri,  6 Feb 2009 14:15:55 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 11D583A6C7E for <[e-mail]>; Fri,  6 Feb 2009 14:15:55 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,393,1231113600"; d="scan'208";a="139068387"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 06 Feb 2009 22:15:57 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n16MFv1d032344;  Fri, 6 Feb 2009 14:15:57 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n16MFv4g007916; Fri, 6 Feb 2009 22:15:57 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 14:15:57 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 14:15:55 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 06 Feb 2009 16:15:54 -0600
To: Ted Hardie <[e-mail]>, Henning Schulzrinne <[e-mail]>, "Winterbottom, James" <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <p0624080ac5b25a5b6f64@[10.227.68.59]>
References: <000701c9883c$59b095d0$[e-mail]> <OFB3ABC009.AA6A83E9-ON85257 [e-mail]> <001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$[e-mail]> <[e-mail]> <[e-mail]> <p0624080ac5b25a5b6f64@[10.227.68.59]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 06 Feb 2009 22:15:55.0650 (UTC) FILETIME=[7B03CE20:01C988A8]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=42153; t=1233958557; x=1234822557; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=4VQ8OUddTb6yBmOu+DftaoHXTyqQG77tPLVgt6ioGxE=; b=eMSc8S4QnYgck7hFjDAu/xDzzsyfo45+6m0IAQoTskU7AMAJ9SrzJamd62 V1rjWdI3l8S8cFpRtTSDUcQQI6kueecdOHtI21zRK0ATWh9ls7SNEezEZSXc bVRO9QHGGx;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 22:15:58 -0000

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: [e-mail] 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:[e-mail]]
> >>> 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:[e-mail]]
> >>>> 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: [e-mail] [mailto:[e-mail]]
> >>>>>> 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-
> >>>>>>> [e-mail]
> >>>>>>> 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: [e-mail] [mailto:[e-mail]] On
> >>>>>>>> Behalf Of Hannes Tschofenig
> >>>>>>>> Sent: 06 February, 2009 15:07
> >>>>>>>> To: 'Janet P Gunn'
> >>>>>>>> Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
> >>>>>>>>         Sent: 06 February, 2009 14:11
> >>>>>>>>         To: Hannes Tschofenig
> >>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >>>>>>>> [e-mail]; 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.
> >>>>>>>>
> >>>>>>>>         [e-mail] 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:[e-mail]]
> >>>>>>>>         > >> >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: [e-mail]
> >>>>>> [mailto:[e-mail]]
> >>>>>>>>         > >> >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:[e-mail]]
> >>>>>>>>         > >> >> > 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:[e-mail]]
> >>>>>>>>         > >> >> > >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: [e-mail]
> >>>>>>>> [mailto:[e-mail]]
> >>>>>>>>         > >> >> > >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
> >>>>>>>>         > >> >> > >> [e-mail]
> >>>>>>>>         > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>         > >> >> > >
> >>>>>>>>         > >> >>
> >>>>>>>>         > >> >> _______________________________________________
> >>>>>>>>         > >> >> Ecrit mailing list
> >>>>>>>>         > >> >> [e-mail]
> >>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>         > >> >>
> >>>>>>>>         > >> >
> >>>>>>>>         > >
> >>>>>>>>         >
> >>>>>>>>         > _______________________________________________
> >>>>>>>>         > Ecrit mailing list
> >>>>>>>>         > [e-mail]
> >>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Ecrit mailing list
> >>>>>>>> [e-mail]
> >>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Ecrit mailing list
> >>>>>>> [e-mail]
> >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Ecrit mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>
> >>>
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> [e-mail]
> >> 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
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ecrit
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D412C3A6CA0 for <[e-mail]>; Fri,  6 Feb 2009 14:21:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.466
X-Spam-Level: 
X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCdbxiVUtq5i for <[e-mail]>; Fri,  6 Feb 2009 14:21:10 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E40683A6C9C for <[e-mail]>; Fri,  6 Feb 2009 14:21:09 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,393,1231113600"; d="scan'208";a="129615356"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 06 Feb 2009 22:21:12 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n16MLCpo008721;  Fri, 6 Feb 2009 14:21:12 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n16MLCoK012896; Fri, 6 Feb 2009 22:21:12 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 14:21:12 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 14:21:11 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 06 Feb 2009 16:21:10 -0600
To: Henning Schulzrinne <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]> <[e-mail]> <001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 06 Feb 2009 22:21:11.0666 (UTC) FILETIME=[37600520:01C988A9]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3230; t=1233958872; x=1234822872; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=gDKMJQFH4ymODMEF0eYbQNqUAJqTmIWtI+bK2Ph8Hvk=; b=T27xVXRYqQ1/pDjxcProqxZ2f5WsJOiWhGTLAOESNhPmoaBmV1YA1RYThu sDFog4wN50lQzWPyoVfKMD1Da6G5fQWA9jOhuZ2YRgENgaWR0ZSUQUcRlxWc 0tgXoSE5fU;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 22:21:10 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814C83A6CA4 for <[e-mail]>; Fri,  6 Feb 2009 14:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.679
X-Spam-Level: 
X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFEzMb5o-bYO for <[e-mail]>; Fri,  6 Feb 2009 14:29:28 -0800 (PST)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 9635A3A6A1D for <[e-mail]>; Fri,  6 Feb 2009 14:29:28 -0800 (PST)
Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n16MT97P024659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Feb 2009 17:29:09 -0500 (EST)
Message-Id: <[e-mail]>
From: Henning Schulzrinne <[e-mail]>
To: "James M. Polk" <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 6 Feb 2009 17:29:09 -0500
References: <000701c9883c$59b095d0$[e-mail]> <[e-mail]> <001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8
Cc: ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 22:29:32 -0000

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...



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200E93A684F for <[e-mail]>; Fri,  6 Feb 2009 14:37:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.469
X-Spam-Level: 
X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG11DK55MXLU for <[e-mail]>; Fri,  6 Feb 2009 14:37:28 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EAB173A6967 for <[e-mail]>; Fri,  6 Feb 2009 14:37:27 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,393,1231113600"; d="scan'208";a="244588395"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Feb 2009 22:37:30 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n16MbRlp001407;  Fri, 6 Feb 2009 14:37:30 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n16MbRAF004496; Fri, 6 Feb 2009 22:37:27 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 14:37:27 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 14:37:27 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 06 Feb 2009 16:37:26 -0600
To: Henning Schulzrinne <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]> <[e-mail]> <001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 06 Feb 2009 22:37:27.0173 (UTC) FILETIME=[7CD29350:01C988AB]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2610; t=1233959850; x=1234823850; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=s7EWmWmtvCfr1fmgTZwa3KlESx3jlf0u5HZpgYXbRhU=; b=ja0pWf51mye33lkFsJv9ImHKs/HkHSzxGkwc2ucjq83OOtxtNQJNzSVVFv tAH5PeFrAMrdWvy5oyvdqeIlF9NZ2Tb6YXs3cpBgYTCwsW4Ut8V6trQVG7pF GqQPifsZEInoX5/BGrJ/8EFqAInHAWnltwxGd6QIzX1kk9NKyL7is=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Cc: ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 22:37:29 -0000

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...



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254B23A6C9F for <[e-mail]>; Fri,  6 Feb 2009 14:46:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.208
X-Spam-Level: 
X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[AWL=-0.909, BAYES_00=-2.599, MANGLED_EMRG=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxwuUsWEcKCQ for <[e-mail]>; Fri,  6 Feb 2009 14:46:08 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D76523A6C98 for <[e-mail]>; Fri,  6 Feb 2009 14:46:07 -0800 (PST)
Received: (qmail invoked by alias); 06 Feb 2009 22:46:08 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp049) with SMTP; 06 Feb 2009 23:46:08 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/DRYgNT4XDoU/ax14u2Rvc0GOhUtsphtHzAwIQZv sah5oNO/obM/zn
From: "Hannes Tschofenig" <[e-mail]>
To: "'James M. Polk'" <[e-mail]>
References: <[e-mail]> <000801c98708$5973f6f0$[e-mail]> <[e-mail]> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$[e-mail]> <0a1101c98716$91287db0$b3797910$@net> <[e-mail]> <009701c987c4$c3cb7340$[e-mail]> <[e-mail]> <000701c9883c$59b095d0$[e-mail]> <[e-mail]>
Date: Sat, 7 Feb 2009 00:46:53 +0200
Message-ID: <000001c988ac$d0261940$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: AcmIppJ3db5pt/4hRciq0u3Zrgn8DQABfvUg
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.52
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 22:46:10 -0000

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:[e-mail]] 
>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:[e-mail]]
>> >> >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: [e-mail] [mailto:[e-mail]]
>> >> >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:[e-mail]]
>> >> >> > 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:[e-mail]]
>> >> >> > >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: [e-mail] 
>> >> >> > >> [mailto:[e-mail]]
>> >> >> > >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
>> >> >> > >> [e-mail]
>> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> > >
>> >> >>
>> >> >> _______________________________________________
>> >> >> Ecrit mailing list
>> >> >> [e-mail]
>> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>
>> >> >
>> >
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77BA3A6B3A for <[e-mail]>; Fri,  6 Feb 2009 14:50:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.449
X-Spam-Level: 
X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjaAam+Afx+x for <[e-mail]>; Fri,  6 Feb 2009 14:50:27 -0800 (PST)
Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 09B643A6C34 for <[e-mail]>; Fri,  6 Feb 2009 14:50:26 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-14.tower-167.messagelabs.com!1233960628!17371104!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 18821 invoked from network); 6 Feb 2009 22:50:28 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-14.tower-167.messagelabs.com with AES256-SHA encrypted SMTP; 6 Feb 2009 22:50:28 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n16MoR4o025051; Fri, 6 Feb 2009 17:50:27 -0500
Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n16MoPPh025023; Fri, 6 Feb 2009 17:50:25 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Fri, 6 Feb 2009 17:50:24 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] RPH
Thread-Index: AcmIqmlw2KPubKXZS3KfgX/Sk5WgMgAAuLjt
From: "DOLLY, MARTIN C, ATTLABS" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: [e-mail]
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 22:50:28 -0000

V2hhdCBuZXR3b3JrIGhhdmUgeW91IGV2ZXIgZW5naW5lZXJlZD8NCg0KLS0tLS0gT3JpZ2luYWwg
TWVzc2FnZSAtLS0tLQ0KRnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyA8ZWNyaXQtYm91bmNl
c0BpZXRmLm9yZz4NClRvOiBKYW1lcyBNLiBQb2xrIDxqbXBvbGtAY2lzY28uY29tPg0KQ2M6IEVD
UklUIDxlY3JpdEBpZXRmLm9yZz4NClNlbnQ6IEZyaSBGZWIgMDYgMTc6Mjk6MDkgMjAwOQ0KU3Vi
amVjdDogUmU6IFtFY3JpdF0gUlBIDQoNClRvIHJlc3RhdGU6IEkgd2lsbCBvYmplY3QgdG8gYW55
IHRleHQgbWVudGlvbmluZyB1c2Ugb2YgRVNORVQgaW4gVUFzLiAgDQpJdCdzIHVzZWxlc3MgKHNp
bmNlIHVuZGVyLXNwZWNpZmllZCksIGxpa2VseSB0byBiZSBoYXJtZnVsIHRvIHJlbGlhYmxlICAN
Cm5ldHdvcmsgb3BlcmF0aW9uIGFuZCBqdXN0IGNhdXNlcyBjb25mdXNpb24uIFRoZSB0ZXh0IHNo
b3VsZCBkZXNjcmliZSAgDQp3aGVuIGl0IGlzIHVzZWZ1bCAod2l0aGluIGEgImNsb3NlZCIgRVNO
RVQsIHByZXN1bWFibHkpIGFuZCB3aGF0ICANCmNvbmRpdGlvbnMgbmVlZCB0byBiZSBtZXQgaW4g
b3JkZXIgdG8gZW5zdXJlIHJlbGlhYmxlIGFuZCBzZWN1cmUgIA0KdXNhZ2UuIFRoYXQgc29tZXRo
aW5nIG1pZ2h0IGJlIHVzZWZ1bCBzb21ld2hlcmUgZWxzZSBpcyBhbHdheXMgdHJ1ZSwgIA0KaW4g
YW55IHNwZWNpZmljYXRpb24sIGJ1dCB3ZSBkb24ndCBhZGQgYSAiVGhpcyBkb2N1bWVudCBkb2Vz
IG5vdCAgDQpwcmV2ZW50IHRoZSB1c2Ugb2YgdGhpcyBtZWNoYW5pc20gc29tZXdoZXJlIGVsc2Uu
IiBpbiBkb2N1bWVudHMuDQoNCkhlbm5pbmcNCg0KT24gRmViIDYsIDIwMDksIGF0IDU6MjEgUE0s
IEphbWVzIE0uIFBvbGsgd3JvdGU6DQoNCj4gQXQgMDQ6MDUgUE0gMi82LzIwMDksIEhlbm5pbmcg
U2NodWx6cmlubmUgd3JvdGU6DQo+PiBKYW1lcywNCj4+DQo+PiB3ZSBkb24ndCBnbyB0aHJvdWdo
IGV2ZXJ5IHBvc3NpYmxlIFNJUCBoZWFkZXIgdGhhdCBtaWdodCBiZSBpbnNlcnRlZA0KPj4gaW50
byBlbWVyZ2VuY3kgcmVxdWVzdHMuIFllcywgc29tZWJvZHkgY291bGQgYWRkIFJQSCwgYnV0IHRo
aXMgIA0KPj4gYXBwbGllcw0KPj4gdG8gUEFJIGFuZCBkb3plbnMgb2Ygb3RoZXIgU0lQIGhlYWRl
cnMgYXMgd2VsbC4gU28gZmFyLCBub2JvZHkgaGFzDQo+PiBwcm92aWRlZCwgaW4gbXkgb3Bpbmlv
biwgYSBjb21wZWxsaW5nIHVzZSBjYXNlIHRoYXQgaXMgd29ydGgNCj4+IGRvY3VtZW50aW5nLiAi
SXQgY291bGQgYmUgdXNlZnVsIHNvbWV3aGVyZSBmb3Igc29tZXRoaW5nIiBkb2Vzbid0IGN1dA0K
Pj4gaXQuIEkgaGF2ZSBwcm92aWRlZCBtdWx0aXBsZSByZWFzb25zIHdoeSBJIHRoaW5rIHRoYXQg
aXQgaXMgYSBiYWQgIA0KPj4gaWRlYQ0KPj4gZm9yIChub3JtYWwpIFVBcyB0byBkbyBzbywgbm9u
ZSBvZiB3aGljaCB5b3UgYWRkcmVzcy4NCj4NCj4NCj4+IEkgc2VlIG5vIG5lZWQgdG8gIHNheSAi
ZG8gbm90IGluc2VydCBSUEgiLA0KPg0KPiB0aGlzIGlzIHRoZSBvbmx5IHRoaW5nIC0gcmlnaHQg
bm93IC0gdGhhdCBJJ20gYWZyYWlkIG9uZSBvZiB1cyAgDQo+IGJlbGlldmVzIHNob3VsZCBiZSB0
aGUgY2FzZS4gSSdtIGdsYWQgeW91IGFyZSBub3Qgam9pbmluZyB0aGF0ICANCj4gcG9zaXRpb24u
ICBJIHJlYWxseSBkbyBub3Qgd2FudCB0byBoaWdobGlnaHQgdGhlIGlkZWEgZm8gVUFzICANCj4g
aW5zZXJ0aW5nIGVzbmV0LCBidXQgSSBiZWxpZXZlIHNvbWV0aW1lIGRvd24gdGhlIHJvYWQgLSBz
b21lICANCj4gY3VzdG9tZXIgd2lsbCBjb21lIHVwIHdpdGggYSB2YWxpZCByZWFzb24gZm9yIHRo
aXMsIGFuZCBJIGRvbid0IHdhbnQgIA0KPiB0byBzdGF0ZSBpbiB0ZXh0IHRoYXQgaXQgaXMgcHJl
dmVudGVkIGZyb20gYmVpbmcgaW5zZXJ0ZWQgKGFuZCB5ZXQgIA0KPiBoYXZlIHRoZSB2ZW5kb3Ig
d2hvIHdhbnRzIHRvIHNlbGwgdG8gdGhhdCBjdXN0b21lciBhbHNvIHdhbnQgdGhhdCAgDQo+IHZl
bmRvciB0byBhZGhlcmUgdG8gdGhpcyBzcGVjIGFzIHdlbGwpLg0KPg0KPiBJJ20ganVzdCBhZHZv
Y2F0aW5nIHdlIG5vdCBoYXZlIHRoZSB0ZXh0IHByZXZlbnQgaXRzIGluY2x1c2lvbi4NCj4NCj4g
QXMgSSd2ZSBzYWlkLCBJIHdpbGwgYmVlZiB1cCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg
c2VjdGlvbiB3cnQgIA0KPiBVQSBpbnNlcnRpb24gb2YgZXNuZXQgLSB1bmxlc3Mgb3RoZXJzIG9i
amVjdCB0byB0aGlzLi4uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnDQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo=


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0C93A6C9F for <[e-mail]>; Fri,  6 Feb 2009 14:51:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.05
X-Spam-Level: 
X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=-0.051,  BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNNbnRZRmDAB for <[e-mail]>; Fri,  6 Feb 2009 14:51:21 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BC8083A6C46 for <[e-mail]>; Fri,  6 Feb 2009 14:51:20 -0800 (PST)
Received: (qmail invoked by alias); 06 Feb 2009 22:51:22 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp001) with SMTP; 06 Feb 2009 23:51:22 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/8D0ZhUfv8O7X9+2FOX+sFzfkPgCsBjSSYbGb7+j WGWMJBGWk+TyVm
From: "Hannes Tschofenig" <[e-mail]>
To: "'DOLLY, MARTIN C, ATTLABS'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Date: Sat, 7 Feb 2009 00:52:07 +0200
Message-ID: <000101c988ad$8ac92e90$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: AcmIp7cDTjOFrFzQSeSaJoip38DOVgAAJrguAAEikiA=
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.47
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 22:51:24 -0000

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: [e-mail] [mailto:[e-mail]] 
>On Behalf Of DOLLY, MARTIN C, ATTLABS
>Sent: 07 February, 2009 00:15
>To: [e-mail]; [e-mail]; 
>[e-mail]
>Cc: [e-mail]; [e-mail]
>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: [e-mail] <[e-mail]>
>To: Henning Schulzrinne <[e-mail]>; Winterbottom, 
>James <[e-mail]>
>Cc: Tschofenig, Hannes (NSN - FI/Espoo) 
><[e-mail]>; ECRIT <[e-mail]>
>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: [e-mail] 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:[e-mail]]
>>>>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:[e-mail]]
>>>>>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: [e-mail] [mailto:[e-mail]]
>>>>>>>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-
>>>>>>>>[e-mail]
>>>>>>>>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: [e-mail] [mailto:[e-mail]] On
>>>>>>>>>Behalf Of Hannes Tschofenig
>>>>>>>>>Sent: 06 February, 2009 15:07
>>>>>>>>>To: 'Janet P Gunn'
>>>>>>>>>Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
>>>>>>>>>         Sent: 06 February, 2009 14:11
>>>>>>>>>         To: Hannes Tschofenig
>>>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
>>>>>>>>>[e-mail]; 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.
>>>>>>>>>
>>>>>>>>>         [e-mail] 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:[e-mail]]
>>>>>>>>>         > >> >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: [e-mail]
>>>>>>>[mailto:[e-mail]]
>>>>>>>>>         > >> >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:[e-mail]]
>>>>>>>>>         > >> >> > 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:[e-mail]]
>>>>>>>>>         > >> >> > >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: [e-mail]
>>>>>>>>>[mailto:[e-mail]]
>>>>>>>>>         > >> >> > >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
>>>>>>>>>         > >> >> > >> [e-mail]
>>>>>>>>>         > >> >> > >> 
>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>         > >> >> > >
>>>>>>>>>         > >> >>
>>>>>>>>>         > >> >> 
>_______________________________________________
>>>>>>>>>         > >> >> Ecrit mailing list
>>>>>>>>>         > >> >> [e-mail]
>>>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>         > >> >>
>>>>>>>>>         > >> >
>>>>>>>>>         > >
>>>>>>>>>         >
>>>>>>>>>         > _______________________________________________
>>>>>>>>>         > Ecrit mailing list
>>>>>>>>>         > [e-mail]
>>>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>_______________________________________________
>>>>>>>>>Ecrit mailing list
>>>>>>>>>[e-mail]
>>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>
>>>>>>>>_______________________________________________
>>>>>>>>Ecrit mailing list
>>>>>>>>[e-mail]
>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>
>>>>>>_______________________________________________
>>>>>>Ecrit mailing list
>>>>>>[e-mail]
>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>>_______________________________________________
>>>Ecrit mailing list
>>>[e-mail]
>>>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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ecrit
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF253A684F for <[e-mail]>; Fri,  6 Feb 2009 14:52:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.666
X-Spam-Level: 
X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKNdebCUjVAy for <[e-mail]>; Fri,  6 Feb 2009 14:52:34 -0800 (PST)
Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 324F13A6A00 for <[e-mail]>; Fri,  6 Feb 2009 14:52:34 -0800 (PST)
Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n16MqX45011568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Feb 2009 17:52:34 -0500 (EST)
Message-Id: <[e-mail]>
From: Henning Schulzrinne <[e-mail]>
To: "James M. Polk" <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 6 Feb 2009 17:52:33 -0500
References: <000701c9883c$59b095d0$[e-mail]> <[e-mail]> <001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5
Cc: ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 22:52:35 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B33553A6B3A for <[e-mail]>; Fri,  6 Feb 2009 15:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.323
X-Spam-Level: 
X-Spam-Status: No, score=-5.323 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_00=-2.599, MANGLED_EMRG=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnppHVt0PORS for <[e-mail]>; Fri,  6 Feb 2009 15:09:23 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3EB703A680C for <[e-mail]>; Fri,  6 Feb 2009 15:09:23 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,394,1231113600"; d="scan'208";a="29450600"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 06 Feb 2009 23:09:23 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n16N9OrJ006137;  Fri, 6 Feb 2009 15:09:24 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n16N9N5J024398; Fri, 6 Feb 2009 23:09:23 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 15:09:23 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 15:09:22 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 06 Feb 2009 17:09:21 -0600
To: "Hannes Tschofenig" <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <000001c988ac$d0261940$[e-mail]>
References: <[e-mail]> <000801c98708$5973f6f0$[e-mail]> <[e-mail]> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$[e-mail]> <0a1101c98716$91287db0$b3797910$@net> <[e-mail]> <009701c987c4$c3cb7340$[e-mail]> <[e-mail]> <000701c9883c$59b095d0$[e-mail]> <[e-mail]> <000001c988ac$d0261940$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 06 Feb 2009 23:09:23.0038 (UTC) FILETIME=[F2C45FE0:01C988AF]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18894; t=1233961764; x=1234825764; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20RE=3A=20ECRIT=20Virtual=20Interim=20Meeting=3A= 20Agenda=20(RPH=20&=20GETS) |Sender:=20; bh=hcGzh0hf19CApJw78ipSA3a8nzBvP7p57WYNf/LRZms=; b=iRHc/VvWi19kRbG56t1/YyuJDs64hX2WPmXZX8Gt+TYoIqCr8ZrBYToS74 yshpNTDT8PutIs8AecvHwcHghKEbJu/opPy0M89as72qtowPei+iPnDYflNR G8YVP9hVq8;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 23:09:25 -0000

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:[e-mail]]
> >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:[e-mail]]
> >> >> >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: [e-mail] [mailto:[e-mail]]
> >> >> >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:[e-mail]]
> >> >> >> > 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:[e-mail]]
> >> >> >> > >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: [e-mail]
> >> >> >> > >> [mailto:[e-mail]]
> >> >> >> > >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
> >> >> >> > >> [e-mail]
> >> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >> > >
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> Ecrit mailing list
> >> >> >> [e-mail]
> >> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >>
> >> >> >
> >> >
> >



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814203A6B9F for <[e-mail]>; Fri,  6 Feb 2009 15:33:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.146
X-Spam-Level: 
X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1IAsJn0Vxdu for <[e-mail]>; Fri,  6 Feb 2009 15:33:00 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D53D03A6C23 for <[e-mail]>; Fri,  6 Feb 2009 15:32:17 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,394,1231113600"; d="scan'208";a="62628621"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 06 Feb 2009 23:32:20 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n16NWKGH030143;  Fri, 6 Feb 2009 15:32:20 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n16NWKjQ015487; Fri, 6 Feb 2009 23:32:20 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 15:32:20 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Feb 2009 15:32:19 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 06 Feb 2009 17:32:02 -0600
To: "Hannes Tschofenig" <[e-mail]>, "'DOLLY, MARTIN C, ATTLABS'" <[e-mail]>, <[e-mail]>, <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <000101c988ad$8ac92e90$[e-mail]>
References: <[e-mail]> <000101c988ad$8ac92e90$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 06 Feb 2009 23:32:19.0335 (UTC) FILETIME=[271AA170:01C988B3]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=46657; t=1233963140; x=1234827140; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20RE=3A=20[Ecrit]=20RPH |Sender:=20; bh=RQZYazNduFE5QNH7ls9TWYzbZBuFImDIJwQ6CrXLrNo=; b=G7PQp9ct1/tjPA3Pv5kb6K/vYISzw9zZNXN4OmRChVQEWWf7gVYyilAjXS b5Xn9absW4SBrawRLInft9gA7tQe2etSEzupYWLhMAgjazgBzFHvD8Vc5Jfd QikPdXAIiX;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 23:33:03 -0000

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: [e-mail] [mailto:[e-mail]]
> >On Behalf Of DOLLY, MARTIN C, ATTLABS
> >Sent: 07 February, 2009 00:15
> >To: [e-mail]; [e-mail];
> >[e-mail]
> >Cc: [e-mail]; [e-mail]
> >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: [e-mail] <[e-mail]>
> >To: Henning Schulzrinne <[e-mail]>; Winterbottom,
> >James <[e-mail]>
> >Cc: Tschofenig, Hannes (NSN - FI/Espoo)
> ><[e-mail]>; ECRIT <[e-mail]>
> >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: [e-mail] 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:[e-mail]]
> >>>>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:[e-mail]]
> >>>>>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: [e-mail] [mailto:[e-mail]]
> >>>>>>>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-
> >>>>>>>>[e-mail]
> >>>>>>>>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: [e-mail] [mailto:[e-mail]] On
> >>>>>>>>>Behalf Of Hannes Tschofenig
> >>>>>>>>>Sent: 06 February, 2009 15:07
> >>>>>>>>>To: 'Janet P Gunn'
> >>>>>>>>>Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
> >>>>>>>>>         Sent: 06 February, 2009 14:11
> >>>>>>>>>         To: Hannes Tschofenig
> >>>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >>>>>>>>>[e-mail]; 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.
> >>>>>>>>>
> >>>>>>>>>         [e-mail] 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:[e-mail]]
> >>>>>>>>>         > >> >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: [e-mail]
> >>>>>>>[mailto:[e-mail]]
> >>>>>>>>>         > >> >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:[e-mail]]
> >>>>>>>>>         > >> >> > 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:[e-mail]]
> >>>>>>>>>         > >> >> > >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: [e-mail]
> >>>>>>>>>[mailto:[e-mail]]
> >>>>>>>>>         > >> >> > >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
> >>>>>>>>>         > >> >> > >> [e-mail]
> >>>>>>>>>         > >> >> > >>
> >https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>>         > >> >> > >
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >>
> >_______________________________________________
> >>>>>>>>>         > >> >> Ecrit mailing list
> >>>>>>>>>         > >> >> [e-mail]
> >>>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >
> >>>>>>>>>         > >
> >>>>>>>>>         >
> >>>>>>>>>         > _______________________________________________
> >>>>>>>>>         > Ecrit mailing list
> >>>>>>>>>         > [e-mail]
> >>>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>_______________________________________________
> >>>>>>>>>Ecrit mailing list
> >>>>>>>>>[e-mail]
> >>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>
> >>>>>>>>_______________________________________________
> >>>>>>>>Ecrit mailing list
> >>>>>>>>[e-mail]
> >>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>
> >>>>>>_______________________________________________
> >>>>>>Ecrit mailing list
> >>>>>>[e-mail]
> >>>>>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>
> >>>_______________________________________________
> >>>Ecrit mailing list
> >>>[e-mail]
> >>>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
> >>[e-mail]
> >>https://www.ietf.org/mailman/listinfo/ecrit
> >
> >_______________________________________________
> >Ecrit mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ecrit
> >_______________________________________________
> >Ecrit mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ecrit
> >



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EE03A6B9F for <[e-mail]>; Fri,  6 Feb 2009 15:39:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.199
X-Spam-Level: 
X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v0fvhosYWtW for <[e-mail]>; Fri,  6 Feb 2009 15:39:03 -0800 (PST)
Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id B784B3A682D for <[e-mail]>; Fri,  6 Feb 2009 15:39:02 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-7.tower-161.messagelabs.com!1233963543!19296858!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 30221 invoked from network); 6 Feb 2009 23:39:03 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-7.tower-161.messagelabs.com with AES256-SHA encrypted SMTP; 6 Feb 2009 23:39:03 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n16Nd3kE012820; Fri, 6 Feb 2009 18:39:03 -0500
Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n16Nd1bs012805; Fri, 6 Feb 2009 18:39:01 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Fri, 6 Feb 2009 18:39:00 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] RPH
Thread-Index: AcmIp7cDTjOFrFzQSeSaJoip38DOVgAAJrguAAEikiAAAc6YOQ==
From: "DOLLY, MARTIN C, ATTLABS" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2009 23:39:06 -0000

V3JvbmcsIGV2ZXJ5dGhpbmcgaXMgYmFzZWQgb24gc2VjdXJpdHkgcG9saWNpZXMNCg0KLS0tLS0g
T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5U
c2Nob2ZlbmlnQGdteC5uZXQ+DQpUbzogRE9MTFksIE1BUlRJTiBDLCBBVFRMQUJTOyBqbXBvbGtA
Y2lzY28uY29tIDxqbXBvbGtAY2lzY28uY29tPjsgaGdzQGNzLmNvbHVtYmlhLmVkdSA8aGdzQGNz
LmNvbHVtYmlhLmVkdT47IEphbWVzLldpbnRlcmJvdHRvbUBhbmRyZXcuY29tIDxKYW1lcy5XaW50
ZXJib3R0b21AYW5kcmV3LmNvbT4NCkNjOiBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0Vz
cG9vKSA8aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbT47IGVjcml0QGlldGYub3JnIDxlY3JpdEBp
ZXRmLm9yZz4NClNlbnQ6IEZyaSBGZWIgMDYgMTc6NTI6MDcgMjAwOQ0KU3ViamVjdDogUkU6IFtF
Y3JpdF0gUlBIDQoNCkhpIE1hcnRpbiwgDQoNCkkgYW0gYXJndWluZyB0aGF0IGlmIHRoZSBVRSBk
b2VzIG1hcmsgdGhlIGNhbGwgd2l0aCB0aGUgRUNSSVQgUlBIIChJIGNhbGwgaXQNCnRoYXQgd2F5
IHRvIGRpZmZlcmVudGlhdGUgaXQgZnJvbSBSRkMgNDQxMiBSUEggdXNhZ2UsIHdoaWNoIGlzIHZl
cnkNCmRpZmZlcmVudCkgdGhlbiBpdCBzaG91bGQgYmUgaWdub3JlZC4gDQpQcm9jZXNzaW5nIGl0
IHdpbGwgbm90IGhlbHAgaW4gYW55IHdheSAoYXMgSSBkZXNjcmliZWQgaW4gbXkgcHNldWRvIGNv
ZGUNCnNuaXBwZXQpLiBJbmNvcnJlY3RseSBwcm9jZXNzaW5nIGl0ICh3aGljaCBpcyBhIHBvc3Np
YmlsaXR5IHdoZW4gdGhlDQppbXBsZW1lbnRlciBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoZSBzZWN1
cml0eSBpbXBsaWNhdGlvbnMgLS0gdGhleSB3aWxsIG5vdA0KZ2V0IGl0IGZyb20gdGhlIGN1cnJl
bnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQpIHdpbGwgbGVhZCB0byBzZWN1cml0eSBwcm9ibGVtcw0K
KGZyYXVkICYgRG9TIHBvdGVudGlhbCkuIA0KDQpXaGlsZSB5b3UgY2Fubm90IHByZXZlbnQgc29t
ZW9uZSBmcm9tIHNlbmRpbmcgeW91LCB0aGVyZSBpcyBjZXJ0YWlubHkgdGhlDQpjaGFuY2UgdG8g
ZG9jdW1lbnQgd2hhdCB0aGUgcmVjZWl2ZXIgc2hvdWxkIGRvIHdpdGggaXQuDQoNCkNpYW8NCkhh
bm5lcyANCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogZWNyaXQtYm91bmNl
c0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIA0KPk9uIEJlaGFsZiBP
ZiBET0xMWSwgTUFSVElOIEMsIEFUVExBQlMNCj5TZW50OiAwNyBGZWJydWFyeSwgMjAwOSAwMDox
NQ0KPlRvOiBqbXBvbGtAY2lzY28uY29tOyBoZ3NAY3MuY29sdW1iaWEuZWR1OyANCj5KYW1lcy5X
aW50ZXJib3R0b21AYW5kcmV3LmNvbQ0KPkNjOiBoYW5uZXMudHNjaG9mZW5pZ0Buc24uY29tOyBl
Y3JpdEBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbRWNyaXRdIFJQSA0KPg0KPllvdSBjYW4gbm90
IGRpc2FsbG93IHRoaXMgZnJvbSBhbiBVRS4gVGhlIHRydXN0IHJlbGF0aW9uc2hpcCANCj53aWxs
IGRpY3RhdGUgd2hldGhlciBpdCBpcyBhY2NlcHRlZCBvciBub3QNCj4NCj4tLS0tLSBPcmlnaW5h
bCBNZXNzYWdlIC0tLS0tDQo+RnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyA8ZWNyaXQtYm91
bmNlc0BpZXRmLm9yZz4NCj5UbzogSGVubmluZyBTY2h1bHpyaW5uZSA8aGdzQGNzLmNvbHVtYmlh
LmVkdT47IFdpbnRlcmJvdHRvbSwgDQo+SmFtZXMgPEphbWVzLldpbnRlcmJvdHRvbUBhbmRyZXcu
Y29tPg0KPkNjOiBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0VzcG9vKSANCj48aGFubmVz
LnRzY2hvZmVuaWdAbnNuLmNvbT47IEVDUklUIDxlY3JpdEBpZXRmLm9yZz4NCj5TZW50OiBGcmkg
RmViIDA2IDE3OjEwOjA4IDIwMDkNCj5TdWJqZWN0OiBSZTogW0Vjcml0XSBSUEgNCj4NCj5BdCAw
MzowNSBQTSAyLzYvMjAwOSwgSGVubmluZyBTY2h1bHpyaW5uZSB3cm90ZToNCj4+VGhlcmUncyBh
bm90aGVyIHByb2JsZW0gd2l0aCB0aGUgIml0IGRvZXNuJ3QgaHVydCBhcmd1bWVudCIuIA0KPkFz
c3VtZSBmb3IgDQo+PmEgbW9tZW50IHdlIGhhdmUgYSAiVUEgTUFZIGluY2x1ZGUgUlBIIiB3b3Jk
aW5nLiBUaGVyZSBhcmUgbm93IHR3bw0KPj5jYXNlczoNCj4+DQo+PigxKSBBbGwgVUFzIGltcGxl
bWVudCBpdC4NCj4+DQo+PigyKSBPbmx5IHNvbWUgVUFzIGltcGxlbWVudCBpdC4NCj4+DQo+Pigx
KSBzZWVtcyB1bmxpa2VseSBmb3IgYSBNQVkuIElmICgyKSBvY2N1cnMsIHdlIGhhdmUgdGhlIA0K
PmNob2ljZSBiZXR3ZWVuIA0KPj50d28gdW5kZXNpcmFibGUgb3V0Y29tZXM6DQo+Pg0KPj4oYSkg
c29tZSBVQXMgdGhhdCBhcmUgb3RoZXJ3aXNlIGNvbXBsaWFudCBnZXQgd29yc2Ugc2VydmljZSBq
dXN0IA0KPj5iZWNhdXNlIHRoZXkgZGlkbid0IGluY2x1ZGUgdGhlIFJQSDsNCj4NCj5hbSBJIHJl
YWRpbmcgdGhpcyBjb3JyZWN0bHkgLSB0aGF0IHVubGVzcyBhbGwgVUFzIGltcGxlbWVudCANCj50
aGlzIGNhcGFiaWxpdHkgdGhpcyBzaG91bGQgbmV2ZXIgYmUgaW1wbGVtZW50ZWQgYnkgYW55IFVB
cz8NCj4NCj5UaGlzIGZsaWVzIGluIHRoZSBmYWNlIG9mIHZlbmRvcnMgc29sdmluZyBmb3IgdGhl
aXIgY3VzdG9tZXIncyANCj5yZXF1aXJlbWVudHMuDQo+DQo+SSB3aWxsIGFkbWl0IHRoYXQgYXQg
dGhpcyB0aW1lLCBJIGtub3cgb2Ygbm8gQ2lzY28gY3VzdG9tZXJzIA0KPnRoYXQgd2FudCB0aGlz
IGNhcGFiaWxpdHksIHNvIEknbSBub3QgYW5nbGluZyBmb3IgYW55IG9mIG91ciANCj5yZXZlbnVl
IGhlcmUuICBJJ20gc2F5aW5nIHRoYXQgSSB0aGluayBJIGhlYXIgeW91IHNheWluZyB0aGlzIA0K
PklEIHNob3VsZCBzYXkgc29tZXRoaW5nIGxpa2UNCj4NCj4gICAgICAgICBVQXMgYXJlIHByZXZl
bnRlZCBmcm9tIGltcGxlbWVudGluZyB0aGUgUlAgbmFtZXNwYWNlIGVzbmV0DQo+DQo+SSdtIGZp
Z2h0aW5nIGFnYWluc3QgdGhhdCwgYmVjYXVzZSBjdXN0b21lcnMgYXJlIGFsd2F5cyBjb21pbmcg
DQo+dG8gZXZlcnkgdmVuZG9yIHdpdGggbmV3IHJlcXVpcmVtZW50cywgc29tZSBvZiB0aGVtIHVu
aXF1ZSBhdCANCj50aGUgdGltZS4gIFRoaXMgcHJldmVudGlvbiB0ZXh0IHdvdWxkIHByZXZlbnQg
YSB2ZW5kb3IgZnJvbSANCj5jb21wbHlpbmcgd2l0aCB0aGlzIHNwZWNpZmljYXRpb24gYW5kIHN0
aWxsIG1lZXQgdGhlIGN1c3RvbWVyJ3MgbmVlZHMuDQo+DQo+SSBiZWxpZXZlIHRoYXQgdGhpcyBJ
RCBuZWVkcyB0byByZXRhaW4gdGhlIGVuZHBvaW50cyBNQVkgDQo+aW5zZXJ0IGVzbmV0LCBhbmQg
aGF2ZSBhcHByb3ByaWF0ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyANCj50ZXh0IHRoYXQgaGln
aGxpZ2h0cyB0aGUgY29uY2VybnMgZXhwcmVzc2VkIGhlcmUuDQo+DQo+U29tZSBmdXR1cmUgSUQg
Y2FuIHRoZW4gdXBkYXRlIHRoaXMgY3VycmVudCBSRkMgKHRvLWJlKSB3aXRoaW4gdGhlDQo+MjEx
OSBydWxlcyBvZiB0aGUgdXNlIG9mIE1BWSBoZXJlLg0KPg0KPg0KPj5PUg0KPj4NCj4+KGIpIHRo
ZSBwcm94eSBoYXMgdG8gbG9vayBmb3IgdGhlIHNlcnZpY2UgVVJOIHRvIGdpdmUgdGhlIGNhbGwg
dGhlDQo+PmFwcHJvcHJpYXRlIHRyZWF0bWVudCwgdGh1cyBvYnZpYXRpbmcgYW55IGFkdmFudGFn
ZSBvZiBoYXZpbmcgdGhlDQo+PmhlYWRlciwgeWV0IGluY3VycmluZyBtb3JlIGNvbXBsaWNhdGVk
IHByb2Nlc3NpbmcgbG9naWMuDQo+Pg0KPj4NCj4+SSBoYXZlIG5vIG9iamVjdGlvbiB0byB3aGF0
ZXZlciBtYXJraW5ncyBwZW9wbGUgd2FudCB0byBhcHBseSB0byBjYWxscw0KPj53aXRoaW4gYW4g
RVNOIC0gdGhhdCdzIGxhcmdlbHkgYSBwcml2YXRlIG1hdHRlci4NCj4+DQo+Pkhlbm5pbmcNCj4+
DQo+Pk9uIEZlYiA2LCAyMDA5LCBhdCAzOjAxIFBNLCBXaW50ZXJib3R0b20sIEphbWVzIHdyb3Rl
Og0KPj4NCj4+PkhpIEFsbCwNCj4+Pg0KPj4+SSBoYXZlIGZvbGxvd2VkIHRoaSB0aHJlYWQgd2l0
aCBzb21lIGludGVyZXN0IGFuZCBJIHN0cnVnZ2xpbmcgdG8NCj4+PnNlZSBhIHVzZSBjYXNlIGZv
ciB0aGUNCj4+PnByb3ZpZGluZyBSUEggZm9yIGVtZXJnZW5jeSBjYWxscyBmcm9tIHRoZSBlbmQt
cG9pbnQuDQo+Pj4NCj4+PlRoZSByZWZlcmVuY2UtbW9kZWwgY2FsbCBpbiBFQ1JJVCwgZm9yIGJl
dHRlciBvciB3b3JzZSwgaXMgZm9yIGFsbA0KPj4+Y2FsbHMgdG8gZ28gYmFjayB0aHJvdWdoIGEg
aG9tZS1WU1AuDQo+Pj5XZSBwbGFjZWQgcXVpdGUgYSBsb3Qgb2YgZW1waGFzaXMsIGxhcmdlbHkg
Zm9yIHRyYWZmaW5nIHJlYXNvbnMsIGZvcg0KPj4+dGhlIFZTUCB0byBiZSBhYmxlIHRvIHZlcmlm
eSB0aGF0DQo+Pj5hIGNhbGwgaXMgaW4gZmFjdCBhbiBlbWVyZ2VuY3kgY2FsbC4gVGhpcyBpcyBk
b25lIGJ5IHRoZSBwcm94eQ0KPj4+dGFraW5nIHRoZSBpbmJhbmQgbG9jYXRpb24sIGRvaW5nIGEg
TG9TVA0KPj4+cXVlcnkgd2l0aCB0aGUgcHJvdmlkZWQgVVJOLCBhbmQgdmVyaWZ5aW5nIHRoYXQg
dGhlIHJlc3VsdGluZw0KPj4+ZGVzdGluYXRpb24gVVJJIGlzIHRoZSBzYW1lIGFzIHRoZSBkZXN0
aW5hdGlvbg0KPj4+VVJJIHByb3ZpZGUgaW4gdGhlIFNJUCBJTlZJVEUuIE15IHVuZGVyc3RhbmRp
bmcgd2FzIHRoYXQgVlNQcyB3b3VsZA0KPj4+YWx3YXlzIGRvIHRoaXMgY2hlY2sgc28gdGhleSBj
b3VsZA0KPj4+dGVsbCBpZiB0aGV5IGNvdWxkIGJpbGwgZm9yIHRoZSBjYWxsIG9yIG5vdCwgYW5k
IGJlY2F1c2UgdGhlIFZTUCBjYW4NCj4+PmJlIHVzZSB0aGF0IHRoZSBjYWxsIGlzIGFuIGVtZXJn
ZW5jeSBjYWxsDQo+Pj5pdCBjYW4gYXBwbHkgYW55IHNwZWNpYWwgcHJpb3JpdGllcyB0aGF0IG1h
eSBiZSBhcHBsaWNhYmxlLiBUaGlzDQo+Pj5vYnZpYXRlcyB0aGUgbmVlZCBmb3IgUlBIIGZyb20g
dGhlIGVuZC1wb2ludA0KPj4+dG8gdGhlIG5ldHdvcmsuDQo+Pj4NCj4+PlRoaXMgbGVhdmVzIHVz
IHdpdGggdGhlIGFyZ3VtZW50IG9mICJpdCBkb2Vzbid0IGh1cnQgdG8gaXQiLCB3aGljaA0KPj4+
aXMgbm90IGEgZ29vZCByZWFzb24gdG8gd3JpdGUgYSBzcGVjaWZpY2F0aW9uLg0KPj4+SXQgd2Fz
IGludGltYXRlZCBvbiB0aGUgZ2VvcHJpdiBtYWlsaW5nIGxpc3QgbGFzdCB5ZWFyIHRoYXQgZ3Jl
YXQNCj4+PnBhaW5zIGhhZCBiZWVuIHRha2VuIHRvIGtlZXAgU0lQIHdpdGggaW4gdGhlDQo+Pj5N
VFUgbGltaXRzIG9mIFVEUCBvdmVyIEV0aGVybmV0IA0KPj4+KGh0dHA6Ly93d3cuaWV0Zi5vcmcv
bWFpbC1hcmNoaXZlL3dlYi9nZW9wcml2L2N1cnJlbnQvbXNnMDYxMg0KPjAuaHRtbCApLiBBc3N1
bWluZw0KPj4+dGhhdCB0aGlzIGlzIHRoZSBjYXNlLCBwZXJoYXBzIHRoZXJlIGlzIGhhcm0gaW4g
aW5jbHVkaW5nDQo+Pj5pbmZvcm1hdGlvbiB0aGF0IHdlIGtub3cgd2lsbCBiZSBpZ25vcmVkLg0K
Pj4+DQo+Pj5DaGVlcnMNCj4+PkphbWVzDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg
b2YgSGFubmVzIFRzY2hvZmVuaWcNCj4+PlNlbnQ6IEZyaSAyLzYvMjAwOSAxMjozMyBQTQ0KPj4+
VG86ICdCcmlhbiBSb3Nlbic7ICdIZW5uaW5nIFNjaHVsenJpbm5lJw0KPj4+Q2M6IFRzY2hvZmVu
aWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pOyAnRUNSSVQnDQo+Pj5TdWJqZWN0OiBSZTogW0Vj
cml0XSBSUEgNCj4+Pg0KPj4+VG8gdGhlIHN0b3J5IHNob3J0IGhlcmUgaXMgdGhlIGNvZGUgZm9y
IHRoZSBwcm94eToNCj4+Pg0KPj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4+PklGIGVt
ZXJnZW5jeSBjYWxsIHdhcyByZWNvZ25pemVkIFRIRU4NCj4+PiAgICBleGVjdXRlIGVtZXJnZW5j
eSBjYWxsIHNwZWNpZmljIHByb2NlZHVyZXMgKHByaW9yaXR5IHF1ZXVpbmcsDQo+Pj5wcmVlbXB0
aW9uLCBmZXRjaCBsb2NhdGlvbiwgZGV0ZXJtaW5lIHJvdXRpbmcsIGRvIGZ1bm55IFFvUyB0aGlu
Z3MgJg0KPj4+Y28pDQo+Pj5FTFNFDQo+Pj4gICAgbm9ybWFsIGNhbGwgaGFuZGxpbmcgcHJvY2Vk
dXJlcy4NCj4+Pg0KPj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4+PklmIHlvdSBjYW4g
bWFrZSB0aGlzIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIGFuIGVtZXJnZW5jeSBjYWxsIGFuZCBh
DQo+Pj5yZWd1bGFyDQo+Pj5jYWxsIHRoZW4geW91IGNhbiBhbHNvIGRvIGV2ZXJ5dGhpbmcgdGhh
dCBpcyBuZWNlc3NhcnkgZm9yIGVtZXJnZW5jeQ0KPj4+Y2FsbA0KPj4+aGFuZGxpbmcuDQo+Pj4N
Cj4+PkJyaWFuICsgS2VpdGg6IFBsZWFzZSB0ZWxsIG1lIHRoYXQgd2UgY2Fubm90IGRvIHRoZSBh
Ym92ZSB3aXRoIG91cg0KPj4+Y3VycmVudGx5DQo+Pj5zcGVjaWZpZWQgbWVjaGFuaXNtcy4NCj4+
Pg0KPj4+Q2lhbw0KPj4+SGFubmVzDQo+Pj4NCj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPj4+PkZyb206IEJyaWFuIFJvc2VuIFttYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXRdDQo+Pj4+
U2VudDogMDYgRmVicnVhcnksIDIwMDkgMTc6NDkNCj4+Pj5UbzogJ0hlbm5pbmcgU2NodWx6cmlu
bmUnOyAnSGFubmVzIFRzY2hvZmVuaWcnDQo+Pj4+Q2M6ICdUc2Nob2ZlbmlnLCBIYW5uZXMgKE5T
TiAtIEZJL0VzcG9vKSc7ICdFQ1JJVCcNCj4+Pj5TdWJqZWN0OiBSRTogW0Vjcml0XSBSUEgNCj4+
Pj4NCj4+Pj5JIGFncmVlIHRoYXQgbm90IGFsbCBuZXR3b3JrcyB3aWxsIHBlcm1pdCAob3IgcGF5
IGF0dGVudGlvbg0KPj4+PnRvKSBhIHByaW9yaXR5IHJlcXVlc3QgZnJvbSBhbiBlbmQgZGV2aWNl
Lg0KPj4+Pg0KPj4+Pk5vIG9uZSBoYXMgYXNrZWQgZm9yIHRoYXQuDQo+Pj4+DQo+Pj4+VGhlIG5h
bWVzcGFjZSByZXF1ZXN0IGhhcyBzZXZlcmFsIHVzZXMsIG9uZSBvZiB3aGljaCBpcyB3aXRoaW4N
Cj4+Pj5hbiBlbWVyZ2VuY3kgc2VydmljZXMgSVAgbmV0d29yaywgb25lIG9mIHdoaWNoIGlzIGJl
dHdlZW4NCj4+Pj5lbGVtZW50cyB3aXRoaW4gYSBwdWJsaWMgbmV0d29yayBjb250cm9sbGVkIGJ5
IHRoZSBvcGVyYXRvciwNCj4+Pj5hbmQgb25lIG9mIHdoaWNoIGlzIGFuIGVuZHBvaW50IHJlcXVl
c3QgZm9yIHJlc291cmNlIHByaW9yaXR5Lg0KPj4+Pg0KPj4+PlRob3NlIG9mIHVzIHJlcXVlc3Rp
bmcgdGhpcyB3b3JrIHByb2NlZWQgYXJlIGhhcHB5IGlmIHRoZQ0KPj4+PmVuZHBvaW50IHBhcnQg
aXMgc2ltcGx5IGxlZnQgYXMgcG9zc2libGUgKE1BWSksIGFuZCwgc3BlYWtpbmcNCj4+Pj5mb3Ig
bXlzZWxmLCBoYXZpbmcgdGhlIGRyYWZ0IGRpc2N1c3MgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9u
cw0KPj4+Pm9mIGVuZHBvaW50IG1hcmtpbmcgaXMgcmVhc29uYWJsZS4NCj4+Pj4NCj4+Pj5IYXZp
bmcgZGlzY3Vzc2VkIHRoaXMgaXNzdWUgd2l0aCBhbiBpbXBsZW1lbnRhdGlvbiB0ZWFtIHdobw0K
Pj4+PndvcmtlZCBvbiBNTFBQIHN5c3RlbXMsIEkgYW0gY29uZmlkZW50IEkga25vdyB3aGF0IEkn
bSB0YWxraW5nDQo+Pj4+YWJvdXQsIGJ1dCBZTU1WLiAgVGhlIGZhY3QgdGhhdCB5b3UgY291bGQs
IGlmIHlvdSB3YW50ZWQgdG8sDQo+Pj4+Z2l2ZSByZXNvdXJjZSBwcmlvcml0eSB0byBhIGNhbGwg
eW91IGRlY2lkZWQsIGhvd2V2ZXIgeW91DQo+Pj4+ZGVjaWRlZCwgd2FzIGFuIGVtZXJnZW5jeSBj
YWxsIGlzIGFuIGltcGxlbWVudGF0aW9uIGRlY2lzaW9uLA0KPj4+PmFuZCBub3Qgc3ViamVjdCB0
byBzdGFuZGFyZGl6YXRpb24uDQo+Pj4+DQo+Pj4+UlBIIGlzIHRoZSBJRVRGIHN0YW5kYXJkIHdh
eSBmb3Igb25lIGVudGl0eSB0byByZXF1ZXN0DQo+Pj4+cmVzb3VyY2UgcHJpb3JpdHkgb2YgYW5v
dGhlciBlbnRpdHkgaW4gYSBTSVAgc3lzdGVtLiAgV2UncmUNCj4+Pj5hc2tpbmcgZm9yIGEgbmFt
ZXNwYWNlIHRvIHVzZSB0aGF0IHdpdGhpbiB0aGUgZG9tYWluIG9mDQo+Pj4+ZW1lcmdlbmN5IGNh
bGxzLiAgVGhhdCBpcywgSSB0aGluaywgYSBWRVJZIHJlYXNvbmFibGUgcmVxdWVzdC4NCj4+Pj4N
Cj4+Pj5Ccmlhbg0KPj4+Pg0KPj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj5G
cm9tOiBIZW5uaW5nIFNjaHVsenJpbm5lIFttYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdV0NCj4+
Pj4+U2VudDogRnJpZGF5LCBGZWJydWFyeSAwNiwgMjAwOSAxMDozMyBBTQ0KPj4+Pj5UbzogSGFu
bmVzIFRzY2hvZmVuaWcNCj4+Pj4+Q2M6IEJyaWFuIFJvc2VuOyBUc2Nob2ZlbmlnLCBIYW5uZXMg
KE5TTiAtIEZJL0VzcG9vKTsgRUNSSVQNCj4+Pj4+U3ViamVjdDogUmU6IFtFY3JpdF0gUlBIDQo+
Pj4+Pg0KPj4+Pj5UbyBjaGltZSBpbiBoZXJlOg0KPj4+Pj4NCj4+Pj4+SSBkb24ndCB0aGluayBp
dCdzIHByb2R1Y3RpdmUgdG8gc2ltcGx5IHN0YXRlIHRoYXQgNDQxMg0KPj4+PmRvZXNuJ3Qgd29y
cnkNCj4+Pj4+YWJvdXQgYXV0aG9yaXphdGlvbiwgc28gd2Ugc2hvdWxkbid0IGVpdGhlciAoc2lt
cGxpZnlpbmcgYSBiaXQpLg0KPj4+Pj5BdXRob3JpemF0aW9uIHdhcyBkaXNjdXNzZWQgcmVwZWF0
ZWRseSwgYW5kIHRoZSBnZW5lcmFsDQo+Pj4+YXNzdW1wdGlvbiB3YXMNCj4+Pj4+dGhhdCB0aGVy
ZSB3ZXJlIHR3byBjb25kaXRpb25zOiBFaXRoZXIgdGhlIHVzZXIgaW52b2tpbmcgcmVzb3VyY2Ut
DQo+Pj4+PnByaW9yaXR5IHdhcyB3ZWxsIGtub3duIGFuZCBoYWQgYSBzZXQgb2YgcGVybWlzc2lv
bnMgdGhhdCBjb3VsZCBiZQ0KPj4+Pj5jaGVja2VkIGluIHJlYWwgdGltZSBvciB0aGVyZSBhcmUg
d2F5cyB0byBkZWFsIHdpdGggYWJ1c2UgYWZ0ZXIgdGhlDQo+Pj4+PmZhY3QgaW4gd2F5cyB0aGF0
IGRldGVyIGFidXNlICh0aGUgY291cnQtbWFydGlhbCBraW5kIG9mIHRoaW5nIGluIGENCj4+Pj4+
bWlsaXRhcnkgY29udGV4dCkuDQo+Pj4+Pg0KPj4+Pj5UaGUgUkZDIDQ0MTIgc2VjdXJpdHkgY29u
c2lkZXJhdGlvbiAoMTEuMikgY2FsbCB0aGlzIG91dCBpbiBwcmV0dHkNCj4+Pj4+c3Ryb25nIGxh
bmd1YWdlOg0KPj4+Pj4NCj4+Pj4+ICBQcmlvcml0aXplZCBhY2Nlc3MgdG8gbmV0d29yayBhbmQg
ZW5kLXN5c3RlbSByZXNvdXJjZXMgaW1wb3Nlcw0KPj4+Pj4gICAgcGFydGljdWxhcmx5IHN0cmlu
Z2VudCByZXF1aXJlbWVudHMgb24gYXV0aGVudGljYXRpb24gYW5kDQo+Pj4+PiAgICBhdXRob3Jp
emF0aW9uIG1lY2hhbmlzbXMsIHNpbmNlIGFjY2VzcyB0byBwcmlvcml0aXplZA0KPj4+PnJlc291
cmNlcyBtYXkNCj4+Pj4+ICAgIGltcGFjdCBvdmVyYWxsIHN5c3RlbSBzdGFiaWxpdHkgYW5kIHBl
cmZvcm1hbmNlIGFuZCBub3QNCj4+Pj5qdXN0IHJlc3VsdA0KPj4+Pj4gICAgaW4gdGhlZnQgb2Ys
IHNheSwgYSBzaW5nbGUgcGhvbmUgY2FsbC4NCj4+Pj4+VGh1cywgdGhlIHF1ZXN0aW9uIGlzIHdo
ZXRoZXIgd2UgaGF2ZSBzdWNoIHN0cm9uZyBhdXRoZW50aWNhdGlvbiBpbg0KPj4+Pj5lbWVyZ2Vu
Y3kgY2FsbGluZy4gSW4gc29tZSBjYXNlcywgc3VjaCBhcyByZXNpZGVudGlhbCBmaXhlZCBsaW5l
DQo+Pj4+PmRlcGxveW1lbnRzIHdoZXJlIElTUCA9IFZTUCwgd2UncmUgcHJvYmFibHkgcHJldHR5
IGNsb3NlLCANCj5pbiBvdGhlcnMsDQo+Pj4+PnN1Y2ggYXMgcHJlcGFpZCBjZWxsIHBob25lcyBv
ciBob3Qgc3BvdHMgb3IgVlNQLW9ubHkgcHJvdmlkZXJzLCB3ZQ0KPj4+Pj5hcmVuJ3QuDQo+Pj4+
Pg0KPj4+Pj5UaGUgb3RoZXIgcG9pbnQgdGhhdCBJIHRoaW5rIEhhbm5lcyBpcyBtYWtpbmcgaXMg
dGhhdCB0aGUNCj4+Pj5pbmZvcm1hdGlvbg0KPj4+Pj5pcyBlaXRoZXIgcmVkdW5kYW50IG9yIGRh
bmdlcm91cy4gSWYgYSBwcm9jZXNzaW5nIGVsZW1lbnQgDQo+cmVjb2duaXplcw0KPj4+Pj50aGUg
Y2FsbCBhcyBiZWluZyBhbiBlbWVyZ2VuY3kgY2FsbCwgaXQgY2FuIGFwcGx5IHdoYXRldmVyIA0K
PnRyZWF0bWVudA0KPj4+Pj5pdCBkZWVtcyBhcHByb3ByaWF0ZSBhbmQgZG9lc24ndCBuZWVkIGFk
ZGl0aW9uYWwgaW5mb3JtYXRpb24uIElmIGl0DQo+Pj4+PmRvZXNuJ3Qgb3IgY2FuJ3QsIHVzaW5n
IGp1c3QgdGhlIFJQSCBjYW4gYmUgcmF0aGVyIGRhbmdlcm91cyB1bmxlc3MNCj4+Pj4+dGhhdCBl
bGVtZW50IGNhbiBiZSByZWFzb25hYmx5IGNlcnRhaW4gdGhhdCB0aGVyZSBpcyBzdHJvbmcNCj4+
Pj4+YXV0aGVudGljYXRpb24gYW5kIHJlY291cnNlLg0KPj4+Pj4NCj4+Pj4+SSBkb24ndCBidXkg
dGhlIGFyZ3VtZW50IHRoYXQgc29tZWhvdyBmaW5kaW5nIHRoZSBSUEggaXMgDQo+ZmFzdGVyIHRo
YW4NCj4+Pj4+anVzdCBsb29raW5nIGZvciB0aGUgaWRlbnRpZmllci4gVGh1cywgZ2l2ZW4gdGhh
dCB0aGUgDQo+aW5mb3JtYXRpb24gaXMNCj4+Pj4+ZWl0aGVyIHJlZHVuZGFudCBvciBkYW5nZXJv
dXMsIEkgZmFpbCB0byBzZWUgdGhlIGFkdmFudGFnZS4NCj4+Pj4+DQo+Pj4+Pkhlbm5pbmcNCj4+
Pj4+DQo+Pj4+Pg0KPj4+Pj5PbiBGZWIgNiwgMjAwOSwgYXQgMTA6MjAgQU0sIEhhbm5lcyBUc2No
b2ZlbmlnIHdyb3RlOg0KPj4+Pj4NCj4+Pj4+PkRvbid0IGdldCBodW5nIHVwIG9uIHRoZSBkZXRh
aWxzLiBUaGVyZSBhcmUgd2F5cyB0byBvcHRpbWl6ZSBpdC4NCj4+Pj4+PlRoYXQgd2FzDQo+Pj4+
Pj5ub3QgdGhlIHBvaW50IG9mIHRoZSBjb2RlIGV4YW1wbGUuDQo+Pj4+Pj4NCj4+Pj4+PlRoZSBw
cm9ibGVtIHRoYXQgbXkgcHNldWRvIGNvZGUgc2hvdWxkIGhhdmUgc2hvd24geW91IGlzIHRoYXQg
eW91DQo+Pj4+Pj4qIGRvbid0IGdhaW4gYW55dGhpbmcgd2l0aCBSUEggbWFya2luZyBmb3IgdGhl
IGVtZXJnZW5jeSBjYWxsIGNhc2UNCj4+Pj4+PmZyb20gdGhlIFNJUCBVQSB0b3dhcmRzIHRoZSBv
dXRib3VuZCBwcm94eSBzaW5jZSB0aGUgZnVuY3Rpb25hbGl0eQ0KPj4+Pj4+aXMgYWxyZWFkeSBw
cm92aWRlIG90aGVyd2lzZS4gSG93IG9mdGVuIGRvZXMgdGhlIHByb3h5IG5lZWQgdG8gZ2V0DQo+
Pj4+Pj50b2xkIHRoYXQgdGhpcyBpcyBhbiBlbWVyZ2VuY3kgY2FsbCB0b2RvIHdoYXRldmVyIGVt
ZXJnZW5jeSBjYWxsDQo+Pj4+Pj5oYW5kbGluZyBwcm9jZWR1cmVzIGFyZSBuZWNlc3Nhcnk/DQo+
Pj4+Pj4qIHlvdSBvbmx5IGludHJvZHVjZSBmcmF1ZCBwcm9ibGVtcyAoaWYgeW91IGFyZSBub3QN
Cj4+Pj5jYXJlZnVsIGFuZCB5b3UNCj4+Pj4+PnVuZGVyc3RhbmQgdGhlIHNlY3VyaXR5IHN0dWZm
IHdlbGwgZW5vdWdoKQ0KPj4+Pj4+DQo+Pj4+Pj5JZiB5b3UgY2FuIHBvaW50IG1lIHRvIHBlb3Bs
ZSB3aG8gaW1wbGVtZW50IHRoZSBSUEggZW1lcmdlbmN5IGNhbGwNCj4+Pj4+PmNhc2UgcGxlYXNl
IGRvIHNvLiBJIHdvdWxkIGxvdmUgdG8gdGFsayB0byB0aGVtLg0KPj4+Pj4+DQo+Pj4+Pj5DaWFv
DQo+Pj4+Pj5IYW5uZXMNCj4+Pj4+Pg0KPj4+Pj4+UFM6IFlvdSBuZWVkIHRvIHBhcnNlIGluY29t
aW5nIG1lc3NhZ2VzIHRvIHNvbWUgZXh0ZW5kIHNvIHRoYXQgeW91DQo+Pj4+Pj5rbm93IHdoYXQg
aXQgY29udGFpbnMgOi0pIE9ubHkgbG9va2luZyBmb3IgdGhlIGVtZXJnZW5jeQ0KPj4+PlJQSCBo
ZWFkZXINCj4+Pj4+PihhbmQgbm90IGZvciB0aGUgU2VydmljZSBVUk4vZGlhbA0KPj4+Pj4+c3Ry
aW5nKSB3b3VsZCBleGFjdGx5IGJlIHRoZSBEb1MvZnJhdWQgYXR0YWNrIEkgYW0gd29ycmllZCBh
Ym91dC4NCj4+Pj4+PlRoYXQncyB0aGUgdGhpbmcgSGVubmluZyB3YXMgd29ycmllZCBhYm91dCAo
Z28gYW5kIGxpc3RlbiB0byB0aGUNCj4+Pj4+PnBhc3QgbWVldGluZyBtaW51dGVzKS4NCj4+Pj4+
Pg0KPj4+Pj4+DQo+Pj4+Pj4+SGFubmVzDQo+Pj4+Pj4+DQo+Pj4+Pj4+WW91IG5lZWQgdG8gdGFs
ayB0byBwZW9wbGUgd2hvIHJlYWxseSBpbXBsZW1lbnQgdGhpcyBraW5kDQo+Pj4+b2YgdGhpbmcu
DQo+Pj4+Pj4+WW91IGFyZSB3YXkgb2ZmLg0KPj4+Pj4+Pg0KPj4+Pj4+PldoZW4geW91IGltcGxl
bWVudCBhIHJlc291cmNlIHByaW9yaXR5IHN5c3RlbSwgdGhlIHBvaW50IG9mIGRvaW5nDQo+Pj4+
Pj4+dGhhdCBpcyB0byBsb29rIHRob3VnaCB0aGUgcXVldWUgb2Ygd29yayBhbmQgcGljayBvdXQg
dGhlDQo+Pj4+b25lcyB3aXRoDQo+Pj4+Pj4+cHJpb3JpdHksIGhhbmRsaW5nIHRoZW0gZmlyc3Qu
ICBZb3UgZG9uJ3QgZG8gYWxsIHRoZSBwYXJzaW5nLCB5b3UNCj4+Pj4+Pj5kb24ndCBkbyBhIGxv
dCBvZiBkZWNpc2lvbiB0cmVlLg0KPj4+Pj4+Pg0KPj4+Pj4+PlR5cGljYWxseToNCj4+Pj4+Pj5D
aGVjayBmb3IgRG9TIHRoaW5ncywgbGlrZSB0b28gYmlnIG1lc3NhZ2VzLCBldGMgRG8gYSBxdWlj
ayBzY2FuDQo+Pj4+Pj4+Zm9yIHRoZSBSUEggbWVzc2FnZSBoZWFkZXIgSWYgZm91bmQ6DQo+Pj4+
Pj4+UGFyc2UgdGhlIG1lc3NhZ2UNCj4+Pj4+Pj5EZXRlcm1pbmUgdmFsaWRpdHkNCj4+Pj4+Pj5E
ZXRlcm1pbmUgcHJpb3JpdHkNCj4+Pj4+Pj5RdWV1ZSBvbiB0aGUgY29ycmVjdCB3b3JrIHF1ZXVl
DQo+Pj4+Pj4+DQo+Pj4+Pj4+VGhlIGZpcnN0IHR3byBhY3Rpb25zIGhhdmUgdG8gYmUgdmVyeSBm
YXN0LiAgQW55b25lIHdobyBidWlsZHMgYQ0KPj4+Pj4+PlNJUCB0aGluZ2llIHdpbGwgdGVsbCB5
b3UgdGhhdCBwYXJzaW5nIGlzIG9uZSBvZiB0aGUgYmlnIGN5Y2xlDQo+Pj4+Pj4+Y29uc3VtZXJz
OiBpZiB5b3UgaGF2ZSB0byBwYXJzZSBldmVyeSBtZXNzYWdlIEJFRk9SRSB5b3UNCj4+Pj5kZXRl
cm1pbmUNCj4+Pj4+Pj5wcmlvcml0eSwgeW91IGNhbid0IGdpdmUgbXVjaCByZXNvdXJjZSBwcmlv
cml0eS4NCj4+Pj4+Pj5PbmNlIHlvdSBnZXQgdGhlIHdob2xlIG1lc3NhZ2UgcGFyc2VkLCB5b3Ug
bWlnaHQgYXMgd2VsbCBmaW5pc2gNCj4+Pj4+Pj53b3JraW5nIG9uIGl0LCBiZWNhdXNlIHlvdSd2
ZSBkb25lIHNvIG11Y2ggb2YgdGhlIHdvcmsuDQo+Pj4+Pj4+T1RIT0gsIGZpbmRpbmcgdGhlIGVu
ZC1vZi1tZXNzYWdlIGRlbGltaXRlciBhbmQgZG9pbmcgYSBxdWljaw0KPj4+Pj4+PnN0cmluZyBz
ZWFyY2ggZm9yIFJQSCBpcyBmYXN0LiAgSWYgeW91IGFyZSBkb2luZw0KPj4+PnByaW9yaXR5LCB5
b3UgbmVlZA0KPj4+Pj4+PnRvIGtlZXAgYWxsIHRoZSBwcmlvcml0eSBwcm9jZXNzaW5nIHByZXR0
eSB1bmlmb3JtLCBhbmQgcHJldHR5DQo+Pj4+Pj4+c2ltcGxlLCBvciB5b3UgdGVuZCB0byBzcGVu
ZCB0b28gbXVjaCB0aW1lIGZ1dHppbmcgYXJvdW5kDQo+Pj4+ZmlndXJpbmcNCj4+Pj4+Pj5vdXQg
d2hhdCB0byBkby4gIFlvdSBwdXQgYWxsIHRoZSBwcmlvcml0eSByZWxhdGVkIHN0dWZmIHRvZ2V0
aGVyLA0KPj4+Pj4+PmFuZCB1c2UgYXMgbXVjaCBjb21tb24gY29kZSBhcyBwb3NzaWJsZS4NCj4+
Pj4+Pj4NCj4+Pj4+Pj5Ccmlhbg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KPj4+Pj4+Pj5Gcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNy
aXQtYm91bmNlc0BpZXRmLm9yZ10NCj4+Pj4+Pj5PbiBCZWhhbGYNCj4+Pj4+Pj4+T2YgSGFubmVz
IFRzY2hvZmVuaWcNCj4+Pj4+Pj4+U2VudDogRnJpZGF5LCBGZWJydWFyeSAwNiwgMjAwOSA4OjQx
IEFNDQo+Pj4+Pj4+PlRvOiAnSGFubmVzIFRzY2hvZmVuaWcnOyAnSmFuZXQgUCBHdW5uJw0KPj4+
Pj4+Pj5DYzogVHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3Bvbyk7ICdFQ1JJVCc7IGVj
cml0LQ0KPj4+Pj4+Pj5ib3VuY2VzQGlldGYub3JnDQo+Pj4+Pj4+PlN1YmplY3Q6IFtFY3JpdF0g
UlBIDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj5PdmVyIGx1bmNoIEkgd2FzIGFsc28gdGhpbmtpbmcgaG93
IGFuIG91dGJvdW5kIHByb3h5IHdvdWxkDQo+Pj4+PmltcGxlbWVudA0KPj4+Pj4+Pj5zb21lIG9m
IHRoZSBlbWVyZ2VuY3kgcHJvY2VkdXJlcy4gSGVyZSBhcmUgc29tZSB0aG91Z2h0czoNCj4+Pj4+
Pj4+DQo+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+Ly8gUHJvY2VzcyBpbmNvbWluZyBtZXNzYWdlDQo+
Pj4+Pj4+PlBhcnNlKG1zZyk7DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4vLyBTSVAgSU5WSVRFIHdpdGhv
dXQgU2VydmljZSBVUk4NCj4+Pj4+Pj4+Ly8gbGVnYWN5IGRldmljZXMNCj4+Pj4+Pj4+SWYgKHJl
Y29nbml6ZS1kaWFsc3RyaW5nKG1zZyk9PVRSVUUpIHsgIC8vIHdlIGdvdCBhbiBlbWVyZ2VuY3kN
Cj4+Pj4+Pj4+Y2FsbCBnb2luZyBvbiAgZW1lcmdlbmN5PVRSVUU7ICBpZiAoZGlhbHN0cmluZyht
c2cpID09IDkxMSkNCj4+Pj4+Pj4+c2VydmljZVVSTj11cm46c2VydmljZTpzb3M7IH0gZWxzZSBp
Zg0KPj4+Pj4+Pj4ocmVjb2duaXplLXNlcnZpY2VVUk4obXNnKT09VFJVRSkgeyAgLy8gb2guIEEg
dXBkYXRlZA0KPj4+PmRldmljZSB0aGF0DQo+Pj4+Pj4+PmhhcyBhIHNlcnZpY2UgVVJOIGF0dGFj
aGVkIHRvIHRoZQ0KPj4+Pj5jYWxsDQo+Pj4+Pj4+PnNlcnZpY2VVUk49cmV0cmlldmVfU2Vydmlj
ZVVSTihtc2cpOw0KPj4+Pj4+Pj5lbWVyZ2VuY3k9VFJVRTsNCj4+Pj4+Pj4+fSBlbHNlIHsNCj4+
Pj4+Pj4+Ly8gc3RhbmRhcmQgU0lQIG1lc3NhZ2UNCj4+Pj4+Pj4+Ly8gcmVndWxhciBwcm9jZXNz
aW5nDQo+Pj4+Pj4+PnByb2Nlc3MobXNnKTsNCj4+Pj4+Pj4+ZW1lcmdlbmN5PUZBTFNFOw0KPj4+
Pj4+Pj59DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj5JZiAoZW1lcmdlbmN5ID09IFRSVUUpIHsNCj4+Pj4+
Pj4+ICAvLyBtYWtlIHN1cmUgdGhhdCB0aGUgZW1lcmdlbmN5IGNhbGwgZG9lcyBub3QgZ2V0DQo+
Pj4+ZHJvcHBlZCBvbiB0aGUNCj4+Pj4+Pj4+Zmxvb3INCj4+Pj4+Pj4+ICAvLyBza2lwIGF1dGhv
cml6YXRpb24gZmFpbHVyZXMNCj4+Pj4+Pj4+ICAvLyBnaXZlIHRoZSBjYWxsIGEgc3BlY2lhbCB0
cmVhdG1lbnQNCj4+Pj4+Pj4+ICBsb3RzLW9mLWNvZGUtaGVyZSgpOw0KPj4+Pj4+Pj4NCj4+Pj4+
Pj4+ICAvLyB0cmlnZ2VyIGFsbCB0aGUgUW9TIHNpZ25hbGluZyB5b3UgaGF2ZSBpbiB0aGUNCj4+
Pj5uZXR3b3JrIHRvIG1ha2UNCj4+Pj4+Pj4+SmFtZXMgaGFwcHkNCj4+Pj4+Pj4+ICB0cmlnZ2Vy
LXFvcygpOw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAvLyBxdWVyeSBsb2NhdGlvbg0KPj4+Pj4+Pj4g
IGxvY2F0aW9uPXJldHJpZXZlLWxvY2F0aW9uKCk7DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gIC8vIGRl
dGVybWluZSBuZXh0IGhvcA0KPj4+Pj4+Pj4gIG5leHQtaG9wPWxvc3QobG9jYXRpb24sIHNlcnZp
Y2VVUk4pDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gIC8vIGF0dGFjaCBSUEggbWFya2luZyB0byBvdXRn
b2luZyBtc2cgdG8gbWFrZSBKYW1lcyBhbmQNCj4+Pj4+Pj5LZWl0aCBoYXBweQ0KPj4+Pj4+Pj4g
IG1zZz1hZGQobXNnLCBSUEgpOw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICBzZW5kKG1zZywgbmV4dC1o
b3ApOw0KPj4+Pj4+Pj59DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj5JZiAoKHJwaC1wcmVzZW50KG1zZykg
PT0gVFJVRSkgJiYgKGVtZXJnZW5jeSA9PSBUUlVFKSkgew0KPj4+Pj4+Pj4gIC8vIGFsbCB0aGUg
ZW1lcmdlbmN5IHJlbGF0ZWQgcHJvY2Vzc2luZyBkb25lIGFscmVhZHkgdXBmcm9udA0KPj4+Pj4+
Pj4gIC8vIGhlbmNlIEkgbG9nIHNvbWV0aGluZy4NCj4+Pj4+Pj4+ICBsb2coUlBIX1dBU19QUkVT
RU5UX0pVSFUpOw0KPj4+Pj4+Pj59IGVsc2UgaWYgKChycGgtcHJlc2VudChtc2cpID09IFRSVUUp
ICYmIChlbWVyZ2VuY3kgPT0NCj4+Pj5GQUxTRSkpIHsNCj4+Pj4+Pj4+Ly8gdGhpcyBpcyBub3Qg
YW4gZW1lcmdlbmN5IGNhbGwgIC8vIHRoaXMgaXMgc29tZXRoaW5nDQo+Pj4+bGlrZSBHRVRTDQo+
Pj4+Pj4+PnJlc3VsdD1zcGVjaWFsLWF1dGhvcml6YXRpb24tcHJvY2VkdXJlKHVzZXIpOw0KPj4+
Pj4+Pj4NCj4+Pj4+Pj4+aWYgKHJlc3VsdCA9PSBBVVRIT1JJWkVEKSB7DQo+Pj4+Pj4+PiAgIC8v
IGRvIHNvbWUgcHJpb3JpdHkgJiBwcmVlbXB0aW9uIHRoaW5nIGhlcmUuDQo+Pj4+Pj4+PiAgIC8v
IHRyaWdnZXIgYWxsIHRoZSBRb1MgeW91IGhhdmUNCj4+Pj4+Pj4+ICAgbG90cy1vZi1jb2RlLWhl
cmUoKTsNCj4+Pj4+Pj4+fSBlbHNlIHsNCj4+Pj4+Pj4+ICAgbG9nKCJOT1QgQVVUSE9SSVpFRDsg
ZG9uJ3QgRG9TIG15IG5ldHdvcmsiKTsgIH0gfSBlbHNlIHsgIC8vDQo+Pj4+Pj4+PmRvbid0IG5l
ZWQgdG9kbyBhbnkgUlBIIHByb2Nlc3NpbmcgIC8vIHRoaXMgaW5jbHVkZXMgdGhlIGNhc2UNCj4+
Pj4+Pj4+d2hlcmUgdGhlIGNhbGwgd2FzIGFuIGVtZXJnZW5jeSBjYWxsIGJ1dCB0aGUgUlBIDQo+
Pj4+Pj4+Pg0KPj4+Pj4+Pj4vLyBtYXJraW5nIHdhcyBub3QgdGhlcmUuDQo+Pj4+Pj4+Pm5vdGhp
bmcoKTsNCj4+Pj4+Pj4+fQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+
Pj4+Q2lhbw0KPj4+Pj4+Pj5IYW5uZXMNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4tLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+RnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFp
bHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj4+Pj4+Pj5CZWhhbGYgT2YgSGFubmVz
IFRzY2hvZmVuaWcNCj4+Pj4+Pj4+PlNlbnQ6IDA2IEZlYnJ1YXJ5LCAyMDA5IDE1OjA3DQo+Pj4+
Pj4+Pj5UbzogJ0phbmV0IFAgR3VubicNCj4+Pj4+Pj4+PkNjOiAnRUNSSVQnOyBlY3JpdC1ib3Vu
Y2VzQGlldGYub3JnOyBUc2Nob2ZlbmlnLEhhbm5lcyAoTlNOIC0NCj4+Pj4+Pj4+RkkvRXNwb28p
DQo+Pj4+Pj4+Pj5TdWJqZWN0OiBSZTogW0Vjcml0XSBFQ1JJVCBWaXJ0dWFsIEludGVyaW0gTWVl
dGluZzogDQo+QWdlbmRhIChSUEgpDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PldobyB3b3VsZCBkZWZp
bmUgc29tZXRoaW5nIHRoYXQgY291bGQgcHJldmVudCBEb1MgcHJvYmxlbXM/DQo+Pj4+Pj4+Pj4N
Cj4+Pj4+Pj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+Pj4NCj4+
Pj4+Pj4+PiAgICAgICAgIEZyb206IEphbmV0IFAgR3VubiBbbWFpbHRvOmpndW5uNkBjc2MuY29t
XQ0KPj4+Pj4+Pj4+ICAgICAgICAgU2VudDogMDYgRmVicnVhcnksIDIwMDkgMTQ6MTENCj4+Pj4+
Pj4+PiAgICAgICAgIFRvOiBIYW5uZXMgVHNjaG9mZW5pZw0KPj4+Pj4+Pj4+ICAgICAgICAgQ2M6
ICdCcmlhbiBSb3Nlbic7ICdEUkFHRSwgS2VpdGggKEtlaXRoKSc7ICdFQ1JJVCc7DQo+Pj4+Pj4+
Pj5lY3JpdC1ib3VuY2VzQGlldGYub3JnOyBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0Vz
cG9vKTsNCj4+Pj4+J0phbWVzDQo+Pj4+Pj4+Pj5NLiBQb2xrJw0KPj4+Pj4+Pj4+ICAgICAgICAg
U3ViamVjdDogUmU6IFtFY3JpdF0gRUNSSVQgVmlydHVhbCBJbnRlcmltDQo+Pj4+TWVldGluZzog
QWdlbmRhIChSUEgpDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4g
ICAgICAgICBCdXQgdGhlcmUgaXMgbm90aGluZyBJTiBSRkM0NDEyIHRoYXQgc3BlY2lmaWNhbGx5
DQo+Pj4+Pj4+YWRkcmVzc2VzIGhvdyB0bw0KPj4+Pj4+Pj4+cHJldmVudCBhbnkgcGFydGljdWxh
ciBuYW1lc3BhY2UgYmVpbmcgdXNlZCBmb3IgRG9TLiAgDQo+QW55b25lL2FueQ0KPj4+Pj5VQQ0K
Pj4+Pj4+Pj4+Y2FuIEFUVEVNUFQgdG8gaW52b2tlIHByaW9yaXR5IHRyZWF0bWVudCBieSBhdHRh
Y2hpbmcgUlBILiAgRm9yDQo+Pj4+PmFsbA0KPj4+Pj4+Pj4+b2YgdGhlIDQ0MTIgbmFtZXNwYWNl
cywgYXMgd2l0aCB0aGUgbmV3IHByb3Bvc2VkIG5hbWVzcGFjZSwgdGhlDQo+Pj4+Pj4+Pj5tZWNo
YW5pc21zIGZvciBwcmV2ZW50aW5nIERvUyBhcmUgbm90IHNwZWNpZmllZCBpbiB0aGUNCj4+Pj4+
Pj5kb2N1bWVudCB0aGF0DQo+Pj4+Pj4+Pj5kZWZpbmVzIHRoZSBuYW1lc3BhY2UuDQo+Pj4+Pj4+
Pj5UaGV5IGFyZS93aWxsIGJlIHNwZWNpZmllZCBlbHNld2hlcmUuDQo+Pj4+Pj4+Pj4NCj4+Pj4+
Pj4+PiAgICAgICAgIEphbmV0DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAgICAgICAgIFRoaXMgaXMg
YSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPj4+Pj4+PnJl
Y2lwaWVudCwNCj4+Pj4+Pj4+PnBsZWFzZSBkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5k
bHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZg0KPj4+Pj50aGUNCj4+Pj4+Pj4+Pm1pc3Rha2UgaW4g
ZGVsaXZlcnkuDQo+Pj4+Pj4+Pj4gICAgICAgICBOT1RFOiBSZWdhcmRsZXNzIG9mIGNvbnRlbnQs
IHRoaXMgZS1tYWlsIHNoYWxsIG5vdA0KPj4+Pj4+Pm9wZXJhdGUgdG8gYmluZA0KPj4+Pj4+Pj4+
Q1NDIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhw
bGljaXQNCj4+Pj4+Pj4+PndyaXR0ZW4gYWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2
ZSBleHByZXNzbHkgcGVybWl0dGluZw0KPj4+Pj50aGUNCj4+Pj4+Pj4+PnVzZSBvZiBlLW1haWwg
Zm9yIHN1Y2ggcHVycG9zZS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgZWNyaXQtYm91
bmNlc0BpZXRmLm9yZyB3cm90ZSBvbiAwMi8wNi8yMDA5IA0KPjA0OjIxOjUxIEFNOg0KPj4+Pj4+
Pj4+DQo+Pj4+Pj4+Pj4gICAgICAgICA+IEhpIEphbWVzLA0KPj4+Pj4+Pj4+ICAgICAgICAgPg0K
Pj4+Pj4+Pj4+ICAgICAgICAgPiBJIGhhdmUgcmVhZCBSRkMgNDQxMiBhbmQgYWxzbyB0aGUgR0VU
Uy9NTFBQIElFVEYNCj4+Pj4+Pj5kb2N1bWVudHMuIFdoYXQgSQ0KPj4+Pj4+Pj4+d291bGQNCj4+
Pj4+Pj4+PiAgICAgICAgID4gbGlrZSB0byBwb2ludCBvdXQgaXMgdGhhdCB0aGVyZSBpcyBtb3Jl
IHRoYW4ganVzdCBhDQo+Pj4+Pj4+aGVhZGVyIGFuZA0KPj4+Pj4+Pj4+dmFsdWVzIHdpdGhpbg0K
Pj4+Pj4+Pj4+ICAgICAgICAgPiB0aGUgaGVhZGVyIHRoYXQgaGF2ZSB0byBiZSBjb25zaWRlcmVk
IGluIG9yZGVyIHRvDQo+Pj4+Pj4+bWFrZSBhIGp1ZGdlbWVudA0KPj4+Pj4+Pj4+b2Ygd2hhdA0K
Pj4+Pj4+Pj4+ICAgICAgICAgPiBpcyBhcHByb3ByaWF0ZSBhbmQgd2hhdCBpc24ndC4gVGhlcmUg
aXMgYW4NCj4+Pj4+Pj5hcmNoaXRlY3R1cmFsIHF1ZXN0aW9uDQo+Pj4+Pj4+Pj5hbmQNCj4+Pj4+
Pj4+PiAgICAgICAgID4gd2hldGhlciB0aGUgZW52aXJvbm1lbnQgd2UgYXJlIHVzaW5nIHRoZSBz
dHVmZiBpcw0KPj4+Pj4+PmluZGVlZCBwcm92aWRpbmcNCj4+Pj4+Pj4+PnRoZQ0KPj4+Pj4+Pj4+
ICAgICAgICAgPiBwcm9wZXJ0aWVzIHlvdSBuZWVkIGZvciB0aGUgc29sdXRpb24gdG8gYmUNCj4+
Pj5hcHByb3ByaWF0ZS4NCj4+Pj4+Pj4+PiAgICAgICAgID4NCj4+Pj4+Pj4+PiAgICAgICAgID4g
TGV0IG1lIGRlc2NyaWJlIGluIG1vcmUgZGV0YWlsIHdoYXQgSSBtZWFudCAoYW5kDQo+Pj4+Pj4+
cGxlYXNlIGNvcnJlY3QgbWUNCj4+Pj4+Pj4+PmlmIEkgYW0NCj4+Pj4+Pj4+PiAgICAgICAgID4g
d3JvbmcpLg0KPj4+Pj4+Pj4+ICAgICAgICAgPg0KPj4+Pj4+Pj4+ICAgICAgICAgPiBHZXR0aW5n
IHByaW9yaXR5IGZvciBTSVAgcmVxdWVzdHMgd2hlbiB1c2luZyBhIEdFVFMNCj4+Pj4+Pj5hbGlr
ZSBzY2VuYXJpbw0KPj4+Pj4+Pj4+bWVhbnMNCj4+Pj4+Pj4+PiAgICAgICAgID4gdGhhdCB0aGUg
ZW50aXR5IHRoYXQgaXNzdWVzIHRoZSByZXF1ZXN0IGlzIHNwZWNpYWxseQ0KPj4+Pj4+PmF1dGhv
cml6ZWQNCj4+Pj4+Pj4+PnNpbmNlDQo+Pj4+Pj4+Pj4gICAgICAgICA+IG90aGVyd2lzZSB5b3Ug
aW50cm9kdWNlIGEgbmljZSBkZW5pYWwgb2YNCj4+Pj5zZXJ2aWNlIGF0dGFjay4gVGhpcw0KPj4+
Pj4+Pj4+YXV0aG9yaXphdGlvbg0KPj4+Pj4+Pj4+ICAgICAgICAgPiBpcyB0aWVkIHRvIHRoZSBl
bnRpdHkgdGhhdCBtYWtlcyB0aGUgcmVxdWVzdC4gRm9yDQo+Pj4+Pj4+ZXhhbXBsZSwgdGhlDQo+
Pj4+Pj4+Pj5wZXJzb24gaXMNCj4+Pj4+Pj4+PiAgICAgICAgID4gd29ya2luZyBmb3IgdGhlIGdv
dmVybm1lbnQgYW5kIGhhcyBzcGVjaWFsIHJpZ2h0cy4NCj4+Pj4+Pj4+PkphbWVzIEJvbmQgYXMg
YSAobm90IHNvKQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiBzZWNyZXQgYWdlbnQgbWlnaHQgaGF2ZSB0
aGVzZSByaWdodHMuDQo+Pj4+Pj4+Pj4gICAgICAgICA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+IFRo
ZSBlbWVyZ2VuY3kgc2VydmljZXMgY2FzZQ0KPj4+PihjaXRpemVuLXRvLWF1dGhvcml0eSkgaXMg
YSBiaXQNCj4+Pj4+Pj4+PmRpZmZlcmVudCBhcw0KPj4+Pj4+Pj4+ICAgICAgICAgPiB0aGVyZSBh
cmVuJ3QgcmVhbGx5IHNwZWNpYWwgcmlnaHRzIHdpdGggcmVzcGVjdCB0bw0KPj4+Pj4+PmF1dGhv
cml6YXRpb24NCj4+Pj4+Pj4+PnRpZWQgdG8NCj4+Pj4+Pj4+PiAgICAgICAgID4gaW5kaXZpZHVh
bHMuIEluc3RlYWQsIHRoZSBmYWN0IHRoYXQgc29tZXRoaW5nIGlzIGFuDQo+Pj4+Pj4+ZW1lcmdl
bmN5IGlzDQo+Pj4+Pj4+Pj5wdXJlbHkgYQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiBqdWRnZW1lbnQg
b2YgdGhlIGh1bWFuIHRoYXQgZGlhbHMgYSBzcGVjaWFsIG51bWJlci4NCj4+Pj4+Pj4+PlRvIGRl
YWwgd2l0aCBmcmF1ZCwgd2UNCj4+Pj4+Pj4+PiAgICAgICAgID4gZGlzY3Vzc2VkIGluIHRoZSBn
cm91cCBvbiB3aGF0IHdlIGNhbiBhY3R1YWxseSBkbyB0bw0KPj4+Pj4+PmVuc3VyZSB0aGF0DQo+
Pj4+Pj4+Pj5lbmQgdXNlcnMNCj4+Pj4+Pj4+PiAgICAgICAgID4gZG8gbm90IGJ5cGFzcyBzZWN1
cml0eSBwcm9jZWR1cmVzIChzdWNoIGFzDQo+Pj4+Pj4+YXV0aG9yaXphdGlvbiBjaGVja3MsDQo+
Pj4+Pj4+Pj5jaGFyZ2luZw0KPj4+Pj4+Pj4+ICAgICAgICAgPiBhbmQgc28gb24pLiBQYXJ0IG9m
IHRoaXMgaW52ZXN0aWdhdGlvbiB3YXMNCj4+Pj50aGUgcHVibGljYXRpb24gb2YNCj4+Pj4+Pj4+
PiAgICAgICAgID4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjNTA2OS50eHQgdGhhdCBhbHNv
DQo+Pj4+ZGVzY3JpYmVzIHRoaXMNCj4+Pj4+Pj4+Pmlzc3VlLg0KPj4+Pj4+Pj4+ICAgICAgICAg
Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiBTbywgaW1hZ2luZSB0aGUgaW1wbGVtZW50YXRpb24gb2Yg
YSBTSVAgDQo+cHJveHkgKGFuZCB3ZQ0KPj4+Pj4+PmltcGxlbWVudGVkDQo+Pj4+Pj4+Pj50aGF0
DQo+Pj4+Pj4+Pj4gICAgICAgICA+IHN0dWZmKSB0aGF0IHJlY2VpdmVzIGEgY2FsbCB0aGF0IGNv
bnRhaW5zIGEgU2VydmljZQ0KPj4+Pj4+PlVSTi4gVGhlIGNvZGUNCj4+Pj4+Pj4+PmJyYW5jaGVz
DQo+Pj4+Pj4+Pj4gICAgICAgICA+IGludG8gYSBzcGVjaWFsIG1vZGUgd2hlcmUgZXZlcnl0aGlu
ZyBpcyBkb25lDQo+Pj4+c28gdGhhdCB0aGUgY2FsbA0KPj4+Pj4+Pj4+cmVjZWl2ZXMNCj4+Pj4+
Pj4+PiAgICAgICAgID4gYXBwcm9wcmlhdGUgdHJlYXRtZW50IGFuZCBkb2VzIG5vdCBnZXQgDQo+
ZHJvcHBlZCBvbiB0aGUNCj4+Pj4+Pj5mbG9vci4gVGhlDQo+Pj4+Pj4+Pj53YXkgaG93IHRoZQ0K
Pj4+Pj4+Pj4+ICAgICAgICAgPiBTZXJ2aWNlIFVSTiBpcyBwbGFjZWQgaW4gdGhlIG1lc3NhZ2Ug
DQo+ZW5zdXJlcyB0aGF0IHRoZQ0KPj4+Pj4+PmNhbGwgY2Fubm90DQo+Pj4+Pj4+Pj5nbyB0byBt
eQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiBmcmllbmQgKGluc3RlYWQgb2YgdGhlIFBTQVApIHVubGVz
cyB0aGUgZW5kIGhvc3QgcmFuDQo+Pj4+Pj4+TG9TVCBhbHJlYWR5Lg0KPj4+Pj4+Pj4+SW4gdGhl
DQo+Pj4+Pj4+Pj4gICAgICAgICA+IGxhdHRlciBjYXNlLCB3ZSBkaXNjdXNzZWQgdGhpcyBhbHNv
IG9uIHRoZSANCj5saXN0IGZvciBhDQo+Pj4+Pj4+d2hpbGUgYW5kDQo+Pj4+Pj4+Pj5SaWNoYXJk
IGV2ZW4NCj4+Pj4+Pj4+PiAgICAgICAgID4gd3JvdGUgYSBkcmFmdCBhYm91dCBpdCBpbiB0aGUg
Y29udGV4dCBvZiB0aGUNCj4+Pj5sb2NhdGlvbiBoaWRpbmcNCj4+Pj4+Pj4+PnRvcGljLCB3ZSBz
YWlkDQo+Pj4+Pj4+Pj4gICAgICAgICA+IHRoYXQgdGhlIHByb3h5IHdvdWxkIGhhdmUgdG8gcnVu
IExvU1QgaWYgaGUNCj4+Pj5jYXJlcyBhYm91dCBhDQo+Pj4+Pj4+Pj5wb3RlbnRpYWwNCj4+Pj4+
Pj4+PiAgICAgICAgID4gZnJhdWR1bGVudCB1c2FnZS4NCj4+Pj4+Pj4+PiAgICAgICAgID4NCj4+
Pj4+Pj4+PiAgICAgICAgID4gU28sIHdoYXQgZG8gd2UgbmVlZCB0b2RvIGluIG9yZGVyIHRvIHBy
b3ZpZGUNCj4+Pj5zZWN1cmUgUkZDIDQ0MTINCj4+Pj4+Pj4+PmZ1bmN0aW9uYWxpdHkNCj4+Pj4+
Pj4+PiAgICAgICAgID4gaW4gb3VyIGNvbnRleHQ/DQo+Pj4+Pj4+Pj4gICAgICAgICA+DQo+Pj4+
Pj4+Pj4gICAgICAgICA+IERvIHlvdSB0aGluayB0aGF0IHRoZSBjdXJyZW50IHRleHQgaW4NCj4+
Pj4+Pj4+PiAgICAgICAgID4NCj4+Pj4+Pj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt
ZHJhZnRzL2RyYWZ0LWlldGYtZWNyaXQtbG9jYWwtZW1lcg0KPj4+Pj4+Pj4+Z2VuY3ktcnBoLW5h
bQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiBlc3BhY2UtMDAudHh0IHJlZmxlY3RzIGFueSBvZiB0aGUN
Cj4+Pj5hYm92ZS1kZXNjcmliZWQgaXNzdWVzOg0KPj4+Pj4+Pj4+ICAgICAgICAgPiAiDQo+Pj4+
Pj4+Pj4gICAgICAgICA+ICAgIFRoZSBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0aGF0IGFwcGx5
IA0KPnRvIFJGQyA0NDEyDQo+Pj4+Pj4+Pj5bUkZDNDQxMl0NCj4+Pj4+Pj4+PmFwcGx5DQo+Pj4+
Pj4+Pj4gICAgICAgICA+ICAgIGhlcmUuICBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgbm8gbmV3
IHNlY3VyaXR5DQo+Pj4+Pj4+Pj5pc3N1ZXMgcmVsYXRpdmUNCj4+Pj4+Pj4+PnRvDQo+Pj4+Pj4+
Pj4gICAgICAgICA+ICAgIFJGQyA0NDEyLg0KPj4+Pj4+Pj4+ICAgICAgICAgPiAiDQo+Pj4+Pj4+
Pj4gICAgICAgICA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+IEZyb20gdmFyaW91cyBkaXNjdXNzaW9u
cyBpbiBHRU9QUklWIEkgcmVjYWxsDQo+Pj4+dGhhdCB5b3UgYXJlDQo+Pj4+Pj4+Pj5zdXBlci1z
ZW5zaXRpdmUNCj4+Pj4+Pj4+PiAgICAgICAgID4gcmVnYXJkaW5nIHNlY3VyaXR5IGFuZCBwcml2
YWN5LiBGb3Igc29tZSByZWFzb25zIHlvdQ0KPj4+Pj4+PmRvbid0IHNlZW0gdG8NCj4+Pj4+Pj4+
PmhhdmUgdGhlDQo+Pj4+Pj4+Pj4gICAgICAgICA+IHNhbWUgY29uY2VybnMgaGVyZS4gSSB3b3Vs
ZCBsaWtlIHRvDQo+Pj4+dW5kZXJzdGFuZCB5b3VyIHJlYXNvbmluZy4NCj4+Pj4+Pj4+PiAgICAg
ICAgID4NCj4+Pj4+Pj4+PiAgICAgICAgID4gUGxlYXNlIGFsc28gZG8gbWUgYW5vdGhlciBmYXZv
cjogRG9uJ3QgYWx3YXlzIHNheQ0KPj4+Pj4+PnRoYXQgSSBkb24ndA0KPj4+Pj4+Pj4+dW5kZXJz
dGFuZA0KPj4+Pj4+Pj4+ICAgICAgICAgPiB0aGUgc3ViamVjdC4gRXZlbiBpZiB0aGF0IHdvdWxk
IGJlIHRoZSBjYXNlIGl0IGlzbid0DQo+Pj4+Pj4+cGFydGljdWxhcg0KPj4+Pj4+Pj4+ZmFpciBn
aXZlbg0KPj4+Pj4+Pj4+ICAgICAgICAgPiB0aGF0IGRpZmZlcmVudCBmb2xrcyBoYWQgdG8gZWR1
Y2F0ZSB5b3Ugb24gb3RoZXINCj4+Pj4+Pj50b3BpY3MgaW4gdGhlDQo+Pj4+Pj4+Pj5wYXN0IGFz
IHdlbGwuDQo+Pj4+Pj4+Pj4gICAgICAgICA+IEFkZGl0aW9uYWxseSwgaWYgeW91IGxpc3RlbiB0
byB0aGUgYXVkaW8gcmVjb3JkaW5ncw0KPj4+Pj4+PnRoZW4geW91IHdpbGwNCj4+Pj4+Pj4+Pm5v
dGljZQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiB0aGF0IEhlbm5pbmcsIFRlZCwgYW5kIEpvbiBkbyBu
b3Qgc2VlbSB0byB1bmRlcnN0YW5kDQo+Pj4+Pj4+dGhlIGlzc3VlDQo+Pj4+Pj4+Pj5laXRoZXIg
YXMNCj4+Pj4+Pj4+PiAgICAgICAgID4gdGhleSBoYXZlIHJhaXNlZCBzaW1pbGFyIGlzc3VlcyBk
dXJpbmcgdGhlDQo+Pj4+RjJGIG1lZXRpbmdzLg0KPj4+Pj4+Pj4+ICAgICAgICAgPg0KPj4+Pj4+
Pj4+ICAgICAgICAgPiBDaWFvDQo+Pj4+Pj4+Pj4gICAgICAgICA+IEhhbm5lcw0KPj4+Pj4+Pj4+
ICAgICAgICAgPg0KPj4+Pj4+Pj4+ICAgICAgICAgPg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+SGFu
bmVzIC0gSSBiZWxpZXZlIGl0IGlzIHlvdSB3aG8gZG8gbm90IHVuZGVyc3RhbmQNCj4+Pj4+Pj5S
RkMgNDQxMiAtLQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+YW5kIG1hbnkgb2YgdXMgYXJlIHRyeWlu
ZyB0byBnZXQgdGhhdA0KPj4+PnRocm91Z2ggdG8geW91LCBidXQgeW91DQo+Pj4+Pj4+Pj4gICAg
ICAgICA+ID5kb24ndCBzZWVtIHRvIHdhbnQgdG8gbGlzdGVuL3JlYWQuDQo+Pj4+Pj4+Pj4gICAg
ICAgICA+ID4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPlJGQyA0NDEyIGlzICpmb3IqIHByaW9yaXR5
IG1hcmtpbmcgU0lQIHJlcXVlc3RzLA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+DQo+Pj4+Pj4+Pj4g
ICAgICAgICA+ID5PbmUgdXNlIGlzIEdFVFMuDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4NCj4+Pj4+
Pj4+PiAgICAgICAgID4gPk9uZSB1c2UgaXMgTUxQUC4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPg0K
Pj4+Pj4+Pj4+ICAgICAgICAgPiA+VGhlc2UgZXhhbXBsZXMgYXJlIGluIFJGQyA0NDEyIGJlY2F1
c2UgdGhlcmUNCj4+Pj53ZXJlIHNwZWNpZmljDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5uYW1lc3Bh
Y2VzIGJlaW5nIGNyZWF0ZWQgZm9yIHRoZSBJQU5BIHNlY3Rpb24gb2YNCj4+Pj4+Pj50aGF0IGRv
Y3VtZW50Lg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5SZWFk
aW5nIHRoZSB3aG9sZSBkb2N1bWVudCwgeW91IHdpbGwgc2VlDQo+Pj4+dGhhdCBSUEggY2FuIGJl
DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5zcGVjaWZpZWQgZm9yIG90aGVyIHVzZXMgdGhhbiBHRVRT
IG9yIE1MUFANCj4+Pj5zcGVjaWZpY2FsbHkuDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4NCj4+Pj4+
Pj4+PiAgICAgICAgID4gPkkga25ldyB3aGVuIEkgd3JvdGUgUkZDIDQ0MTIgdGhhdCBvbmUgZGF5
IHdlDQo+Pj4+d291bGQgc3BlY2lmeSBhDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5uYW1lc3BhY2Ug
Zm9yIEVDUklUICh0aGUgImVzbmV0IiBuYW1lc3BhY2UNCj4+Pj5ub3cpIC0tIGJ1dCBJIGFsc28N
Cj4+Pj4+Pj4+PiAgICAgICAgID4gPmtuZXcgaXQgd2FzIHByZW1hdHVyZSBmb3IgUkZDIDQ0MTIg
dG8NCj4+Pj5pbmNvcnBvcmF0ZSB0aGF0DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5uYW1lc3BhY2Us
IHRoYXQgYSBmdXR1cmUgZG9jIHRvIFJGQyA0NDEyDQo+Pj4+d291bGQgaGF2ZSB0byBiZQ0KPj4+
Pj4+Pj4+ICAgICAgICAgPiA+d3JpdHRlbiB0byBkbyB0aGlzLiBCcmlhbiBhbmQgSSB0YWxrZWQg
YWJvdXQNCj4+Pj50aGlzIGF0IHRoZQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+b3JpZ2luYWwgTkVO
QSBtZWV0aW5nIHRoYXQgY3JlYXRlZCB0aGUgSVAgV0dzIHRoZXJlDQo+Pj4+Pj4+KGluIEF1Z3Vz
dA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+b2YgMDMpLiAgV2UgYm90aCBhZ3JlZWQgd2Ugc2hvdWxk
IHdhaXQgdW50aWwgaXQgd2FzDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5hcHByb3ByaWF0ZSB0byB0
aGUgd29yayBpbiB0aGUgSUVURiB0bw0KPj4+PnN1Ym1pdCB0aGlzIGRvY3VtZW50DQo+Pj4+Pj4+
Pj4gICAgICAgICA+ID50aGF0IGlzIG5vdw0KPj4+Pj4+Pj4+ICAgICAgICAgPg0KPj4+Pj4+Pj4+
Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZWNyaXQtbA0K
Pm9jYWwtZW1lcg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+Z2VuY3ktcnBoLW5hbWVzcGFjZS0wMC50
eHQNCj4+Pj4+Pj4+PiAgICAgICAgID4gPg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+WWV0LCB5b3Ug
c2VlbSB0byB3YW50IHRvIHVzZSBzb21lIGFkZGl0aW9uYWwNCj4+Pj5tZWNoYW5pc20gdG8NCj4+
Pj4+Pj4+PiAgICAgICAgID4gPmluZGljYXRlIHByaW9yaXR5IG9mIGEgY2FsbCBpbiBTSVAuICBU
aGF0DQo+Pj4+bWVhbnMgeW91IHdhbnQgdG8NCj4+Pj4+Pj4+PiAgICAgICAgID4gPmludHJvZHVj
ZSBhIHNlY29uZCB3YXkgdG8gYWNjb21wbGlzaCB0aGlzIGluIFNJUC4NCj4+Pj4+Pj4+PldoeSBk
byB5b3UNCj4+Pj4+Pj4+PiAgICAgICAgID4gPndhbnQgdG8gcHJvbW90ZSBhIHNlcGFyYXRlIHdh
eSB0byBkbyBzb21ldGhpbmcgU0lQDQo+Pj4+Pj4+aGFzIGFscmVhZHkNCj4+Pj4+Pj4+PiAgICAg
ICAgID4gPmRlZmluZWQ/IFRoYXQgd2lsbCBjYXVzZSBpbnRlcm9wZXJhYmlsaXR5IA0KPmlzc3Vl
cyBhbmQNCj4+Pj4+Pj53ZSBib3RoIGtub3cNCj4+Pj4+Pj4+PnRoYXQuDQo+Pj4+Pj4+Pj4gICAg
ICAgICA+ID4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPllvdSd2ZSBzYWlkIHRvIG1lIChhbmQgb3Ro
ZXJzKSB0aGF0IHlvdQ0KPj4+PmJlbGlldmUgUlBIIGlzIGp1c3QNCj4+Pj4+Pj4+PiAgICAgICAg
ID4gPmFub3RoZXIgd2F5IHRvIGFjY29tcGxpc2ggd2hhdCBzb3Mgb3IgYSBVUkkgY2FuDQo+Pj4+
Pj4+aW5kaWNhdGUgLSBhbmQNCj4+Pj4+Pj4+PiAgICAgICAgID4gPnlvdSdyZSB3cm9uZy4gIFlv
dXIgd2F5IHdvdWxkIGJlDQo+Pj4+X3RoZV9zZWNvbmRfd2F5X3RvX2RvX2l0LA0KPj4+Pj4+Pj4+
ICAgICAgICAgPiA+YmVjYXVzZSBTSVAgYWxyZWFkeSBjb25zaWRlcnMgUlBIIHRvIGJlDQo+Pj4+
KnRoZSp3YXkqIHRvIHByaW9yaXR5DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5tYXJrIFNJUCByZXF1
ZXN0cy4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+SWYgeW91
IGRvbid0IGJlbGlldmUgbWUgKG5vIGNvbW1lbnQpLCB0aGVuDQo+Pj4+d2h5IGRvIHlvdSBub3QN
Cj4+Pj4+Pj4+PiAgICAgICAgID4gPmJlbGlldmUgdGhlIFNJUCBXRyBjaGFpciAod2hvIGtub3dz
IG1vcmUNCj4+Pj5hYm91dCBTSVAgdGhhbiBib3RoDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5vZiB1
cykgLSB3aG8sIG9uIHRoaXMgdGhyZWFkLCBoYXMgYWdhaW4gc2FpZA0KPj4+PnRvIHlvdSAiUkZD
IDQ0MTINCj4+Pj4+Pj4+PiAgICAgICAgID4gPihSUEgpIGlzIHRoZSBTSVAgbWVjaGFuaXNtIHRv
IHByaW9yaXR5IG1hcmsNCj4+Pj5TSVAgcmVxdWVzdHMiPw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+
DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5GdXJ0aGVyLCBJIGJlbGlldmUgaXQgaXMgaW5hcHByb3By
aWF0ZSB0bw0KPj4+PnByb2hpYml0IGVuZHBvaW50cw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+ZnJv
bSBiZWluZyBhYmxlIHRvIHNldCB0aGUgZXNuZXQgbmFtZXNwYWNlLg0KPj4+PkkgYWJzb2x1dGVs
eQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+YmVsaWV2ZSBpdCB3aWxsIG5vdCBiZSBuZWVkZWQgbW9z
dCBvZiB0aGUNCj4+Pj50aW1lLCBidXQgSSBiZWxpZXZlDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5p
ZiBzb21lb25lIGRvZXMgZmluZCBhIHZhbGlkIHVzZSBmb3INCj4+Pj5lbmRwb2ludHMgdG8gbWFy
aw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+cHJpb3JpdHkgaW4gU0lQLCB0aGlzIElEIC0gb25jZSBp
dCBoYXMNCj4+Pj5iZWNvbWUgYW4gUkZDIC0tIHdpbGwNCj4+Pj4+Pj4+PiAgICAgICAgID4gPmhh
dmUgdG8gYmUgb2Jzb2xldGVkIHdpdGggYSBuZXcgUkZDIHNheWluZyANCj50aGUgZXhhY3QNCj4+
Pj4+Pj5vcHBvc2l0ZS4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPg0KPj4+Pj4+Pj4+ICAgICAgICAg
PiA+KGNvbG9yIG1lIGNvbmZ1c2VkIC4uLiBvdmVyIGFuZCBvdmVyIGFnYWluKQ0KPj4+Pj4+Pj4+
ICAgICAgICAgPiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5KYW1lcw0KPj4+Pj4+Pj4+ICAgICAg
ICAgPiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5BdCAwMTowNSBQTSAyLzUvMjAwOSwgSGFubmVz
IFRzY2hvZmVuaWcgd3JvdGU6DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+S2VpdGgsIHBsZWFzZSB1
bmRlcnN0YW5kIHRoYXQgdGhlIHVzYWdlIA0KPm9mIFJGQyA0NDEyDQo+Pj4+Pj4+Zm9yIEdFVFMg
YW5kDQo+Pj4+Pj4+Pj5mb3INCj4+Pj4+Pj4+PiAgICAgICAgID4gPj50aGUgdHlwZSBvZiBlbWVy
Z2VuY3kgY2FsbCB3ZSBkaXNjdXNzIGhlcmUgaXMNCj4+Pj4+Pj5kaWZmZXJlbnQuIEp1c3QNCj4+
Pj4+Pj4+Pmxvb2tpbmcNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj5hdCB0aGUgaGVhZGVyIGFuZCB0
aGUgbmFtZSBvZiB0aGUgDQo+bmFtZXNwYWNlIGlzIGEgYml0DQo+Pj4+Pj4+Pj4gICAgICAgICA+
ID5hcnRpZmljaWFsLiBJIGhvcGUNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj55b3UgdW5kZXJzdGFu
ZCB0aGF0Lg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPkZyb206
IERSQUdFLCBLZWl0aCAoS2VpdGgpDQo+Pj4+Pj4+Pj5bbWFpbHRvOmRyYWdlQGFsY2F0ZWwtbHVj
ZW50LmNvbV0NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPlNlbnQ6IDA1IEZlYnJ1YXJ5LCAyMDA5
IDE0OjU1DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID5UbzogQnJpYW4gUm9zZW47ICdIYW5uZXMg
VHNjaG9mZW5pZyc7ICdKYW1lcyBNLg0KPj4+Pj4+Pj4+UG9sayc7ICdUc2Nob2ZlbmlnLA0KPj4+
Pj4+Pj4+ICAgICAgICAgPiA+PiA+SGFubmVzIChOU04gLSBGSS9Fc3BvbyknOyAnRUNSSVQnDQo+
Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID5TdWJqZWN0OiBSRTogW0Vjcml0XSBFQ1JJVCBWaXJ0dWFs
IEludGVyaW0NCj4+Pj4+Pj4+Pk1lZXRpbmc6IEFnZW5kYSAobXkNCj4+Pj4+Pj4+Pg0KPj4+Pj4+
Pj4+ICAgICAgICAgPiA+PiA+bWlzdGFrZSkNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPg0KPj4+
Pj4+Pj4+ICAgICAgICAgPiA+PiA+V2hpY2ggaXMgZXhhY3RseSB3aGF0IFJGQyA0NDEyIHNwZWNp
ZmllcyBmb3IgYWxsDQo+Pj4+Pj4+bmFtZXNwYWNlcy4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4g
Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+cmVnYXJkcw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+
PiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID5LZWl0aA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+
PiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcN
Cj4+Pj4+Pj5bbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddDQo+Pj4+Pj4+Pj4gICAgICAg
ICA+ID4+ID5PbiBCZWhhbGYNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gT2YgQnJpYW4gUm9z
ZW4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAw
NCwgMjAwOSAxMDoxOSBQTQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBUbzogJ0hhbm5lcyBU
c2Nob2ZlbmlnJzsgJ0phbWVzIE0uDQo+Pj4+UG9sayc7ICdUc2Nob2ZlbmlnLA0KPj4+Pj4+Pj4+
ICAgICAgICAgPiA+SGFubmVzIChOU04NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gLSBGSS9F
c3BvbyknOyAnRUNSSVQnDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IFN1YmplY3Q6IFJlOiBb
RWNyaXRdIEVDUklUIFZpcnR1YWwgSW50ZXJpbQ0KPj4+Pj4+Pj4+TWVldGluZzogQWdlbmRhICht
eQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBtaXN0YWtlKQ0KPj4+Pj4+Pj4+ICAgICAgICAg
PiA+PiA+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBUaGUgdmFsdWUgaXMgdGhhdCBpbiBz
b21lIG5ldHdvcmtzDQo+Pj4+d2hlcmUgcHJpb3JpdHkgZm9yDQo+Pj4+Pj4+Pj4gICAgICAgICA+
ID4+ID5lbWVyZ2VuY3kgY2FsbHMNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gaXMgYXBwcm9w
cmlhdGUsIGFuZCBhcHByb3ByaWF0ZQ0KPj4+PnBvbGljaW5nIG9mIG1hcmtpbmcgaXMNCj4+Pj4+
Pj4+PiAgICAgICAgID4gPmltcGxlbWVudGVkLA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBl
bWVyZ2VuY3kgY2FsbHMgd2lsbCByZWNlaXZlIHJlc291cmNlIA0KPnByaW9yaXR5Lg0KPj4+Pj4+
Pj4+ICAgICAgICAgPiA+PiA+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBOb3QgYWxsIG5l
dHdvcmtzIHdvdWxkIG5lZWQgcG9saWNpbmcuICBTb21lDQo+Pj4+Pj4+d2lsbC4gIFBvbGljaW5n
DQo+Pj4+Pj4+Pj5jb3VsZA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBiZSB0byBSb3V0ZSBo
ZWFkZXIvUi1VUkkgY29udGVudCwgYnV0IG90aGVyDQo+Pj4+Pj4+Y3JpdGVyaWEgYXJlDQo+Pj4+
Pj4+Pj5wb3NzaWJsZS4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4NCj4+Pj4+Pj4+PiAgICAg
ICAgID4gPj4gPj4gTm90IGFsbCBuZXR3b3JrcyB3aWxsIG5lZWQgcmVzb3VyY2UgcHJpb3JpdHkN
Cj4+Pj4+Pj5mb3IgZW1lcmdlbmN5DQo+Pj4+Pj4+Pj5jYWxscy4NCj4+Pj4+Pj4+PiAgICAgICAg
ID4gPj4gPj4gRmluZSwgaWdub3JlIHRoaXMgbWFya2luZy9uYW1lc3BhY2UuDQo+Pj4+Pj4+Pj4g
ICAgICAgICA+ID4+ID4+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IEJyaWFuDQo+Pj4+Pj4+
Pj4gICAgICAgICA+ID4+ID4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+
PiAgICAgICAgID4gPj4gPj4gPiBGcm9tOiBIYW5uZXMgVHNjaG9mZW5pZw0KPj4+Pj4+Pj4+W21h
aWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0XQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+
PiA+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDQsIDIwMDkgNTowOSBQTQ0KPj4+Pj4+Pj4+
ICAgICAgICAgPiA+PiA+PiA+IFRvOiAnQnJpYW4gUm9zZW4nOyAnSmFtZXMgTS4gUG9sayc7DQo+
Pj4+Pj4+VHNjaG9mZW5pZywgSGFubmVzDQo+Pj4+Pj4+Pj4oTlNOIC0NCj4+Pj4+Pj4+PiAgICAg
ICAgID4gPj4gPj4gPiBGSS9Fc3Bvbyk7ICdFQ1JJVCcNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4g
Pj4gPiBTdWJqZWN0OiBSRTogW0Vjcml0XSBFQ1JJVCBWaXJ0dWFsIEludGVyaW0NCj4+Pj4+Pj4+
Pk1lZXRpbmc6IEFnZW5kYSAobXkNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiBtaXN0YWtl
KQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+
ID4gSSBkb24ndCBldmVuIHNlZSB0aGUgdmFsdWUgaW4gcGVybWl0dGluZyB0aGUNCj4+Pj4+Pj5l
bmRwb2ludCB0b2RvDQo+Pj4+Pj4+Pj50aGUNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiBS
UEggbWFya2luZy4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiBJbiBhZGRpdGlvbiB0byB0
aGUgc2VjdXJpdHkgY29uY2VybnMNCj4+Pj50aGVyZSBpcyBhbHNvIHRoZQ0KPj4+Pj4+Pj4+ICAg
ICAgICAgPiA+PiA+cHJvYmxlbSB0aGF0DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gdGhl
cmUgYXJlIG1vcmUgb3B0aW9ucyB0byBpbXBsZW1lbnQgd2l0aG91dA0KPj4+Pj4+PmFuIGFkZGl0
aW9uYWwNCj4+Pj4+Pj4+PnZhbHVlLg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+DQo+Pj4+
Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+
Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPkZyb206IEJyaWFuIFJvc2VuIA0KPlttYWlsdG86YnJA
YnJpYW5yb3Nlbi5uZXRdDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPlNlbnQ6IDA1IEZl
YnJ1YXJ5LCAyMDA5IDAwOjAzDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPlRvOiAnSmFt
ZXMgTS4gUG9sayc7ICdIYW5uZXMgVHNjaG9mZW5pZyc7DQo+Pj4+Pj4+J1RzY2hvZmVuaWcsDQo+
Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IEhhbm5lcyAoTlNOIC0NCj4+Pj4+Pj4+PiAgICAgICAg
ID4gPj4gPj4gPiA+RkkvRXNwb28pJzsgJ0VDUklUJw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+
PiA+ID5TdWJqZWN0OiBSRTogW0Vjcml0XSBFQ1JJVCBWaXJ0dWFsDQo+Pj4+SW50ZXJpbSBNZWV0
aW5nOg0KPj4+Pj4+Pj4+QWdlbmRhIChteQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+IG1p
c3Rha2UpDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPg0KPj4+Pj4+Pj4+ICAgICAgICAg
PiA+PiA+PiA+ID5IYW5uZXMNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+DQo+Pj4+Pj4+
Pj4gICAgICAgICA+ID4+ID4+ID4gPlRoaXMgbWF0Y2hlcyBteSB1bmRlcnN0YW5kaW5nDQo+Pj4+
cHJlY2lzZWx5LiAgV2Ugd2lzaCB0bw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBwZXJtaXQg
ZW5kcG9pbnRzDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPnRvIG1hcmsuIFdlIGRvIG5v
dCByZXF1aXJlIGl0LCBhbmQNCj4+Pj5kb24ndCBuZWNlc3NhcmlseQ0KPj4+Pj4+Pj4+ZXhwZWN0
IGl0DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPmluIG1hbnkgKGV2ZW4NCj4+Pj4+Pj4+
PiAgICAgICAgID4gPj4gPj4gPiA+bW9zdCkgY2FzZXMuICBXZSBkb24ndCB3aXNoIHRvIHNlZSB0
aGUNCj4+Pj4+Pj5kb2N1bWVudCBwcm9oaWJpdA0KPj4+Pj4+Pj4+aXQuDQo+Pj4+Pj4+Pj4gICAg
ICAgICA+ID4+ID4+ID4gPldlIGFsbCBzZWVtIHRvIGFncmVlIGl0IGhhcyB2YWx1ZSANCj53aXRo
aW4gdGhlDQo+Pj4+Pj4+RW1lcmdlbmN5DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID5TZXJ2aWNl
cyBJUA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID5OZXR3b3Jrcy4NCj4+Pj4+Pj4+PiAg
ICAgICAgID4gPj4gPj4gPiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPkJyaWFuDQo+
Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+
ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+
ID4gPj4gRnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZw0KPj4+Pj4+Pj4+W21haWx0bzplY3Jp
dC1ib3VuY2VzQGlldGYub3JnXQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID5PbiBCZWhh
bGYNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBPZiBKYW1lcyBNLiBQb2xrDQo+Pj4+
Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNCwg
DQo+MjAwOSA0OjAxIFBNDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gVG86IEhhbm5l
cyBUc2Nob2ZlbmlnOyBUc2Nob2ZlbmlnLA0KPj4+Pkhhbm5lcyAoTlNOIC0NCj4+Pj4+Pj4+PiAg
ICAgICAgID4gPj4gPj4gRkkvRXNwb28pOyAnRUNSSVQnDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+
ID4+ID4gPj4gU3ViamVjdDogUmU6IFtFY3JpdF0gRUNSSVQgDQo+VmlydHVhbCBJbnRlcmltDQo+
Pj4+Pj4+Pj5NZWV0aW5nOg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+QWdlbmRhIChteQ0KPj4+Pj4+
Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IG1pc3Rha2UpDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+
ID4+ID4gPj4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBBdCAwMjozNyBQTSAyLzQv
MjAwOSwgSGFubmVzDQo+Pj4+VHNjaG9mZW5pZyB3cm90ZToNCj4+Pj4+Pj4+PiAgICAgICAgID4g
Pj4gPj4gPiA+PiA+ID4gSmFtZXMgd3JvdGU6DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4g
Pj4gPiA+PiB5b3UgYXJlIHRoZSBfbG9uZV8gdm9pY2Ugbm90DQo+Pj4+Pj4+c3VwcG9ydGluZyB0
aGlzIElELA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID4NCj4+Pj4+Pj4+PiAgICAg
ICAgID4gPj4gPj4gPiA+PiA+TGlzdGVuaW5nIHRvIHRoZSBhdWRpbyByZWNvcmRpbmcgb2YgcGFz
dA0KPj4+Pj4+Pm1lZXRpbmdzIEkNCj4+Pj4+Pj4+PmhhdmUgdG8NCj4+Pj4+Pj4+PiAgICAgICAg
ID4gPj4gPj4gPiA+c2F5IHRoYXQNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiA+SQ0K
Pj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHdhcw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+
PiA+PiA+ID4+ID5ub3QgdGhlIG9ubHkgcGVyc29ucyByYWlzaW5nDQo+Pj4+Y29uY2VybnMgYWJv
dXQgdGhlDQo+Pj4+Pj4+Pj5kb2N1bWVudC4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+
PiA+VGhhdCB3YXMgcHJvYmFibHkgdGhlIHJlYXNvbiB3aHkgeW91DQo+Pj4+Pj4+YWdyZWVkIHRv
IGxpbWl0DQo+Pj4+Pj4+Pj50aGUNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+c2NvcGUg
b2YgdGhlDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gPmRvY3VtZW50ICh3aGljaCB5
b3UgZGlkbid0IGxhdGVyIGRvKSB0bw0KPj4+Pj4+PmdldCBmb2xrcyB0bw0KPj4+Pj4+Pj4+YWdy
ZWUNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+dG8gbWFrZSBpdA0KPj4+Pj4+Pj4+ICAg
ICAgICAgPiA+PiA+PiA+ID4+IGEgV0cNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiA+
aXRlbS4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+Pg0KPj4+Pj4+Pj4+ICAgICAgICAg
PiA+PiA+PiA+ID4+IHJlLWxpc3RlbiB0byB0aGUgYXVkaW8gcGxlYXNlDQo+Pj4+Pj4+Pj4gICAg
ICAgICA+ID4+ID4+ID4gPj4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBUZWQncyBj
b25jZXJucyB3ZXJlIGNvbnNpc3RlbnQgd2l0aCBtb3N0DQo+Pj4+Pj4+Pj4oYWxsPykgb3RoZXIN
Cj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gY29uY2VybnMgLS0NCj4+Pj4+Pj4+PiAgICAgICAg
ID4gPj4gPj4gPiA+PiB3aGljaCB3ZXJlIGJhc2VkIG9uIHRoZSBwcmVtaXNlIA0KPm9mIHdoZXRo
ZXINCj4+Pj4+Pj5vciBub3QgdGhlDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IFVBQyBzaG91
bGQgYmUNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiB0cnVzdGVkIHRvIGluaXRpYXRl
IHRoZSBtYXJraW5nIG9uIHRoZQ0KPj4+Pj4+PklOVklURS4gIFRoZQ0KPj4+Pj4+Pj4+bW9zdA0K
Pj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHJlY2VudCB2ZXJzaW9uIGhhcyBiYWNrZWQg
b2ZmIHRoaXMNCj4+Pj50byBhICJjYW4iIC0tDQo+Pj4+Pj4+Pj5tZWFuaW5nIG5vdA0KPj4+Pj4+
Pj4+ICAgICAgICAgPiA+PiA+cHJvaGliaXRlZA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+
ID4+IChpLmUuLCBubyAyMTE5IHRleHQpLiAgSSBhbHNvIGJhY2tlZCBvZmYNCj4+Pj4+Pj50aGUg
dGV4dCBpbg0KPj4+Pj4+Pj4+dGhlDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IFNQIGRvbWFp
bg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHBhcnQgdG8gImNhbiIsIHN1Y2ggdGhh
dCB0aGVyZSBpcw0KPj4+Pm5vIDIxMTkgdGV4dA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+bWFu
ZGF0aW5nIG9yIGV2ZW4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiByZWNvbW1lbmRp
bmcgaXRzIHVzYWdlIHRoZXJlLiBJIGFsc28gZG8NCj4+Pj4+Pj5ub3QgcHJvaGliaXQNCj4+Pj4+
Pj4+Pml0cw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID51c2UsIGJhc2VkIG9uDQo+Pj4+
Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gbG9jYWwgcG9saWN5LiAgS2VpdGggaGFzIGNvbWUg
DQo+Zm9yd2FyZCB3aXRoDQo+Pj4+Pj4+dGhlIHNwZWNpZmljDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+
PiAgICAgICAgID4gPj4gPj4gPiA+PiByZXF1ZXN0IHRoYXQgbm9uLUVTSW5ldCBuZXR3b3JrcyBi
ZQ0KPj4+Pj4+PmFsbG93ZWQgdG8gbWFyayBhbmQNCj4+Pj4+Pj4+PnBheQ0KPj4+Pj4+Pj4+ICAg
ICAgICAgPiA+PiA+YXR0ZW50aW9uIHRvDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4g
dGhpcyBwcmlvcml0eSBpbmRpY2F0aW9uIC0tIHdpdGggSU1TIGFzDQo+Pj4+Pj4+dGhlIHNwZWNp
ZmljDQo+Pj4+Pj4+Pj5leGFtcGxlDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gaGUg
d2lzaGVzIHRvIGhhdmUgdGhpcyB2YWxpZCBmb3IuDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+
ID4gPj4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBXaGVyZSB0aGVyZSBpcyBubyBk
aXNhZ3JlZW1lbnQsIHNhdmUgZm9yDQo+Pj4+Pj4+eW91ciByZWNlbnQNCj4+Pj4+Pj4+PiAgICAg
ICAgID4gPj4gPj4gPiA+cHVzaGJhY2sgLSBpcyBpbg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+
PiA+ID4+IHRoZSBFU0luZXQsIHdoaWNoIGlzIHdoZXJlIEJyaWFuDQo+Pj4+aGFzIHJlcXVlc3Rl
ZCBpdCdzDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPmRlZmluaXRpb24gaW4gdGhlDQo+
Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gSUVURiBvbiBiZWhhbGYgb2YgTkVOQS4gIEhl
J3MgdGhlIGkzIFdHDQo+Pj4+Pj4+Y2hhaXIgd2l0aGluDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+
ID4+IE5FTkEsIGFuZCBpZg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IGhlIGFza3Mg
Zm9yIGl0LCBhcmUgeW91IGdvaW5nIHRvIHNheSB5b3UNCj4+Pj4+Pj5rbm93IGJldHRlcg0KPj4+
Pj4+Pj4+dGhhbiBoZT8NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+Pg0KPj4+Pj4+Pj4+
ICAgICAgICAgPiA+PiA+PiA+ID4+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gPkJ0
dywgSSBub3QgZGlzYWdyZWVpbmcgd2l0aCB0aGUgZG9jdW1lbnQNCj4+Pj4+Pj5hcyBzdWNoLiBJ
DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID5qdXN0IHdhbnQgdG8NCj4+Pj4+Pj4+PiAgICAgICAg
ID4gPj4gPj4gPiB0aGUNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBzY29wZQ0KPj4+
Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID50byBjaGFuZ2UuIFRoZSB1c2FnZSBvZiBSUEgN
Cj4+Pj53aXRoaW4gdGhlIGVtZXJnZW5jeQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBzZXJ2
aWNlcyBuZXR3b3JrDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gaXMNCj4+Pj4+Pj4+PiAg
ICAgICAgID4gPj4gPj4gPiA+PiBmaW5lDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4g
PmZvciBtZS4gSSBtYXkgZ2V0IGNvbnZpbmNlZCB0byBzdGFydCB0aGUNCj4+Pj4+Pj5SUEggbWFy
a2luZw0KPj4+Pj4+Pj4+ZnJvbQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID50aGUgdGhl
IFZTUA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID50b3dhcmRzIHRoZSBQU0FQLiBJ
IGZlZWwgdW5lYXN5IA0KPmFib3V0IHRoZQ0KPj4+Pj4+PmVuZCBob3N0DQo+Pj4+Pj4+Pj5kb2lu
Zw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID50aGUgbWFya2luZy4NCj4+Pj4+Pj4+PiAg
ICAgICAgID4gPj4gPj4gPiA+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHBsZWFz
ZSByZWFkIHdoYXQgSSB3cm90ZSBhYm92ZSwgYW5kIHRoZW4NCj4+Pj4+Pj5yZS1yZWFkIHRoZQ0K
Pj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+bW9zdCByZWNlbnQNCj4+Pj4+Pj4+PiAgICAgICAgID4g
Pj4gPj4gPiA+PiB2ZXJzaW9uIG9mIHRoZSBJRC4gSSBkb24ndCBoYXZlIGVuZHBvaW50cw0KPj4+
Pj4+PnRoYXQgU0hPVUxEDQo+Pj4+Pj4+Pj5vcg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBN
VVNUIG1hcmsNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBhbnl0aGluZyB3cnQgUlBI
LiAgSSBhbHNvIGRvbid0IHdhbnQgdG8NCj4+Pj4+Pj5wcm9oaWJpdCBpdCwNCj4+Pj4+Pj4+PiAg
ICAgICAgID4gPj4gPj4gYmVjYXVzZSB0aGVyZQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+
ID4+IG1pZ2h0IGJlIGNhc2VzICh0aGF0IEkgZG9uJ3Qga25vdw0KPj4+Pm9mKSBvZiB2YWxpZCB1
c2VzDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IHVuZGVyIGNlcnRhaW4NCj4+Pj4+Pj4+PiAg
ICAgICAgID4gPj4gPj4gPiA+PiBjaXJjdW1zdGFuY2VzLiAgRmlndXJlIDEgaXMgdmVyeSBjbGVh
cg0KPj4+Pj4+PnRoYXQgdGhlcmUgYXJlIDMNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gbmV0
d29ya2luZw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHBhcnRzIHRvIGNvbnNpZGVy
DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4g
Pj4gPiA+PiAjMSAtIGZyb20gdGhlIGVuZHBvaW50DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+
ID4gPj4gIzIgLSB3aXRoaW4gdGhlIFZTUA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+
ICMzIC0gd2l0aGluIHRoZSBFU0luZXQNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+Pg0K
Pj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHRoZSBtb3N0IHJlY2VudCBJRCB2ZXJzaW9u
IGhhcyAiY2FuIiBmb3INCj4+Pj4+Pj4jcyAxIGFuZCAyLA0KPj4+Pj4+Pj4+YW5kDQo+Pj4+Pj4+
Pj4gICAgICAgICA+ID4+ID4+ID4gPjIxMTkgbGFuZ3VhZ2UNCj4+Pj4+Pj4+PiAgICAgICAgID4g
Pj4gPj4gPiA+PiBvZmZlcmluZyB0aG9zZSBzdXBwb3J0aW5nIHRoaXMNCj4+Pj4+Pj5zcGVjaWZp
Y2F0aW9uIHdpbGwgaGF2ZQ0KPj4+Pj4+Pj4+UlBIDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+
ID4gPj4gYWRoZXJlbmNlIHdpdGhpbiAjMyAodGhlIEVTSW5ldCkuDQo+Pj4+Pj4+Pj4gICAgICAg
ICA+ID4+ID4+ID4gPj4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBXaGF0IG90aGVy
IHNjb3BlIGNoYW5nZXMgZG8geW91IHdhbnQsDQo+Pj4+Pj4+YmVjYXVzZSBJIGhhdmVuJ3QNCj4+
Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gaGVhcmQgdGhlbS4NCj4+Pj4+Pj4+PiAgICAgICAgID4g
Pj4gPj4gPiA+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IEkgb25seSBoZWFyZCB5
b3UgY2xhaW0gaW4gZW1haWwgDQo+ZHVyaW5nIHRoZQ0KPj4+Pj4+Pmxhc3QgSUVURg0KPj4+Pj4+
Pj4+YW5kIGluDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPnRoZSBFQ1JJVA0KPj4+Pj4+
Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHNlc3Npb24gdGhhdCBSUEggc2hvdWxkIG5vdCBiZQ0K
Pj4+PnVzZWQgZm9yIHByaW9yaXR5DQo+Pj4+Pj4+Pj5tYXJraW5nDQo+Pj4+Pj4+Pj4gICAgICAg
ICA+ID4+ID4+IHJlcXVlc3RzLg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IFRoaXMg
aXMgc29tZXRoaW5nIEtlaXRoIChTSVAgV0cNCj4+Pj5jaGFpcikgdm9pY2VkIGhpcw0KPj4+Pj4+
Pj4+b3Bwb3NpdGlvbg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHRvIHlvdXIgdmll
d3MgcmVnYXJkaW5nIGNyZWF0aW5nIGEgc2Vjb25kDQo+Pj4+Pj4+bWVhbnMgZm9yIFNJUA0KPj4+
Pj4+Pj4+dG8NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPnByaW9yaXR5DQo+Pj4+Pj4+Pj4gICAg
ICAgICA+ID4+ID4+ID4gPj4gbWFyayByZXF1ZXN0ICJ3aGVuIFNJUCBhbHJlYWR5IGhhcyBvbmUN
Cj4+Pj4+Pj5pbnRlcm9wZXJhYmxlDQo+Pj4+Pj4+Pj53YXkgdG8NCj4+Pj4+Pj4+PiAgICAgICAg
ID4gPj4gPj4gPiA+PiBhY2NvbXBsaXNoIHRoaXMuLi4gaXQncyBjYWxsIHRoZSANCj5SUCBoZWFk
ZXINCj4+Pj4+Pj5tZWNoYW5pc20iLg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+DQo+
Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gPkkgZG9uJ3Qgc2VlIGFkdmFudGFnZXMgLS0g
b25seQ0KPj4+PmRpc2FkdmFudGFnZXMuDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4g
Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID5DaWFvDQo+Pj4+Pj4+Pj4gICAgICAg
ICA+ID4+ID4+ID4gPj4gPkhhbm5lcw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+DQo+
Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4NCj4+Pj5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+
IEVjcml0IG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IEVjcml0
QGlldGYub3JnDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gDQo+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+
PiA+ID4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4g
Pj4gDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+
Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4gICAg
ICAgICA+ID4+ID4+IEVjcml0QGlldGYub3JnDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+Pj4+Pj4+PiAgICAg
ICAgID4gPj4gPj4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPg0KPj4+Pj4+Pj4+ICAgICAgICAg
PiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+Pj4gICAgICAgICA+
IEVjcml0IG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+ICAgICAgICAgPiBFY3JpdEBpZXRmLm9yZw0K
Pj4+Pj4+Pj4+ICAgICAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2Vjcml0DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj5fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+RWNyaXQg
bWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj5FY3JpdEBpZXRmLm9yZw0KPj4+Pj4+Pj4+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+RWNy
aXQgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PkVjcml0QGlldGYub3JnDQo+Pj4+Pj4+Pmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+Pj4+Pg0KPj4+Pj4+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PkVjcml0IG1h
aWxpbmcgbGlzdA0KPj4+Pj4+RWNyaXRAaWV0Zi5vcmcNCj4+Pj4+Pmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+Pg0KPj4+X19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PkVjcml0IG1haWxpbmcgbGlzdA0KPj4+RWNy
aXRAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNy
aXQNCj4+Pg0KPj4+DQo+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCj4+PlRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkg
YW5kIG1heQ0KPj4+Y29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNl
IHByaXZhdGUgaW5mb3JtYXRpb24uDQo+Pj5JZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJv
ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+Pj5pbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRo
ZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQo+Pj50aGlzIGVtYWlsIGlzIHBy
b2hpYml0ZWQuDQo+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
Cj4+PlttZjJdDQo+Pj4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+PkVjcml0IG1haWxpbmcgbGlzdA0KPj5FY3JpdEBpZXRmLm9yZw0KPj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+DQo+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5FY3JpdCBtYWlsaW5nIGxp
c3QNCj5FY3JpdEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vZWNyaXQNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPkVjcml0IG1haWxpbmcgbGlzdA0KPkVjcml0QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPg0KDQo=


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D843A6C10 for <[e-mail]>; Fri,  6 Feb 2009 16:15:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.844
X-Spam-Level: 
X-Spam-Status: No, score=-5.844 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2FHCG9pXLJZ for <[e-mail]>; Fri,  6 Feb 2009 16:15:14 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id D48EA3A6BFF for <[e-mail]>; Fri,  6 Feb 2009 16:15:12 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n170Em9T028032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 7 Feb 2009 01:14:48 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 7 Feb 2009 01:14:48 +0100
From: "DRAGE, Keith (Keith)" <[e-mail]>
To: "Winterbottom, James" <[e-mail]>, Hannes Tschofenig <[e-mail]>, Brian Rosen <[e-mail]>, Henning Schulzrinne <[e-mail]>
Date: Sat, 7 Feb 2009 01:14:48 +0100
Thread-Topic: [Ecrit] RPH
Thread-Index: AcmIcEMWynRMTvqBQWy4A3ghfLDfOQAALFXwAAXxMbAAAz+/JgAIprow
Message-ID: <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]> <001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 00:15:17 -0000

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: [e-mail] [mailto:[e-mail]]
> 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: [e-mail] 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:[e-mail]]
> >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:[e-mail]]
> >> 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: [e-mail] [mailto:[e-mail]]
> >> >> 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-
> >> >>> [e-mail]
> >> >>> 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: [e-mail]
> [mailto:[e-mail]] On
> >> >>>> Behalf Of Hannes Tschofenig
> >> >>>> Sent: 06 February, 2009 15:07
> >> >>>> To: 'Janet P Gunn'
> >> >>>> Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
> >> >>>>       Sent: 06 February, 2009 14:11
> >> >>>>       To: Hannes Tschofenig
> >> >>>>       Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >> >>>> [e-mail]; 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.
> >> >>>>
> >> >>>>       [e-mail] 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:[e-mail]]
> >> >>>>       > >> >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: [e-mail]
> >> >> [mailto:[e-mail]]
> >> >>>>       > >> >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:[e-mail]]
> >> >>>>       > >> >> > 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:[e-mail]]
> >> >>>>       > >> >> > >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: [e-mail]
> >> >>>> [mailto:[e-mail]]
> >> >>>>       > >> >> > >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
> >> >>>>       > >> >> > >> [e-mail]
> >> >>>>       > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>       > >> >> > >
> >> >>>>       > >> >>
> >> >>>>       > >> >> _______________________________________________
> >> >>>>       > >> >> Ecrit mailing list
> >> >>>>       > >> >> [e-mail]
> >> >>>>       > >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>       > >> >>
> >> >>>>       > >> >
> >> >>>>       > >
> >> >>>>       >
> >> >>>>       > _______________________________________________
> >> >>>>       > Ecrit mailing list
> >> >>>>       > [e-mail]
> >> >>>>       > https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> Ecrit mailing list
> >> >>>> [e-mail]
> >> >>>> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> Ecrit mailing list
> >> >>> [e-mail]
> >> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>
> >> >
> >> > _______________________________________________
> >> > Ecrit mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/ecrit
> >> >
> >
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068313A6B70 for <[e-mail]>; Fri,  6 Feb 2009 16:21:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.137
X-Spam-Level: 
X-Spam-Status: No, score=-6.137 tagged_above=-999 required=5 tests=[AWL=0.112,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2whzSct2cxje for <[e-mail]>; Fri,  6 Feb 2009 16:21:55 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id D4F413A6856 for <[e-mail]>; Fri,  6 Feb 2009 16:21:54 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n170LfM7029067 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 7 Feb 2009 01:21:41 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sat, 7 Feb 2009 01:21:41 +0100
From: "DRAGE, Keith (Keith)" <[e-mail]>
To: Henning Schulzrinne <[e-mail]>, "James M. Polk" <[e-mail]>
Date: Sat, 7 Feb 2009 01:21:40 +0100
Thread-Topic: [Ecrit] RPH
Thread-Index: AcmIqmZ/facwrgsDSaOG521IP+Vb0gADyoqA
Message-ID: <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]> <[e-mail]> <001d01c9885b$d5d705d0$[e-mail]> <001f01c98860$910658c0$[e-mail]> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$[e-mail]> <[e-mail]> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Cc: ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 00:21:56 -0000

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: [e-mail] [mailto:[e-mail]]=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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
> =


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475FC3A6856 for <[e-mail]>; Fri,  6 Feb 2009 16:26:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.841
X-Spam-Level: 
X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2ZPtpnfHeAt for <[e-mail]>; Fri,  6 Feb 2009 16:26:48 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 7C5A33A6B70 for <[e-mail]>; Fri,  6 Feb 2009 16:26:47 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n170Q5fM029633 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 7 Feb 2009 01:26:05 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sat, 7 Feb 2009 01:26:05 +0100
From: "DRAGE, Keith (Keith)" <[e-mail]>
To: Hannes Tschofenig <[e-mail]>, "'DOLLY, MARTIN C, ATTLABS'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Sat, 7 Feb 2009 01:26:02 +0100
Thread-Topic: [Ecrit] RPH
Thread-Index: AcmIp7cDTjOFrFzQSeSaJoip38DOVgAAJrguAAEikiAAA19QMA==
Message-ID: <[e-mail]>
References: <[e-mail]> <000101c988ad$8ac92e90$[e-mail]>
In-Reply-To: <000101c988ad$8ac92e90$[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 00:26:51 -0000

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: [e-mail] [mailto:[e-mail]]
> On Behalf Of Hannes Tschofenig
> Sent: Friday, February 06, 2009 10:52 PM
> To: 'DOLLY, MARTIN C, ATTLABS'; [e-mail];
> [e-mail]; [e-mail]
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> On Behalf
> >Of DOLLY, MARTIN C, ATTLABS
> >Sent: 07 February, 2009 00:15
> >To: [e-mail]; [e-mail];
> >[e-mail]
> >Cc: [e-mail]; [e-mail]
> >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: [e-mail] <[e-mail]>
> >To: Henning Schulzrinne <[e-mail]>; Winterbottom, James
> ><[e-mail]>
> >Cc: Tschofenig, Hannes (NSN - FI/Espoo) <[e-mail]>;
> >ECRIT <[e-mail]>
> >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: [e-mail] 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:[e-mail]]
> >>>>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:[e-mail]]
> >>>>>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: [e-mail] [mailto:[e-mail]]
> >>>>>>>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-
> >>>>>>>>[e-mail]
> >>>>>>>>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: [e-mail]
> [mailto:[e-mail]] On
> >>>>>>>>>Behalf Of Hannes Tschofenig
> >>>>>>>>>Sent: 06 February, 2009 15:07
> >>>>>>>>>To: 'Janet P Gunn'
> >>>>>>>>>Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
> >>>>>>>>>         Sent: 06 February, 2009 14:11
> >>>>>>>>>         To: Hannes Tschofenig
> >>>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >>>>>>>>>[e-mail]; 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.
> >>>>>>>>>
> >>>>>>>>>         [e-mail] 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:[e-mail]]
> >>>>>>>>>         > >> >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: [e-mail]
> >>>>>>>[mailto:[e-mail]]
> >>>>>>>>>         > >> >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:[e-mail]]
> >>>>>>>>>         > >> >> > 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:[e-mail]]
> >>>>>>>>>         > >> >> > >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: [e-mail]
> >>>>>>>>>[mailto:[e-mail]]
> >>>>>>>>>         > >> >> > >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
> >>>>>>>>>         > >> >> > >> [e-mail]
> >>>>>>>>>         > >> >> > >>
> >https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>>         > >> >> > >
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >>
> >_______________________________________________
> >>>>>>>>>         > >> >> Ecrit mailing list
> >>>>>>>>>         > >> >> [e-mail]
> >>>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>>         > >> >>
> >>>>>>>>>         > >> >
> >>>>>>>>>         > >
> >>>>>>>>>         >
> >>>>>>>>>         > _______________________________________________
> >>>>>>>>>         > Ecrit mailing list
> >>>>>>>>>         > [e-mail]
> >>>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>_______________________________________________
> >>>>>>>>>Ecrit mailing list
> >>>>>>>>>[e-mail]
> >>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>>>
> >>>>>>>>_______________________________________________
> >>>>>>>>Ecrit mailing list
> >>>>>>>>[e-mail]
> >>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>>>>
> >>>>>>_______________________________________________
> >>>>>>Ecrit mailing list
> >>>>>>[e-mail]
> >>>>>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>
> >>>_______________________________________________
> >>>Ecrit mailing list
> >>>[e-mail]
> >>>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
> >>[e-mail]
> >>https://www.ietf.org/mailman/listinfo/ecrit
> >
> >_______________________________________________
> >Ecrit mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ecrit
> >_______________________________________________
> >Ecrit mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ecrit
> >
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325AB28C105 for <[e-mail]>; Fri,  6 Feb 2009 16:48:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.985
X-Spam-Level: 
X-Spam-Status: No, score=-4.985 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_EMRG=2.3,  RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZeTZclUMIuN for <[e-mail]>; Fri,  6 Feb 2009 16:48:35 -0800 (PST)
Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id B37BF28C104 for <[e-mail]>; Fri,  6 Feb 2009 16:48:34 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n170m3QS028283 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 7 Feb 2009 01:48:03 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 7 Feb 2009 01:48:03 +0100
From: "DRAGE, Keith (Keith)" <[e-mail]>
To: Hannes Tschofenig <[e-mail]>, "'James M. Polk'" <[e-mail]>
Date: Sat, 7 Feb 2009 01:47:57 +0100
Thread-Topic: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
Thread-Index: AcmIppJ3db5pt/4hRciq0u3Zrgn8DQABfvUgAAQ5v+A=
Message-ID: <[e-mail]>
References: <[e-mail]> <000801c98708$5973f6f0$[e-mail]> <[e-mail]> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$[e-mail]> <0a1101c98716$91287db0$b3797910$@net> <[e-mail]> <009701c987c4$c3cb7340$[e-mail]> <[e-mail]> <000701c9883c$59b095d0$[e-mail]> <[e-mail]> <000001c988ac$d0261940$[e-mail]>
In-Reply-To: <000001c988ac$d0261940$[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 00:48:37 -0000

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:[e-mail]]
> 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:[e-mail]]
> >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:[e-mail]]
> >> >> >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: [e-mail] [mailto:[e-mail]]
> >> >> >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:[e-mail]]
> >> >> >> > 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:[e-mail]]
> >> >> >> > >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: [e-mail]
> >> >> >> > >> [mailto:[e-mail]]
> >> >> >> > >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
> >> >> >> > >> [e-mail]
> >> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >> > >
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> Ecrit mailing list
> >> >> >> [e-mail]
> >> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >>
> >> >> >
> >> >
> >
>
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9419E3A6BD0 for <[e-mail]>; Sat,  7 Feb 2009 00:12:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.05
X-Spam-Level: 
X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=-0.051,  BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46nz3YCEhUex for <[e-mail]>; Sat,  7 Feb 2009 00:12:11 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CA9C73A688C for <[e-mail]>; Sat,  7 Feb 2009 00:12:10 -0800 (PST)
Received: (qmail invoked by alias); 07 Feb 2009 08:11:54 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp008) with SMTP; 07 Feb 2009 09:11:54 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+0Aj4pMV60wgRF8shAD6mXoLv7OjpYk9Tp1R8HXq CXXnzdm8xcjbpD
From: "Hannes Tschofenig" <[e-mail]>
To: "'DOLLY, MARTIN C, ATTLABS'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Date: Sat, 7 Feb 2009 10:12:40 +0200
Message-ID: <007101c988fb$e2fc3c80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: AcmIp7cDTjOFrFzQSeSaJoip38DOVgAAJrguAAEikiAAAc6YOQAR4E/g
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.47
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 08:12:14 -0000

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:[e-mail]] 
>Sent: 07 February, 2009 01:39
>To: [e-mail]; [e-mail]; 
>[e-mail]; [e-mail]
>Cc: [e-mail]; [e-mail]
>Subject: Re: [Ecrit] RPH
>
>Wrong, everything is based on security policies
>
>----- Original Message -----
>From: Hannes Tschofenig <[e-mail]>
>To: DOLLY, MARTIN C, ATTLABS; [e-mail] 
><[e-mail]>; [e-mail] <[e-mail]>; 
>[e-mail] <[e-mail]>
>Cc: Tschofenig, Hannes (NSN - FI/Espoo) 
><[e-mail]>; [e-mail] <[e-mail]>
>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: [e-mail] [mailto:[e-mail]] 
>On Behalf 
>>Of DOLLY, MARTIN C, ATTLABS
>>Sent: 07 February, 2009 00:15
>>To: [e-mail]; [e-mail]; 
>>[e-mail]
>>Cc: [e-mail]; [e-mail]
>>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: [e-mail] <[e-mail]>
>>To: Henning Schulzrinne <[e-mail]>; Winterbottom, James 
>><[e-mail]>
>>Cc: Tschofenig, Hannes (NSN - FI/Espoo) <[e-mail]>; 
>>ECRIT <[e-mail]>
>>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: [e-mail] 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:[e-mail]]
>>>>>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:[e-mail]]
>>>>>>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: [e-mail] [mailto:[e-mail]]
>>>>>>>>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- 
>>>>>>>>>[e-mail]
>>>>>>>>>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: [e-mail] 
>[mailto:[e-mail]] On 
>>>>>>>>>>Behalf Of Hannes Tschofenig
>>>>>>>>>>Sent: 06 February, 2009 15:07
>>>>>>>>>>To: 'Janet P Gunn'
>>>>>>>>>>Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
>>>>>>>>>>         Sent: 06 February, 2009 14:11
>>>>>>>>>>         To: Hannes Tschofenig
>>>>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; 
>>>>>>>>>>[e-mail]; 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.
>>>>>>>>>>
>>>>>>>>>>         [e-mail] 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:[e-mail]]
>>>>>>>>>>         > >> >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: [e-mail]
>>>>>>>>[mailto:[e-mail]]
>>>>>>>>>>         > >> >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:[e-mail]]
>>>>>>>>>>         > >> >> > 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:[e-mail]]
>>>>>>>>>>         > >> >> > >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: [e-mail] 
>>>>>>>>>>[mailto:[e-mail]]
>>>>>>>>>>         > >> >> > >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
>>>>>>>>>>         > >> >> > >> [e-mail]
>>>>>>>>>>         > >> >> > >>
>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>         > >> >> > >
>>>>>>>>>>         > >> >>
>>>>>>>>>>         > >> >>
>>_______________________________________________
>>>>>>>>>>         > >> >> Ecrit mailing list
>>>>>>>>>>         > >> >> [e-mail]
>>>>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>         > >> >>
>>>>>>>>>>         > >> >
>>>>>>>>>>         > >
>>>>>>>>>>         >
>>>>>>>>>>         > _______________________________________________
>>>>>>>>>>         > Ecrit mailing list
>>>>>>>>>>         > [e-mail]
>>>>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>_______________________________________________
>>>>>>>>>>Ecrit mailing list
>>>>>>>>>>[e-mail]
>>>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>
>>>>>>>>>_______________________________________________
>>>>>>>>>Ecrit mailing list
>>>>>>>>>[e-mail]
>>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>Ecrit mailing list
>>>>>>>[e-mail]
>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>>_______________________________________________
>>>>Ecrit mailing list
>>>>[e-mail]
>>>>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
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/ecrit
>>
>>_______________________________________________
>>Ecrit mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ecrit
>>_______________________________________________
>>Ecrit mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ecrit
>>
>
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A913A6CA6 for <[e-mail]>; Sat,  7 Feb 2009 00:14:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level: 
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Man7wY7kYfW1 for <[e-mail]>; Sat,  7 Feb 2009 00:14:08 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0BEA63A67B1 for <[e-mail]>; Sat,  7 Feb 2009 00:14:07 -0800 (PST)
Received: (qmail invoked by alias); 07 Feb 2009 08:14:10 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp069) with SMTP; 07 Feb 2009 09:14:10 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+Aidc+WZ6ABXkf8M7elJcm53835OTD2CEA/9W7Yu msLn3vkoQrRDAg
From: "Hannes Tschofenig" <[e-mail]>
To: "'DRAGE, Keith \(Keith\)'" <[e-mail]>, "'Henning Schulzrinne'" <[e-mail]>, "'James M. Polk'" <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]><001d01c9885b$d5d705d0$[e-mail]><001f01c98860$910658c0$[e-mail]><0d6901c9886b$6c9bfc50$45d3f4f0$@net><003001c9886e$7d133280$[e-mail]><[e-mail]><0d9101c98872$7b2129b0$71637d10$@net><003d01c98889$666c23f0$[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
Date: Sat, 7 Feb 2009 10:14:57 +0200
Message-ID: <007201c988fc$2aab5f20$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: AcmIqmZ/facwrgsDSaOG521IP+Vb0gADyoqAABCWV2A=
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.53
Cc: 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 08:14:09 -0000

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: [e-mail] [mailto:[e-mail]] 
>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: [e-mail] [mailto:[e-mail]] 
>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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F9428C0D8 for <[e-mail]>; Sat,  7 Feb 2009 00:22:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.051
X-Spam-Level: 
X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3jN1xfERPVk for <[e-mail]>; Sat,  7 Feb 2009 00:22:11 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1B2843A6A5C for <[e-mail]>; Sat,  7 Feb 2009 00:22:09 -0800 (PST)
Received: (qmail invoked by alias); 07 Feb 2009 08:22:11 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp027) with SMTP; 07 Feb 2009 09:22:11 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/AmWUYbi7AccD12KI3ad4BzQo0hmFVZgOqourAZ8 Ij7yL3X9HClt4A
From: "Hannes Tschofenig" <[e-mail]>
To: "'DRAGE, Keith \(Keith\)'" <[e-mail]>, "'DOLLY, MARTIN C, ATTLABS'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]> <000101c988ad$8ac92e90$[e-mail]> <[e-mail]>
Date: Sat, 7 Feb 2009 10:22:58 +0200
Message-ID: <007301c988fd$497f6940$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: AcmIp7cDTjOFrFzQSeSaJoip38DOVgAAJrguAAEikiAAA19QMAAQefrQ
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.48
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 08:22:14 -0000

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: [e-mail] [mailto:[e-mail]] 
>On Behalf 
>> Of Hannes Tschofenig
>> Sent: Friday, February 06, 2009 10:52 PM
>> To: 'DOLLY, MARTIN C, ATTLABS'; [e-mail]; 
>[e-mail]; 
>> [e-mail]
>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); [e-mail]
>> 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: [e-mail] [mailto:[e-mail]]
>> On Behalf
>> >Of DOLLY, MARTIN C, ATTLABS
>> >Sent: 07 February, 2009 00:15
>> >To: [e-mail]; [e-mail]; 
>> >[e-mail]
>> >Cc: [e-mail]; [e-mail]
>> >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: [e-mail] <[e-mail]>
>> >To: Henning Schulzrinne <[e-mail]>; Winterbottom, James 
>> ><[e-mail]>
>> >Cc: Tschofenig, Hannes (NSN - FI/Espoo) 
><[e-mail]>; 
>> >ECRIT <[e-mail]>
>> >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: [e-mail] 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:[e-mail]]
>> >>>>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:[e-mail]]
>> >>>>>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: [e-mail] [mailto:[e-mail]]
>> >>>>>>>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- 
>> >>>>>>>>[e-mail]
>> >>>>>>>>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: [e-mail]
>> [mailto:[e-mail]] On
>> >>>>>>>>>Behalf Of Hannes Tschofenig
>> >>>>>>>>>Sent: 06 February, 2009 15:07
>> >>>>>>>>>To: 'Janet P Gunn'
>> >>>>>>>>>Cc: 'ECRIT'; [e-mail]; 
>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:[e-mail]]
>> >>>>>>>>>         Sent: 06 February, 2009 14:11
>> >>>>>>>>>         To: Hannes Tschofenig
>> >>>>>>>>>         Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 
>'ECRIT'; 
>> >>>>>>>>>[e-mail]; 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.
>> >>>>>>>>>
>> >>>>>>>>>         [e-mail] 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:[e-mail]]
>> >>>>>>>>>         > >> >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: [e-mail]
>> >>>>>>>[mailto:[e-mail]]
>> >>>>>>>>>         > >> >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:[e-mail]]
>> >>>>>>>>>         > >> >> > 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:[e-mail]]
>> >>>>>>>>>         > >> >> > >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: [e-mail] 
>> >>>>>>>>>[mailto:[e-mail]]
>> >>>>>>>>>         > >> >> > >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
>> >>>>>>>>>         > >> >> > >> [e-mail]
>> >>>>>>>>>         > >> >> > >>
>> >https://www.ietf.org/mailman/listinfo/ecrit
>> >>>>>>>>>         > >> >> > >
>> >>>>>>>>>         > >> >>
>> >>>>>>>>>         > >> >>
>> >_______________________________________________
>> >>>>>>>>>         > >> >> Ecrit mailing list
>> >>>>>>>>>         > >> >> [e-mail]
>> >>>>>>>>>         > >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >>>>>>>>>         > >> >>
>> >>>>>>>>>         > >> >
>> >>>>>>>>>         > >
>> >>>>>>>>>         >
>> >>>>>>>>>         > _______________________________________________
>> >>>>>>>>>         > Ecrit mailing list
>> >>>>>>>>>         > [e-mail]
>> >>>>>>>>>         > https://www.ietf.org/mailman/listinfo/ecrit
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>_______________________________________________
>> >>>>>>>>>Ecrit mailing list
>> >>>>>>>>>[e-mail]
>> >>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>> >>>>>>>>
>> >>>>>>>>_______________________________________________
>> >>>>>>>>Ecrit mailing list
>> >>>>>>>>[e-mail]
>> >>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>> >>>>>>
>> >>>>>>_______________________________________________
>> >>>>>>Ecrit mailing list
>> >>>>>>[e-mail]
>> >>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>> >>>
>> >>>_______________________________________________
>> >>>Ecrit mailing list
>> >>>[e-mail]
>> >>>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
>> >>[e-mail]
>> >>https://www.ietf.org/mailman/listinfo/ecrit
>> >
>> >_______________________________________________
>> >Ecrit mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/ecrit
>> >_______________________________________________
>> >Ecrit mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/ecrit
>> >
>>
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B831E3A67B1 for <[e-mail]>; Sat,  7 Feb 2009 00:27:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.051
X-Spam-Level: 
X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQdmjZuhJHBc for <[e-mail]>; Sat,  7 Feb 2009 00:27:54 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0C4283A679F for <[e-mail]>; Sat,  7 Feb 2009 00:27:52 -0800 (PST)
Received: (qmail invoked by alias); 07 Feb 2009 08:27:54 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp062) with SMTP; 07 Feb 2009 09:27:54 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX184DqUj8QQ4mk4KWBlv7Yn4SAks1DbX1826kP0bFO p55TGm3nIrijL3
From: "Hannes Tschofenig" <[e-mail]>
To: "'DRAGE, Keith \(Keith\)'" <[e-mail]>, "'Winterbottom, James'" <[e-mail]>, "'Brian Rosen'" <[e-mail]>, "'Henning Schulzrinne'" <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]><001d01c9885b$d5d705d0$[e-mail]><001f01c98860$910658c0$[e-mail]><0d6901c9886b$6c9bfc50$45d3f4f0$@net><003001c9886e$7d133280$[e-mail]><[e-mail]><0d9101c98872$7b2129b0$71637d10$@net><003d01c98889$666c23f0$[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 7 Feb 2009 10:28:40 +0200
Message-ID: <007401c988fe$15e06cf0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: AcmIcEMWynRMTvqBQWy4A3ghfLDfOQAALFXwAAXxMbAAAz+/JgAIprowABE/KKA=
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.5
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 08:27:56 -0000

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:[e-mail]] 
>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: [e-mail] [mailto:[e-mail]] 
>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: [e-mail] 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:[e-mail]]
>> >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:[e-mail]]
>> >> 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: [e-mail] [mailto:[e-mail]]
>> >> >> 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- 
>> >> >>> [e-mail]
>> >> >>> 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: [e-mail]
>> [mailto:[e-mail]] On
>> >> >>>> Behalf Of Hannes Tschofenig
>> >> >>>> Sent: 06 February, 2009 15:07
>> >> >>>> To: 'Janet P Gunn'
>> >> >>>> Cc: 'ECRIT'; [e-mail]; 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:[e-mail]]
>> >> >>>>       Sent: 06 February, 2009 14:11
>> >> >>>>       To: Hannes Tschofenig
>> >> >>>>       Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; 
>> >> >>>> [e-mail]; 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.
>> >> >>>>
>> >> >>>>       [e-mail] 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:[e-mail]]
>> >> >>>>       > >> >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: [e-mail]
>> >> >> [mailto:[e-mail]]
>> >> >>>>       > >> >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:[e-mail]]
>> >> >>>>       > >> >> > 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:[e-mail]]
>> >> >>>>       > >> >> > >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: [e-mail] 
>> >> >>>> [mailto:[e-mail]]
>> >> >>>>       > >> >> > >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
>> >> >>>>       > >> >> > >> [e-mail]
>> >> >>>>       > >> >> > >> 
>https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>>>       > >> >> > >
>> >> >>>>       > >> >>
>> >> >>>>       > >> >> _______________________________________________
>> >> >>>>       > >> >> Ecrit mailing list
>> >> >>>>       > >> >> [e-mail]
>> >> >>>>       > >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>>>       > >> >>
>> >> >>>>       > >> >
>> >> >>>>       > >
>> >> >>>>       >
>> >> >>>>       > _______________________________________________
>> >> >>>>       > Ecrit mailing list
>> >> >>>>       > [e-mail]
>> >> >>>>       > https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> _______________________________________________
>> >> >>>> Ecrit mailing list
>> >> >>>> [e-mail]
>> >> >>>> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>>>
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> Ecrit mailing list
>> >> >>> [e-mail]
>> >> >>> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>
>> >> >
>> >> > _______________________________________________
>> >> > Ecrit mailing list
>> >> > [e-mail]
>> >> > https://www.ietf.org/mailman/listinfo/ecrit
>> >> >
>> >
>>
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05AB83A6CA6 for <[e-mail]>; Sat,  7 Feb 2009 00:31:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.201
X-Spam-Level: 
X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, MANGLED_EMRG=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zLDKCxVMlG3 for <[e-mail]>; Sat,  7 Feb 2009 00:31:43 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6AC9B3A6A5C for <[e-mail]>; Sat,  7 Feb 2009 00:31:41 -0800 (PST)
Received: (qmail invoked by alias); 07 Feb 2009 08:31:44 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp048) with SMTP; 07 Feb 2009 09:31:44 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18va00mj48vC5udUcvOFTFbZZhxc6wlb9rgqT5rDA bz5rc6OQDY2vNc
From: "Hannes Tschofenig" <[e-mail]>
To: "'DRAGE, Keith \(Keith\)'" <[e-mail]>, "'James M. Polk'" <[e-mail]>
References: <[e-mail]> <000801c98708$5973f6f0$[e-mail]> <[e-mail]> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$[e-mail]> <0a1101c98716$91287db0$b3797910$@net> <[e-mail]> <009701c987c4$c3cb7340$[e-mail]> <[e-mail]> <000701c9883c$59b095d0$[e-mail]> <[e-mail]> <000001c988ac$d0261940$[e-mail]> <[e-mail]>
Date: Sat, 7 Feb 2009 10:32:30 +0200
Message-ID: <007501c988fe$9ec32670$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: AcmIppJ3db5pt/4hRciq0u3Zrgn8DQABfvUgAAQ5v+AAEDNLUA==
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.53
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 08:31:45 -0000

>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:[e-mail]]
>> 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:[e-mail]]
>> >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:[e-mail]]
>> >> >> >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: [e-mail] [mailto:[e-mail]]
>> >> >> >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:[e-mail]]
>> >> >> >> > 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:[e-mail]]
>> >> >> >> > >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: [e-mail] 
>> >> >> >> > >> [mailto:[e-mail]]
>> >> >> >> > >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
>> >> >> >> > >> [e-mail]
>> >> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >> > >
>> >> >> >>
>> >> >> >> _______________________________________________
>> >> >> >> Ecrit mailing list
>> >> >> >> [e-mail]
>> >> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >>
>> >> >> >
>> >> >
>> >
>>
>>
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F110F3A692F; Sat,  7 Feb 2009 08:27:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.023
X-Spam-Level: 
X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.575,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3iyruZ+u2Fr; Sat,  7 Feb 2009 08:27:50 -0800 (PST)
Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id 482363A6C7A; Sat,  7 Feb 2009 08:27:12 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-4.tower-164.messagelabs.com!1234024034!16144134!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 32625 invoked from network); 7 Feb 2009 16:27:14 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-4.tower-164.messagelabs.com with AES256-SHA encrypted SMTP; 7 Feb 2009 16:27:14 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n17GRDCw023268; Sat, 7 Feb 2009 11:27:14 -0500
In-Reply-To: <007201c988fc$2aab5f20$[e-mail]>
To: "Hannes Tschofenig" <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn <[e-mail]>
Message-ID: <[e-mail]>
Date: Sat, 7 Feb 2009 11:27:14 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/07/2009 11:29:35 AM, Serialize complete at 02/07/2009 11:29:35 AM
Content-Type: multipart/alternative; boundary="=_alternative 005A5FB785257556_="
Cc: 'ECRIT' <[e-mail]>, [e-mail]
Subject: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 16:27:52 -0000

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

.

[e-mail] 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>[e-mail] 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_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1183A6CA4; Sat,  7 Feb 2009 08:56:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level: 
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3pMxERrOMuQ; Sat,  7 Feb 2009 08:56:41 -0800 (PST)
Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 7B4D93A6CB0; Sat,  7 Feb 2009 08:56:41 -0800 (PST)
Received: from Upstairs.home (pool-98-109-204-63.nwrknj.fios.verizon.net [98.109.204.63]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n17GugMc014391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 7 Feb 2009 11:56:43 -0500 (EST)
Message-Id: <[e-mail]>
From: Henning Schulzrinne <[e-mail]>
To: Janet P Gunn <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Sat, 7 Feb 2009 11:56:42 -0500
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6
Cc: ECRIT <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 16:56:42 -0000

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:

>
>
> .
>
> [e-mail] 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6CC3A6CD2; Sat,  7 Feb 2009 09:17:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.087
X-Spam-Level: 
X-Spam-Status: No, score=-6.087 tagged_above=-999 required=5 tests=[AWL=0.511,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxLMqo-AYZxJ; Sat,  7 Feb 2009 09:17:13 -0800 (PST)
Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id 8E4F03A6CCD; Sat,  7 Feb 2009 09:17:13 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-6.tower-164.messagelabs.com!1234027035!8941662!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 13943 invoked from network); 7 Feb 2009 17:17:15 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-6.tower-164.messagelabs.com with AES256-SHA encrypted SMTP; 7 Feb 2009 17:17:15 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n17HH7iR031145; Sat, 7 Feb 2009 12:17:14 -0500
In-Reply-To: <[e-mail]>
To: Henning Schulzrinne <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn <[e-mail]>
Message-ID: <[e-mail]>
Date: Sat, 7 Feb 2009 12:17:12 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/07/2009 12:19:36 PM, Serialize complete at 02/07/2009 12:19:36 PM
Content-Type: multipart/alternative; boundary="=_alternative 005EF2FA85257556_="
Cc: ECRIT <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 17:17:15 -0000

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 <[e-mail]> 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:
> 
> >
> >
> > .
> >
> > [e-mail] 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;[e-mail]&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; [e-mail] 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_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6114F3A6CC7; Sat,  7 Feb 2009 09:29:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.449
X-Spam-Level: 
X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8JuWHSuNFka; Sat,  7 Feb 2009 09:29:38 -0800 (PST)
Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 2781D3A6CB6; Sat,  7 Feb 2009 09:29:38 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-5.tower-146.messagelabs.com!1234027781!12454975!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 21766 invoked from network); 7 Feb 2009 17:29:42 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-5.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 7 Feb 2009 17:29:42 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n17HTdMR013933; Sat, 7 Feb 2009 12:29:39 -0500
Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n17HTZkd013918; Sat, 7 Feb 2009 12:29:36 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Sat, 7 Feb 2009 12:29:35 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Semantics  Re:  RPH
Thread-Index: AcmJRRX7MtWq02JtRZaMQukWCeihVwABI88y
From: "DOLLY, MARTIN C, ATTLABS" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2009 17:29:39 -0000

RG8geW91IGhhdmUgYSBjbHVlIGR1ZGU/IEErQSBvZiBhbiB1c2VyIGNvbWVzIGluIG1hbnkgZm9y
bXMuDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IGVjcml0LWJvdW5jZXNA
aWV0Zi5vcmcgPGVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogSmFuZXQgUCBHdW5uIDxqZ3Vu
bjZAY3NjLmNvbT4NCkNjOiBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc+OyBlY3JpdC1ib3VuY2VzQGll
dGYub3JnIDxlY3JpdC1ib3VuY2VzQGlldGYub3JnPg0KU2VudDogU2F0IEZlYiAwNyAxMTo1Njo0
MiAyMDA5DQpTdWJqZWN0OiBSZTogW0Vjcml0XSBTZW1hbnRpY3MgIFJlOiAgUlBIDQoNClBsZWFz
ZSBzZWUgbXkgZWFybGllciBtZXNzYWdlIGFzIHRvIHdoeSB5b3VyIGFwcHJvYWNoIGZhaWxzIGZv
ciB0aGUgVUEtIA0KaW5zZXJ0ZWQgY2FzZSB3aGVyZSBub3QgYWxsIGVtZXJnZW5jeSBjYWxscyBo
YXZlIFJQSCBtYXJraW5ncy4gSSB0aGluayAgDQppdCB3b3VsZCBiZSBhIHJlYWxseSBiYWQgaWRl
YSBpZiBlbWVyZ2VuY3kgY2FsbHMgd2l0aCBSUEggYXJlIHRyZWF0ZWQgIA0KZGlmZmVyZW50bHkg
dGhhbiBlbWVyZ2VuY3kgY2FsbHMgd2l0aG91dCBpdC4gKEFnYWluLCBJJ20gdGFsa2luZyBhYm91
dCAgDQp0aGUgdXNlci1pbml0aWF0ZWQgY2FsbHMuIEFuIEVTTkVUIGNhbiBkbyB3aGF0ZXZlciBp
dCB3YW50cyBhbmQgY2FuICANCmFzc2lnbiBleHRyYSBwcmlvcml0eSB0byBjYWxscyBmcm9tIGNp
dGl6ZW5zIHRoYXQgaGF2ZSBib3VnaHQgUEJBICANCnN0aWNrZXJzIG9yIHppcCBjb2RlcyB0aGF0
IHBheSBtb3JlIHRheGVzLCBidXQgdGhhdCdzIGEgc2VwYXJhdGUgIA0KcHJvYmxlbS4pDQoNCkkg
YWxzbyBkb24ndCBiZWxpZXZlIHlvdXIgaW1wbGVtZW50YXRpb24gbG9naWMuIEEgbXVjaCBiZXR0
ZXIgYXBwcm9hY2ggIA0KaXMgdG8gc2VtYW50aWNhbGx5IGRlY2xhcmUgdGhlIGNsYXNzIG9mIGNh
bGwgZWFybHkgb24gKGUuZy4sIGJhc2VkIG9uICANCnRoZSBVUk4gb3IgYWZ0ZXIgYXV0aGVudGlj
YXRpb24vYXV0aG9yaXphdGlvbiksIGFuZCBtYWtlIHRoYXQgcGFydCBvZiAgDQp0aGUgY2FsbCBz
dGF0ZSByZWNvcmQsIHJhdGhlciB0aGFuIGh1bnQgZm9yIGhlYWRlcnMgZWFjaCB0aW1lIGEgIA0K
aGFuZGxpbmcgZGVjaXNpb24gbmVlZHMgdG8gYmUgbWFkZS4gR2l2ZW4gdGhlIGF1dGhvcml6YXRp
b24gIA0KcmVxdWlyZW1lbnRzLCBqdXN0IGxvb2tpbmcgYXQgImhhcyBoZWFkZXIgWCIgaXMgbmV2
ZXIgZ29pbmcgdG8gYmUgIA0Kc3VmZmljaWVudCBhbnl3YXkuDQoNCkhlbm5pbmcNCg0KT24gRmVi
IDcsIDIwMDksIGF0IDExOjI3IEFNLCBKYW5ldCBQIEd1bm4gd3JvdGU6DQoNCj4NCj4NCj4gLg0K
Pg0KPiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIHdyb3RlIG9uIDAyLzA3LzIwMDkgMDM6MTQ6NTcg
QU06DQo+DQo+ID4gUExFQVNFIHRyeSB0byB1bmRlcnN0YW5kIHRoYXQgdGhlIHN5bnRheCBpcyBz
aW1pbGFyIChoZWFkZXIsIG5ldyAgDQo+IG5hbWVzcGFjZSwNCj4gPiBuZXcgdmFsdWVzKQ0KPiA+
IEJVVCB0aGUgc2VtYW50aWMgaXMgZGlmZmVyZW50Lg0KPiA+DQo+ID4gRm9yIGFsbCBtZXNzYWdl
IGl0IGlzIHRydWUgdGhhdCB0aGUgc2VuZGVyIGNhbiBhZGQgd2hhdGV2ZXIgdGhleSAgDQo+IHdh
bnQuIFRoZQ0KPiA+IGJpZyBxdWVzdGlvbiBpcyB3aGF0IGRvZXMgaXQgbWVhbiBmb3IgdGhlIHJl
Y2lwaWVudC4NCj4gPg0KPiA+IFRoaXMgaXMgd2hhdCB0aGUgZGlzY3Vzc2lvbiBpcyBhYm91dC4N
Cj4gPg0KPiBPbiB0aGUgY29udHJhcnksIHRoZSBzZW1hbnRpYyBpcywgb3IgYXQgbGVhc3QgY2Fu
IGJlLCB2ZXJ5IHNpbWlsYXIuDQo+DQo+IENvbnNpZGVyIHRoZSBoeXBvdGhldGljYWwsIGJ1dCBw
bGF1c2libGUsIGNhc2Ugb2YgYSBuZXR3b3JrIHdpdGggYW4gIA0KPiBleHBsaWNpdCBjYWxsL2Nh
cGFjaXR5IGFkbWlzc2lvbiBwcm9jZXNzLCBpbiB3aGljaCBib3RoIDkxMS10eXBlLSANCj4gZW1l
cmdlbmN5IGNhbGxzIGFuZCBHRVRTIGNhbGxzIGdldCBwcmVmZXJlbnRpYWwgYWRtaXNzaW9uICAN
Cj4gdHJlYXRtZW50LiAgQnkgdGhlIHRpbWUgdGhlIElOVklURSBnZXRzIHRvIHRoaXMgRnVuY3Rp
b25hbCBNb2R1bGUvICANCj4gYmxvY2sgb2YgY29kZSwgYWxsIGF1dGhlbnRpY2F0aW9uLCBhdXRo
b3JpemF0aW9uLCBhbmQgY2hhbmdlcy8gDQo+IGNvbmZpcm1hdGlvbiBvZiB0aGUgZGVzdGluYXRp
b24gaGF2ZSBhbHJlYWR5IHRha2VuIHBsYWNlLiAgQWxsIHRoaXMgIA0KPiBibG9jayBvZiBjb2Rl
IGRlYWxzIHdpdGggaXMgY2FsbC9jYXBhY2l0eSBhZG1pc3Npb24uDQo+DQo+IEZvciB0aGUgc2Fr
ZSBvZiBhcmd1bWVudCwgc3VwcG9zZSB0aGlzIGlzIHRoZSBuYXR1cmUgb2YgdGhlICANCj4gcHJl
ZmVyZW5jZS4NCj4NCj4gMSkgRm9yIElOVklURXMgd2l0aG91dCBSUEgsIG9yIHdpdGggYW4gUlBI
IHRoaXMgbmV0d29yayBkb2VzIG5vdCB1c2UvIA0KPiB1bmRlcnN0YW5kLCBpZiB0aGUgYWRtaXNz
aW9uIHByb2Nlc3MgZmFpbHMsIHRoZSBJTlZJVEUgZmFpbHMNCj4NCj4gMikgRm9yIElOVklURXMg
d2l0aCBSUEggd2l0aCB0aGUgZXRzIG5hbWVzcGFjZSwgaWYgdGhlIGFkbWlzc2lvbiAgDQo+IHBy
b2Nlc3MgaW5pdGlhbGx5IGZhaWxzLCB0aGUgSU5WSVRFIGlzIHB1dCBpbiBxdWV1ZSB1bnRpbCB0
aGUgIA0KPiByZXNvdXJjZXMgYmVjb21lIGF2YWlsYWJsZSBzbyBpdCBjYW4gYmUgYWRtaXR0ZWQu
DQo+DQo+IDMpIEZvciBJTlZJVEVzIHdpdGggUlBIIHdpdGggdGhlIGVzbmV0IG5hbWVzcGFjZSwg
aWYgdGhlIGFkbWlzc2lvbiAgDQo+IHByb2Nlc3MgaW5pdGlhbGx5IGZhaWxzLCB0aGUgSU5WSVRF
IGlzIHB1dCBpbiBxdWV1ZSwgYnV0IGF0IGxvd2VyICANCj4gcHJpb3JpdHkgdGhhbiB0aGUgY2Fs
bHMgd2l0aCB0aGUgZXRzIG5hbWVzcGFjZS4NCj4NCj4gV2l0aCB0aGUgZXNuZXQgbmFtZXNwYWNl
LCB0aGlzIGJsb2NrIG9mIGNvZGUgb25seSBuZWVkcyB0byBkZWFsIHdpdGggIA0KPiB0aGUgUlBI
IGluIGRldGVybWluaW5nIHdoaWNoIElOVklURXMgdG8gcmVqZWN0LCBhbmQgd2hpY2ggdG8gcXVl
dWUsICANCj4gYW5kIGhvdy4NCj4NCj4gQnV0IGlmIHRoZXJlIGlzIG5vIGVzbmV0IG5hbWVzcGFj
ZSBmb3IgUlBILCB0aGVuIHRoaXMgYmxvY2sgb2YgY29kZSAgDQo+IHdvdWxkIG5lZWQgdG8gZGVh
bCB3aXRoIEJPVEggdGhlIFJQSCBhbmQgdGhlIFVSTi4gIFRoYXQgd291bGQgYmUgYSAgDQo+IGNv
bXBsZXRlbHkgdW5uZWNlc3NhcnkgY29tcGxpY2F0aW9uLg0KPg0KPiBKYW5ldA0KDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBs
aXN0DQpFY3JpdEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9lY3JpdA0K


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6498F3A67EC for <[e-mail]>; Sat,  7 Feb 2009 16:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.802
X-Spam-Level: 
X-Spam-Status: No, score=-5.802 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a-s+oFalSYe for <[e-mail]>; Sat,  7 Feb 2009 16:59:26 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 84DAF3A67FB for <[e-mail]>; Sat,  7 Feb 2009 16:59:24 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n180xAc7010230 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 8 Feb 2009 01:59:10 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sun, 8 Feb 2009 01:59:10 +0100
From: "DRAGE, Keith (Keith)" <[e-mail]>
To: Hannes Tschofenig <[e-mail]>, "'Winterbottom, James'" <[e-mail]>, "'Brian Rosen'" <[e-mail]>, "'Henning Schulzrinne'" <[e-mail]>
Date: Sun, 8 Feb 2009 01:59:10 +0100
Thread-Topic: [Ecrit] RPH
Thread-Index: AcmIcEMWynRMTvqBQWy4A3ghfLDfOQAALFXwAAXxMbAAAz+/JgAIprowABE/KKAAIrWZwA==
Message-ID: <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]><001d01c9885b$d5d705d0$[e-mail]><001f01c98860$910658c0$[e-mail]><0d6901c9886b$6c9bfc50$45d3f4f0$@net><003001c9886e$7d133280$[e-mail]><[e-mail]><0d9101c98872$7b2129b0$71637d10$@net><003d01c98889$666c23f0$[e-mail]> <[e-mail]> <[e-mail]> <007401c988fe$15e06cf0$[e-mail]>
In-Reply-To: <007401c988fe$15e06cf0$[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 00:59:29 -0000

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:[e-mail]]
> 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:[e-mail]]
> >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: [e-mail] [mailto:[e-mail]]
> >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: [e-mail] 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:[e-mail]]
> >> >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:[e-mail]]
> >> >> 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: [e-mail] [mailto:[e-mail]]
> >> >> >> 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-
> >> >> >>> [e-mail]
> >> >> >>> 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: [e-mail]
> >> [mailto:[e-mail]] On
> >> >> >>>> Behalf Of Hannes Tschofenig
> >> >> >>>> Sent: 06 February, 2009 15:07
> >> >> >>>> To: 'Janet P Gunn'
> >> >> >>>> Cc: 'ECRIT'; [e-mail];
> 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:[e-mail]]
> >> >> >>>>       Sent: 06 February, 2009 14:11
> >> >> >>>>       To: Hannes Tschofenig
> >> >> >>>>       Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';
> >> >> >>>> [e-mail]; 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.
> >> >> >>>>
> >> >> >>>>       [e-mail] 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:[e-mail]]
> >> >> >>>>       > >> >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: [e-mail]
> >> >> >> [mailto:[e-mail]]
> >> >> >>>>       > >> >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:[e-mail]]
> >> >> >>>>       > >> >> > 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:[e-mail]]
> >> >> >>>>       > >> >> > >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: [e-mail]
> >> >> >>>> [mailto:[e-mail]]
> >> >> >>>>       > >> >> > >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
> >> >> >>>>       > >> >> > >> [e-mail]
> >> >> >>>>       > >> >> > >>
> >https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >>>>       > >> >> > >
> >> >> >>>>       > >> >>
> >> >> >>>>       > >> >>
> _______________________________________________
> >> >> >>>>       > >> >> Ecrit mailing list
> >> >> >>>>       > >> >> [e-mail]
> >> >> >>>>       > >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >>>>       > >> >>
> >> >> >>>>       > >> >
> >> >> >>>>       > >
> >> >> >>>>       >
> >> >> >>>>       > _______________________________________________
> >> >> >>>>       > Ecrit mailing list
> >> >> >>>>       > [e-mail]
> >> >> >>>>       > https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> _______________________________________________
> >> >> >>>> Ecrit mailing list
> >> >> >>>> [e-mail]
> >> >> >>>> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >>>>
> >> >> >>>
> >> >> >>> _______________________________________________
> >> >> >>> Ecrit mailing list
> >> >> >>> [e-mail]
> >> >> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >>
> >> >> >
> >> >> > _______________________________________________
> >> >> > Ecrit mailing list
> >> >> > [e-mail]
> >> >> > https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >
> >> >
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> [e-mail]
> >> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >
>
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35D343A6870 for <[e-mail]>; Sun,  8 Feb 2009 01:23:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.043
X-Spam-Level: 
X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFQDjZ6CcK6P for <[e-mail]>; Sun,  8 Feb 2009 01:23:10 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6DECF3A6847 for <[e-mail]>; Sun,  8 Feb 2009 01:23:08 -0800 (PST)
Received: (qmail invoked by alias); 08 Feb 2009 09:23:10 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp008) with SMTP; 08 Feb 2009 10:23:10 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18wN+h09fwwuzBCzgI0BRq6hV40msqkjxgoJerY43 fe0BiH0S7+i5J9
From: "Hannes Tschofenig" <[e-mail]>
To: "'DRAGE, Keith \(Keith\)'" <[e-mail]>, "'Winterbottom, James'" <[e-mail]>, "'Brian Rosen'" <[e-mail]>, "'Henning Schulzrinne'" <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]><001d01c9885b$d5d705d0$[e-mail]><001f01c98860$910658c0$[e-mail]><0d6901c9886b$6c9bfc50$45d3f4f0$@net><003001c9886e$7d133280$[e-mail]><[e-mail]><0d9101c98872$7b2129b0$71637d10$@net><003d01c98889$666c23f0$[e-mail]> <[e-mail]> <[e-mail]> <007401c988fe$15e06cf0$[e-mail]> <[e-mail]>
Date: Sun, 8 Feb 2009 11:23:55 +0200
Message-ID: <004601c989ce$f932e3e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <[e-mail]>
Thread-Index: AcmIcEMWynRMTvqBQWy4A3ghfLDfOQAALFXwAAXxMbAAAz+/JgAIprowABE/KKAAIrWZwAARrSHw
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.48
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 09:23:13 -0000

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:[e-mail]] 
>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:[e-mail]]
>> 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:[e-mail]]
>> >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: [e-mail] [mailto:[e-mail]]
>> >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: [e-mail] 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:[e-mail]]
>> >> >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:[e-mail]]
>> >> >> 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: [e-mail] 
>[mailto:[e-mail]]
>> >> >> >> 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- 
>> >> >> >>> [e-mail]
>> >> >> >>> 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: [e-mail]
>> >> [mailto:[e-mail]] On
>> >> >> >>>> Behalf Of Hannes Tschofenig
>> >> >> >>>> Sent: 06 February, 2009 15:07
>> >> >> >>>> To: 'Janet P Gunn'
>> >> >> >>>> Cc: 'ECRIT'; [e-mail];
>> 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:[e-mail]]
>> >> >> >>>>       Sent: 06 February, 2009 14:11
>> >> >> >>>>       To: Hannes Tschofenig
>> >> >> >>>>       Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; 
>> >> >> >>>> [e-mail]; 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.
>> >> >> >>>>
>> >> >> >>>>       [e-mail] 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:[e-mail]]
>> >> >> >>>>       > >> >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: [e-mail]
>> >> >> >> [mailto:[e-mail]]
>> >> >> >>>>       > >> >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:[e-mail]]
>> >> >> >>>>       > >> >> > 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:[e-mail]]
>> >> >> >>>>       > >> >> > >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: [e-mail] 
>> >> >> >>>> [mailto:[e-mail]]
>> >> >> >>>>       > >> >> > >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
>> >> >> >>>>       > >> >> > >> [e-mail]
>> >> >> >>>>       > >> >> > >>
>> >https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >>>>       > >> >> > >
>> >> >> >>>>       > >> >>
>> >> >> >>>>       > >> >>
>> _______________________________________________
>> >> >> >>>>       > >> >> Ecrit mailing list
>> >> >> >>>>       > >> >> [e-mail]
>> >> >> >>>>       > >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >>>>       > >> >>
>> >> >> >>>>       > >> >
>> >> >> >>>>       > >
>> >> >> >>>>       >
>> >> >> >>>>       > _______________________________________________
>> >> >> >>>>       > Ecrit mailing list
>> >> >> >>>>       > [e-mail]
>> >> >> >>>>       > https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> _______________________________________________
>> >> >> >>>> Ecrit mailing list
>> >> >> >>>> [e-mail]
>> >> >> >>>> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>> _______________________________________________
>> >> >> >>> Ecrit mailing list
>> >> >> >>> [e-mail]
>> >> >> >>> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >>
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > Ecrit mailing list
>> >> >> > [e-mail]
>> >> >> > https://www.ietf.org/mailman/listinfo/ecrit
>> >> >> >
>> >> >
>> >>
>> >> _______________________________________________
>> >> Ecrit mailing list
>> >> [e-mail]
>> >> 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
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >>
>> >
>>
>>
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C643A69D2 for <[e-mail]>; Sun,  8 Feb 2009 01:31:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.343
X-Spam-Level: 
X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwPMjYyZkMAk for <[e-mail]>; Sun,  8 Feb 2009 01:31:35 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D181D3A69AC for <[e-mail]>; Sun,  8 Feb 2009 01:31:34 -0800 (PST)
Received: (qmail invoked by alias); 08 Feb 2009 09:31:37 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp036) with SMTP; 08 Feb 2009 10:31:37 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX181VLgwbLc1NM0tOBfmvkCZG13qrabthjdA5fIGam 7msnbAnRZDfAWw
From: "Hannes Tschofenig" <[e-mail]>
To: "'DOLLY, MARTIN C, ATTLABS'" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Date: Sun, 8 Feb 2009 11:32:25 +0200
Message-ID: <004701c989d0$2781a320$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <[e-mail]>
Thread-Index: AcmJRRX7MtWq02JtRZaMQukWCeihVwABI88yACGKpsA=
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.49
Cc: [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 09:31:36 -0000

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: [e-mail] [mailto:[e-mail]] 
>On Behalf Of DOLLY, MARTIN C, ATTLABS
>Sent: 07 February, 2009 19:30
>To: [e-mail]; [e-mail]
>Cc: [e-mail]; [e-mail]
>Subject: Re: [Ecrit] Semantics Re: RPH
>
>Do you have a clue dude? A+A of an user comes in many forms.
>
>----- Original Message -----
>From: [e-mail] <[e-mail]>
>To: Janet P Gunn <[e-mail]>
>Cc: ECRIT <[e-mail]>; [e-mail] 
><[e-mail]>
>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:
>
>>
>>
>> .
>>
>> [e-mail] 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E313A6870 for <[e-mail]>; Sun,  8 Feb 2009 01:47:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.345
X-Spam-Level: 
X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufXr1t2HNzWS for <[e-mail]>; Sun,  8 Feb 2009 01:47:42 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CEEFF3A6782 for <[e-mail]>; Sun,  8 Feb 2009 01:47:41 -0800 (PST)
Received: (qmail invoked by alias); 08 Feb 2009 09:47:41 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp063) with SMTP; 08 Feb 2009 10:47:41 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+wibkcAFGwDUodxaxPCT1dEmLyguhZiLLodmrVet YALu4gRJxBE7A0
From: "Hannes Tschofenig" <[e-mail]>
To: "'Janet P Gunn'" <[e-mail]>
References: <007201c988fc$2aab5f20$[e-mail]> <[e-mail]>
Date: Sun, 8 Feb 2009 11:48:28 +0200
Message-ID: <004801c989d2$65eb0b90$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <[e-mail]>
Thread-Index: AcmJQO+/MrC029JNQj+nRmcE91C5+gAjrsqA
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.53
Cc: 'ECRIT' <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 09:47:43 -0000

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
	



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9743A69C2 for <[e-mail]>; Sun,  8 Feb 2009 04:12:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.479
X-Spam-Level: 
X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjLJPG0+wimB for <[e-mail]>; Sun,  8 Feb 2009 04:12:21 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 490143A686A for <[e-mail]>; Sun,  8 Feb 2009 04:12:21 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-9.tower-120.messagelabs.com!1234095143!45432831!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 20064 invoked from network); 8 Feb 2009 12:12:23 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 8 Feb 2009 12:12:23 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n18CCMjU014800; Sun, 8 Feb 2009 07:12:22 -0500
Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n18CCGDO014779; Sun, 8 Feb 2009 07:12:17 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Sun, 8 Feb 2009 07:12:16 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Semantics  Re:  RPH
Thread-Index: AcmJRRX7MtWq02JtRZaMQukWCeihVwABI88yACGKpsAABarkNA==
From: "DOLLY, MARTIN C, ATTLABS" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 12:12:22 -0000

SGFubmVzLA0KDQpXZSBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlIGF0dGFjaG1lbnQgb2YgdGhlIFVF
IHRvIHRoZSBuZXR3b3JrLiBUaGVyZSBpcyBhbiBBQSBwcm9jZXNzIHByaW9yIHRvIGFsbG93aW5n
IGFueSB1c2UuIFdpdGhvdXQgdGhpcyB3ZSB3b3VsZCBub3QgdHJ1c3QgdGhlIFJQSCwgZXZlbiBm
b3IgRVRTLCBuZXZlciBtaW5kIDkxMQ0KDQpNYXJ0aW4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn
ZSAtLS0tLQ0KRnJvbTogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5u
ZXQ+DQpUbzogRE9MTFksIE1BUlRJTiBDLCBBVFRMQUJTOyBoZ3NAY3MuY29sdW1iaWEuZWR1IDxo
Z3NAY3MuY29sdW1iaWEuZWR1Pjsgamd1bm42QGNzYy5jb20gPGpndW5uNkBjc2MuY29tPg0KQ2M6
IGVjcml0QGlldGYub3JnIDxlY3JpdEBpZXRmLm9yZz4NClNlbnQ6IFN1biBGZWIgMDggMDQ6MzI6
MjUgMjAwOQ0KU3ViamVjdDogUkU6IFtFY3JpdF0gU2VtYW50aWNzICBSZTogIFJQSA0KDQpIaSBN
YXJ0aW4sIA0KDQpZb3VyIHJlbWFya3MgYXJlIGEgYml0IGEgc2hvcnQuDQoNCkNsZWFybHksIGF1
dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGNhbiBjb21lIGluIGRpZmZlcmVudCBmb3Jt
cy4gDQpUaGlzIHdhcyBhY3R1YWxseSBvbmUgb2YgdGhlIGRpc2N1c3Npb24gd2UgaGFkIHNvIGZh
ciB0aGF0IHRoZSBhdXRob3JpemF0aW9uDQptZWNoYW5pc21zIGZvciB0aGUgR0VUUyBSUEggYW5k
IHRoZSBwcm9wb3NlZCBFQ1JJVCBSUEggaXMgZGlmZmVyZW50LiANCg0KU28sIGNvdWxkIHlvdSBl
bGFib3JhdGUgYSBiaXQ/IA0KDQpDaWFvDQpIYW5uZXMNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+RnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5j
ZXNAaWV0Zi5vcmddIA0KPk9uIEJlaGFsZiBPZiBET0xMWSwgTUFSVElOIEMsIEFUVExBQlMNCj5T
ZW50OiAwNyBGZWJydWFyeSwgMjAwOSAxOTozMA0KPlRvOiBoZ3NAY3MuY29sdW1iaWEuZWR1OyBq
Z3VubjZAY3NjLmNvbQ0KPkNjOiBlY3JpdEBpZXRmLm9yZzsgZWNyaXQtYm91bmNlc0BpZXRmLm9y
Zw0KPlN1YmplY3Q6IFJlOiBbRWNyaXRdIFNlbWFudGljcyBSZTogUlBIDQo+DQo+RG8geW91IGhh
dmUgYSBjbHVlIGR1ZGU/IEErQSBvZiBhbiB1c2VyIGNvbWVzIGluIG1hbnkgZm9ybXMuDQo+DQo+
LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPkZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5v
cmcgPGVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+DQo+VG86IEphbmV0IFAgR3VubiA8amd1bm42QGNz
Yy5jb20+DQo+Q2M6IEVDUklUIDxlY3JpdEBpZXRmLm9yZz47IGVjcml0LWJvdW5jZXNAaWV0Zi5v
cmcgDQo+PGVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+DQo+U2VudDogU2F0IEZlYiAwNyAxMTo1Njo0
MiAyMDA5DQo+U3ViamVjdDogUmU6IFtFY3JpdF0gU2VtYW50aWNzICBSZTogIFJQSA0KPg0KPlBs
ZWFzZSBzZWUgbXkgZWFybGllciBtZXNzYWdlIGFzIHRvIHdoeSB5b3VyIGFwcHJvYWNoIGZhaWxz
IA0KPmZvciB0aGUgVUEtIGluc2VydGVkIGNhc2Ugd2hlcmUgbm90IGFsbCBlbWVyZ2VuY3kgY2Fs
bHMgaGF2ZSANCj5SUEggbWFya2luZ3MuIEkgdGhpbmsgaXQgd291bGQgYmUgYSByZWFsbHkgYmFk
IGlkZWEgaWYgDQo+ZW1lcmdlbmN5IGNhbGxzIHdpdGggUlBIIGFyZSB0cmVhdGVkIGRpZmZlcmVu
dGx5IHRoYW4gDQo+ZW1lcmdlbmN5IGNhbGxzIHdpdGhvdXQgaXQuIChBZ2FpbiwgSSdtIHRhbGtp
bmcgYWJvdXQgdGhlIA0KPnVzZXItaW5pdGlhdGVkIGNhbGxzLiBBbiBFU05FVCBjYW4gZG8gd2hh
dGV2ZXIgaXQgd2FudHMgYW5kIA0KPmNhbiBhc3NpZ24gZXh0cmEgcHJpb3JpdHkgdG8gY2FsbHMg
ZnJvbSBjaXRpemVucyB0aGF0IGhhdmUgDQo+Ym91Z2h0IFBCQSBzdGlja2VycyBvciB6aXAgY29k
ZXMgdGhhdCBwYXkgbW9yZSB0YXhlcywgYnV0IA0KPnRoYXQncyBhIHNlcGFyYXRlDQo+cHJvYmxl
bS4pDQo+DQo+SSBhbHNvIGRvbid0IGJlbGlldmUgeW91ciBpbXBsZW1lbnRhdGlvbiBsb2dpYy4g
QSBtdWNoIGJldHRlciANCj5hcHByb2FjaCBpcyB0byBzZW1hbnRpY2FsbHkgZGVjbGFyZSB0aGUg
Y2xhc3Mgb2YgY2FsbCBlYXJseSBvbiANCj4oZS5nLiwgYmFzZWQgb24gdGhlIFVSTiBvciBhZnRl
ciANCj5hdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uKSwgYW5kIG1ha2UgdGhhdCBwYXJ0IG9m
IHRoZSBjYWxsIA0KPnN0YXRlIHJlY29yZCwgcmF0aGVyIHRoYW4gaHVudCBmb3IgaGVhZGVycyBl
YWNoIHRpbWUgYSANCj5oYW5kbGluZyBkZWNpc2lvbiBuZWVkcyB0byBiZSBtYWRlLiBHaXZlbiB0
aGUgYXV0aG9yaXphdGlvbiANCj5yZXF1aXJlbWVudHMsIGp1c3QgbG9va2luZyBhdCAiaGFzIGhl
YWRlciBYIiBpcyBuZXZlciBnb2luZyB0byANCj5iZSBzdWZmaWNpZW50IGFueXdheS4NCj4NCj5I
ZW5uaW5nDQo+DQo+T24gRmViIDcsIDIwMDksIGF0IDExOjI3IEFNLCBKYW5ldCBQIEd1bm4gd3Jv
dGU6DQo+DQo+Pg0KPj4NCj4+IC4NCj4+DQo+PiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIHdyb3Rl
IG9uIDAyLzA3LzIwMDkgMDM6MTQ6NTcgQU06DQo+Pg0KPj4gPiBQTEVBU0UgdHJ5IHRvIHVuZGVy
c3RhbmQgdGhhdCB0aGUgc3ludGF4IGlzIHNpbWlsYXIgKGhlYWRlciwgbmV3DQo+PiBuYW1lc3Bh
Y2UsDQo+PiA+IG5ldyB2YWx1ZXMpDQo+PiA+IEJVVCB0aGUgc2VtYW50aWMgaXMgZGlmZmVyZW50
Lg0KPj4gPg0KPj4gPiBGb3IgYWxsIG1lc3NhZ2UgaXQgaXMgdHJ1ZSB0aGF0IHRoZSBzZW5kZXIg
Y2FuIGFkZCB3aGF0ZXZlciB0aGV5DQo+PiB3YW50LiBUaGUNCj4+ID4gYmlnIHF1ZXN0aW9uIGlz
IHdoYXQgZG9lcyBpdCBtZWFuIGZvciB0aGUgcmVjaXBpZW50Lg0KPj4gPg0KPj4gPiBUaGlzIGlz
IHdoYXQgdGhlIGRpc2N1c3Npb24gaXMgYWJvdXQuDQo+PiA+DQo+PiBPbiB0aGUgY29udHJhcnks
IHRoZSBzZW1hbnRpYyBpcywgb3IgYXQgbGVhc3QgY2FuIGJlLCB2ZXJ5IHNpbWlsYXIuDQo+Pg0K
Pj4gQ29uc2lkZXIgdGhlIGh5cG90aGV0aWNhbCwgYnV0IHBsYXVzaWJsZSwgY2FzZSBvZiBhIG5l
dHdvcmsgd2l0aCBhbiANCj4+IGV4cGxpY2l0IGNhbGwvY2FwYWNpdHkgYWRtaXNzaW9uIHByb2Nl
c3MsIGluIHdoaWNoIGJvdGggOTExLXR5cGUtIA0KPj4gZW1lcmdlbmN5IGNhbGxzIGFuZCBHRVRT
IGNhbGxzIGdldCBwcmVmZXJlbnRpYWwgYWRtaXNzaW9uIA0KPnRyZWF0bWVudC4gIA0KPj4gQnkg
dGhlIHRpbWUgdGhlIElOVklURSBnZXRzIHRvIHRoaXMgRnVuY3Rpb25hbCBNb2R1bGUvIGJsb2Nr
IA0KPm9mIGNvZGUsIA0KPj4gYWxsIGF1dGhlbnRpY2F0aW9uLCBhdXRob3JpemF0aW9uLCBhbmQg
Y2hhbmdlcy8gY29uZmlybWF0aW9uIG9mIHRoZSANCj4+IGRlc3RpbmF0aW9uIGhhdmUgYWxyZWFk
eSB0YWtlbiBwbGFjZS4gIEFsbCB0aGlzIGJsb2NrIG9mIGNvZGUgZGVhbHMgDQo+PiB3aXRoIGlz
IGNhbGwvY2FwYWNpdHkgYWRtaXNzaW9uLg0KPj4NCj4+IEZvciB0aGUgc2FrZSBvZiBhcmd1bWVu
dCwgc3VwcG9zZSB0aGlzIGlzIHRoZSBuYXR1cmUgb2YgdGhlIA0KPj4gcHJlZmVyZW5jZS4NCj4+
DQo+PiAxKSBGb3IgSU5WSVRFcyB3aXRob3V0IFJQSCwgb3Igd2l0aCBhbiBSUEggdGhpcyBuZXR3
b3JrIGRvZXMgDQo+bm90IHVzZS8gDQo+PiB1bmRlcnN0YW5kLCBpZiB0aGUgYWRtaXNzaW9uIHBy
b2Nlc3MgZmFpbHMsIHRoZSBJTlZJVEUgZmFpbHMNCj4+DQo+PiAyKSBGb3IgSU5WSVRFcyB3aXRo
IFJQSCB3aXRoIHRoZSBldHMgbmFtZXNwYWNlLCBpZiB0aGUgYWRtaXNzaW9uIA0KPj4gcHJvY2Vz
cyBpbml0aWFsbHkgZmFpbHMsIHRoZSBJTlZJVEUgaXMgcHV0IGluIHF1ZXVlIHVudGlsIHRoZSAN
Cj4+IHJlc291cmNlcyBiZWNvbWUgYXZhaWxhYmxlIHNvIGl0IGNhbiBiZSBhZG1pdHRlZC4NCj4+
DQo+PiAzKSBGb3IgSU5WSVRFcyB3aXRoIFJQSCB3aXRoIHRoZSBlc25ldCBuYW1lc3BhY2UsIGlm
IHRoZSBhZG1pc3Npb24gDQo+PiBwcm9jZXNzIGluaXRpYWxseSBmYWlscywgdGhlIElOVklURSBp
cyBwdXQgaW4gcXVldWUsIGJ1dCBhdCBsb3dlciANCj4+IHByaW9yaXR5IHRoYW4gdGhlIGNhbGxz
IHdpdGggdGhlIGV0cyBuYW1lc3BhY2UuDQo+Pg0KPj4gV2l0aCB0aGUgZXNuZXQgbmFtZXNwYWNl
LCB0aGlzIGJsb2NrIG9mIGNvZGUgb25seSBuZWVkcyB0byBkZWFsIHdpdGggDQo+PiB0aGUgUlBI
IGluIGRldGVybWluaW5nIHdoaWNoIElOVklURXMgdG8gcmVqZWN0LCBhbmQgd2hpY2ggdG8gcXVl
dWUsIA0KPj4gYW5kIGhvdy4NCj4+DQo+PiBCdXQgaWYgdGhlcmUgaXMgbm8gZXNuZXQgbmFtZXNw
YWNlIGZvciBSUEgsIHRoZW4gdGhpcyBibG9jayBvZiBjb2RlIA0KPj4gd291bGQgbmVlZCB0byBk
ZWFsIHdpdGggQk9USCB0aGUgUlBIIGFuZCB0aGUgVVJOLiAgVGhhdCB3b3VsZCBiZSBhIA0KPj4g
Y29tcGxldGVseSB1bm5lY2Vzc2FyeSBjb21wbGljYXRpb24uDQo+Pg0KPj4gSmFuZXQNCj4NCj5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkVjcml0IG1h
aWxpbmcgbGlzdA0KPkVjcml0QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9lY3JpdA0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+RWNyaXQgbWFpbGluZyBsaXN0DQo+RWNyaXRAaWV0Zi5vcmcNCj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+DQoNCg==


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 668333A6A4D for <[e-mail]>; Sun,  8 Feb 2009 05:13:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.347
X-Spam-Level: 
X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo6iknLofZsp for <[e-mail]>; Sun,  8 Feb 2009 05:13:46 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C259F3A68A6 for <[e-mail]>; Sun,  8 Feb 2009 05:13:45 -0800 (PST)
Received: (qmail invoked by alias); 08 Feb 2009 13:13:46 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp043) with SMTP; 08 Feb 2009 14:13:46 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/k+lgScQPkRtEb4VZzi8kSJtljfRHZtXUTOmZpdO c0uSrQSHgbMjM/
From: "Hannes Tschofenig" <[e-mail]>
To: "'DOLLY, MARTIN C, ATTLABS'" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Date: Sun, 8 Feb 2009 15:14:32 +0200
Message-ID: <004901c989ef$302749c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <[e-mail]>
Thread-Index: AcmJRRX7MtWq02JtRZaMQukWCeihVwABI88yACGKpsAABarkNAABBb6A
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.48
Cc: [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 13:13:47 -0000

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 <[e-mail]>
>To: DOLLY, MARTIN C, ATTLABS; [e-mail] 
><[e-mail]>; [e-mail] <[e-mail]>
>Cc: [e-mail] <[e-mail]>
>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: [e-mail] [mailto:[e-mail]] 
>On Behalf 
>>Of DOLLY, MARTIN C, ATTLABS
>>Sent: 07 February, 2009 19:30
>>To: [e-mail]; [e-mail]
>>Cc: [e-mail]; [e-mail]
>>Subject: Re: [Ecrit] Semantics Re: RPH
>>
>>Do you have a clue dude? A+A of an user comes in many forms.
>>
>>----- Original Message -----
>>From: [e-mail] <[e-mail]>
>>To: Janet P Gunn <[e-mail]>
>>Cc: ECRIT <[e-mail]>; [e-mail] 
>><[e-mail]>
>>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:
>>
>>>
>>>
>>> .
>>>
>>> [e-mail] 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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ecrit
>>_______________________________________________
>>Ecrit mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ecrit
>>
>
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FA423A6B4B for <[e-mail]>; Sun,  8 Feb 2009 06:02:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.499
X-Spam-Level: 
X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a6qslh3Y06U for <[e-mail]>; Sun,  8 Feb 2009 06:02:22 -0800 (PST)
Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 529FF28C0E2 for <[e-mail]>; Sun,  8 Feb 2009 06:02:04 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-11.tower-129.messagelabs.com!1234101726!5806118!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 3864 invoked from network); 8 Feb 2009 14:02:06 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-11.tower-129.messagelabs.com with AES256-SHA encrypted SMTP; 8 Feb 2009 14:02:06 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n18E25Ta001087; Sun, 8 Feb 2009 09:02:05 -0500
Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n18E22ki001067; Sun, 8 Feb 2009 09:02:04 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Sun, 8 Feb 2009 09:02:01 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Semantics  Re:  RPH
Thread-Index: AcmJRRX7MtWq02JtRZaMQukWCeihVwABI88yACGKpsAABarkNAABBb6AAALPqOk=
From: "DOLLY, MARTIN C, ATTLABS" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 14:02:23 -0000

VGhlc2UgYXJlIHRoZSBydWxlLCBub3QgdGhlIGV4Y2VwdGlvbi4gSSBkbyBub3QgY2FyZSBhYm91
dCB0aGUgaW50ZXJuZXQgZnJlZSBzY2VuYXJpb3MuIA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdl
IC0tLS0tDQpGcm9tOiBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5l
dD4NClRvOiBET0xMWSwgTUFSVElOIEMsIEFUVExBQlM7IGhnc0Bjcy5jb2x1bWJpYS5lZHUgPGhn
c0Bjcy5jb2x1bWJpYS5lZHU+OyBqZ3VubjZAY3NjLmNvbSA8amd1bm42QGNzYy5jb20+DQpDYzog
ZWNyaXRAaWV0Zi5vcmcgPGVjcml0QGlldGYub3JnPg0KU2VudDogU3VuIEZlYiAwOCAwODoxNDoz
MiAyMDA5DQpTdWJqZWN0OiBSRTogW0Vjcml0XSBTZW1hbnRpY3MgIFJlOiAgUlBIDQoNCkhpIE1h
cnRpbiwgDQoNClRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLiANCg0KSSBhbSBhd2FyZSBv
ZiB0aGVzZSBuZXR3b3JrIGFjY2VzcyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbg0K
cHJvY2VkdXJlcyAoaW5jbHVkaW5nIHRoZSBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlv
biBwcm9jZWR1cmUgYXQgdGhlDQpTSVAgbGF5ZXIpLiBUaGV5IGFyZSBjbGVhcmx5IGltcG9ydGFu
dCBmb3Igc29tZSBvZiB0aGUgUlBIIHVzYWdlIHNjZW5hcmlvcy4gDQoNCkZvciB0aGlzIHNwZWNp
ZmljIGNhc2UgKHRoZSBuZXcgZXNuZXQgUlBIIG1lY2hhbmlzbSkgdGhlcmUgYXJlIGFkZGl0aW9u
YWwNCmZhY2V0cyB0aGF0IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQgKGJleW9uZCB0aGUgYWJvdmUt
bWVudGlvbmVkIHNlY3VyaXR5DQphc3BlY3RzKTogDQoNCiogV2hhdCBkb2VzIHRoZSBlc25ldCBS
UEggdXNhZ2UgbWVhbiBpbiB0aGUgY29udGV4dCBvZiBhbiBlbWVyZ2VuY3kgY2FsbA0KKGZvciBl
eGFtcGxlLCBpbiBjb21wYXJpc29uIHRvIGFuIGVtZXJnZW5jeSBjYWxsIHdpdGhvdXQgZXNuZXQg
UlBIIHVzYWdlKT8gDQoNCiogRm9yIGVtZXJnZW5jeSBjYWxscyB0aGUgYXV0aG9yaXphdGlvbiBw
cm9jZWR1cmVzIGFyZSBkaWZmZXJlbnQgdGhhbiB3aXRoDQpyZWd1bGFyIGNhbGxzLiBUaGVyZSBh
cmUgY2VydGFpbmx5IGRpZmZlcmVuY2VzIHRvIHRoZSBHRVRTLWFsaWtlIGNhbGxzIGFzDQp3ZWxs
LiAoV2UgaWdub3JlIGZvciBhIG1vbWVudCB0aGF0IHRoZXJlIGFyZSB0aGVzZSB1bmF1dGhlbnRp
Y2F0ZWQgZW1lcmdlbmN5DQpjYWxscyB3aGVyZSBldmVuIHRoZSBhdXRoZW50aWNhdGlvbiBwcm9j
ZWR1cmUgaXMgbWlzc2luZy4pIFRoZSBjdXJyZW50DQpzZWN1cml0eSBjb25zaWRlcmF0aW9uIHNl
Y3Rpb24gZG9lcyBub3QgYWNrbm93bGVkZ2UgdGhlc2UgZGlmZmVyZW5jZXMuIA0KDQpJdCB3b3Vs
ZCBiZSBoZWxwZnVsIHRoYXQgZHJhZnQtaWV0Zi1lY3JpdC1sb2NhbC1lbWVyZ2VuY3ktcnBoLW5h
bWVzcGFjZQ0KY2FwdHVyZXMgc29tZSBvZiB0aGVzZSBhc3BlY3RzIHRvIGFsbG93IHRob3NlIHdo
byBpbXBsZW1lbnQgYW5kIGRlcGxveSB0aGUNCmVzbmV0IFJQSCBtZWNoYW5pc20gdG8gdW5kZXJz
dGFuZCB3aGF0IGl0IGRvZXMgYW5kIGhvdyB0byBjb3JyZWN0bHkNCmltcGxlbWVudCBpdC4gIA0K
DQpDaWFvDQpIYW5uZXMNCg0KUFM6IFRoZXJlIGFyZSBkZXRhaWxzIHRoYXQgYWxzbyBuZWVkIHRv
IGJlIGRpc2N1c3NlZC4gRm9yIGV4YW1wbGUsIHdoaWNoDQplc25ldCB2YWx1ZSB3b3VsZCB0aGUg
ZGV2aWNlIHVzZSBmb3IgYW4gZW1lcmdlbmN5IGNhbGw/ICJlc25ldC4wIiwNCiJlc25ldC4xIiwg
ImVzbmV0LjIiLCAiZXNuZXQuMyIsICJlc25ldC40Ii4gT3V0LW9mLXNjb3BlIGlzIGEgcG9zc2li
bGUNCmFuc3dlciBidXQgaXQgd2lsbCBub3QgaGVscCB0aGUgaW1wbGVtZW50ZXIgaW4gZG9pbmcg
aXQncyBqb2IuIElzIHRoZXJlIGENCnNwZWNpZmljIGRlZmF1bHQgdmFsdWUgKG1heWJlIHRoZSBo
aWdoZXN0IHZhbHVlLCBqdXN0IHRvIGJlIHN1cmUpPyBXb3VsZCB0aGUNClVBIGdldCBwcm92aXNp
b25lZCB0byBwaWNrIGEgc3BlY2lmaWMgdmFsdWU/IFdoYXQgaXMgdGhlIHByb3Zpc2lvbmluZw0K
bWVjaGFuaXNtPyBJcyB0aGVyZSBhIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBlc25ldCB2YWx1
ZXMgYW5kIHRoZSBTZXJ2aWNlDQpVUk4gdmFsdWVzPyBEbyB0aGUgdXJuOnNlcnZpY2U6Y291bnNl
bGluZzoqIHNlcnZpY2VzIGdldCBhIGxvd2VyIHByaW9yaXR5DQp0aGFuIHRoZSB1cm46c2Vydmlj
ZTpzb3M6KiBzZXJ2aWNlcz8gICANCg0KPkhhbm5lcywNCj4NCj5XZSBuZWVkIHRvIHVuZGVyc3Rh
bmQgdGhlIGF0dGFjaG1lbnQgb2YgdGhlIFVFIHRvIHRoZSBuZXR3b3JrLiANCj5UaGVyZSBpcyBh
biBBQSBwcm9jZXNzIHByaW9yIHRvIGFsbG93aW5nIGFueSB1c2UuIFdpdGhvdXQgdGhpcyANCj53
ZSB3b3VsZCBub3QgdHJ1c3QgdGhlIFJQSCwgZXZlbiBmb3IgRVRTLCBuZXZlciBtaW5kIDkxMQ0K
Pg0KPk1hcnRpbg0KPg0KPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj5Gcm9tOiBIYW5u
ZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldD4NCj5UbzogRE9MTFksIE1B
UlRJTiBDLCBBVFRMQUJTOyBoZ3NAY3MuY29sdW1iaWEuZWR1IA0KPjxoZ3NAY3MuY29sdW1iaWEu
ZWR1Pjsgamd1bm42QGNzYy5jb20gPGpndW5uNkBjc2MuY29tPg0KPkNjOiBlY3JpdEBpZXRmLm9y
ZyA8ZWNyaXRAaWV0Zi5vcmc+DQo+U2VudDogU3VuIEZlYiAwOCAwNDozMjoyNSAyMDA5DQo+U3Vi
amVjdDogUkU6IFtFY3JpdF0gU2VtYW50aWNzICBSZTogIFJQSA0KPg0KPkhpIE1hcnRpbiwgDQo+
DQo+WW91ciByZW1hcmtzIGFyZSBhIGJpdCBhIHNob3J0Lg0KPg0KPkNsZWFybHksIGF1dGhlbnRp
Y2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGNhbiBjb21lIGluIGRpZmZlcmVudCBmb3Jtcy4gDQo+
VGhpcyB3YXMgYWN0dWFsbHkgb25lIG9mIHRoZSBkaXNjdXNzaW9uIHdlIGhhZCBzbyBmYXIgdGhh
dCB0aGUgDQo+YXV0aG9yaXphdGlvbiBtZWNoYW5pc21zIGZvciB0aGUgR0VUUyBSUEggYW5kIHRo
ZSBwcm9wb3NlZCANCj5FQ1JJVCBSUEggaXMgZGlmZmVyZW50LiANCj4NCj5TbywgY291bGQgeW91
IGVsYWJvcmF0ZSBhIGJpdD8gDQo+DQo+Q2lhbw0KPkhhbm5lcw0KPg0KPj4tLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNy
aXQtYm91bmNlc0BpZXRmLm9yZ10gDQo+T24gQmVoYWxmIA0KPj5PZiBET0xMWSwgTUFSVElOIEMs
IEFUVExBQlMNCj4+U2VudDogMDcgRmVicnVhcnksIDIwMDkgMTk6MzANCj4+VG86IGhnc0Bjcy5j
b2x1bWJpYS5lZHU7IGpndW5uNkBjc2MuY29tDQo+PkNjOiBlY3JpdEBpZXRmLm9yZzsgZWNyaXQt
Ym91bmNlc0BpZXRmLm9yZw0KPj5TdWJqZWN0OiBSZTogW0Vjcml0XSBTZW1hbnRpY3MgUmU6IFJQ
SA0KPj4NCj4+RG8geW91IGhhdmUgYSBjbHVlIGR1ZGU/IEErQSBvZiBhbiB1c2VyIGNvbWVzIGlu
IG1hbnkgZm9ybXMuDQo+Pg0KPj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+PkZyb206
IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgPGVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+DQo+PlRvOiBK
YW5ldCBQIEd1bm4gPGpndW5uNkBjc2MuY29tPg0KPj5DYzogRUNSSVQgPGVjcml0QGlldGYub3Jn
PjsgZWNyaXQtYm91bmNlc0BpZXRmLm9yZyANCj4+PGVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+DQo+
PlNlbnQ6IFNhdCBGZWIgMDcgMTE6NTY6NDIgMjAwOQ0KPj5TdWJqZWN0OiBSZTogW0Vjcml0XSBT
ZW1hbnRpY3MgIFJlOiAgUlBIDQo+Pg0KPj5QbGVhc2Ugc2VlIG15IGVhcmxpZXIgbWVzc2FnZSBh
cyB0byB3aHkgeW91ciBhcHByb2FjaCBmYWlscyANCj5mb3IgdGhlIFVBLSANCj4+aW5zZXJ0ZWQg
Y2FzZSB3aGVyZSBub3QgYWxsIGVtZXJnZW5jeSBjYWxscyBoYXZlIFJQSCANCj5tYXJraW5ncy4g
SSB0aGluayANCj4+aXQgd291bGQgYmUgYSByZWFsbHkgYmFkIGlkZWEgaWYgZW1lcmdlbmN5IGNh
bGxzIHdpdGggUlBIIGFyZSB0cmVhdGVkIA0KPj5kaWZmZXJlbnRseSB0aGFuIGVtZXJnZW5jeSBj
YWxscyB3aXRob3V0IGl0LiAoQWdhaW4sIEknbSANCj50YWxraW5nIGFib3V0IA0KPj50aGUgdXNl
ci1pbml0aWF0ZWQgY2FsbHMuIEFuIEVTTkVUIGNhbiBkbyB3aGF0ZXZlciBpdCB3YW50cyBhbmQg
Y2FuIA0KPj5hc3NpZ24gZXh0cmEgcHJpb3JpdHkgdG8gY2FsbHMgZnJvbSBjaXRpemVucyB0aGF0
IGhhdmUgYm91Z2h0IFBCQSANCj4+c3RpY2tlcnMgb3IgemlwIGNvZGVzIHRoYXQgcGF5IG1vcmUg
dGF4ZXMsIGJ1dCB0aGF0J3MgYSBzZXBhcmF0ZQ0KPj5wcm9ibGVtLikNCj4+DQo+PkkgYWxzbyBk
b24ndCBiZWxpZXZlIHlvdXIgaW1wbGVtZW50YXRpb24gbG9naWMuIEEgbXVjaCBiZXR0ZXIgDQo+
YXBwcm9hY2ggDQo+PmlzIHRvIHNlbWFudGljYWxseSBkZWNsYXJlIHRoZSBjbGFzcyBvZiBjYWxs
IGVhcmx5IG9uIChlLmcuLCBiYXNlZCBvbiANCj4+dGhlIFVSTiBvciBhZnRlciBhdXRoZW50aWNh
dGlvbi9hdXRob3JpemF0aW9uKSwgYW5kIG1ha2UgdGhhdCBwYXJ0IG9mIA0KPj50aGUgY2FsbCBz
dGF0ZSByZWNvcmQsIHJhdGhlciB0aGFuIGh1bnQgZm9yIGhlYWRlcnMgZWFjaCB0aW1lIGEgDQo+
PmhhbmRsaW5nIGRlY2lzaW9uIG5lZWRzIHRvIGJlIG1hZGUuIEdpdmVuIHRoZSBhdXRob3JpemF0
aW9uIA0KPj5yZXF1aXJlbWVudHMsIGp1c3QgbG9va2luZyBhdCAiaGFzIGhlYWRlciBYIiBpcyBu
ZXZlciBnb2luZyB0byBiZSANCj4+c3VmZmljaWVudCBhbnl3YXkuDQo+Pg0KPj5IZW5uaW5nDQo+
Pg0KPj5PbiBGZWIgNywgMjAwOSwgYXQgMTE6MjcgQU0sIEphbmV0IFAgR3VubiB3cm90ZToNCj4+
DQo+Pj4NCj4+Pg0KPj4+IC4NCj4+Pg0KPj4+IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgd3JvdGUg
b24gMDIvMDcvMjAwOSAwMzoxNDo1NyBBTToNCj4+Pg0KPj4+ID4gUExFQVNFIHRyeSB0byB1bmRl
cnN0YW5kIHRoYXQgdGhlIHN5bnRheCBpcyBzaW1pbGFyIChoZWFkZXIsIG5ldw0KPj4+IG5hbWVz
cGFjZSwNCj4+PiA+IG5ldyB2YWx1ZXMpDQo+Pj4gPiBCVVQgdGhlIHNlbWFudGljIGlzIGRpZmZl
cmVudC4NCj4+PiA+DQo+Pj4gPiBGb3IgYWxsIG1lc3NhZ2UgaXQgaXMgdHJ1ZSB0aGF0IHRoZSBz
ZW5kZXIgY2FuIGFkZCB3aGF0ZXZlciB0aGV5DQo+Pj4gd2FudC4gVGhlDQo+Pj4gPiBiaWcgcXVl
c3Rpb24gaXMgd2hhdCBkb2VzIGl0IG1lYW4gZm9yIHRoZSByZWNpcGllbnQuDQo+Pj4gPg0KPj4+
ID4gVGhpcyBpcyB3aGF0IHRoZSBkaXNjdXNzaW9uIGlzIGFib3V0Lg0KPj4+ID4NCj4+PiBPbiB0
aGUgY29udHJhcnksIHRoZSBzZW1hbnRpYyBpcywgb3IgYXQgbGVhc3QgY2FuIGJlLCB2ZXJ5IHNp
bWlsYXIuDQo+Pj4NCj4+PiBDb25zaWRlciB0aGUgaHlwb3RoZXRpY2FsLCBidXQgcGxhdXNpYmxl
LCBjYXNlIG9mIGEgbmV0d29yayB3aXRoIGFuIA0KPj4+IGV4cGxpY2l0IGNhbGwvY2FwYWNpdHkg
YWRtaXNzaW9uIHByb2Nlc3MsIGluIHdoaWNoIGJvdGggOTExLXR5cGUtIA0KPj4+IGVtZXJnZW5j
eSBjYWxscyBhbmQgR0VUUyBjYWxscyBnZXQgcHJlZmVyZW50aWFsIGFkbWlzc2lvbg0KPj50cmVh
dG1lbnQuICANCj4+PiBCeSB0aGUgdGltZSB0aGUgSU5WSVRFIGdldHMgdG8gdGhpcyBGdW5jdGlv
bmFsIE1vZHVsZS8gYmxvY2sNCj4+b2YgY29kZSwNCj4+PiBhbGwgYXV0aGVudGljYXRpb24sIGF1
dGhvcml6YXRpb24sIGFuZCBjaGFuZ2VzLyBjb25maXJtYXRpb24gb2YgdGhlIA0KPj4+IGRlc3Rp
bmF0aW9uIGhhdmUgYWxyZWFkeSB0YWtlbiBwbGFjZS4gIEFsbCB0aGlzIGJsb2NrIG9mIGNvZGUg
ZGVhbHMgDQo+Pj4gd2l0aCBpcyBjYWxsL2NhcGFjaXR5IGFkbWlzc2lvbi4NCj4+Pg0KPj4+IEZv
ciB0aGUgc2FrZSBvZiBhcmd1bWVudCwgc3VwcG9zZSB0aGlzIGlzIHRoZSBuYXR1cmUgb2YgdGhl
IA0KPj4+IHByZWZlcmVuY2UuDQo+Pj4NCj4+PiAxKSBGb3IgSU5WSVRFcyB3aXRob3V0IFJQSCwg
b3Igd2l0aCBhbiBSUEggdGhpcyBuZXR3b3JrIGRvZXMNCj4+bm90IHVzZS8NCj4+PiB1bmRlcnN0
YW5kLCBpZiB0aGUgYWRtaXNzaW9uIHByb2Nlc3MgZmFpbHMsIHRoZSBJTlZJVEUgZmFpbHMNCj4+
Pg0KPj4+IDIpIEZvciBJTlZJVEVzIHdpdGggUlBIIHdpdGggdGhlIGV0cyBuYW1lc3BhY2UsIGlm
IHRoZSBhZG1pc3Npb24gDQo+Pj4gcHJvY2VzcyBpbml0aWFsbHkgZmFpbHMsIHRoZSBJTlZJVEUg
aXMgcHV0IGluIHF1ZXVlIHVudGlsIHRoZSANCj4+PiByZXNvdXJjZXMgYmVjb21lIGF2YWlsYWJs
ZSBzbyBpdCBjYW4gYmUgYWRtaXR0ZWQuDQo+Pj4NCj4+PiAzKSBGb3IgSU5WSVRFcyB3aXRoIFJQ
SCB3aXRoIHRoZSBlc25ldCBuYW1lc3BhY2UsIGlmIHRoZSBhZG1pc3Npb24gDQo+Pj4gcHJvY2Vz
cyBpbml0aWFsbHkgZmFpbHMsIHRoZSBJTlZJVEUgaXMgcHV0IGluIHF1ZXVlLCBidXQgYXQgbG93
ZXIgDQo+Pj4gcHJpb3JpdHkgdGhhbiB0aGUgY2FsbHMgd2l0aCB0aGUgZXRzIG5hbWVzcGFjZS4N
Cj4+Pg0KPj4+IFdpdGggdGhlIGVzbmV0IG5hbWVzcGFjZSwgdGhpcyBibG9jayBvZiBjb2RlIG9u
bHkgbmVlZHMgdG8gDQo+ZGVhbCB3aXRoIA0KPj4+IHRoZSBSUEggaW4gZGV0ZXJtaW5pbmcgd2hp
Y2ggSU5WSVRFcyB0byByZWplY3QsIGFuZCB3aGljaCB0byBxdWV1ZSwgDQo+Pj4gYW5kIGhvdy4N
Cj4+Pg0KPj4+IEJ1dCBpZiB0aGVyZSBpcyBubyBlc25ldCBuYW1lc3BhY2UgZm9yIFJQSCwgdGhl
biB0aGlzIGJsb2NrIG9mIGNvZGUgDQo+Pj4gd291bGQgbmVlZCB0byBkZWFsIHdpdGggQk9USCB0
aGUgUlBIIGFuZCB0aGUgVVJOLiAgVGhhdCB3b3VsZCBiZSBhIA0KPj4+IGNvbXBsZXRlbHkgdW5u
ZWNlc3NhcnkgY29tcGxpY2F0aW9uLg0KPj4+DQo+Pj4gSmFuZXQNCj4+DQo+Pl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PkVjcml0IG1haWxpbmcgbGlz
dA0KPj5FY3JpdEBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2Vjcml0DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+PkVjcml0IG1haWxpbmcgbGlzdA0KPj5FY3JpdEBpZXRmLm9yZw0KPj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+Pg0KPg0KPg0KDQo=


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097C53A6B64 for <[e-mail]>; Sun,  8 Feb 2009 06:04:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.098
X-Spam-Level: 
X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.151,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGcCdwfmPk2g for <[e-mail]>; Sun,  8 Feb 2009 06:04:49 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 6F85D3A6B62 for <[e-mail]>; Sun,  8 Feb 2009 06:04:48 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n18E4evP026269 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 8 Feb 2009 15:04:40 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sun, 8 Feb 2009 15:04:40 +0100
From: "DRAGE, Keith (Keith)" <[e-mail]>
To: Hannes Tschofenig <[e-mail]>, "'Henning Schulzrinne'" <[e-mail]>, "'James M. Polk'" <[e-mail]>
Date: Sun, 8 Feb 2009 15:04:38 +0100
Thread-Topic: [Ecrit] RPH
Thread-Index: AcmIqmZ/facwrgsDSaOG521IP+Vb0gADyoqAABCWV2AAIvWSkA==
Message-ID: <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]><001d01c9885b$d5d705d0$[e-mail]><001f01c98860$910658c0$[e-mail]><0d6901c9886b$6c9bfc50$45d3f4f0$@net><003001c9886e$7d133280$[e-mail]><[e-mail]><0d9101c98872$7b2129b0$71637d10$@net><003d01c98889$666c23f0$[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <007201c988fc$2aab5f20$[e-mail]>
In-Reply-To: <007201c988fc$2aab5f20$[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Cc: 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 14:04:51 -0000

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:[e-mail]]=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: [e-mail] [mailto:[e-mail]]=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: [e-mail] [mailto:[e-mail]]
> >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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>=20
> >_______________________________________________
> >Ecrit mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ecrit
> >
>=20
> =


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09DF3A6929 for <[e-mail]>; Sun,  8 Feb 2009 10:41:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level: 
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUKTIqNs6eBt for <[e-mail]>; Sun,  8 Feb 2009 10:41:31 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9F24F3A68DE for <[e-mail]>; Sun,  8 Feb 2009 10:41:29 -0800 (PST)
Received: (qmail invoked by alias); 08 Feb 2009 18:41:32 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp071) with SMTP; 08 Feb 2009 19:41:32 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18O4pVR64sOAps73nyGNjTwgSOhBPUdPIBWkMieGg NSyX1+T9gWUSBg
From: "Hannes Tschofenig" <[e-mail]>
To: "'DRAGE, Keith \(Keith\)'" <[e-mail]>, "'Henning Schulzrinne'" <[e-mail]>, "'James M. Polk'" <[e-mail]>
References: <000701c9883c$59b095d0$[e-mail]><[e-mail]><001d01c9885b$d5d705d0$[e-mail]><001f01c98860$910658c0$[e-mail]><0d6901c9886b$6c9bfc50$45d3f4f0$@net><003001c9886e$7d133280$[e-mail]><[e-mail]><0d9101c98872$7b2129b0$71637d10$@net><003d01c98889$666c23f0$[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <007201c988fc$2aab5f20$[e-mail]> <[e-mail]>
Date: Sun, 8 Feb 2009 20:42:14 +0200
Message-ID: <005001c98a1c$fa8afd60$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <[e-mail]>
Thread-Index: AcmIqmZ/facwrgsDSaOG521IP+Vb0gADyoqAABCWV2AAIvWSkAAlKZRA
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.51
Cc: 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 18:41:33 -0000

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:[e-mail]] 
>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:[e-mail]]
>> 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: [e-mail] [mailto:[e-mail]]
>> 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: [e-mail] [mailto:[e-mail]]
>> >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
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> 
>> >_______________________________________________
>> >Ecrit mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/ecrit
>> >
>> 
>> 
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0D243A687D for <[e-mail]>; Sun,  8 Feb 2009 10:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.353
X-Spam-Level: 
X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIIiEaYqq48m for <[e-mail]>; Sun,  8 Feb 2009 10:44:37 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 068593A698E for <[e-mail]>; Sun,  8 Feb 2009 10:44:36 -0800 (PST)
Received: (qmail invoked by alias); 08 Feb 2009 18:44:37 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp070) with SMTP; 08 Feb 2009 19:44:37 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/r6INWuOrr3LeliwI5P7s2FuWdHPSZ6/7uuHn5BR tGJUW5Dc9hP9Hq
From: "Hannes Tschofenig" <[e-mail]>
To: "'DOLLY, MARTIN C, ATTLABS'" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Date: Sun, 8 Feb 2009 20:45:21 +0200
Message-ID: <005101c98a1d$686ba6e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <[e-mail]>
Thread-Index: AcmJRRX7MtWq02JtRZaMQukWCeihVwABI88yACGKpsAABarkNAABBb6AAALPqOkACc/Q0A==
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.5
Cc: [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 18:44:38 -0000

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:[e-mail]] 
>Sent: 08 February, 2009 16:02
>To: [e-mail]; [e-mail]; [e-mail]
>Cc: [e-mail]
>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 <[e-mail]>
>To: DOLLY, MARTIN C, ATTLABS; [e-mail] 
><[e-mail]>; [e-mail] <[e-mail]>
>Cc: [e-mail] <[e-mail]>
>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 <[e-mail]>
>>To: DOLLY, MARTIN C, ATTLABS; [e-mail] 
>><[e-mail]>; [e-mail] <[e-mail]>
>>Cc: [e-mail] <[e-mail]>
>>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: [e-mail] [mailto:[e-mail]]
>>On Behalf
>>>Of DOLLY, MARTIN C, ATTLABS
>>>Sent: 07 February, 2009 19:30
>>>To: [e-mail]; [e-mail]
>>>Cc: [e-mail]; [e-mail]
>>>Subject: Re: [Ecrit] Semantics Re: RPH
>>>
>>>Do you have a clue dude? A+A of an user comes in many forms.
>>>
>>>----- Original Message -----
>>>From: [e-mail] <[e-mail]>
>>>To: Janet P Gunn <[e-mail]>
>>>Cc: ECRIT <[e-mail]>; [e-mail] 
>>><[e-mail]>
>>>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:
>>>
>>>>
>>>>
>>>> .
>>>>
>>>> [e-mail] 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
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>_______________________________________________
>>>Ecrit mailing list
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>
>>
>
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4F228C0F3 for <[e-mail]>; Sun,  8 Feb 2009 12:12:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.138
X-Spam-Level: 
X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=0.460,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpG491udjPVU for <[e-mail]>; Sun,  8 Feb 2009 12:12:54 -0800 (PST)
Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id CF8BA3A6783 for <[e-mail]>; Sun,  8 Feb 2009 12:12:53 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-13.tower-164.messagelabs.com!1234123975!9908727!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 3670 invoked from network); 8 Feb 2009 20:12:56 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-13.tower-164.messagelabs.com with AES256-SHA encrypted SMTP; 8 Feb 2009 20:12:56 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n18KCt3b029015 for <[e-mail]>; Sun, 8 Feb 2009 15:12:55 -0500
In-Reply-To: <005101c98a1d$686ba6e0$[e-mail]>
To: "Hannes Tschofenig" <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn <[e-mail]>
Message-ID: <[e-mail]>
Date: Sun, 8 Feb 2009 15:12:50 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/08/2009 03:15:16 PM, Serialize complete at 02/08/2009 03:15:16 PM
Content-Type: multipart/alternative; boundary="=_alternative 006F076685257557_="
Cc: [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 20:12:55 -0000

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

Up to local policy.

Janet

"Hannes Tschofenig" <[e-mail]> 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:[e-mail]] 
> >Sent: 08 February, 2009 16:02
> >To: [e-mail]; [e-mail]; [e-mail]
> >Cc: [e-mail]
> >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 <[e-mail]>
> >To: DOLLY, MARTIN C, ATTLABS; [e-mail] 
> ><[e-mail]>; [e-mail] <[e-mail]>
> >Cc: [e-mail] <[e-mail]>
> >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 <[e-mail]>
> >>To: DOLLY, MARTIN C, ATTLABS; [e-mail] 
> >><[e-mail]>; [e-mail] <[e-mail]>
> >>Cc: [e-mail] <[e-mail]>
> >>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: [e-mail] [mailto:[e-mail]]
> >>On Behalf
> >>>Of DOLLY, MARTIN C, ATTLABS
> >>>Sent: 07 February, 2009 19:30
> >>>To: [e-mail]; [e-mail]
> >>>Cc: [e-mail]; [e-mail]
> >>>Subject: Re: [Ecrit] Semantics Re: RPH
> >>>
> >>>Do you have a clue dude? A+A of an user comes in many forms.
> >>>
> >>>----- Original Message -----
> >>>From: [e-mail] <[e-mail]>
> >>>To: Janet P Gunn <[e-mail]>
> >>>Cc: ECRIT <[e-mail]>; [e-mail] 
> >>><[e-mail]>
> >>>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:
> >>>
> >>>>
> >>>>
> >>>> .
> >>>>
> >>>> [e-mail] 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
> >>>[e-mail]
> >>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>_______________________________________________
> >>>Ecrit mailing list
> >>>[e-mail]
> >>>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;[e-mail]&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:[e-mail]] <br>
&gt; &gt;Sent: 08 February, 2009 16:02<br>
&gt; &gt;To: [e-mail]; [e-mail]; [e-mail]<br>
&gt; &gt;Cc: [e-mail]<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;[e-mail]&gt;<br>
&gt; &gt;To: DOLLY, MARTIN C, ATTLABS; [e-mail] <br>
&gt; &gt;&lt;[e-mail]&gt;; [e-mail] &lt;[e-mail]&gt;<br>
&gt; &gt;Cc: [e-mail] &lt;[e-mail]&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;[e-mail]&gt;<br>
&gt; &gt;&gt;To: DOLLY, MARTIN C, ATTLABS; [e-mail] <br>
&gt; &gt;&gt;&lt;[e-mail]&gt;; [e-mail] &lt;[e-mail]&gt;<br>
&gt; &gt;&gt;Cc: [e-mail] &lt;[e-mail]&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: [e-mail] [mailto:[e-mail]]<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: [e-mail]; [e-mail]<br>
&gt; &gt;&gt;&gt;Cc: [e-mail]; [e-mail]<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: [e-mail] &lt;[e-mail]&gt;<br>
&gt; &gt;&gt;&gt;To: Janet P Gunn &lt;[e-mail]&gt;<br>
&gt; &gt;&gt;&gt;Cc: ECRIT &lt;[e-mail]&gt;; [e-mail]
<br>
&gt; &gt;&gt;&gt;&lt;[e-mail]&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; [e-mail] 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;[e-mail]<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;[e-mail]<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_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714513A6B2C for <[e-mail]>; Sun,  8 Feb 2009 23:33:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.205
X-Spam-Level: 
X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.394,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJaYlhIcN1Sy for <[e-mail]>; Sun,  8 Feb 2009 23:33:52 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 820B93A6994 for <[e-mail]>; Sun,  8 Feb 2009 23:33:51 -0800 (PST)
Received: (qmail invoked by alias); 09 Feb 2009 07:33:55 -0000
Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp052) with SMTP; 09 Feb 2009 08:33:55 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/qX5xv3q3qa+k0hr734L/mj2oPkMuhbWW/XV36FT N1KW5tcCLWj0mM
From: "Hannes Tschofenig" <[e-mail]>
To: "'Janet P Gunn'" <[e-mail]>
References: <005101c98a1d$686ba6e0$[e-mail]> <[e-mail]>
Date: Mon, 9 Feb 2009 09:34:42 +0200
Message-ID: <007901c98a88$e0c2add0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <[e-mail]>
Thread-Index: AcmKKaJr8ARQIZ9aRYSjxto6ln5OpAAXEJew
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.82
Cc: [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 07:33:53 -0000

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:[e-mail]] 
	Sent: 08 February, 2009 22:13
	To: Hannes Tschofenig
	Cc: [e-mail]; [e-mail]; 'DOLLY, MARTIN C, ATTLABS'
	Subject: RE: [Ecrit] Semantics Re: RPH
	
	

	
	
	Up to local policy. 
	
	Janet 
	
	"Hannes Tschofenig" <[e-mail]> 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:[e-mail]] 
	> >Sent: 08 February, 2009 16:02
	> >To: [e-mail]; [e-mail];
[e-mail]
	> >Cc: [e-mail]
	> >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 <[e-mail]>
	> >To: DOLLY, MARTIN C, ATTLABS; [e-mail] 
	> ><[e-mail]>; [e-mail] <[e-mail]>
	> >Cc: [e-mail] <[e-mail]>
	> >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 <[e-mail]>
	> >>To: DOLLY, MARTIN C, ATTLABS; [e-mail] 
	> >><[e-mail]>; [e-mail] <[e-mail]>
	> >>Cc: [e-mail] <[e-mail]>
	> >>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: [e-mail] [mailto:[e-mail]]
	> >>On Behalf
	> >>>Of DOLLY, MARTIN C, ATTLABS
	> >>>Sent: 07 February, 2009 19:30
	> >>>To: [e-mail]; [e-mail]
	> >>>Cc: [e-mail]; [e-mail]
	> >>>Subject: Re: [Ecrit] Semantics Re: RPH
	> >>>
	> >>>Do you have a clue dude? A+A of an user comes in many forms.
	> >>>
	> >>>----- Original Message -----
	> >>>From: [e-mail] <[e-mail]>
	> >>>To: Janet P Gunn <[e-mail]>
	> >>>Cc: ECRIT <[e-mail]>; [e-mail] 
	> >>><[e-mail]>
	> >>>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:
	> >>>
	> >>>>
	> >>>>
	> >>>> .
	> >>>>
	> >>>> [e-mail] 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
	> >>>[e-mail]
	> >>>https://www.ietf.org/mailman/listinfo/ecrit
	> >>>_______________________________________________
	> >>>Ecrit mailing list
	> >>>[e-mail]
	> >>>https://www.ietf.org/mailman/listinfo/ecrit
	> >>>
	> >>
	> >>
	> >
	> >
	> 
	




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF153A6BBC for <[e-mail]>; Mon,  9 Feb 2009 05:53:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.222
X-Spam-Level: 
X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju6ZR1bNAXl6 for <[e-mail]>; Mon,  9 Feb 2009 05:53:15 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DEE793A67AE for <[e-mail]>; Mon,  9 Feb 2009 05:53:14 -0800 (PST)
Received: (qmail invoked by alias); 09 Feb 2009 13:46:37 -0000
Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp012) with SMTP; 09 Feb 2009 14:46:37 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19A73o1gIhAU4VY3D7VhduwyY2fFvNrc7c6o6NuYZ m4daldFgLcgCQW
From: "Hannes Tschofenig" <[e-mail]>
To: "'Janet P Gunn'" <[e-mail]>, "'Brian Rosen'" <[e-mail]>
References: <054601c98545$ccd81280$66883780$@net> <[e-mail]>
Date: Mon, 9 Feb 2009 15:47:25 +0200
Message-ID: <011901c98abc$f172d810$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <[e-mail]>
Thread-Index: AcmFcdbm9wRihwACSKyhQJneXcFjnAFSm/5g
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.76
Cc: [e-mail], [e-mail]
Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 13:53:15 -0000

-- 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:[e-mail]] 
	Sent: 02 February, 2009 22:07
	To: Brian Rosen
	Cc: [e-mail]; [e-mail]; '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. 
	
	[e-mail] 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.
	




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31D53A6A6A for <[e-mail]>; Mon,  9 Feb 2009 08:49:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.425
X-Spam-Level: 
X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmVhQr9+1o7r for <[e-mail]>; Mon,  9 Feb 2009 08:49:33 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BA3E13A6A48 for <[e-mail]>; Mon,  9 Feb 2009 08:49:29 -0800 (PST)
Received: (qmail invoked by alias); 09 Feb 2009 15:49:25 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp008) with SMTP; 09 Feb 2009 16:49:25 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18fnopt6MEfdp76MPxtNDo73Wnja60N9ceRLlhMbw RluvsNqVwR9b+0
From: "Hannes Tschofenig" <[e-mail]>
To: <[e-mail]>
Date: Mon, 9 Feb 2009 17:50:14 +0200
Message-ID: <017301c98ace$1a18d1a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: AcmKzhkUZBM/AyChSmWdMt9/BOw/Pw==
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.71
Cc: 'ext Gonzalo Camarillo' <[e-mail]>
Subject: [Ecrit] Next steps for draft-patel-ecrit-sos-parameter-03.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 16:49:34 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF743A6A6A for <[e-mail]>; Mon,  9 Feb 2009 09:03:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.17
X-Spam-Level: 
X-Spam-Status: No, score=-105.17 tagged_above=-999 required=5 tests=[AWL=1.429, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXaQCXUUR7FU for <[e-mail]>; Mon,  9 Feb 2009 09:03:35 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 99E773A69A8 for <[e-mail]>; Mon,  9 Feb 2009 09:03:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[e-mail]; q=dns/txt; s=qcdkim; t=1234199018; x=1265735018; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20<p06240801c5b60fcc7136 @[10.227.68.59]>|In-Reply-To:=20<XFE-SJC-211zyAmbnk10000c [e-mail]>|References:=20<14C85D6CCB [e-mail] m>=0D=0A=20<000101c988ad$8ac92e90$[e-mail]> =0D=0A=20<[e-mail] sco.com>|Date:=20Mon,=209=20Feb=202009=2009:03:34=20-0800 |To:=20"James=20M.=20Polk"=20<[e-mail]>,=0D=0A=20 =20=20=20=20=20=20=20Hannes=20Tschofenig=0D=0A=09<Hannes. [e-mail]>,=0D=0A=20=20=20=20=20=20=20=20"'DOLLY ,=20MARTIN=20C,=20=20ATTLABS'"=20<[e-mail]>,=0D=0A =20=20=20=20=20=20=20=20"[e-mail]"=20<hgs@cs.c olumbia.edu>,=0D=0A=20=20=20=20=20=20=20=20"James.Winterb [e-mail]"=0D=0A=09<[e-mail]> |From:=20Ted=20Hardie=20<[e-mail]>|Subject:=20 Re:=20[Ecrit]=20RPH|CC:=20"Tschofenig,=20Hannes=20(NSN=20 -=20FI/Espoo)"=20<[e-mail]>,=0D=0A=20=20 =20=20=20=20=20=20"[e-mail]"=20<[e-mail]> |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5520"=3B=20 a=3D"15347285"; bh=0IPforLVd9xGVbWCPIawwuJbPbznM07hB4y2gZBfbgo=; b=hLOR9n2C++g5xP6HajFElZkjiEUBESQH8Rqdby8EHYKASCxrsCqYf3/A m16IwQpC8eGk0/RkEIBroI1To7ZnyhKT1VRnhblXy4ObN15G6kEckaKWL uCxzRHIJMJSXllSFhf8P8X94VrmHHeRnyWtFf+n/w6/9gILretIMlY8d4 g=;
X-IronPort-AV: E=McAfee;i="5300,2777,5520"; a="15347285"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2009 09:03:37 -0800
Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n19H3bw2010379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Feb 2009 09:03:37 -0800
Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n19H3a2s020583 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Feb 2009 09:03:36 -0800
Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 9 Feb 2009 09:03:36 -0800
Received: from [10.227.68.59] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 9 Feb 2009 09:03:35 -0800
MIME-Version: 1.0
Message-ID: <p06240801c5b60fcc7136@[10.227.68.59]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <000101c988ad$8ac92e90$[e-mail]> <[e-mail]>
Date: Mon, 9 Feb 2009 09:03:34 -0800
To: "James M. Polk" <[e-mail]>, Hannes Tschofenig <[e-mail]>, "'DOLLY, MARTIN C,  ATTLABS'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
From: Ted Hardie <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 17:03:36 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7FA3A67DA for <[e-mail]>; Mon,  9 Feb 2009 09:13:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.443
X-Spam-Level: 
X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.156,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeoi7puDWpYh for <[e-mail]>; Mon,  9 Feb 2009 09:13:32 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 60DA43A69DC for <[e-mail]>; Mon,  9 Feb 2009 09:13:32 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="139822517"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2009 17:13:23 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n19HDNdW021276;  Mon, 9 Feb 2009 09:13:23 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19HDNpq016347; Mon, 9 Feb 2009 17:13:23 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 09:13:23 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 09:13:22 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 09 Feb 2009 11:13:21 -0600
To: "Hannes Tschofenig" <[e-mail]>, "'DRAGE, Keith \(Keith\)'" <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <007501c988fe$9ec32670$[e-mail]>
References: <[e-mail]> <000801c98708$5973f6f0$[e-mail]> <[e-mail]> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$[e-mail]> <0a1101c98716$91287db0$b3797910$@net> <[e-mail]> <009701c987c4$c3cb7340$[e-mail]> <[e-mail]> <000701c9883c$59b095d0$[e-mail]> <[e-mail]> <000001c988ac$d0261940$[e-mail]> <[e-mail]> <007501c988fe$9ec32670$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 09 Feb 2009 17:13:22.0963 (UTC) FILETIME=[B668D630:01C98AD9]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=21176; t=1234199603; x=1235063603; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20RE=3A=20ECRIT=20Virtual=20Interim=20Meeting=3A= 20Agenda=20(RPH=20&=20GETS) |Sender:=20; bh=UuP/2rjah9/54pO4cWfSNz84BcDOa2AMS40qUBRGWos=; b=ZG63V4uxfOB0jRxCEKwTivj3jbkTgKAq8/W8caA/pcKhNB71ZENv+twEs0 fhrOu6g3duofMxtPYSn5eOJcgGlpanDF+EVPa51NBtaUJK27Da9zUa7aeKvP VgtTK09XOANwBd3vSuLbbVWVDhmZk+uJtNJq4MoZOJHbo9f0ehQl0=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 17:13:34 -0000

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:[e-mail]]
> >> 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:[e-mail]]
> >> >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:[e-mail]]
> >> >> >> >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: [e-mail] [mailto:[e-mail]]
> >> >> >> >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:[e-mail]]
> >> >> >> >> > 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:[e-mail]]
> >> >> >> >> > >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: [e-mail]
> >> >> >> >> > >> [mailto:[e-mail]]
> >> >> >> >> > >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
> >> >> >> >> > >> [e-mail]
> >> >> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >> >> > >
> >> >> >> >>
> >> >> >> >> _______________________________________________
> >> >> >> >> Ecrit mailing list
> >> >> >> >> [e-mail]
> >> >> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> >> >>
> >> >> >> >
> >> >> >
> >> >
> >>
> >>
> >



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84483A6944; Mon,  9 Feb 2009 09:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.447
X-Spam-Level: 
X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.152,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUpiYyZVCoFC; Mon,  9 Feb 2009 09:20:53 -0800 (PST)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id EC01E3A6AB3; Mon,  9 Feb 2009 09:20:52 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="133964773"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2009 17:20:55 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n19HKsLm017853;  Mon, 9 Feb 2009 09:20:54 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n19HKsb1014982; Mon, 9 Feb 2009 17:20:54 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 09:20:54 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 09:20:54 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 09 Feb 2009 11:20:52 -0600
To: "Hannes Tschofenig" <[e-mail]>, "'Janet P Gunn'" <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <004801c989d2$65eb0b90$[e-mail]>
References: <007201c988fc$2aab5f20$[e-mail]> <[e-mail]> <004801c989d2$65eb0b90$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 09 Feb 2009 17:20:54.0103 (UTC) FILETIME=[C34F5670:01C98ADA]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3784; t=1234200054; x=1235064054; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20RE=3A=20Semantics=20=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=10UvIGfxunJkirSj9EEpywLN1mfR7mfgoRDJXRuuNzI=; b=E03KOsEFrU/sNVX1n1a8FhEVmLRFYn/hBxHZc4CozE0qv6MBqVcF715VYc 1cEf3+F+Hi8MmiftayfxhDsxP40EraTJODc/6PClnjX4M6N4FQr/j4b6Rrwr 71l/kuldfn;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
Cc: 'ECRIT' <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 17:20:54 -0000

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
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47AC33A6AF7 for <[e-mail]>; Mon,  9 Feb 2009 09:36:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level: 
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQAEIPENwS-P for <[e-mail]>; Mon,  9 Feb 2009 09:36:19 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E31DE3A6B08 for <[e-mail]>; Mon,  9 Feb 2009 09:36:18 -0800 (PST)
Received: (qmail invoked by alias); 09 Feb 2009 17:36:06 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp012) with SMTP; 09 Feb 2009 18:36:06 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18LdnlknSsLPtB6ClurYZt4etiupjdOZCfKx1Eov3 cOGACqQHoNgefk
From: "Hannes Tschofenig" <[e-mail]>
To: "'Ted Hardie'" <[e-mail]>, "'James M. Polk'" <[e-mail]>, "'DOLLY, MARTIN C,  ATTLABS'" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]> <000101c988ad$8ac92e90$[e-mail]> <[e-mail]> <p06240801c5b60fcc7136@[10.227.68.59]>
Date: Mon, 9 Feb 2009 19:36:49 +0200
Message-ID: <01c701c98add$00aea1e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <p06240801c5b60fcc7136@[10.227.68.59]>
Thread-Index: AcmK2FpXH9Qas32lRRuKLwzp946nKgABGHnw
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.53
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 17:36:20 -0000

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:[e-mail]] 
>Sent: 09 February, 2009 19:04
>To: James M. Polk; Hannes Tschofenig; 'DOLLY, MARTIN C, 
>ATTLABS'; [e-mail]; [e-mail]
>Cc: Tschofenig, Hannes (NSN - FI/Espoo); [e-mail]
>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
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855FB3A6AF7 for <[e-mail]>; Mon,  9 Feb 2009 09:41:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.45
X-Spam-Level: 
X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bda8B7R2PbnT for <[e-mail]>; Mon,  9 Feb 2009 09:41:17 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 173C03A6AB3 for <[e-mail]>; Mon,  9 Feb 2009 09:41:17 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="130066534"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 Feb 2009 17:41:19 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n19HfJeb024004;  Mon, 9 Feb 2009 09:41:19 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19HfJ0S005584; Mon, 9 Feb 2009 17:41:19 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 09:41:18 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 09:41:18 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 09 Feb 2009 11:41:17 -0600
To: "Hannes Tschofenig" <[e-mail]>, "'DOLLY, MARTIN C, ATTLABS'" <[e-mail]>, <[e-mail]>, <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <004901c989ef$302749c0$[e-mail]>
References: <[e-mail]> <004901c989ef$302749c0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 09 Feb 2009 17:41:18.0400 (UTC) FILETIME=[9D0C3C00:01C98ADD]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9914; t=1234201279; x=1235065279; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20Semantics=20=20Re=3A=20=20RPH |Sender:=20; bh=leOIFxuu2BxtY7M3KzbISqTRf3IUO1IY/GJrJOTd0p4=; b=Qw2SG58ZPR/siMMnQfRECplkYR5VX9vlo6X9f5eXL9FeS5Owe8csWFFFc9 CyO+lSnQSIaVIr1vF4NwXQsV2jQL14gj2yz/q6+8Kcv8O2Qtm6RTzhzFtyuE Y9pBmscK1E9MKVNuB4Wi7yqkSyPyrai6FbN6hE8v1T33prmJkpYFs=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Cc: [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 17:41:18 -0000

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 <[e-mail]>
> >To: DOLLY, MARTIN C, ATTLABS; [e-mail]
> ><[e-mail]>; [e-mail] <[e-mail]>
> >Cc: [e-mail] <[e-mail]>
> >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: [e-mail] [mailto:[e-mail]]
> >On Behalf
> >>Of DOLLY, MARTIN C, ATTLABS
> >>Sent: 07 February, 2009 19:30
> >>To: [e-mail]; [e-mail]
> >>Cc: [e-mail]; [e-mail]
> >>Subject: Re: [Ecrit] Semantics Re: RPH
> >>
> >>Do you have a clue dude? A+A of an user comes in many forms.
> >>
> >>----- Original Message -----
> >>From: [e-mail] <[e-mail]>
> >>To: Janet P Gunn <[e-mail]>
> >>Cc: ECRIT <[e-mail]>; [e-mail]
> >><[e-mail]>
> >>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:
> >>
> >>>
> >>>
> >>> .
> >>>
> >>> [e-mail] 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
> >>[e-mail]
> >>https://www.ietf.org/mailman/listinfo/ecrit
> >>_______________________________________________
> >>Ecrit mailing list
> >>[e-mail]
> >>https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >
> >
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D753A68B9 for <[e-mail]>; Mon,  9 Feb 2009 09:49:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.454
X-Spam-Level: 
X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVbNw4Y19BOY for <[e-mail]>; Mon,  9 Feb 2009 09:49:12 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 13FC83A67D4 for <[e-mail]>; Mon,  9 Feb 2009 09:49:12 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="245927754"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Feb 2009 17:49:14 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n19HnEpF010906;  Mon, 9 Feb 2009 09:49:14 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19HnEQA018418; Mon, 9 Feb 2009 17:49:14 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 09:49:14 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 09:49:13 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 09 Feb 2009 11:49:12 -0600
To: "Hannes Tschofenig" <[e-mail]>, "'DOLLY, MARTIN C, ATTLABS'" <[e-mail]>, <[e-mail]>, <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <005101c98a1d$686ba6e0$[e-mail]>
References: <[e-mail]> <005101c98a1d$686ba6e0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 09 Feb 2009 17:49:13.0916 (UTC) FILETIME=[B87A37C0:01C98ADE]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8762; t=1234201754; x=1235065754; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20Semantics=20=20Re=3A=20=20RPH |Sender:=20; bh=TFWg91MI53N5sLIQ9GhbubctIQJZRyS8h+hcN74TOcg=; b=lv63tKoIg7Q1ftTyMpSpk3ZEU7IqQrbTRl92e9yAQkF6rYFfNIpecNAehj DVguDOcjIR1chBHR0gcYTKP6r923PWJnVGn4YavySLbD/J18UVWB4xKfz0xa 34Aq80sNDB;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 17:49:13 -0000

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:[e-mail]]
> >Sent: 08 February, 2009 16:02
> >To: [e-mail]; [e-mail]; [e-mail]
> >Cc: [e-mail]
> >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 <[e-mail]>
> >To: DOLLY, MARTIN C, ATTLABS; [e-mail]
> ><[e-mail]>; [e-mail] <[e-mail]>
> >Cc: [e-mail] <[e-mail]>
> >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 <[e-mail]>
> >>To: DOLLY, MARTIN C, ATTLABS; [e-mail]
> >><[e-mail]>; [e-mail] <[e-mail]>
> >>Cc: [e-mail] <[e-mail]>
> >>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: [e-mail] [mailto:[e-mail]]
> >>On Behalf
> >>>Of DOLLY, MARTIN C, ATTLABS
> >>>Sent: 07 February, 2009 19:30
> >>>To: [e-mail]; [e-mail]
> >>>Cc: [e-mail]; [e-mail]
> >>>Subject: Re: [Ecrit] Semantics Re: RPH
> >>>
> >>>Do you have a clue dude? A+A of an user comes in many forms.
> >>>
> >>>----- Original Message -----
> >>>From: [e-mail] <[e-mail]>
> >>>To: Janet P Gunn <[e-mail]>
> >>>Cc: ECRIT <[e-mail]>; [e-mail]
> >>><[e-mail]>
> >>>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:
> >>>
> >>>>
> >>>>
> >>>> .
> >>>>
> >>>> [e-mail] 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
> >>>[e-mail]
> >>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>_______________________________________________
> >>>Ecrit mailing list
> >>>[e-mail]
> >>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>
> >>
> >>
> >
> >
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31923A6A91 for <[e-mail]>; Mon,  9 Feb 2009 09:52:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.457
X-Spam-Level: 
X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSx2UGDOUlVS for <[e-mail]>; Mon,  9 Feb 2009 09:52:06 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 694823A6911 for <[e-mail]>; Mon,  9 Feb 2009 09:52:06 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="139842294"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2009 17:52:08 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n19Hq5AE014850;  Mon, 9 Feb 2009 09:52:05 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19Hq5EV022076; Mon, 9 Feb 2009 17:52:05 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 09:52:05 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 09:52:04 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 09 Feb 2009 11:52:03 -0600
To: "Hannes Tschofenig" <[e-mail]>, "'Janet P Gunn'" <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <007901c98a88$e0c2add0$[e-mail]>
References: <005101c98a1d$686ba6e0$[e-mail]> <[e-mail]> <007901c98a88$e0c2add0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 09 Feb 2009 17:52:04.0760 (UTC) FILETIME=[1E4EF180:01C98ADF]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11832; t=1234201928; x=1235065928; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20Semantics=20=20Re=3A=20=20RPH |Sender:=20; bh=o2qKbQ+ki0o2rv7LzKN/f/nsUfI3irYVw8I3QCuSFjQ=; b=WFhf8AbdBItJ+p9Fj9Rx0Dlt/07inf1zOFKhGkkJF9jQHrvqcXoDJ6dq6B A2E+0Fo4UpiZ1cIviDdsySXWnYFke4jggtXRB1slxxemz3h733Bj0wWusSE9 Rp4BzkND6v/mxGSpDRZMwaaEf0W2bxi5gBDMx6ifPIiVl90umt3jQ=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Cc: [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 17:52:08 -0000

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:[e-mail]]
>         Sent: 08 February, 2009 22:13
>         To: Hannes Tschofenig
>         Cc: [e-mail]; [e-mail]; 'DOLLY, MARTIN C, ATTLABS'
>         Subject: RE: [Ecrit] Semantics Re: RPH
>
>
>
>
>
>         Up to local policy.
>
>         Janet
>
>         "Hannes Tschofenig" <[e-mail]> 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:[e-mail]]
>         > >Sent: 08 February, 2009 16:02
>         > >To: [e-mail]; [e-mail];
>[e-mail]
>         > >Cc: [e-mail]
>         > >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 <[e-mail]>
>         > >To: DOLLY, MARTIN C, ATTLABS; [e-mail]
>         > ><[e-mail]>; [e-mail] <[e-mail]>
>         > >Cc: [e-mail] <[e-mail]>
>         > >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 <[e-mail]>
>         > >>To: DOLLY, MARTIN C, ATTLABS; [e-mail]
>         > >><[e-mail]>; [e-mail] <[e-mail]>
>         > >>Cc: [e-mail] <[e-mail]>
>         > >>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: [e-mail] [mailto:[e-mail]]
>         > >>On Behalf
>         > >>>Of DOLLY, MARTIN C, ATTLABS
>         > >>>Sent: 07 February, 2009 19:30
>         > >>>To: [e-mail]; [e-mail]
>         > >>>Cc: [e-mail]; [e-mail]
>         > >>>Subject: Re: [Ecrit] Semantics Re: RPH
>         > >>>
>         > >>>Do you have a clue dude? A+A of an user comes in many forms.
>         > >>>
>         > >>>----- Original Message -----
>         > >>>From: [e-mail] <[e-mail]>
>         > >>>To: Janet P Gunn <[e-mail]>
>         > >>>Cc: ECRIT <[e-mail]>; [e-mail]
>         > >>><[e-mail]>
>         > >>>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:
>         > >>>
>         > >>>>
>         > >>>>
>         > >>>> .
>         > >>>>
>         > >>>> [e-mail] 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
>         > >>>[e-mail]
>         > >>>https://www.ietf.org/mailman/listinfo/ecrit
>         > >>>_______________________________________________
>         > >>>Ecrit mailing list
>         > >>>[e-mail]
>         > >>>https://www.ietf.org/mailman/listinfo/ecrit
>         > >>>
>         > >>
>         > >>
>         > >
>         > >
>         >
>
>
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA503A6911 for <[e-mail]>; Mon,  9 Feb 2009 09:55:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level: 
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psIQI5o33lGa for <[e-mail]>; Mon,  9 Feb 2009 09:55:12 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C19EC3A6866 for <[e-mail]>; Mon,  9 Feb 2009 09:55:11 -0800 (PST)
Received: (qmail invoked by alias); 09 Feb 2009 17:48:19 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp069) with SMTP; 09 Feb 2009 18:48:19 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18Qymcx3n0QJruL51iBtbh31CpxCDrSBKjSbn6zbG jK16H4mX/Npe/x
From: "Hannes Tschofenig" <[e-mail]>
To: "'James M. Polk'" <[e-mail]>, "'Janet P Gunn'" <[e-mail]>
References: <007201c988fc$2aab5f20$[e-mail]> <[e-mail]> <004801c989d2$65eb0b90$[e-mail]> <[e-mail]>
Date: Mon, 9 Feb 2009 19:48:56 +0200
Message-ID: <01c801c98ade$b59cba50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <[e-mail]>
Thread-Index: AcmK2sY6eEDu4BOuTyKjI3BYqucowAAAnQFA
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.6899999999999999
Cc: 'ECRIT' <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 17:55:12 -0000

>>[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. 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 186583A6AFE for <[e-mail]>; Mon,  9 Feb 2009 10:06:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.46
X-Spam-Level: 
X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrspBzps0egc for <[e-mail]>; Mon,  9 Feb 2009 10:06:14 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 12A4F3A6AF7 for <[e-mail]>; Mon,  9 Feb 2009 10:06:14 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="130075792"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 Feb 2009 18:06:16 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n19I6Ggk018479;  Mon, 9 Feb 2009 10:06:16 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n19I6Glb022510; Mon, 9 Feb 2009 18:06:16 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 10:06:16 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 10:06:15 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 09 Feb 2009 12:06:14 -0600
To: Ted Hardie <[e-mail]>, Hannes Tschofenig <[e-mail]>, "'DOLLY, MARTIN C,  ATTLABS'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <p06240801c5b60fcc7136@[10.227.68.59]>
References: <[e-mail]> <000101c988ad$8ac92e90$[e-mail]> <[e-mail]> <p06240801c5b60fcc7136@[10.227.68.59]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 09 Feb 2009 18:06:15.0900 (UTC) FILETIME=[19A099C0:01C98AE1]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3631; t=1234202776; x=1235066776; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=IJbhf16k1R59lr7mmZBt6qH3ucBS3Su1cxsBiELPc1o=; b=XzniXQ3EVrWfIa9Oppp3ZeM9xjDG+5i0yN6Iud3gPPShwqoRuGxD70YRwo LThYV9OKUbJ28pmj7tbns8eDswDveKj9WryiTMVmBJ8wUxVD2UfNWgHdrT3h fxtkMGa1Nkp+Onloy2ASgGMtpdej5wfaGmnvGjcI2t4X04H0aGKWw=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 18:06:15 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD68F28C12D for <[e-mail]>; Mon,  9 Feb 2009 10:07:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.353
X-Spam-Level: 
X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqkNGqhhPQcK for <[e-mail]>; Mon,  9 Feb 2009 10:07:25 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E22943A6B8D for <[e-mail]>; Mon,  9 Feb 2009 10:07:23 -0800 (PST)
Received: (qmail invoked by alias); 09 Feb 2009 18:07:24 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp007) with SMTP; 09 Feb 2009 19:07:24 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19x2Lwwa4Nx2Mugg3lT2jWbtrEQss3uOO6x32h5Yu vqXdWhE0QHWfzD
From: "Hannes Tschofenig" <[e-mail]>
To: "'James M. Polk'" <[e-mail]>, "'DOLLY, MARTIN C, ATTLABS'" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]> <004901c989ef$302749c0$[e-mail]> <[e-mail]>
Date: Mon, 9 Feb 2009 20:08:01 +0200
Message-ID: <01cc01c98ae1$60518640$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <[e-mail]>
Thread-Index: AcmK3Z6YOPNg9SbnQSOK+npHcOJXcQAAQ/3Q
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.51
Cc: [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 18:07:26 -0000

>>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 <[e-mail]>
>> >To: DOLLY, MARTIN C, ATTLABS; [e-mail] 
>> ><[e-mail]>; [e-mail] <[e-mail]>
>> >Cc: [e-mail] <[e-mail]>
>> >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: [e-mail] [mailto:[e-mail]]
>> >On Behalf
>> >>Of DOLLY, MARTIN C, ATTLABS
>> >>Sent: 07 February, 2009 19:30
>> >>To: [e-mail]; [e-mail]
>> >>Cc: [e-mail]; [e-mail]
>> >>Subject: Re: [Ecrit] Semantics Re: RPH
>> >>
>> >>Do you have a clue dude? A+A of an user comes in many forms.
>> >>
>> >>----- Original Message -----
>> >>From: [e-mail] <[e-mail]>
>> >>To: Janet P Gunn <[e-mail]>
>> >>Cc: ECRIT <[e-mail]>; [e-mail] 
>> >><[e-mail]>
>> >>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:
>> >>
>> >>>
>> >>>
>> >>> .
>> >>>
>> >>> [e-mail] 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
>> >>[e-mail]
>> >>https://www.ietf.org/mailman/listinfo/ecrit
>> >>_______________________________________________
>> >>Ecrit mailing list
>> >>[e-mail]
>> >>https://www.ietf.org/mailman/listinfo/ecrit
>> >>
>> >
>> >
>>
>>_______________________________________________
>>Ecrit mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ecrit
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1B728C120 for <[e-mail]>; Mon,  9 Feb 2009 10:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.463
X-Spam-Level: 
X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq3ufPXWMFG5 for <[e-mail]>; Mon,  9 Feb 2009 10:17:53 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7E12D28C118 for <[e-mail]>; Mon,  9 Feb 2009 10:17:53 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="139855487"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2009 18:17:56 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n19IHuZ0014804;  Mon, 9 Feb 2009 10:17:56 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19IHtpN027286; Mon, 9 Feb 2009 18:17:55 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 10:17:55 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 10:17:55 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 09 Feb 2009 12:17:51 -0600
To: "Hannes Tschofenig" <[e-mail]>, "'Ted Hardie'" <[e-mail]>, "'DOLLY, MARTIN C, ATTLABS'" <[e-mail]>, <[e-mail]>,  <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <01c701c98add$00aea1e0$[e-mail]>
References: <[e-mail]> <000101c988ad$8ac92e90$[e-mail]> <[e-mail]> <p06240801c5b60fcc7136@[10.227.68.59]> <01c701c98add$00aea1e0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 09 Feb 2009 18:17:55.0322 (UTC) FILETIME=[BA83EDA0:01C98AE2]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3627; t=1234203476; x=1235067476; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20RE=3A=20[Ecrit]=20RPH |Sender:=20; bh=67axeFuLWoZePi2If6y4FnyIvxcFEtJMxZ6gf2DxvLM=; b=avnH1WhViOV86+AZ0Fb8sgzwIKhZooyKBpto6vUrJntcZUGATtYBqlABsb 03OdjM2PRoBD+/XSAE4HprTdDSAQT5f8OlRaPBKbuLWFlQOX6D7+Ak6+E5d+ I7bRq9ayYb;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 18:17:54 -0000

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:[e-mail]]
> >Sent: 09 February, 2009 19:04
> >To: James M. Polk; Hannes Tschofenig; 'DOLLY, MARTIN C,
> >ATTLABS'; [e-mail]; [e-mail]
> >Cc: Tschofenig, Hannes (NSN - FI/Espoo); [e-mail]
> >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
> >



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1D93A6866 for <[e-mail]>; Mon,  9 Feb 2009 10:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.102
X-Spam-Level: 
X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[AWL=0.147,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6gZojJE4gn7 for <[e-mail]>; Mon,  9 Feb 2009 10:23:38 -0800 (PST)
Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id C69A83A67D4 for <[e-mail]>; Mon,  9 Feb 2009 10:23:37 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n19INNc7012348 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Feb 2009 19:23:23 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 9 Feb 2009 19:23:23 +0100
From: "DRAGE, Keith (Keith)" <[e-mail]>
To: "James M. Polk" <[e-mail]>, Hannes Tschofenig <[e-mail]>, "'DOLLY, MARTIN C, ATTLABS'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Mon, 9 Feb 2009 19:23:21 +0100
Thread-Topic: [Ecrit] Semantics  Re:  RPH
Thread-Index: AcmK3bIJkLXqXXkBSoijeFuxWxTttgABcVTA
Message-ID: <[e-mail]>
References: <[e-mail]> <004901c989ef$302749c0$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 18:23:39 -0000

Concur with James.

Keith=20

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]=20
> On Behalf Of James M. Polk
> Sent: Monday, February 09, 2009 5:41 PM
> To: Hannes Tschofenig; 'DOLLY, MARTIN C, ATTLABS';=20
> [e-mail]; [e-mail]
> Cc: [e-mail]
> 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 <[e-mail]>
> > >To: DOLLY, MARTIN C, ATTLABS; [e-mail]=20
> > ><[e-mail]>; [e-mail] <[e-mail]>
> > >Cc: [e-mail] <[e-mail]>
> > >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: [e-mail] [mailto:[e-mail]]
> > >On Behalf
> > >>Of DOLLY, MARTIN C, ATTLABS
> > >>Sent: 07 February, 2009 19:30
> > >>To: [e-mail]; [e-mail]
> > >>Cc: [e-mail]; [e-mail]
> > >>Subject: Re: [Ecrit] Semantics Re: RPH
> > >>
> > >>Do you have a clue dude? A+A of an user comes in many forms.
> > >>
> > >>----- Original Message -----
> > >>From: [e-mail] <[e-mail]>
> > >>To: Janet P Gunn <[e-mail]>
> > >>Cc: ECRIT <[e-mail]>; [e-mail]=20
> > >><[e-mail]>
> > >>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:
> > >>
> > >>>
> > >>>
> > >>> .
> > >>>
> > >>> [e-mail] 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
> > >>[e-mail]
> > >>https://www.ietf.org/mailman/listinfo/ecrit
> > >>_______________________________________________
> > >>Ecrit mailing list
> > >>[e-mail]
> > >>https://www.ietf.org/mailman/listinfo/ecrit
> > >>
> > >
> > >
> >
> >_______________________________________________
> >Ecrit mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ecrit
>=20
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
> =


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043D328C140 for <[e-mail]>; Mon,  9 Feb 2009 10:28:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.656
X-Spam-Level: 
X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1LbJw65rtB7 for <[e-mail]>; Mon,  9 Feb 2009 10:28:46 -0800 (PST)
Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 0FBEB28C121 for <[e-mail]>; Mon,  9 Feb 2009 10:28:45 -0800 (PST)
Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n19ISQs0001981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Feb 2009 13:28:26 -0500 (EST)
Message-Id: <[e-mail]>
From: Henning Schulzrinne <[e-mail]>
To: "James M. Polk" <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Mon, 9 Feb 2009 13:28:26 -0500
References: <[e-mail]> <000101c988ad$8ac92e90$[e-mail]> <[e-mail]> <p06240801c5b60fcc7136@[10.227.68.59]> <01c701c98add$00aea1e0$[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5
Cc: ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 18:28:47 -0000

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.
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13CD3A6B58 for <[e-mail]>; Mon,  9 Feb 2009 10:31:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level: 
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RADPUdbSRaJG for <[e-mail]>; Mon,  9 Feb 2009 10:31:35 -0800 (PST)
Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id D21E03A6AF4 for <[e-mail]>; Mon,  9 Feb 2009 10:31:34 -0800 (PST)
Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n19IVaXK002865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Feb 2009 13:31:36 -0500 (EST)
Message-Id: <[e-mail]>
From: Henning Schulzrinne <[e-mail]>
To: Ted Hardie <[e-mail]>
In-Reply-To: <p06240801c5b60fcc7136@[10.227.68.59]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Mon, 9 Feb 2009 13:31:36 -0500
References: <[e-mail]> <000101c988ad$8ac92e90$[e-mail]> <[e-mail]> <p06240801c5b60fcc7136@[10.227.68.59]>
X-Mailer: Apple Mail (2.930.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5
Cc: ECRIT <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 18:31:35 -0000

>

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
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDE493A699F; Mon,  9 Feb 2009 10:36:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.466
X-Spam-Level: 
X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwB1fTxfBFZY; Mon,  9 Feb 2009 10:36:27 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D4A0E3A68B1; Mon,  9 Feb 2009 10:36:27 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="139863670"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2009 18:36:30 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n19IaUKw022023;  Mon, 9 Feb 2009 10:36:30 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n19IaU4I027243; Mon, 9 Feb 2009 18:36:30 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 10:36:30 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 10:36:29 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 09 Feb 2009 12:36:28 -0600
To: "Hannes Tschofenig" <[e-mail]>, "'Janet P Gunn'" <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <01c801c98ade$b59cba50$[e-mail]>
References: <007201c988fc$2aab5f20$[e-mail]> <[e-mail]> <004801c989d2$65eb0b90$[e-mail]> <[e-mail]> <01c801c98ade$b59cba50$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 09 Feb 2009 18:36:29.0806 (UTC) FILETIME=[52CCB0E0:01C98AE5]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3360; t=1234204590; x=1235068590; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20RE=3A=20Semantics=20=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=m3+zZLoVJpIJYbzjGOJ87h7Mkzbjxd+skfK7P0sBWWc=; b=aImiesPZPmXlQgdYo2hgVoc1aEKhncBbMTQ4u+8zyIudm2ivLGytYMj37Z 1SS5jUeU4DCNjPYqkBZ5hBlWcfDev9IzY6i16/09YMnTWhwqSuNVgOV6V6nE fzXTrxj1Jqri6tHJCE/ZiCu/ex6KGJl2eG4F3m/gpBDeCZCsfnrLM=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Cc: 'ECRIT' <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 18:36:28 -0000

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.




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7705528C160 for <[e-mail]>; Mon,  9 Feb 2009 10:45:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.469
X-Spam-Level: 
X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP42T3GL1isZ for <[e-mail]>; Mon,  9 Feb 2009 10:45:50 -0800 (PST)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id EA40E28C144 for <[e-mail]>; Mon,  9 Feb 2009 10:45:50 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="133994010"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2009 18:45:53 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n19IjrwF023508;  Mon, 9 Feb 2009 10:45:53 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19IjrVX001427; Mon, 9 Feb 2009 18:45:53 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 10:45:53 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 10:45:52 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 09 Feb 2009 12:45:51 -0600
To: "Hannes Tschofenig" <[e-mail]>, "'DOLLY, MARTIN C, ATTLABS'" <[e-mail]>, <[e-mail]>, <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <01cc01c98ae1$60518640$[e-mail]>
References: <[e-mail]> <004901c989ef$302749c0$[e-mail]> <[e-mail]> <01cc01c98ae1$60518640$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 09 Feb 2009 18:45:52.0525 (UTC) FILETIME=[A234CBD0:01C98AE6]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12607; t=1234205153; x=1235069153; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20RE=3A=20[Ecrit]=20Semantics=20=20Re=3A=20=20RPH |Sender:=20; bh=3dBsvPh/oqmH3BAd4fkCv7Gt6YpTKBINNUw0z5w4HVI=; b=XCKT4OrmKV0KM2fAXdEIdaskCuH32xOJ2DSxXT8wOaXVQmQW/ICpSmyFzg Id1sEFFH+4tsYRis6nHvRNdcSbrfwPj6u7IUY2ZgEnah/gGzu1G1S68ITqUs m80Nq5p5Gr;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
Cc: [e-mail]
Subject: Re: [Ecrit] Semantics  Re:  RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 18:45:52 -0000

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 <[e-mail]>
> >> >To: DOLLY, MARTIN C, ATTLABS; [e-mail]
> >> ><[e-mail]>; [e-mail] <[e-mail]>
> >> >Cc: [e-mail] <[e-mail]>
> >> >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: [e-mail] [mailto:[e-mail]]
> >> >On Behalf
> >> >>Of DOLLY, MARTIN C, ATTLABS
> >> >>Sent: 07 February, 2009 19:30
> >> >>To: [e-mail]; [e-mail]
> >> >>Cc: [e-mail]; [e-mail]
> >> >>Subject: Re: [Ecrit] Semantics Re: RPH
> >> >>
> >> >>Do you have a clue dude? A+A of an user comes in many forms.
> >> >>
> >> >>----- Original Message -----
> >> >>From: [e-mail] <[e-mail]>
> >> >>To: Janet P Gunn <[e-mail]>
> >> >>Cc: ECRIT <[e-mail]>; [e-mail]
> >> >><[e-mail]>
> >> >>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:
> >> >>
> >> >>>
> >> >>>
> >> >>> .
> >> >>>
> >> >>> [e-mail] 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
> >> >>[e-mail]
> >> >>https://www.ietf.org/mailman/listinfo/ecrit
> >> >>_______________________________________________
> >> >>Ecrit mailing list
> >> >>[e-mail]
> >> >>https://www.ietf.org/mailman/listinfo/ecrit
> >> >>
> >> >
> >> >
> >>
> >>_______________________________________________
> >>Ecrit mailing list
> >>[e-mail]
> >>https://www.ietf.org/mailman/listinfo/ecrit
> >



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D82233A6B82 for <[e-mail]>; Mon,  9 Feb 2009 11:06:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73LP7ayAGbTH for <[e-mail]>; Mon,  9 Feb 2009 11:06:39 -0800 (PST)
Received: from mail64.messagelabs.com (mail64.messagelabs.com [216.82.249.227]) by core3.amsl.com (Postfix) with ESMTP id 14C8B3A6A0A for <[e-mail]>; Mon,  9 Feb 2009 11:06:39 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-8.tower-64.messagelabs.com!1234206397!100047261!2
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [20.137.2.87]
Received: (qmail 14145 invoked from network); 9 Feb 2009 19:06:39 -0000
Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-8.tower-64.messagelabs.com with AES256-SHA encrypted SMTP; 9 Feb 2009 19:06:39 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n19J6bWC015266 for <[e-mail]>; Mon, 9 Feb 2009 14:06:39 -0500
To: "James M. Polk" <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Anthony D Pike <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 9 Feb 2009 14:06:37 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/09/2009 02:08:59 PM, Serialize complete at 02/09/2009 02:08:59 PM
Content-Type: multipart/alternative; boundary="=_alternative 0068981485257558_="
Cc: "[e-mail]" <[e-mail]>
Subject: [Ecrit] RPH Priority order for ESNET observation against Priority of other namespaces defined in RFC 4412
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 19:06:39 -0000

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_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418553A6BBE for <[e-mail]>; Mon,  9 Feb 2009 11:13:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.471
X-Spam-Level: 
X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQYEt1Ec-HhB for <[e-mail]>; Mon,  9 Feb 2009 11:13:29 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 380153A6A8F for <[e-mail]>; Mon,  9 Feb 2009 11:13:29 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="139887344"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2009 19:13:31 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n19JDVLv031449;  Mon, 9 Feb 2009 11:13:31 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19JDVo5006204; Mon, 9 Feb 2009 19:13:31 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 11:13:31 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 11:13:31 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 09 Feb 2009 13:13:29 -0600
To: Henning Schulzrinne <[e-mail]>, Ted Hardie <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <000101c988ad$8ac92e90$[e-mail]> <[e-mail]> <p06240801c5b60fcc7136@[10.227.68.59]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 09 Feb 2009 19:13:31.0072 (UTC) FILETIME=[7EC6FC00:01C98AEA]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2721; t=1234206811; x=1235070811; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20RPH=20=22esnet=22=20in=20the=203=20areas=20of=2 0the=20network |Sender:=20; bh=HJBLkZROSEXcutPNnujwm5Verrq7ivkhQc3Qpo4ll/4=; b=G72tQwtKDCNk2LF2pSJna3zw8MLcINhGJW2D1srnwazTH/w/8gcVODDSr0 6boEHXH4qwvYCsSHuF6GefdnUqskmZ+QP1iQpBSKtvAdWWxkMJ1GwEICkiMX 75ST5FY3m0;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Cc: ECRIT <[e-mail]>
Subject: [Ecrit] RPH "esnet" in the 3 areas of the network
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 19:13:30 -0000

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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E7F28C15B for <[e-mail]>; Mon,  9 Feb 2009 11:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.474
X-Spam-Level: 
X-Spam-Status: No, score=-7.474 tagged_above=-999 required=5 tests=[AWL=1.125,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwOnVpJSN45h for <[e-mail]>; Mon,  9 Feb 2009 11:30:47 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 308B83A69A8 for <[e-mail]>; Mon,  9 Feb 2009 11:30:47 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="245997154"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 Feb 2009 19:29:52 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n19JTqkH001943;  Mon, 9 Feb 2009 11:29:52 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n19JTqlP027615; Mon, 9 Feb 2009 19:29:52 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 11:29:52 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 9 Feb 2009 11:29:51 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 09 Feb 2009 13:29:50 -0600
To: Anthony D Pike <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <OF8A807834.2C1D33BB-ON85257558.0066F54C-85257558.0068FAE3@ csc.com>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 09 Feb 2009 19:29:51.0572 (UTC) FILETIME=[C7336940:01C98AEC]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3313; t=1234207792; x=1235071792; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Re=3A=20RPH=20Priority=20order=20for=20ESNET=20 observation=20against=20Priority=0A=20=20of=20other=20namesp aces=20defined=20in=20RFC=204412 |Sender:=20; bh=1CeTO0AmXfiJ2q1AD4divX6i8vjBaLTVS07v/PcPhug=; b=a3mUNpVb7BSi2M3FQuCz5XGemN9i5kmaf6NsD5tfrfLV7va+du8NSZXgua UibJKmGzI7OkhgqsQWh4Y5w8iYNWbqykWociE6+csvI1Im9/3LpvMX6jD/9D UWPme/qwfe;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Ecrit] RPH Priority order for ESNET observation against Priority of other namespaces defined in RFC 4412
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 19:30:48 -0000

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.



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54A303A6B78 for <[e-mail]>; Mon,  9 Feb 2009 11:56:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.598
X-Spam-Level: 
X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[AWL=1.000,  BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aghJ3B9Tc76G for <[e-mail]>; Mon,  9 Feb 2009 11:56:52 -0800 (PST)
Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id E88CE3A69A7 for <[e-mail]>; Mon,  9 Feb 2009 11:56:51 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-2.tower-164.messagelabs.com!1234209410!14988589!2
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [20.137.2.87]
Received: (qmail 2010 invoked from network); 9 Feb 2009 19:56:52 -0000
Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-2.tower-164.messagelabs.com with AES256-SHA encrypted SMTP; 9 Feb 2009 19:56:52 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n19Juni5032276 for <[e-mail]>; Mon, 9 Feb 2009 14:56:51 -0500
In-Reply-To: <[e-mail]>
To: "James M. Polk" <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Anthony D Pike <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 9 Feb 2009 14:56:48 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/09/2009 02:59:12 PM, Serialize complete at 02/09/2009 02:59:12 PM
Content-Type: multipart/alternative; boundary="=_alternative 006D1F9085257558_="
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Ecrit] RPH Priority order for ESNET observation against Priority of other namespaces defined in RFC 4412
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 19:56:53 -0000

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" <[e-mail]> 
02/09/2009 02:29 PM

To
Anthony D Pike/ESI/CSC@CSC
cc
"[e-mail]" <[e-mail]>
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;[e-mail]&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;[e-mail]&quot; &lt;[e-mail]&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_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4D03A6BDE for <[e-mail]>; Mon,  9 Feb 2009 14:03:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.211
X-Spam-Level: 
X-Spam-Status: No, score=-103.211 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLoP8e6Wvode for <[e-mail]>; Mon,  9 Feb 2009 14:03:44 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id DCF283A6830 for <[e-mail]>; Mon,  9 Feb 2009 14:03:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[e-mail]; q=dns/txt; s=qcdkim; t=1234217026; x=1265753026; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20<p0624080fc5b65643d845 @[10.227.68.59]>|In-Reply-To:=20<XFE-SJC-211CWqolU9C00000 [e-mail]>|References:=20<14C85D6CCB [e-mail] m>=0D=0A=20<000101c988ad$8ac92e90$[e-mail]> =0D=0A=20<[e-mail] sco.com>=0D=0A=20<p06240801c5b60fcc7136@[10.227.68.59]> =0D=0A=20<[e-mail] sco.com>|Date:=20Mon,=209=20Feb=202009=2014:03:27=20-0800 |To:=20"James=20M.=20Polk"=20<[e-mail]>,=0D=0A=20 =20=20=20=20=20=20=20Hannes=20Tschofenig=0D=0A=09<Hannes. [e-mail]>,=0D=0A=20=20=20=20=20=20=20=20"'DOLLY ,=20MARTIN=20C,=20=20ATTLABS'"=20<[e-mail]>,=0D=0A =20=20=20=20=20=20=20=20"[e-mail]"=20<hgs@cs.c olumbia.edu>,=0D=0A=20=20=20=20=20=20=20=20"James.Winterb [e-mail]"=0D=0A=09<[e-mail]> |From:=20Ted=20Hardie=20<[e-mail]>|Subject:=20 Re:=20[Ecrit]=20RPH|CC:=20"Tschofenig,=20Hannes=20(NSN=20 -=20FI/Espoo)"=20<[e-mail]>,=0D=0A=20=20 =20=20=20=20=20=20"[e-mail]"=20<[e-mail]> |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5521"=3B=20a =3D"15340323"; bh=QjSfmX31oHl41TUNNlLdi63PkPNQuqKK/lUsOuPmN28=; b=oGLMA6WVvhF3FRRD/8y2sN5lCL7aerKRPAxFGcIYxXSPmjX7PRbZ0yyw hwtwzIUzw1ln7FSqvTbRjPoBVdvp87H07+0Tf1LVQ7iOzBZWnG63KLm6c X9S1xiYVWytVgtNxOxfupW6nhEEGE9FB1COyjOK44a5pQOit6QWHvQL29 E=;
X-IronPort-AV: E=McAfee;i="5100,188,5521"; a="15340323"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2009 14:03:33 -0800
Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n19M3XZD028471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Feb 2009 14:03:33 -0800
Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n19M3UVx028424 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Feb 2009 14:03:30 -0800
Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 9 Feb 2009 14:03:29 -0800
Received: from [10.227.68.59] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 9 Feb 2009 14:03:29 -0800
MIME-Version: 1.0
Message-ID: <p0624080fc5b65643d845@[10.227.68.59]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <000101c988ad$8ac92e90$[e-mail]> <[e-mail]> <p06240801c5b60fcc7136@[10.227.68.59]> <[e-mail]>
Date: Mon, 9 Feb 2009 14:03:27 -0800
To: "James M. Polk" <[e-mail]>, Hannes Tschofenig <[e-mail]>, "'DOLLY, MARTIN C,  ATTLABS'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
From: Ted Hardie <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 22:03:45 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD303A689E for <[e-mail]>; Mon,  9 Feb 2009 19:12:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.386
X-Spam-Level: 
X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cessWhbHusgu for <[e-mail]>; Mon,  9 Feb 2009 19:12:42 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 4BAC53A6875 for <[e-mail]>; Mon,  9 Feb 2009 19:12:41 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2009_02_09_21_31_58
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 09 Feb 2009 21:31:57 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 21:12:43 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Mon, 9 Feb 2009 21:12:40 -0600
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwDpN2/QAAVj3AA=
From: "Thomson, Martin" <[e-mail]>
To: "Edge, Stephen" <[e-mail]>
X-OriginalArrivalTime: 10 Feb 2009 03:12:43.0057 (UTC) FILETIME=[704BBA10:01C98B2D]
Cc: ECRIT <[e-mail]>
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 10 Feb 2009 03:12:44 -0000

SGkgU3RlcGhlbiwNCg0KSSBiZWxpZXZlIHRoYXQgeW91ciBhbmFseXNpcyBpcyBpbiBwYXJ0IGNv
cnJlY3QgYW5kIGluIHBhcnQgYmFzZWQgb24gc29tZSBtaXNjb25jZXB0aW9ucyBhYm91dCB3aGF0
IEVDUklUIGlzIG9yIHNob3VsZCBiZSBkb2luZy4gIFdoZXRoZXIgb3Igbm90IHRoaXMgaXMgYW4g
aXNzdWUgZm9yIHNvbWVvbmUgZGVwbG95aW5nIDNHUFAgbmV0d29ya3MgaXMgZW50aXJlbHkgYSBz
ZXBhcmF0ZSBjb25zaWRlcmF0aW9uLg0KDQpFQ1JJVCBpcyB3b3JraW5nIHVuZGVyIGEgZGlmZmVy
ZW50IHNldCBvZiBjb25zdHJhaW50cyB0aGFuIHRob3NlIHRoYXQgc2hhcGVkIHRoZSBleGlzdGlu
ZyAzR1BQIGVtZXJnZW5jeSBhcmNoaXRlY3R1cmUuICBJdCBpcyBub3QgdGhlIHN0YXRlZCBidXNp
bmVzcyBvZiBJRVRGIHRvIGRldmVsb3Agc29sdXRpb25zIGZvciBwcm9wcmlldGFyeSBuZXR3b3Jr
IGFjY2Vzcy4gIEVDUklUIGhhcyBkZXZlbG9wZWQgYW4gZ2VuZXJhbCBhcmNoaXRlY3R1cmUgdGhh
dCB3b3JrcyBmb3IgYW55IEludGVybmV0IGRldmljZS4NCg0KVGhlIHByb2JsZW0gZm9yIEVDUklU
IGlzIHRvIGVuc3VyZSBvcGVyYXRpb24gYWNyb3NzIGhldGVyb2dlbmVvdXMgYWNjZXNzLiAgSW4g
cGFydGljdWxhciwgdGhlIEVDUklUIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCBtYWtlIGFueSBhc3N1
bXB0aW9uIGFib3V0IGEgcmVsYXRpb25zaGlwIGJldHdlZW4gYWNjZXNzIHByb3ZpZGVyIGFuZCAo
dm9pY2UpIHNlcnZpY2UgcHJvdmlkZXItLWFuIGFzc3VtcHRpb24gdGhhdCBpcyBuZWl0aGVyIHZh
bGlkLCBub3IgbmVjZXNzYXJ5IHdoZW4gYSBnZW5lcmFsIHNvbHV0aW9uIGlzIGRldmVsb3BlZCBm
b3IgdGhlIEludGVybmV0LiAgT25lIGxpbWl0YXRpb24gb2YgM0dQUCBzb2x1dGlvbnMgaXMgdGhh
dCB0aGV5IGRvIG5vdCB3b3JrIGZvciBhbnkgSW50ZXJuZXQgZGV2aWNlIG9uIGFyYml0cmFyeSBh
Y2Nlc3MuDQoNCkl0IHdvdWxkIGJlIGRpc2luZ2VudW91cyB0byByZXByZXNlbnQgdGhlIEVDUklU
IGFyY2hpdGVjdHVyZSBhcyBpbmNvbXBhdGlibGUgd2l0aCAzR1BQIGFyY2hpdGVjdHVyZXMuICBD
b250cmFyeSB0byB3aGF0IHlvdXIgZW1haWwgaW1wbGllcywgdGhlIG1vZGVscyBkZXZlbG9wZWQg
Zm9yIEVDUklUIGNhbiBiZSBlcXVhbGx5IGFwcGxpZWQgdG8gYW55IEludGVybmV0IGFjY2Vzcy4g
IFdoYXQgSSBjYW4gc2VlIGlzIHJlYWwgY29uY2VybiBpcyB0aGUgZXh0ZW50IHRvIHdoaWNoIHRo
ZSAzR1BQIGVtZXJnZW5jeSBpbmZyYXN0cnVjdHVyZSBpbnRlZ3JhdGVzIGludG8gdGhlIG92ZXJh
bGwgYXJjaGl0ZWN0dXJlLg0KDQpJbiBmYWN0LCB0aGUgM0dQUCBhbmQgSU1TIGFyY2hpdGVjdHVy
ZSBjYW4gYmUgcmVjYXN0IHRvIGZpdCB0aGUgRUNSSVQgYXJjaGl0ZWN0dXJlIHdpdGhvdXQgdG9v
IG1hbnkgY29udG9ydGlvbnMuICBGb3IgaW5zdGFuY2UsIHRoZSBMUkYgZW5jb21wYXNzZXMgTElT
IGFuZCBMb1NUIHNlcnZlciByb2xlcywgYW5kIGNhbGwgcm91dGluZyBmdW5jdGlvbnMgYXNzaWdu
ZWQgdG8gYSBWU1AgaW4gRUNSSVQgY2FuIGJlIGFsbG9jYXRlZCB0byBhbnkgQ1NDRi4NCg0KT2Yg
Y291cnNlLCB0aGUgaW5jb21wYXRpYmlsaXR5IG9mIHRoZSB0d28gYXJjaGl0ZWN0dXJlcyBjYW4g
YmUgZGlzcmVnYXJkZWQgYXMgbG9uZyBhcyB5b3UgYXJlIHdpbGxpbmcgdG8gYWNjZXB0IHRoYXQg
ZGV2aWNlcyBhcmUgb25seSBhYmxlIHRvIG9wZXJhdGUgd2l0aGluIDNHUFAgYWNjZXNzIHdpdGgg
aW50ZWdyYXRlZCBJTVMvVm9JUCBzZXJ2aWNlLiAgVGhlIGFsdGVybmF0aXZlIG9mZmVyZWQgYnkg
RUNSSVQgZG9lcyBub3QgaGF2ZSB0aGlzIGxpbWl0YXRpb24gYmVjYXVzZSBpdCBpcyBkZXNpZ25l
ZCB0byBiZSB1bml2ZXJzYWxseSBhcHBsaWNhYmxlLg0KDQoNCllvdSBjb3ZlciBhIGxvdCBvZiBn
cm91bmQgaW4gdmVyeSBmZXcgd29yZHMsIEknbGwgYWRkcmVzcyBhIGZldyBvZiB5b3VyIGluZGl2
aWR1YWwgcG9pbnRzIGJlbG93Li4uDQoNCihBKSBUaGlzIGlzIGEgZmFpciBzdGF0ZW1lbnQsIGJ1
dCBJIGRvbid0IHRoaW5rIHRoYXQgeW91ciBjb25jbHVzaW9uLS10aGF0IHRoZSAzR1BQIHNvbHV0
aW9ucyBzaG91bGQgYmUgaWRlbnRpZmllZCBhcyB2YWxpZCBhbHRlcm5hdGl2ZXMtLWlzIG5lY2Vz
c2FyaWx5IGNvcnJlY3QuICBXaXRoaW4gcHJvcHJpZXRhcnkgYWNjZXNzLCBhIHByb3ByaWV0YXJ5
IHNvbHV0aW9uIGlzIGFsd2F5cyBhIHBvdGVudGlhbCBjaG9pY2UuICBXaXRoaW4gM0dQUCBhY2Nl
c3MsIGFsbCB0aGUgbmVjZXNzYXJ5IGNvbnN0cmFpbnRzIGNhbiBiZSBlbmZvcmNlZC4gIEludGVy
b3BlcmFiaWxpdHkgb24gdGhlIEludGVybmV0IGRlbWFuZHMgdGhhdCBhbnkgc29sdXRpb24gaW4g
dGhhdCBzcGFjZSBpcyB1bmlmb3JtLg0KDQpUbyBhc3N1bWUgdGhhdCBkZXZpY2VzIGF0dGFjaGVk
IHRvIHRoZSBpbnRlcm5ldCB0aHJvdWdoIGEgM0dQUCBuZXR3b3JrIGFyZSBuZWNlc3NhcmlseSBh
d2FyZSBvZiAzR1BQIGVtZXJnZW5jeSBwcm9jZWR1cmVzIGRvZXMgbm90IHJlY29nbmlzZSB0aGUg
ZnVsbCBkaXZlcnNpdHkgb2YgSW50ZXJuZXQtZW5hYmxlZCBkZXZpY2VzLiAgVU1UUyByYWRpbyBp
cyB3aWRlbHkgdXNlZCBmb3IgYnJvYWRiYW5kIGFjY2Vzcywgc28gaW1hZ2luZSBhIFdpRmkgcm91
dGVyIHdpdGggYSAzRyBjb25uZWN0aW9uLiAgRGV2aWNlcyBjb25uZWN0ZWQgdG8gdGhhdCByb3V0
ZXIgaGF2ZSBubyBtb3JlIG9mIGEgdmlldyBvZiB0aGUgM0cgbmV0d29yayB0aGFuIHRoZXkgd291
bGQgaGF2ZSBpZiB0aGUgcm91dGVyIHdlcmUgYSBEU0wgb25lLiAgQW4gRUNSSVQtY2FwYWJsZSBk
ZXZpY2UgaW4gdGhhdCBuZXR3b3JrIHdvdWxkIG5vdCBiZSBhYmxlIHRvIGJlIHVzZWQgaWYgdGhl
IDNHIG5ldHdvcmsgZGlkIG5vdCBzdXBwb3J0IEVDUklUIHByb2NlZHVyZXMuDQoNCkl0J3MgdXAg
dG8gdGhlIG5ldHdvcmsgb3BlcmF0b3IgdG8gZGVjaWRlIHdoZXRoZXIgdGhpcyBpcyBzb21ldGhp
bmcgdGhleSBhIGNvbmNlcm5lZCBhYm91dC4gIEl0J3MgY2VydGFpbmx5IG5vdCB0aGUgcmVzcG9u
c2liaWxpdHkgb2YgRUNSSVQgdG8gcG9pbnQgb3V0IGhvdyBhbiBvcGVyYXRvciBtaWdodCB1c2Ug
M0dQUCBJTVMgZW1lcmdlbmN5IHNlcnZpY2VzLS1vciBhbnkgb3RoZXIgc3RhbmRhcmQtLWNlcnRh
aW5seSBub3QgdG8gdGhlIGV4Y2x1c2lvbiBvZiBFQ1JJVCBjb21wYXRpYmlsaXR5Lg0KDQoNCkJl
Zm9yZSBhZGRyZXNzaW5nIChCKSBpdCdzIGNsZWFyIHRoYXQgeW91IGhhdmUgc29tZSBtaXNjb25j
ZXB0aW9ucyBhYm91dCB0aGUgRUNSSVQgYXJjaGl0ZWN0dXJlLiAgSSdsbCBhZGRyZXNzIHRob3Nl
IGZpcnN0LiAgRm9yIGluc3RhbmNlOg0KDQo+IChjKSB0aGUNCj4gcmVxdWlyZW1lbnQgdGhhdCBh
IHRlcm1pbmFsIG9yIGF0IGxlYXN0IGEgTElTIHdpbGwgdXBkYXRlIHRoZSBQU0FQDQo+IHdoZW5l
dmVyIGxvY2F0aW9uIGNoYW5nZXMuDQoNClRoZSBwcm9jZXNzIGJ5IHdoaWNoIGEgUFNBUCBhY3F1
aXJlcyBsb2NhdGlvbiBpcyBxdWl0ZSBmbGV4aWJsZS4gIFRoZSBhYm92ZSByZWZsZWN0cyBhbiBh
c3N1bXB0aW9uIHRpZWQgdG8gY29udmV5YW5jZSBvZiBsb2NhdGlvbiAiYnkgdmFsdWUiLiAgVXNl
IG9mIGxvY2F0aW9uICJieSByZWZlcmVuY2UiIChJJ2xsIHJlZmVyIHlvdSBkbyB0aGUgR0VPUFJJ
ViB3b3JrIG9uIHRoaXMgc3ViamVjdCksIHByb3ZpZGVzIGEgbWVhbnMgZm9yIGEgUFNBUCB0byBh
Y3F1aXJlIGxvY2F0aW9uIGF0IGl0cyBkaXNjcmV0aW9uLg0KDQpUaGlzIGxlYWRzIHlvdSB0byBp
bmZlciB0aGF0IGVuZHBvaW50LWRlcml2ZWQgbG9jYXRpb24gaXMgInVuc3VpdGFibGUgZm9yIHdp
cmVsZXNzIG5ldHdvcmtzIi4gIFdoaWxlIHRoZSBwb2ludCBpcyBkZWJhdGFibGUgb2YgaXRzZWxm
LCBsb2NhdGlvbiBieSByZWZlcmVuY2UgcHJvdmlkZXMgYSBtZWFucyBmb3Igd2lyZWxlc3MgbmV0
d29yayBvcGVyYXRvcnMgdG8gc2F2ZSB0aGUgZW5kcG9pbnQgZnJvbSBhbnkgY29zdHMgYXNzb2Np
YXRlZCB3aXRoIGRlcml2YXRpb24gb2YgbG9jYXRpb24uICBGdXJ0aGVybW9yZSwgYXMgSGFubmVz
IG5vdGVkLCBpZiAzR1BQIGFkb3B0ZWQgdGhpcyBhcmNoaXRlY3R1cmUsIHRoZSBQLUNTQ0YgY291
bGQgYmUgZGVsZWdhdGVkIHJlc3BvbnNpYmlsaXR5IGZvciB0aG9zZSBhc3BlY3RzIGFzc2lnbmVk
IHRvIHRoZSBlbmRwb2ludC4gIFRoaXMgaW5jbHVkZXMgZGVyaXZhdGlvbiBvZiBsb2NhdGlvbiBh
bmQgcm91dGUgZGV0ZXJtaW5hdGlvbi4gIEFnYWluLCBvZmZsb2FkIHRvIGFuIExSRiBhcyB5b3Ug
c2VlIGZpdC4NCg0KSG93ZXZlciwgaXQncyBpbXBvcnRhbnQgdG8gdW5kZXJzdGFuZCB0aGF0IHRo
aXMgbGluZSBvZiBhcmd1bWVudCBpcyBwcmVkaWNhdGVkIG9uIGFuIGFzc3VtcHRpb24gdGhhdCBh
Y2Nlc3MgYW5kIHNlcnZpY2UgYXJlIHByb3ZpZGVkIGJ5IHRoZSBzYW1lIGVudGl0eSwgb3IgdGhh
dCB0aGUgdHdvIGVudGl0aWVzIGhhdmUgYSBzdHJvbmcgcmVsYXRpb25zaGlwLiAgRUNSSVQgZG9l
c24ndCBoYXZlIHRoZSBsdXh1cnkgb2YgYmVpbmcgYWJsZSB0byBtYWtlIHRoaXMgYXNzdW1wdGlv
bjsgaWYgeW91IGRvLCB0aGVuIGFsdGVybmF0aXZlcyBsaWtlIDNHUFAgSU1TIG9wZW4gdXAuDQoN
Cj4gKGIpIHJlc3RyaWN0aW9uIG9mIExDUHMgdG8gcHJvdG9jb2xzDQo+IHRoYXQgcmVxdWlyZSB0
ZXJtaW5hbCBpbml0aWF0aW9uIChub3QgYWxsb3dpbmcgZm9yIG5ldHdvcmsgaW5pdGlhdGlvbg0K
PiBhcyBmYXIgYXMgd2UgY2FuIHRlbGwpDQoNClRoZSB2ZXJ5IGRlZmluaXRpb24gb2YgYW4gIkxD
UCIgaXMgYSBwcm90b2NvbCBmb3IgYSBkZXZpY2UgdG8gZ2V0IGl0cyBvd24gbG9jYXRpb24uICBX
aGF0IHlvdSBhcmUgdGFsa2luZyBhYm91dCBpcyBzb21ldGhpbmcgdGhhdCBHRU9QUklWIGFyZSB3
b3JraW5nIG9uLiAgZHJhZnQtd2ludGVyYm90dG9tLWdlb3ByaXYtaGVsZC1pZGVudGl0eS1leHRl
bnNpb25zIGFkZHMgdGhlIGlkZW50aWZpZXJzIG5lY2Vzc2FyeSB0byB0dXJuIGFuIExDUCBpbnRv
IHdoYXQgeW91IG1pZ2h0IHVzZSBmb3IgbmV0d29yayBpbml0aWF0aW9uLg0KDQpPbiB3aGF0IHlv
dSBjbGFpbSBpcyBtaXNzaW5nOg0KDQooQikoYSkoaSkgSSBjYW5ub3QgYWdyZWUgdGhhdCB0aGUg
bmV0d29yayBhbmQgdGVybWluYWwgbG9hZGluZyBjb25zZXF1ZW5jZXMgYXJlIGFzIGRpcmUgYXMg
aW1wbGllZC4gIE9uIHRoZSBjb250cmFyeSwgSSBiZWxpZXZlIHRoZSBFQ1JJVCBhcmNoaXRlY3R1
cmUgaXMgaW5oZXJlbnRseSBtb3JlIHNjYWxhYmxlLiAgQnV0IHdpdGhvdXQgZXZpZGVuY2UgZWl0
aGVyIHdheSwgdGhhdCBhcmd1bWVudCBpcyBwb2ludGxlc3MuICBMZXQgdXMgYWdyZWUgdG8gbm90
IG1ha2Ugc3VjaCBkZWZpbml0aXZlIHN0YXRlbWVudCBvbiB0aGVzZSBpc3N1ZXMgd2l0aG91dCBz
dWJzdGFudGlhdGlvbi4NCg0KKEIpKGEpKGlpKSBJZiB5b3UgYXJlIGNvbmNlcm5lZCBhYm91dCBu
b24tSVAgUFNBUHMsIGNvbnNpZGVyIHRoZSBORU5BIGkyIGFyY2hpdGVjdHVyZS4gIEFzIHN0YXRl
ZCwgRUNSSVQgaXMgY29uY2VybmVkIHdpdGggdGhlIEludGVybmV0LiAgT3IsIG1vcmUgY29uc3Ry
dWN0aXZlbHksIHlvdSBjYW4gZWFzaWx5IGluamVjdCBhbiBJUC1lbmFibGVkIGdhdGV3YXkgYW5k
IHRoZSBhcmNoaXRlY3R1cmUgd29ya3MgYWdhaW4uICBCdXQgdGhlbiwgdGhhdCdzIHdoYXQgaTIg
ZG9lcy4NCg0KVG8gdHVybiB0aGlzIGFib3V0LCBpdCBpcyByZWFzb25hYmxlIHRvIGFzayBpbiB0
dXJuIHdoYXQgM0dQUCBpcyBkb2luZyB0byBlbnN1cmUgdGhhdCBJTVMgZW1lcmdlbmN5IHNwZWNp
ZmljYXRpb25zIHdvcmsgaW4gYW4gZW52aXJvbm1lbnQgd2hlcmUgUFNBUHMgYXNzdW1lIGkyIG9y
IEVDUklUIGFyY2hpdGVjdHVyZXMuICBZb3UgbWVudGlvbiBwb3RlbnRpYWwgcHJvdmlzaW9uIGZv
ciBsb2NhdGlvbiBieSByZWZlcmVuY2UgLSBpcyB0aGF0IGluIFJlbGVhc2UgOT8gIEhhcyAzR1BQ
IGFkb3B0ZWQgU0lQIGxvY2F0aW9uIGNvbnZleWFuY2UgZm9yIGVtZXJnZW5jeT8NCg0KKEIpKGIp
IEFzIG1lbnRpb25lZCwgdXBkYXRlcyBhcmUgcG9zc2libGUuICBZb3UnbGwgbmVlZCB0byBiZSBt
b3JlIGV4cGxpY2l0IGFib3V0IHdoYXQgZ29hbHMgeW91IHNlZSAidmVyaWZpY2F0aW9uIiBhY2Nv
bXBsaXNoaW5nIGJlZm9yZSBJIGNhbiBkZWZpbml0aXZlbHkgcmVzcG9uZC4NCg0KKEIpKGMpIGFu
ZCAoQikoZCkgc2VlIGFib3ZlIHN0YXRlbWVudHMgd2l0aCByZWdhcmQgdG8gbmV0d29yay1kZXRl
cm1pbmVkIGxvY2F0aW9uLg0KDQooQikoZSkgSGFuZG92ZXIgaW50byBjaXJjdWl0IHN3aXRjaGVk
IGRvbWFpbiBpcyBtb3N0IGRlZmluaXRlbHkgbm90IGEgc3RhdGVkIGdvYWwuDQoNCihCKShmKSBV
bmF1dGhlbnRpY2F0ZWQgYWNjZXNzIGlzIGEgbXVsdGktbGF5ZXJlZCBpc3N1ZS4gIEV4dGVuc2l2
ZSBkZWJhdGUgb24gdGhlIHN1YmplY3QgaGFzIGluZXZpdGFibHkgbGVhZCB0byB0aGUgY29uY2x1
c2lvbiB0aGF0IHRoaXMgaXMgYSByZXF1aXJlbWVudCB0aGF0IEVDUklUIGRvZXNuJ3Qgd2FudCB0
byBzb2x2ZSwgdGhvdWdoIHRoYXQgY29uY2x1c2lvbiBpc24ndCBkZWZpbml0aXZlLiAgSSdkIHJl
ZmVyIHlvdSB0byB0aGUgbGlzdCBhcmNoaXZlcy4NCg0KKEIpKGNvbmNsdXNpb24pIEFzIGxvbmcg
YXMgY2VsbHVsYXIgbmV0d29ya3MgcHJvdmlkZSBJbnRlcm5ldCBhY2Nlc3MsIHRoZXkgYXJlIHBv
dGVudGlhbGx5IGNvdmVyZWQgYnkgdGhlIEVDUklUIGFyY2hpdGVjdHVyZS4gIEZvciBhbiBhY2Nl
c3MgbmV0d29yaywgYWxsIHRoYXQgaXMgbmVjZXNzYXJ5IGlzIHRoYXQgaXQgc3VwcG9ydCB0aGUg
cHJvdmlzaW9uIG9mIGxvY2F0aW9uIGluZm9ybWF0aW9uLg0KDQpBcyBmYXIgYXMgdGhlIHZvaWNl
IHNlcnZpY2UgZ29lcywgY2FsbCByb3V0aW5nIGZ1bmN0aW9ucyBhbmQgdGhlIGxpa2UgY291bGQg
ZWFzaWx5IHVzZSB0aGUgbWV0aG9kcyBkZXNjcmliZWQgYnkgRUNSSVQuICBJIGRvbid0IGhhdmUg
YSBnb29kIHZpZXcgb2YgaG93IHRoZSBiaXRzIGFuZCBieXRlcyBhbGlnbiB3aXRoIHdoYXQgaXMg
aW4gSU1TOyBvYnZpb3VzbHkgdGhlcmUgd2lsbCBiZSBtaW5vciBkaWZmZXJlbmNlcywgYnV0IEkg
Y2FuJ3QgaW1hZ2luZSB0aGF0IGl0IHdvdWxkIGJlIGltcG9zc2libGUgdG8gc3VwcG9ydCBzdWNo
IHRoaW5ncyBhcyBzZXJ2aWNlIFVSTnMsIExvU1QgYW5kIGxvY2F0aW9uIGNvbnZleWFuY2UuLi5h
cyBuZWNlc3NhcnkuDQoNCkNpcmN1aXQtc3dpdGNoZWQgY2FsbHMgcmVtYWluIGVudGlyZWx5IHRo
ZSBwdXJ2aWV3IG9mIDNHUFAuDQoNCk5vIGRpc2NsYWltZXIvYXBwbGljYWJpbGl0eSBzdGF0ZW1l
bnQgaXMgbmVjZXNzYXJ5LiAgVGhlIDNHUFAgZW1lcmdlbmN5IGFyY2hpdGVjdHVyZSBkb2VzIG5v
dCBhZGRyZXNzIGFsbCBvZiB0aGUgc3RhdGVkIGdvYWxzIG9mIEVDUklULCB3aGljaCBpbmNsdWRl
IG9wZXJhdGlvbiBhbmQgaW50ZXJvcGVyYXRpb24gZm9yIGFsbCBJbnRlcm5ldCBkZXZpY2VzLg0K
DQpFQ1JJVCBjYW4gaGFyZGx5IGJlIGZhdWx0ZWQgZm9yIGZhaWxpbmcgdG8gYWNjb21tb2RhdGUg
b25lIHBhcnRpY3VsYXIgdmVydGljYWwgc29sdXRpb24uICBFeGlzdGVuY2UgaXMgbm90IGEgdmly
dHVlIHRoYXQgbmVjZXNzaXRhdGVzIHRoZSBraW5kIG9mIHNwZWNpYWwgdHJlYXRtZW50IHlvdSBz
ZWVtIHRvIGV4cGVjdC4NCg0KQ2hlZXJzLA0KTWFydGluDQoNCnAucy4gT24gcG9pbnQgKEMpOiBX
ZSBjYW4ndCBjb25jZXJuIG91cnNlbHZlcyB3aXRoIHdoYXQgbWlnaHQgYmUsIGJ1dCBhcyBmb3Ig
d2hhdCBpcyBvciBpcyBub3QgY29tcGF0aWJsZSwgSSB0aGluayB0aGF0IHRoZSByZXN0IG9mIG15
IGVtYWlsIGhhcyBhZGRyZXNzZWQgdGhhdC4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2Vz
QGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgRWRnZSwgU3RlcGhlbg0KPiBTZW50OiBUaHVyc2Rh
eSwgNSBGZWJydWFyeSAyMDA5IDY6NTAgUE0NCj4gVG86ICdFQ1JJVCcNCj4gU3ViamVjdDogW0Vj
cml0XSBDb21tZW50cyBvbiBGcmFtZXdvcmsgRHJhZnQNCj4gDQo+IEFsbA0KPiANCj4gZHJhZnQt
aWV0Zi1lY3JpdC1mcmFtZXdvcmstMDcgaXMgKGFzIHdlIHNlZSBpdCkgYSBtb3N0bHkgaW5mb3Jt
YXRpdmUNCj4gZGVzY3JpcHRpb24gb2YgaG93IHRlcm1pbmFscyBhbmQgbmV0d29ya3Mgc2hvdWxk
IHN1cHBvcnQgZW1lcmdlbmN5DQo+IGNhbGxzIG1hZGUgb3ZlciBJUCBjYXBhYmxlIGZhY2lsaXRp
ZXMgdG8gSVAgY2FwYWJsZSBQU0FQcy4gSXQgYXBwZWFycw0KPiBpbnRlbmRlZCB0byBjb3ZlciBh
bGwgdHlwZXMgb2YgYWNjZXNzIG5ldHdvcmsgLSBpbmNsdWRpbmcgZml4ZWQgbGluZSwNCj4gV2lG
aSBhbmQgY2VsbHVsYXIgKGUuZy4gZXhhbXBsZXMgaW52b2x2aW5nIGVhY2ggY2FuIGJlIGZvdW5k
IHRocm91Z2hvdXQNCj4gdGhlIGRyYWZ0KS4NCj4gDQo+IFdoZW4gd2UgZXZhbHVhdGVkIHRoaXMg
d2l0aCByZXNwZWN0IHRvIHN1cHBvcnQgb2Ygd2lyZWxlc3MgY2VsbHVsYXINCj4gYWNjZXNzIGFu
ZCBXaUZpIGFjY2VzcyBhc3NvY2lhdGVkIHdpdGggYSBjZWxsdWxhciBvcGVyYXRvciAoZS5nLiBX
TEFODQo+IG9yIEZlbXRvIGNlbGxzIGludGVncmF0ZWQgaW50byBhIGNlbGx1bGFyIG5ldHdvcmsp
LCB3ZSBmb3VuZCB0aGF0DQo+IGNlcnRhaW4gcG9ydGlvbnMgb2YgdGhlIGRyYWZ0IGV4aGliaXRl
ZCBvbmUgb3IgbW9yZSBvZiB0aGUgZm9sbG93aW5nDQo+IGNoYXJhY3RlcmlzdGljczoNCj4gDQo+
IMKgwqDCoCAoQSkgSW5jb25zaXN0ZW50IHdpdGggYWxyZWFkeSBzdGFuZGFyZGl6ZWQgd2lyZWxl
c3Mgc29sdXRpb25zDQo+IA0KPiDCoMKgwqAgKEIpIEluY29uc2lzdGVudCB3aXRoIGVzc2VudGlh
bCB3aXJlbGVzcyByZXF1aXJlbWVudHMgYW5kDQo+IGNvbnZlbnRpb25zDQo+IA0KPiDCoMKgwqAg
KEMpIEFscmVhZHkgcGFydCBvZiB3aXJlbGVzcyBzdGFuZGFyZHMgb3IgcG90ZW50aWFsbHkgcGFy
dCBvZg0KPiBmdXR1cmUgc3RhbmRhcmRzDQo+IA0KPiAoQSkgcmVmZXJzIHRvIGFsbCBwb3J0aW9u
cyBvZiB0aGUgZHJhZnQgZnJhbWV3b3JrIHRoYXQgZGlmZmVyIGZyb20gdGhlDQo+IHJlcXVpcmVt
ZW50cyBhbmQgcHJvY2VkdXJlcyBjdXJyZW50bHkgc3RhbmRhcmRpemVkIGZvciB3aXJlbGVzcw0K
PiBlbWVyZ2VuY3kgYWNjZXNzIGJ5IDNHUFAsIDNHUFAyIGFuZCBPTUEuIFRoaXMgaXMgYSBwbGFp
biBkaWZmZXJlbmNlIG9mDQo+IHNvbHV0aW9uIGFuZCBjb3VsZCBiZSByZXNvbHZlZCB0aHJvdWdo
IHN1cHBvcnQgb2YgYm90aCBzb2x1dGlvbnMgYnkNCj4gdGVybWluYWxzICh3aXRoIGVhY2ggc29s
dXRpb24gYmVpbmcgdXNlZCBhY2NvcmRpbmcgdG8gdGhlIHR5cGUgb2YNCj4gYWNjZXNzIG5ldHdv
cmsgYW5kIFZTUCkgb3IgY291bGQgYmUgcmVzb2x2ZWQgYnkgc3VwcG9ydGluZyBvbmx5IG9uZQ0K
PiBzb2x1dGlvbiBhbmQgYWNjZXNzaW5nIG9ubHkgdGhlIHR5cGVzIG9mIG5ldHdvcmsgc3VwcG9y
dGluZyB0aGF0DQo+IHNvbHV0aW9uLiBUbyBhY2tub3dsZWRnZSB0aGlzIGNhdGVnb3J5LCB0aGUg
ZnJhbWV3b3JrIGRvY3VtZW50IGNvdWxkDQo+IHJlZmVyZW5jZSB0aGUgYXBwbGljYWJsZSB3aXJl
bGVzcyBzdGFuZGFyZHMgYW5kIHBvaW50IG91dCB0aGF0IHRoZXNlDQo+IGFyZSB2YWxpZCBhbHRl
cm5hdGl2ZXMgZm9yIHdpcmVsZXNzIGNlbGx1bGFyIGJhc2VkIGFjY2Vzcy4NCj4gDQo+IChCKSBy
ZWZlcnMgdG8gcG9ydGlvbnMgb2YgdGhlIGRyYWZ0IHRoYXQgd291bGQgYmUgdW5zdWl0YWJsZSBm
b3INCj4gd2lyZWxlc3MgbmV0d29ya3MgZXZlbiBpZiBubyBhbHRlcm5hdGl2ZSBzb2x1dGlvbiBl
eGlzdGVkIHRvZ2V0aGVyIHdpdGgNCj4gb3RoZXIgcG9ydGlvbnMgbWlzc2luZyBmcm9tIHRoZSBk
cmFmdCB0aGF0IHdvdWxkIGJlIG5lZWRlZCB0byBmdWxseQ0KPiBzdXBwb3J0IHdpcmVsZXNzIG5l
dHdvcmtzLiBFeGFtcGxlcyBvZiB0aGUgZm9ybWVyIGluY2x1ZGU6IChhKSBlbXBoYXNpcw0KPiBv
biBlbmRwb2ludCBkZXJpdmF0aW9uIG9mIGxvY2F0aW9uLCBwZXJmb3JtYW5jZSBvZiBMb3N0IHF1
ZXJ5IGFuZA0KPiByZWNlaXB0IG9mIGxvY2FsIGRpYWwgc3RyaW5nczsgKGIpIHJlc3RyaWN0aW9u
IG9mIExDUHMgdG8gcHJvdG9jb2xzDQo+IHRoYXQgcmVxdWlyZSB0ZXJtaW5hbCBpbml0aWF0aW9u
IChub3QgYWxsb3dpbmcgZm9yIG5ldHdvcmsgaW5pdGlhdGlvbg0KPiBhcyBmYXIgYXMgd2UgY2Fu
IHRlbGwpIGFuZCB0aGF0IGluY2x1ZGUgdHdvIExDUHMgKERIQ1AgYW5kIExMRFApIHRoYXQNCj4g
YXJlIG5vdCBhcHBsaWNhYmxlIHRvIChub3QgZGVmaW5lZCBmb3IpIGNlbGx1bGFyIGFjY2Vzczsg
YW5kIChjKSB0aGUNCj4gcmVxdWlyZW1lbnQgdGhhdCBhIHRlcm1pbmFsIG9yIGF0IGxlYXN0IGEg
TElTIHdpbGwgdXBkYXRlIHRoZSBQU0FQDQo+IHdoZW5ldmVyIGxvY2F0aW9uIGNoYW5nZXMuIChh
KSBpcyBpbXByYWN0aWNhbCBkdWUgdG8gbmV0d29yayBhbmQNCj4gdGVybWluYWwgbG9hZGluZyBj
b25zZXF1ZW5jZXMgYW5kIGZhaWx1cmUgdG8gc3VwcG9ydCBub24tSVAgY2FwYWJsZQ0KPiBQU0FQ
czsgKGIpIG1ha2VzIGxvY2F0aW9uIHZlcmlmaWNhdGlvbiBhbmQgdXBkYXRlZCBsb2NhdGlvbiBw
cm92aXNpb24NCj4gdG8gUFNBUHMgZGlmZmljdWx0IG9yIGltcG9zc2libGU7IHdoaWxlIChjKSBp
cyBhbHNvIGluY29tcGF0aWJsZSB3aXRoDQo+IHN1cHBvcnQgb2YgZXhpc3Rpbmcgbm9uLUlQIGNh
cGFibGUgUFNBUHMgYmVzaWRlcyBpbmNyZWFzaW5nIHRlcm1pbmFsDQo+IGxvYWQgYW5kIHBvc3Np
Ymx5IGludGVyZmVyaW5nIHdpdGggb3B0aW11bSBtYWludGVuYW5jZSBvZiB0aGUgUkYNCj4gY29u
bmVjdGlvbiAoZS5nLiBpZiBhIHRlcm1pbmFsIGhhcyB0byB0dW5lIGF3YXkgZnJvbSB0aGUgc2Vy
dmluZyBiYXNlDQo+IHN0YXRpb24gb3IgV0xBTiBwZXJpb2RpY2FsbHkgdG8gbWFrZSBsb2NhdGlv
biBtZWFzdXJlbWVudHMpLiBFeGFtcGxlcw0KPiBvZiB0aGUgbGF0dGVyIGluY2x1ZGUgKGQpIGFi
c2VuY2Ugb2Ygc3VwcG9ydCBmb3IgYWNjZXNzIHRvIG5vbi1JUA0KPiBjYXBhYmxlIFBTQVBzIGFz
IGFscmVhZHkgbWVudGlvbmVkIChlLmcuIHRvIHN1cHBvcnQgRTkxMSBwaGFzZSAyIGluIHRoZQ0K
PiBVUyk7IChlKSBubyBzdXBwb3J0IGZvciBoYW5kb3ZlciBmcm9tIHRoZSBJUCB0byB0aGUgY2ly
Y3VpdCBkb21haW4gd2hlbg0KPiBhIHRlcm1pbmFsIGxvc2VzIChlLmcuIG1vdmVzIG91dCBvZikg
UkYgY292ZXJhZ2UgaW4gdGhlIElQIGRvbWFpbjsgYW5kDQo+IChmKSBubyBhbGxvd2FuY2UgZm9y
IGxpbWl0ZWQgYWNjZXNzIG1vZGVzIHdoZXJlaW4gYSB0ZXJtaW5hbCBtYXkgYWNjZXNzDQo+IGEg
bmV0d29yayBvbmx5IHRvIHBsYWNlIGFuIGVtZXJnZW5jeSBjYWxsIHdpdGggZW5zdWluZyByZXN0
cmljdGlvbnMgb24NCj4gKGZvciBleGFtcGxlKSBsb2NhdGlvbiBhY3F1aXNpdGlvbiwgUFNBUCBj
YWxsYmFjayBhbmQgY2FsbGVyDQo+IHZlcmlmaWNhdGlvbiBhbmQgaWRlbnRpZmljYXRpb24gdG8g
dGhlIFBTQVAuIFRvIHJlc29sdmUgdGhpcyBjYXRlZ29yeQ0KPiBlaXRoZXIgc2lnbmlmaWNhbnQg
Y2hhbmdlcyB0byB0aGUgZnJhbWV3b3JrIGRvY3VtZW50IGNvdWxkIGJlIG1hZGUgb3IgYQ0KPiBk
aXNjbGFpbWVyL2FwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGNvdWxkIGJlIGFkZGVkIHN0YXRpbmcg
dGhhdCBzdXBwb3J0DQo+IG9mIGNlbGx1bGFyIHdpcmVsZXNzIG5ldHdvcmtzIGFuZCB0aGVpciBh
c3NvY2lhdGVkIFdMQU4gYW5kIEZlbXRvDQo+IGFjY2VzcyBwb2ludHMgaXMgbm90IGNvdmVyZWQu
DQo+IA0KPiBDYXRlZ29yeSAoQykgY29tcHJpc2VzIGNvbmNlcHRzIGFuZCBjYXBhYmlsaXRpZXMg
aW4gdGhlIGRyYWZ0IHRoYXQgYXJlDQo+IGVpdGhlciBhbHJlYWR5IHBhcnQgb2YgdGhlIHN0YW5k
YXJkaXplZCBzb2x1dGlvbiBmb3Igd2lyZWxlc3MgbmV0d29ya3MNCj4gb3IgdGhhdCBtaWdodCBi
ZSBhZGRlZCBhdCBhIGxhdGVyIHRpbWUuIEV4YW1wbGVzIG9mIHRoZSBmb3JtZXIgaW5jbHVkZQ0K
PiBMb1NULCBTSVAgbG9jYXRpb24gY29udmV5YW5jZSwgZ2VuZXJhbCB1c2Ugb2YgU0lQLCBsb2Nh
dGlvbiBmb3Igcm91dGluZw0KPiB2ZXJzdXMgZm9yIGRpc3BhdGNoLCBjZWxsdWxhciBwb3NpdGlv
bmluZyBtZXRob2RzLiBFeGFtcGxlcyBvZiB0aGUNCj4gbGF0dGVyIGluY2x1ZGUgdXNlIG9mIGxv
Y2F0aW9uIHJlZmVyZW5jZXMgYW5kIGRlcmVmZXJlbmNpbmcgYW5kDQo+IHBvc3NpYmxlIGludGVy
d29ya2luZyBiZXR3ZWVuIHRoZSBjdXJyZW50IHdpcmVsZXNzIG5ldHdvcmsgc29sdXRpb25zDQo+
IChpbiAzR1BQLCAzR1BQMiBhbmQgT01BKSBhbmQgdGhlIHNvbHV0aW9uIGRlc2NyaWJlZCBpbiB0
aGlzIGRyYWZ0LiBUaGUNCj4gcHJlc2VuY2Ugb2YgdGhpcyBjYXRlZ29yeSBjb3VsZCBiZSBhY2tu
b3dsZWRnZWQgYnkgZm9sbG93aW5nIHRoZQ0KPiBkaXNjbGFpbWVyIGZvciAoQikgd2l0aCBhIHN0
YXRlbWVudCB0aGF0IGNlcnRhaW4gcG9ydGlvbnMgb2YgdGhlDQo+IHNvbHV0aW9uIGFyZSBleHBl
Y3RlZCB0byBiZSBpbmNvcnBvcmF0ZWQgaW50byB3aXJlbGVzcyBuZXR3b3JrcyBub3cNCj4gYW5k
L29yIGluIHRoZSBmdXR1cmUuDQo+IA0KPiBXZSBob3BlIHRoYXQgdGhlc2UgY29tbWVudHMgd2ls
bCBiZSBzZWVuIHRvIGJlIGEgdXNlZnVsIGFkZGl0aW9uIHRvDQo+IHRoaXMgcmV2aWV3IGluIHRo
ZSBzZW5zZSBvZiBlbmFibGluZyBhIG1vcmUgcHJlY2lzZSBzY29waW5nIGZvciB0aGUNCj4gZnJh
bWV3b3JrIGRvY3VtZW50IGFuZCB3ZSBhcmUgd2lsbGluZyB0byBhc3Npc3QgaW4gcHJvdmlkaW5n
IHdvcmRpbmcNCj4gZm9yIGFueSBkaXNjbGFpbWVyL2FwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHRo
YXQgdGhlIEVjcml0IHdvcmtpbmcgZ3JvdXANCj4gbWF5IG5vdyBkZWVtIGZpdCB0byBpbmNsdWRl
Lg0KPiANCj4gS2luZCBSZWdhcmRzDQo+IA0KPiBTdGVwaGVuIEVkZ2UgKFF1YWxjb21tIDNHUFAg
U0EyIHBhcnRpY2lwYW50KSwgS2lyayBCdXJyb3VnaHMgKFF1YWxjb21tDQo+IDNHUFAyIFRTRy1Y
IGFuZCBUU0ctQyBwYXJ0aWNpcGFudCkNCj4gDQo+IFBTICB0aGlzIGJlaW5nIHNlbnQgb24gMi80
LzA5IGF0IDExOjUwcG0gUFNUDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcN
Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhl
IGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBw
cm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBo
YXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVk
aWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YN
CnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KW21mMl0NCg==



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A66B28C13A for <[e-mail]>; Thu, 12 Feb 2009 04:08:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ed8FSU3GRyK0 for <[e-mail]>; Thu, 12 Feb 2009 04:08:25 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CF34928C139 for <[e-mail]>; Thu, 12 Feb 2009 04:08:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[e-mail]; q=dns/txt; s=qcdkim; t=1234440510; x=1265976510; 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<[e-mail]>|To:=20H annes=20Tschofenig=20<[e-mail]>,=20"'ECR IT'"=20<[e-mail]>|Date:=20Thu,=2012=20Feb=202009=20 04:08:22=20-0800|Subject:=20RE:=20[Ecrit]=20Comments=20on =20Framework=20Draft|Thread-Topic:=20[Ecrit]=20Comments =20on=20Framework=20Draft|Thread-Index:=20AcmHZkcFqEtDIGT NRMy2Xqm0XoWoXwAAnQ6gAWY1w+A=3D|Message-ID:=20<1288E74A73 [e-mail] m>|References:=20<1288E74A73964940B132A0B9EA8D8ABC535F030 [e-mail]>=0D=0A=20<003901c98772$b4cc 7710$[e-mail]>|In-Reply-To:=20<003901c98772$ b4cc7710$[e-mail]>|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"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5523"=3B=20a=3D"15422782"; bh=Jb9Kwv/tkguzfbSXxgvSOi7IFLsx0mLztznBcj743n0=; b=ZBNwUESSmnrrYH41WDCfAALNsKZJyYsGEmOom5q/it93JJMErfGpeL0N z3L0LNuOi00VSalVKJveLN+SMpWXKQE4arY6pVhmINd5BksNwLT+26Qw5 8FnE6xB27IuefddlDV0zJ0wvr8ndReVa9RNriANWP2g8aIizlORwmYXq5 0=;
X-IronPort-AV: E=McAfee;i="5100,188,5523"; a="15422782"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2009 04:08:29 -0800
Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1CC8Tmt027966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Feb 2009 04:08:30 -0800
Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1CC8TJU009606 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Feb 2009 04:08:29 -0800
Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Thu, 12 Feb 2009 04:08:28 -0800
From: "Edge, Stephen" <[e-mail]>
To: Hannes Tschofenig <[e-mail]>, "'ECRIT'" <[e-mail]>
Date: Thu, 12 Feb 2009 04:08:22 -0800
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAnQ6gAWY1w+A=
Message-ID: <[e-mail]>
References: <[e-mail]> <003901c98772$b4cc7710$[e-mail]>
In-Reply-To: <003901c98772$b4cc7710$[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2009 12:08:27 -0000

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:[e-mail]]=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: [e-mail] [mailto:[e-mail]]=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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D3828C14B for <[e-mail]>; Thu, 12 Feb 2009 04:28:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoyFF0idcCHu for <[e-mail]>; Thu, 12 Feb 2009 04:28:09 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 1C7A028C139 for <[e-mail]>; Thu, 12 Feb 2009 04:28:08 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2009_02_12_06_47_31
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 12 Feb 2009 06:47:31 -0600
Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 06:28:13 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Feb 2009 06:28:11 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAnQ6gAWY1w+AAAmT/sA==
References: <[e-mail]><003901c98772$b4cc7710$[e-mail]> <[e-mail]>
From: "Dawson, Martin" <[e-mail]>
To: "Edge, Stephen" <[e-mail]>, "Hannes Tschofenig" <[e-mail]>, "ECRIT" <[e-mail]>
X-OriginalArrivalTime: 12 Feb 2009 12:28:13.0389 (UTC) FILETIME=[5F8C47D0:01C98D0D]
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2009 12:28:14 -0000

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: [e-mail] [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=
[e-mail]]=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=
[e-mail] [mailto:[e-mail]]=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=
[e-mail]=0D=0A>https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>=0D=0A=0D=
=0A_______________________________________________=0D=0AEcrit mailing list=0D=
=[e-mail]=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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0943A6AD9 for <[e-mail]>; Thu, 12 Feb 2009 05:50:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww0APIqsyMiw for <[e-mail]>; Thu, 12 Feb 2009 05:50:46 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 26CAD3A6902 for <[e-mail]>; Thu, 12 Feb 2009 05:50:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[e-mail]; q=dns/txt; s=qcdkim; t=1234446651; x=1265982651; 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<[e-mail]>|To:=20" Dawson,=20Martin"=20<[e-mail]>,=0D=0A=20 =20=20=20=20=20=20=20Hannes=20Tschofenig=0D=0A=09<Hannes. [e-mail]>,=20ECRIT=20<[e-mail]>|Date:=20T hu,=2012=20Feb=202009=2005:50:46=20-0800|Subject:=20RE: =20[Ecrit]=20Comments=20on=20Framework=20Draft |Thread-Topic:=20[Ecrit]=20Comments=20on=20Framework=20Dr aft|Thread-Index:=20AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAnQ6gA WY1w+AAAmT/sAABhntA|Message-ID:=20<1288E74A73964940B132A0 [e-mail]> |References:=20<1288E74A73964940B132A0B9EA8D8ABC535F0305@ NASANEXMB04.na.qualcomm.com><003901c98772$b4cc7710$0201a8 [e-mail]>=0D=0A=20<1288E74A73964940B132A0B9EA8D8AB [e-mail]>=0D=0A=20<EB921991A [e-mail]> |In-Reply-To:=20<EB921991A86A974C80EAFA46AD428E1E05285704 @aopex4.andrew.com>|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"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5523"=3B=20a=3D"15424004"; bh=PsLaGc+lLCQIHSKCJwoMzVp6sKCe8MvK1EMClhMswB4=; b=IwGyPn9fOlQ2dhOyEfrYE7h2p+XNSlIBfFj1HntkhMX542FGgJUYDLBz 562aEoWLwV25iQmaEZWcO/I6HWu1bOUOQclqm7jPa5iIuH5CX+RNE0Mpo BOneHSIRVNcyggpdqWkA1EItWnuL2Z+54VcqujXxR3ANbjEckYIVyjr57 A=;
X-IronPort-AV: E=McAfee;i="5100,188,5523"; a="15424004"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2009 05:50:51 -0800
Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1CDopLQ002780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Feb 2009 05:50:51 -0800
Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1CDomEp002562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Feb 2009 05:50:50 -0800
Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Thu, 12 Feb 2009 05:50:48 -0800
From: "Edge, Stephen" <[e-mail]>
To: "Dawson, Martin" <[e-mail]>, Hannes Tschofenig <[e-mail]>, ECRIT <[e-mail]>
Date: Thu, 12 Feb 2009 05:50:46 -0800
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAnQ6gAWY1w+AAAmT/sAABhntA
Message-ID: <[e-mail]>
References: <[e-mail]><003901c98772$b4cc7710$[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2009 13:50:48 -0000

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:[e-mail]]
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: [e-mail] [mailto:[e-mail]] 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:[e-mail]]
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: [e-mail] [mailto:[e-mail]]
>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
[e-mail]
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]



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F92C3A67B2 for <[e-mail]>; Thu, 12 Feb 2009 06:17:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hzxbc7SNd4y for <[e-mail]>; Thu, 12 Feb 2009 06:17:24 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id BD1463A6803 for <[e-mail]>; Thu, 12 Feb 2009 06:17:23 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2009_02_12_08_36_45
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 12 Feb 2009 08:36:45 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 08:17:27 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Feb 2009 08:17:26 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAnQ6gAWY1w+AAAmT/sAABhntAAAIxaxA=
References: <[e-mail]><003901c98772$b4cc7710$[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Winterbottom, James" <[e-mail]>
To: "Edge, Stephen" <[e-mail]>, "Dawson, Martin" <[e-mail]>, "Hannes Tschofenig" <[e-mail]>, "ECRIT" <[e-mail]>
X-OriginalArrivalTime: 12 Feb 2009 14:17:27.0577 (UTC) FILETIME=[A2260090:01C98D1C]
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2009 14:17:26 -0000

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: [e-mail] [mailto:ecr=
[e-mail]] 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:[e-mail]]=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: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:e=
[e-mail]]=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>[e-mail]=0D=0A>https://www.ietf.org/mailman/listinfo/ecri=
t=0D=0A>=0D=0A=0D=0A_______________________________________________=0D=0AEc=
rit mailing list=0D=[e-mail]=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=[e-mail]=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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D5633A67D6 for <[e-mail]>; Thu, 12 Feb 2009 17:15:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PjQMHYoaV3e for <[e-mail]>; Thu, 12 Feb 2009 17:15:09 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 425973A672F for <[e-mail]>; Thu, 12 Feb 2009 17:15:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[e-mail]; 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<[e-mail]>|To:=20" Winterbottom,=20James"=20<[e-mail]>, =0D=0A=20=20=20=20=20=20=20=20"Dawson,=20Martin"=0D=0A=09 <[e-mail]>,=0D=0A=20=20=20=20=20=20=20=20 Hannes=20Tschofenig=20<[e-mail]>,=20ECRI T=20<[e-mail]>|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 [e-mail]>< 003901c98772$b4cc7710$[e-mail]><1288E74A7396 [e-mail]> <[e-mail].c om>=0D=0A=20<1288E74A73964940B132A0B9EA8D8ABC535F075F@NAS ANEXMB04.na.qualcomm.com>=0D=0A=20<E51D5B15BFDEFD448F90BD [e-mail]>|In-Reply-To:=20<E51 [e-mail]> |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=;
X-IronPort-AV: E=McAfee;i="5100,188,5524"; a="15447316"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2009 17:15:15 -0800
Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1D1FEAN031060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Feb 2009 17:15:14 -0800
Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1D1FEPL019120 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Feb 2009 17:15:14 -0800
Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Thu, 12 Feb 2009 17:15:13 -0800
From: "Edge, Stephen" <[e-mail]>
To: "Winterbottom, James" <[e-mail]>, "Dawson, Martin" <[e-mail]>, Hannes Tschofenig <[e-mail]>, ECRIT <[e-mail]>
Date: Thu, 12 Feb 2009 17:15:12 -0800
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAnQ6gAWY1w+AAAmT/sAABhntAAAIxaxAAFvw30A==
Message-ID: <[e-mail]>
References: <[e-mail]><003901c98772$b4cc7710$[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2009 01:15:11 -0000

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:[e-mail]]
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: [e-mail] [mailto:[e-mail]] 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:[e-mail]]
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: [e-mail] [mailto:[e-mail]] 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:[e-mail]]
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: [e-mail] [mailto:[e-mail]]
>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
[e-mail]
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
[e-mail]
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]



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFFF03A6B42 for <[e-mail]>; Fri, 13 Feb 2009 13:18:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8OabhfrVPV1 for <[e-mail]>; Fri, 13 Feb 2009 13:18:10 -0800 (PST)
Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id 245913A6AB3 for <[e-mail]>; Fri, 13 Feb 2009 13:18:05 -0800 (PST)
Received: by fxm13 with SMTP id 13so3985917fxm.13 for <[e-mail]>; Fri, 13 Feb 2009 13:18:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=GPQmNnta+Z9uMAvpVOaDFPOWuyqWkPlwyP3RdfR9Qe8=; b=n0CUSYIv25BelSwMbBnpLBGudfAPYMlXMhXimxXY4quBT86CWHIodVtGAPyFzwHk86 5rsgZOiMqRRk9zg9y6j+06Ihbd8rDRMaiy/rF/vnZz+1GRYoybF/s2PLuYDQEm9clDAo N2u/0IE+nSMGIkLXbZ8Haw27ZxYCE8vX+C7sU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=QnmbB2Ghgq5BAV2LwvdDkjSMIcUG8zR3gWJ3yd4r57IV8K8k194DothNFqFrMr1VA1 +oyH41hoWCfTkBPu8DTcziQhzd3660F4y0bC/K2SnG7HVfMdN5Z+1PuIS53LFqjToM9u 34/Hz7/YUeGovubMYyhFgpfeN1YRTslLXHeQw=
MIME-Version: 1.0
Received: by 10.181.222.5 with SMTP id z5mr853230bkq.151.1234559892327; Fri,  13 Feb 2009 13:18:12 -0800 (PST)
Date: Fri, 13 Feb 2009 22:18:12 +0100
Message-ID: <[e-mail]>
From: Karl Heinz Wolf <[e-mail]>
To: [e-mail], ECRIT <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Ecrit] code sprint @ IETF 74?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2009 21:18:11 -0000

are there plans for an ECRIT/GEOPRIV code sprint at the next IETF meeting?

thanks,

karl heinz


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id EC6183A687C; Sun, 15 Feb 2009 09:30:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Sun, 15 Feb 2009 09:30:01 -0800 (PST)
Cc: [e-mail]
Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-03.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 15 Feb 2009 17:30:02 -0000

--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: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117AD3A6AEF for <[e-mail]>; Sun, 15 Feb 2009 12:16:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.18
X-Spam-Level: 
X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=-1.182,  BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a8OukF98JZF for <[e-mail]>; Sun, 15 Feb 2009 12:16:47 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E3E4D3A6A83 for <[e-mail]>; Sun, 15 Feb 2009 12:16:46 -0800 (PST)
Received: (qmail invoked by alias); 15 Feb 2009 20:16:54 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp046) with SMTP; 15 Feb 2009 21:16:54 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX192hvckDc52WjeFrTqXOlJEgd9Yh+ZPkfufDadGo+ Qzl5xZo2xdIf6w
From: "Hannes Tschofenig" <[e-mail]>
To: <[e-mail]>
Date: Sun, 15 Feb 2009 22:17:48 +0200
Message-ID: <004a01c98faa$791129b0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01C98FBB.3C99F9B0"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: AcmPqnhUYOBdoJ2XS761ffMlH2J+cg==
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.8,0.8
Subject: [Ecrit] LoST Sync
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 15 Feb 2009 20:16:48 -0000

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--



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481C83A6989 for <[e-mail]>; Mon, 16 Feb 2009 01:26:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41r-dJi6XhoH for <[e-mail]>; Mon, 16 Feb 2009 01:26:02 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 388A43A679F for <[e-mail]>; Mon, 16 Feb 2009 01:26:01 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1G9Q88g014612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Feb 2009 10:26:08 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1G9Q8RV023272; Mon, 16 Feb 2009 10:26:08 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 16 Feb 2009 10:26:06 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 16 Feb 2009 11:26:55 +0200
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: code sprint @ IETF 74?
Thread-Index: AcmOIJXyVCQEZBLjTdu6gfc2ON2mIQB9jbXg
References: <[e-mail]>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>
To: <[e-mail]>, "ECRIT" <[e-mail]>
X-OriginalArrivalTime: 16 Feb 2009 09:26:06.0818 (UTC) FILETIME=[9874DC20:01C99018]
Subject: Re: [Ecrit] code sprint @ IETF 74?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Feb 2009 09:26:03 -0000

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: [e-mail]=20
>[mailto:[e-mail]] On Behalf Of ext Karl Heinz Wolf
>Sent: 13 February, 2009 23:18
>To: [e-mail]; 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 [e-mail]=20
>To unsubscribe from this group, send email to=20
>[e-mail]
>For more options, visit this group at=20
>http://groups.google.com/group/loc-imp?hl=3Den
>-~----------~----~----~----~------~----~------~--~---
>
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63EFD3A6813 for <[e-mail]>; Wed, 18 Feb 2009 11:09:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.977
X-Spam-Level: 
X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-0.978, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeXWoxNI-os4 for <[e-mail]>; Wed, 18 Feb 2009 11:09:16 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 407EC3A67AF for <[e-mail]>; Wed, 18 Feb 2009 11:09:15 -0800 (PST)
Received: (qmail invoked by alias); 18 Feb 2009 19:09:26 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp070) with SMTP; 18 Feb 2009 20:09:26 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18Ys1k8fb4Y49kYGMST71OoG5qtetOdgw1K62arYl bL4kRp9MVNZmK7
From: "Hannes Tschofenig" <[e-mail]>
To: "ECRIT" <[e-mail]>
Date: Wed, 18 Feb 2009 21:10:13 +0200
Message-ID: <008501c991fc$8cb889a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcmR/IZQrr1FA6IaQDWHgQTUwU8jvg==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.79
Subject: [Ecrit] PROTO shepherd for RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 18 Feb 2009 19:09:17 -0000

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




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9C23A6917 for <[e-mail]>; Wed, 18 Feb 2009 11:34:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.639
X-Spam-Level: 
X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONGfhUa4D+6Y for <[e-mail]>; Wed, 18 Feb 2009 11:34:51 -0800 (PST)
Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 8BC033A677D for <[e-mail]>; Wed, 18 Feb 2009 11:34:51 -0800 (PST)
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1LZsAm-0006KW-OU; Wed, 18 Feb 2009 13:34:54 -0600
From: "Brian Rosen" <[e-mail]>
To: "'Edge, Stephen'" <[e-mail]>, "'ECRIT'" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 18 Feb 2009 14:07:21 -0500
Message-ID: <0a8d01c991ff$fd063420$f7129c60$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+g
Content-Language: en-us
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 18 Feb 2009 19:34:52 -0000

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: [e-mail] [mailto:[e-mail]] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CDE53A6A28 for <[e-mail]>; Wed, 18 Feb 2009 11:36:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.639
X-Spam-Level: 
X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRqmFFoXOkOR for <[e-mail]>; Wed, 18 Feb 2009 11:36:32 -0800 (PST)
Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 4C04A3A6866 for <[e-mail]>; Wed, 18 Feb 2009 11:36:32 -0800 (PST)
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1LZsD3-0006KW-PG; Wed, 18 Feb 2009 13:36:32 -0600
From: "Brian Rosen" <[e-mail]>
To: "'Ted Hardie'" <[e-mail]>, "'James M. Polk'" <[e-mail]>, "'Hannes Tschofenig'" <[e-mail]>, "'DOLLY, MARTIN C,  ATTLABS'" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>	<000101c988ad$8ac92e90$[e-mail]>	<[e-mail]>	<p06240801c5b60fcc7136@[10.227.68.59]>	<[e-mail]> <p0624080fc5b65643d845@[10.227.68.59]>
In-Reply-To: <p0624080fc5b65643d845@[10.227.68.59]>
Date: Wed, 18 Feb 2009 14:07:21 -0500
Message-ID: <0a9701c99200$37181430$a5483c90$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-index: AcmLAkWPG3AFTHqiQImqvHFJBJwcpgGsL99A
Content-Language: en-us
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] RPH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 18 Feb 2009 19:36:33 -0000

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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Ted Hardie
> Sent: Monday, February 09, 2009 5:03 PM
> To: James M. Polk; Hannes Tschofenig; 'DOLLY, MARTIN C, ATTLABS';
> [e-mail]; [e-mail]
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id E8CEC3A6950; Thu, 19 Feb 2009 18:30:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 19 Feb 2009 18:30:01 -0800 (PST)
Cc: [e-mail]
Subject: [Ecrit] I-D Action:draft-ietf-ecrit-local-emergency-rph-namespace-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2009 02:30:02 -0000

--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: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA133A67A1 for <[e-mail]>; Thu, 19 Feb 2009 18:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqW0VwmvcJq7 for <[e-mail]>; Thu, 19 Feb 2009 18:32:32 -0800 (PST)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id EB7073A6784 for <[e-mail]>; Thu, 19 Feb 2009 18:32:31 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,238,1233532800"; d="scan'208";a="136522265"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 20 Feb 2009 02:32:46 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1K2Wk5Y008307 for <[e-mail]>; Thu, 19 Feb 2009 18:32:46 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1K2Wjhc013928 for <[e-mail]>; Fri, 20 Feb 2009 02:32:46 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 19 Feb 2009 18:32:45 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.18.42]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 19 Feb 2009 18:32:45 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 19 Feb 2009 20:32:44 -0600
To: "'ECRIT'" <[e-mail]>
From: "James M. Polk" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 20 Feb 2009 02:32:45.0583 (UTC) FILETIME=[836BB9F0:01C99303]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1775; t=1235097166; x=1235961166; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20draft-ietf-ecrit-local-emergency-rph-namespace- 01=20submitted |Sender:=20; bh=nCeou/ZJ+xWhVl07xcoGXUp/YG+srtXSb8juooyNBnQ=; b=B8zPOZL4ogtX76Tzd9hx/M9jDVU1fY7ByQv/PibiVE6t7bd2NKecu1q9Dn SPjpdMbd0vGcaMWc8ne+RWuxyUGceGv3R6i7di1/tmTRirYCP5bP9Sowqq+M wR2oeY3tqF;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2009 02:32:32 -0000

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 <[e-mail]>
>To: [e-mail]
>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.



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2BE83A6A26 for <[e-mail]>; Thu, 19 Feb 2009 18:34:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lh1x-MELujb5 for <[e-mail]>; Thu, 19 Feb 2009 18:34:28 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 191E23A6832 for <[e-mail]>; Thu, 19 Feb 2009 18:34:22 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,238,1233532800"; d="scan'208";a="30132112"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 20 Feb 2009 02:34:36 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n1K2YaQL005647 for <[e-mail]>; Thu, 19 Feb 2009 18:34:36 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1K2YZVK014928 for <[e-mail]>; Fri, 20 Feb 2009 02:34:36 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 19 Feb 2009 18:34:36 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.18.42]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 19 Feb 2009 18:34:35 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 19 Feb 2009 20:34:34 -0600
To: "'ECRIT'" <[e-mail]>
From: "James M. Polk" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 20 Feb 2009 02:34:35.0770 (UTC) FILETIME=[C518EDA0:01C99303]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1725; t=1235097276; x=1235961276; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Fwd=3A=20I-D=0A=20=20Action=3Adraft-polk-ecrit- local-emergency-rph-namespace-04.txt=20 |Sender:=20; bh=A9TFq4bVp5upge8eGgl3/NBVw+IZID+sIg4vhuQfP1o=; b=CjPCQKpBG3EMtJL+q8Cwqq2RkxuBh7++peotq1Z+pHgCKNzi4n6NT/lt8C exrJxZiRdzkACBgH0ifHL+Tx7D067zL5TZrtosqFrCGjqz9mJWeyUCNLGwt6 mAXwlrUpkY;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
Subject: [Ecrit] Fwd: I-D Action:draft-polk-ecrit-local-emergency-rph-namespace-04.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2009 02:34:29 -0000

please ignore this ID announcement -- I uploaded the wrong file initially.

sorry

>From: [e-mail]
>To: [e-mail]
>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
>[e-mail]
>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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F1C3A6A6E for <[e-mail]>; Fri, 20 Feb 2009 07:14:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IQxGs55OoFq for <[e-mail]>; Fri, 20 Feb 2009 07:14:30 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 8EF8B3A69E5 for <[e-mail]>; Fri, 20 Feb 2009 07:14:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[e-mail]; q=dns/txt; s=qcdkim; t=1235142885; x=1266678885; h=message-id:in-reply-to:references:x-mailer: x-message-flag:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20<p06240607c5c3848061cf@[10.67.63.198]> |In-Reply-To:=20<003901c98772$b4cc7710$0201a8c0@nsnintra. net>|References:=20<1288E74A73964940B132A0B9EA8D8ABC535F0 [e-mail]>=0D=0A=20<003901c98772$b4 cc7710$[e-mail]>|X-Mailer:=20Eudora=20for=20 Mac=20OS=20X|X-message-flag:=20Warning:=20Outlook=20in=20 use.=20=20Upgrade=20to=20Eudora:=20<http://www.eudora.com >|Date:=20Fri,=2020=20Feb=202009=2007:08:07=20-0800|To: =20Hannes=20Tschofenig=20<[e-mail]>,=0D =0A=20=20=20=20=20=20=20=20"'Edge,=20Stephen'"=0D=0A=09<s [e-mail]>,=20"'ECRIT'"=20<[e-mail]>|From: =20Randall=20Gellens=20<[e-mail]>|Subject:=20Re :=20[Ecrit]=20Comments=20on=20Framework=20Draft |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,553 0"=3B=20a=3D"15650601"; bh=p2RpUnZ8Xf+8jtEjVrIPfh0uFYJUa1nu5t/8yI5SdRs=; b=VAkCJHQdLWgOxpzMahBcansAlSXQUObSeUk3sEW8uoBk0UwaWhvMbSJA HZg9zcI9/DMt6GuSNGtBpeDAztgRxFViyW/xPzr0vRYlyJWgvnYMM/BGk uDEkWUykQgfkZ/FRGn1jnXKYx0DjyFX9r8LtfXIhsXSE66ea3563P5eEZ U=;
X-IronPort-AV: E=McAfee;i="5100,188,5530"; a="15650601"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Feb 2009 07:14:44 -0800
Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1KFEiRq009377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Feb 2009 07:14:44 -0800
Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1KFEhOb028770 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 20 Feb 2009 07:14:44 -0800 (PST)
Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 20 Feb 2009 07:14:43 -0800
Received: from [10.67.63.47] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 20 Feb 2009 07:14:43 -0800
Message-ID: <p06240607c5c3848061cf@[10.67.63.198]>
In-Reply-To: <003901c98772$b4cc7710$[e-mail]>
References: <[e-mail]> <003901c98772$b4cc7710$[e-mail]>
X-Mailer: Eudora for Mac OS X
X-message-flag: Warning: Outlook in use. Upgrade to Eudora: <http://www.eudora.com>
Date: Fri, 20 Feb 2009 07:08:07 -0800
To: Hannes Tschofenig <[e-mail]>, "'Edge, Stephen'" <[e-mail]>, "'ECRIT'" <[e-mail]>
From: Randall Gellens <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2009 15:14:31 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1620D3A6959 for <[e-mail]>; Fri, 20 Feb 2009 08:07:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.23
X-Spam-Level: 
X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.369,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XObkFJepWpTL for <[e-mail]>; Fri, 20 Feb 2009 08:07:14 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AA4413A69B0 for <[e-mail]>; Fri, 20 Feb 2009 08:07:13 -0800 (PST)
Received: (qmail invoked by alias); 20 Feb 2009 16:07:26 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp047) with SMTP; 20 Feb 2009 17:07:26 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18wEN4YtXQweP0PnC+WC1OHHiqTu/sacWYYid+zwj L814dno1Obh5vK
From: "Hannes Tschofenig" <[e-mail]>
To: "'Randall Gellens'" <[e-mail]>, "'Edge, Stephen'" <[e-mail]>, "'ECRIT'" <[e-mail]>
References: <[e-mail]> <003901c98772$b4cc7710$[e-mail]> <p06240607c5c3848061cf@[10.67.63.198]>
Date: Fri, 20 Feb 2009 18:08:20 +0200
Message-ID: <00a701c99375$757e2db0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <p06240607c5c3848061cf@[10.67.63.198]>
Thread-Index: AcmTbflMgC/OsqzlSgSSgJHyC6Sv5gABxINQ
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.57
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2009 16:07:15 -0000

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
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49EC3A6A78 for <[e-mail]>; Fri, 20 Feb 2009 08:28:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level: 
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFiciFNEncK5 for <[e-mail]>; Fri, 20 Feb 2009 08:28:55 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 5BC883A63D3 for <[e-mail]>; Fri, 20 Feb 2009 08:28:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[e-mail]; q=dns/txt; s=qcdkim; t=1235147350; x=1266683350; h=message-id:in-reply-to:references:x-mailer: x-message-flag:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20<p06240600c5c489e28911@[10.67.63.47]> |In-Reply-To:=20<00a701c99375$757e2db0$0201a8c0@nsnintra. net>|References:=20<1288E74A73964940B132A0B9EA8D8ABC535F0 [e-mail]>=0D=0A=20<003901c98772$b4 cc7710$[e-mail]>=0D=0A=20<p06240607c5c384806 1cf@[10.67.63.198]>=0D=0A=20<00a701c99375$757e2db0$0201a8 [e-mail]>|X-Mailer:=20Eudora=20for=20Mac=20OS=20X |X-message-flag:=20Warning:=20Outlook=20in=20use.=20=20Up grade=20to=20Eudora:=20<http://www.eudora.com>|Date:=20Fr i,=2020=20Feb=202009=2008:28:58=20-0800|To:=20Hannes=20Ts chofenig=20<[e-mail]>,=0D=0A=20=20=20=20 =20=20=20=20"'Randall=20Gellens'"=0D=0A=09<randy@qualcomm .com>,=0D=0A=20=20=20=20=20=20=20=20"'Edge,=20Stephen'" =20<[e-mail]>,=20"'ECRIT'"=0D=0A=09<ecrit@ietf. org>|From:=20Randall=20Gellens=20<[e-mail]> |Subject:=20RE:=20[Ecrit]=20Comments=20on=20Framework=20D raft|MIME-Version:=201.0|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"=3B=20format=3Dflowed |X-Random-Sig-Tag:=201.0b28|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5530"=3B=20a=3D"15670749"; bh=AK2iqqzWNrfUtmdDOB9+jxcqdvTp4iZ8tXDVtSv60Dg=; b=DKlVFd8ZAErZn8/ZYKj/e3dBAKeyK+NFGPGe3yulH7DI0trOwhcS226C EYj5IAAfqivKxmU2RLGkkCyXYVjIsK5Zs3i8VXpcN1cvdEF1EbaHJ4dYk 4dn0b/NpOyvTqjVafUn0eOhuspJHJTrDXNFGQiJ7EyXKE/YPzWjP/7R2f M=;
X-IronPort-AV: E=McAfee;i="5300,2777,5530"; a="15670749"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Feb 2009 08:29:07 -0800
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1KGT76k016858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Feb 2009 08:29:07 -0800
Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1KGT6XV026420 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 20 Feb 2009 08:29:07 -0800 (PST)
Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 20 Feb 2009 08:29:06 -0800
Received: from [10.67.63.47] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 20 Feb 2009 08:29:06 -0800
Message-ID: <p06240600c5c489e28911@[10.67.63.47]>
In-Reply-To: <00a701c99375$757e2db0$[e-mail]>
References: <[e-mail]> <003901c98772$b4cc7710$[e-mail]> <p06240607c5c3848061cf@[10.67.63.198]> <00a701c99375$757e2db0$[e-mail]>
X-Mailer: Eudora for Mac OS X
X-message-flag: Warning: Outlook in use. Upgrade to Eudora: <http://www.eudora.com>
Date: Fri, 20 Feb 2009 08:28:58 -0800
To: Hannes Tschofenig <[e-mail]>, "'Randall Gellens'" <[e-mail]>, "'Edge, Stephen'" <[e-mail]>, "'ECRIT'" <[e-mail]>
From: Randall Gellens <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2009 16:28:56 -0000

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.


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED1228C210 for <[e-mail]>; Fri, 20 Feb 2009 08:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NjmZeYMZzjW for <[e-mail]>; Fri, 20 Feb 2009 08:59:27 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 9BBF828C154 for <[e-mail]>; Fri, 20 Feb 2009 08:59:26 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2009_02_20_11_18_01
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 20 Feb 2009 11:18:01 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 10:58:33 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 20 Feb 2009 10:54:28 -0600
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmTeF5Dl31nt99SQqiNTStSkM555AAA4a8W
References: <[e-mail]><003901c98772$b4cc7710$[e-mail]><p06240607c5c3848061cf@[10.67.63.198]><00a701c99375$757e2db0$[e-mail]> <p06240600c5c489e28911@[10.67.63.47]>
From: "Winterbottom, James" <[e-mail]>
To: "Randall Gellens" <[e-mail]>, "Hannes Tschofenig" <[e-mail]>, "Edge, Stephen" <[e-mail]>, "ECRIT" <[e-mail]>
X-OriginalArrivalTime: 20 Feb 2009 16:58:33.0344 (UTC) FILETIME=[76B30000:01C9937C]
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2009 16:59:28 -0000

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=
[e-mail] 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=[e-mail]=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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D2A28C12B for <[e-mail]>; Fri, 20 Feb 2009 09:07:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haGHRRkiro3D for <[e-mail]>; Fri, 20 Feb 2009 09:07:07 -0800 (PST)
Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 64EFD28C110 for <[e-mail]>; Fri, 20 Feb 2009 09:07:07 -0800 (PST)
Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n1KH6x35021418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Feb 2009 12:07:07 -0500 (EST)
Message-Id: <[e-mail]>
From: Henning Schulzrinne <[e-mail]>
To: Randall Gellens <[e-mail]>
In-Reply-To: <p06240600c5c489e28911@[10.67.63.47]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 20 Feb 2009 12:06:59 -0500
References: <[e-mail]> <003901c98772$b4cc7710$[e-mail]> <p06240607c5c3848061cf@[10.67.63.198]> <00a701c99375$757e2db0$[e-mail]> <p06240600c5c489e28911@[10.67.63.47]>
X-Mailer: Apple Mail (2.930.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6
Cc: 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2009 17:07:08 -0000

>
> 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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5E43A6A5C for <[e-mail]>; Fri, 20 Feb 2009 09:20:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.25
X-Spam-Level: 
X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOLCtGMBKh7o for <[e-mail]>; Fri, 20 Feb 2009 09:20:03 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5170E3A6872 for <[e-mail]>; Fri, 20 Feb 2009 09:20:02 -0800 (PST)
Received: (qmail invoked by alias); 20 Feb 2009 17:20:16 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp069) with SMTP; 20 Feb 2009 18:20:16 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+P0kxLb76P2pW3wpjc3npnmzVKFC5o0/BCnsnX5c 5cUh7Lqd7cQ569
From: "Hannes Tschofenig" <[e-mail]>
To: "'Randall Gellens'" <[e-mail]>, "'Edge, Stephen'" <[e-mail]>, "'ECRIT'" <[e-mail]>
References: <[e-mail]> <003901c98772$b4cc7710$[e-mail]> <p06240607c5c3848061cf@[10.67.63.198]> <00a701c99375$757e2db0$[e-mail]> <p06240600c5c489e28911@[10.67.63.47]>
Date: Fri, 20 Feb 2009 19:21:12 +0200
Message-ID: <00c101c9937f$a2bcc660$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <p06240600c5c489e28911@[10.67.63.47]>
Thread-Index: AcmTeFzbdvBjJ00eTn6YXJ8jHRk8pgABnerw
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.71
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2009 17:20:04 -0000

>>  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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CE643A6BF6 for <[e-mail]>; Fri, 20 Feb 2009 10:39:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l93j5Ximnx48 for <[e-mail]>; Fri, 20 Feb 2009 10:39:03 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 186B63A680E for <[e-mail]>; Fri, 20 Feb 2009 10:39:03 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,242,1233532800"; d="scan'208";a="37833277"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Feb 2009 18:39:17 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1KIdHKc021464;  Fri, 20 Feb 2009 13:39:17 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1KIdHXo025506; Fri, 20 Feb 2009 18:39:17 GMT
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 20 Feb 2009 13:39:17 -0500
Received: from [10.67.63.181] ([10.82.253.207]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 20 Feb 2009 13:39:16 -0500
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Fri, 20 Feb 2009 13:39:15 -0500
From: Marc Linsner <[e-mail]>
To: Randall Gellens <[e-mail]>, "'ECRIT'" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmTiofOlBHQSl5S10SIhyaYj6WI3g==
In-Reply-To: <p06240600c5c489e28911@[10.67.63.47]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 20 Feb 2009 18:39:16.0716 (UTC) FILETIME=[88D462C0:01C9938A]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1612; t=1235155157; x=1236019157; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Marc=20Linsner=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20Comments=20on=20Framework=20D raft |Sender:=20 |To:=20Randall=20Gellens=20<[e-mail]>,=20=22'ECRI T'=22=20<[e-mail]>; bh=XbzpMH5ZUX45C7RcXgeSMpqjLZfv0GmT/QCJ5IJJDAk=; b=MvOHPEj1ujAvlF/ZYlTEhhYYHXRvYGm8kJGd0YBpZsnYzB4uRMRhrj1PZk M8EUtjDRgbgfJ8UK4ocmXCYrszDIGkhoC4yNrXpUTG2WW3M41xfrsbow9gZS lJSbM3yY94;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); 
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2009 18:39:05 -0000

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" <[e-mail]> 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.




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E80B3A67B4 for <[e-mail]>; Fri, 20 Feb 2009 13:40:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VewjwMTderV4 for <[e-mail]>; Fri, 20 Feb 2009 13:39:59 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id DA9C43A67A4 for <[e-mail]>; Fri, 20 Feb 2009 13:39:59 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-13.tower-120.messagelabs.com!1235166013!27739275!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [144.160.20.53]
Received: (qmail 5607 invoked from network); 20 Feb 2009 21:40:14 -0000
Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-13.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 20 Feb 2009 21:40:14 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n1KLeBSc020647; Fri, 20 Feb 2009 16:40:13 -0500
Received: from 01GAF5142010621.AD.BLS.COM (01GAF5142010621.ad.bls.com [139.76.131.79]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n1KLe8Jj020601; Fri, 20 Feb 2009 16:40:08 -0500
Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 20 Feb 2009 16:40:08 -0500
Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 20 Feb 2009 16:40:08 -0500
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 20 Feb 2009 16:39:59 -0500
Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0D1FB88C@crexc41p>
In-Reply-To: <p06240600c5c489e28911@[10.67.63.47]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Comments on Framework Draft
thread-index: AcmTeGJsoBLvJ+6vTOqN4erzE4y2FgAKGNtA
References: <[e-mail]><003901c98772$b4cc7710$[e-mail]><p06240607c5c3848061cf@[10.67.63.198]><00a701c99375$757e2db0$[e-mail]> <p06240600c5c489e28911@[10.67.63.47]>
From: "Stark, Barbara" <[e-mail]>
To: "Randall Gellens" <[e-mail]>, "Hannes Tschofenig" <[e-mail]>, "Edge, Stephen" <[e-mail]>, "ECRIT" <[e-mail]>
X-OriginalArrivalTime: 20 Feb 2009 21:40:08.0316 (UTC) FILETIME=[CCE323C0:01C993A3]
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2009 21:40:01 -0000

<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: [e-mail] [mailto:[e-mail]] 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
[e-mail]
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




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E06D28C217 for <[e-mail]>; Fri, 20 Feb 2009 16:28:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfQUv201ODpz for <[e-mail]>; Fri, 20 Feb 2009 16:28:32 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 3F59428C18A for <[e-mail]>; Fri, 20 Feb 2009 16:28:31 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2009_02_20_18_48_14
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 20 Feb 2009 18:48:14 -0600
Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 18:28:46 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 20 Feb 2009 18:28:43 -0600
Message-ID: <[e-mail]>
In-Reply-To: <p06240600c5c489e28911@[10.67.63.47]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmTeF5hx4WNojVNQTy60SBtFJN2ewAQmK5A
References: <[e-mail]><003901c98772$b4cc7710$[e-mail]><p06240607c5c3848061cf@[10.67.63.198]><00a701c99375$757e2db0$[e-mail]> <p06240600c5c489e28911@[10.67.63.47]>
From: "Dawson, Martin" <[e-mail]>
To: "Randall Gellens" <[e-mail]>, "Hannes Tschofenig" <[e-mail]>, "Edge, Stephen" <[e-mail]>, "ECRIT" <[e-mail]>
X-OriginalArrivalTime: 21 Feb 2009 00:28:46.0588 (UTC) FILETIME=[5BD8EBC0:01C993BB]
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 21 Feb 2009 00:28:33 -0000

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: [e-mail] [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=[e-mail]=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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4238B3A6836 for <[e-mail]>; Thu, 19 Feb 2009 05:56:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 338txHTM7yor for <[e-mail]>; Thu, 19 Feb 2009 05:56:53 -0800 (PST)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5AB893A6AD8 for <[e-mail]>; Thu, 19 Feb 2009 05:56:53 -0800 (PST)
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6FBAE21642; Thu, 19 Feb 2009 14:57:05 +0100 (CET)
X-AuditID: c1b4fb3e-ab0b9bb000001315-7a-499d653156b5
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 57EEF2162A; Thu, 19 Feb 2009 14:57:05 +0100 (CET)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 19 Feb 2009 14:57:04 +0100
Received: from [153.88.44.232] ([153.88.44.232]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 19 Feb 2009 14:57:04 +0100
Message-ID: <[e-mail]>
Date: Thu, 19 Feb 2009 15:57:04 +0200
From: Gonzalo Camarillo <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Feb 2009 13:57:04.0583 (UTC) FILETIME=[F2142D70:01C99299]
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Sun, 22 Feb 2009 11:26:05 -0800
Subject: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2009 13:56:54 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D563A6B18 for <[e-mail]>; Mon, 23 Feb 2009 03:25:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqO2nz9YJxby for <[e-mail]>; Mon, 23 Feb 2009 03:25:07 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 6A7793A6874 for <[e-mail]>; Mon, 23 Feb 2009 03:25:06 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1NBPJO6007953 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 23 Feb 2009 12:25:19 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 23 Feb 2009 12:25:19 +0100
From: "DRAGE, Keith (Keith)" <[e-mail]>
To: "Winterbottom, James" <[e-mail]>, Randall Gellens <[e-mail]>, Hannes Tschofenig <[e-mail]>, "Edge, Stephen" <[e-mail]>, ECRIT <[e-mail]>
Date: Mon, 23 Feb 2009 12:25:17 +0100
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmTeF5Dl31nt99SQqiNTStSkM555AAA4a8WAIskkHA=
Message-ID: <[e-mail]>
References: <[e-mail]><003901c98772$b4cc7710$[e-mail]><p06240607c5c3848061cf@[10.67.63.198]><00a701c99375$757e2db0$[e-mail]> <p06240600c5c489e28911@[10.67.63.47]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2009 11:25:09 -0000

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: [e-mail] [mailto:[e-mail]]=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: [e-mail] 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
> =


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87913A6861 for <[e-mail]>; Mon, 23 Feb 2009 03:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.422
X-Spam-Level: 
X-Spam-Status: No, score=-5.422 tagged_above=-999 required=5 tests=[AWL=1.177,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 548ARzXFE8xY for <[e-mail]>; Mon, 23 Feb 2009 03:58:44 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 52B0F3A67A1 for <[e-mail]>; Mon, 23 Feb 2009 03:58:44 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1NBws3U026295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Feb 2009 12:58:54 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1NBws96007907; Mon, 23 Feb 2009 12:58:54 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 23 Feb 2009 12:58:54 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Feb 2009 13:59:51 +0200
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmTeF5Dl31nt99SQqiNTStSkM555AAA4a8WAIskkHAAALu1AA==
References: <[e-mail]><003901c98772$b4cc7710$[e-mail]><p06240607c5c3848061cf@[10.67.63.198]><00a701c99375$757e2db0$[e-mail]><p06240600c5c489e28911@[10.67.63.47]><[e-mail]> <[e-mail]>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>
To: "ext DRAGE, Keith (Keith)" <[e-mail]>, "Winterbottom, James" <[e-mail]>, "Randall Gellens" <[e-mail]>, "Hannes Tschofenig" <[e-mail]>, "Edge,Stephen" <[e-mail]>, "ECRIT" <[e-mail]>
X-OriginalArrivalTime: 23 Feb 2009 11:58:54.0170 (UTC) FILETIME=[198403A0:01C995AE]
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2009 11:58:45 -0000

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: [e-mail] [mailto:[e-mail]]=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: [e-mail] [mailto:[e-mail]]=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: [e-mail] 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
>> [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>=20
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68EC53A69F1 for <[e-mail]>; Mon, 23 Feb 2009 11:47:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asnec2D1SHoC for <[e-mail]>; Mon, 23 Feb 2009 11:47:40 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id C35743A69DF for <[e-mail]>; Mon, 23 Feb 2009 11:47:39 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2009_02_23_14_07_27
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 23 Feb 2009 14:07:27 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 13:47:55 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Feb 2009 13:47:54 -0600
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmTeF5Dl31nt99SQqiNTStSkM555AAA4a8WAIskkHAAALu1AAAQ3aW7
References: <[e-mail]><003901c98772$b4cc7710$[e-mail]><p06240607c5c3848061cf@[10.67.63.198]><00a701c99375$757e2db0$[e-mail]><p06240600c5c489e28911@[10.67.63.47]><[e-mail]> <[e-mail]> <[e-mail]>
From: "Winterbottom, James" <[e-mail]>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>, "ext DRAGE, Keith (Keith)" <[e-mail]>, "Randall Gellens" <[e-mail]>, "Hannes Tschofenig" <[e-mail]>, "Edge,Stephen" <[e-mail]>, "ECRIT" <[e-mail]>
X-OriginalArrivalTime: 23 Feb 2009 19:47:55.0461 (UTC) FILETIME=[9F083F50:01C995EF]
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2009 19:47:41 -0000

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=
[e-mail]]=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: [e-mail] [mailto:[e-mail]]=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: [e-mail] [mail=
to:[e-mail]]=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: [e-mail] 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>> [e-mail]=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>> [e-mail]=0D=0A>> https://=
www.ietf.org/mailman/listinfo/ecrit=0D=0A>>=20=0D=0A>______________________=
_________________________=0D=0A>Ecrit mailing list=0D=0A>[e-mail]=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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297733A6914 for <[e-mail]>; Mon, 23 Feb 2009 23:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.647
X-Spam-Level: 
X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[AWL=0.952,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x91MV7KUe9TE for <[e-mail]>; Mon, 23 Feb 2009 23:14:06 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4C9C13A679C for <[e-mail]>; Mon, 23 Feb 2009 23:14:05 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1O7EIIl005460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Feb 2009 08:14:18 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1O7EIC8015381; Tue, 24 Feb 2009 08:14:18 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 24 Feb 2009 08:14:18 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Feb 2009 09:15:16 +0200
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmTeF5Dl31nt99SQqiNTStSkM555AAA4a8WAIskkHAAALu1AAAQ3aW7ABgwGwA=
References: <[e-mail]><003901c98772$b4cc7710$[e-mail]><p06240607c5c3848061cf@[10.67.63.198]><00a701c99375$757e2db0$[e-mail]><p06240600c5c489e28911@[10.67.63.47]><[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>
To: "ext Winterbottom, James" <[e-mail]>, "ext DRAGE, Keith (Keith)" <[e-mail]>, "Randall Gellens" <[e-mail]>, "Hannes Tschofenig" <[e-mail]>, "Edge,Stephen" <[e-mail]>, "ECRIT" <[e-mail]>
X-OriginalArrivalTime: 24 Feb 2009 07:14:18.0289 (UTC) FILETIME=[81E91A10:01C9964F]
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2009 07:14:08 -0000

I agree with your statement, James.=20

=20

>-----Original Message-----
>From: ext Winterbottom, James [mailto:[e-mail]]=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:[e-mail]]
>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: [e-mail] [mailto:[e-mail]]=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: [e-mail] [mailto:[e-mail]]
>>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: [e-mail] 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
>>> [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>=20
>>_______________________________________________
>>Ecrit mailing list
>>[e-mail]
>>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]
>
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C4F3A6982 for <[e-mail]>; Tue, 24 Feb 2009 06:00:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd+L9nWryBrS for <[e-mail]>; Tue, 24 Feb 2009 05:59:59 -0800 (PST)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 7B80C3A6966 for <[e-mail]>; Tue, 24 Feb 2009 05:59:59 -0800 (PST)
Received: from col-dhcp33-244-189.bbn.com ([128.33.244.189]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1LbxpW-0005c1-DE for [e-mail]; Tue, 24 Feb 2009 09:00:14 -0500
Message-ID: <[e-mail]>
Date: Tue, 24 Feb 2009 09:00:13 -0500
From: Richard Barnes <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: ECRIT <[e-mail]>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Ecrit] [Fwd: New Version Notification for draft-barnes-ecrit-rough-loc-02]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2009 14:00:00 -0000

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 <[e-mail]>
To: [e-mail]
CC: [e-mail]


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.





Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322133A6A1E; Tue, 24 Feb 2009 13:10:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+bY+kj+w9EK; Tue, 24 Feb 2009 13:10:04 -0800 (PST)
Received: from mail170.messagelabs.com (mail170.messagelabs.com [216.82.253.227]) by core3.amsl.com (Postfix) with ESMTP id 3CC3B3A6981; Tue, 24 Feb 2009 13:10:04 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-10.tower-170.messagelabs.com!1235509821!16311231!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [20.137.2.87]
Received: (qmail 7637 invoked from network); 24 Feb 2009 21:10:22 -0000
Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-10.tower-170.messagelabs.com with AES256-SHA encrypted SMTP; 24 Feb 2009 21:10:22 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n1OLAKhI012039; Tue, 24 Feb 2009 16:10:21 -0500
In-Reply-To: <[e-mail]>
To: "James M. Polk" <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 24 Feb 2009 16:10:16 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 02/24/2009 04:12:40 PM, Serialize complete at 02/24/2009 04:12:40 PM
Content-Type: multipart/alternative; boundary="=_alternative 00744BD985257567_="
Cc: 'ECRIT' <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2009 21:10:07 -0000

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" <[e-mail]> 
Sent by: [e-mail]
02/19/2009 09:32 PM

To
"'ECRIT'" <[e-mail]>
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 <[e-mail]>
>To: [e-mail]
>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
[e-mail]
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;[e-mail]&gt;</b> </font>
<br><font size=1 face="sans-serif">Sent by: [e-mail]</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;[e-mail]&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;[e-mail]&gt;<br>
&gt;To: [e-mail]<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>
[e-mail]<br>
https://www.ietf.org/mailman/listinfo/ecrit<br>
</tt></font>
<br>
--=_alternative 00744BD985257567_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C893A67B2 for <[e-mail]>; Tue, 24 Feb 2009 19:23:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDo66uGY2ohx for <[e-mail]>; Tue, 24 Feb 2009 19:23:58 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 76D733A68FF for <[e-mail]>; Tue, 24 Feb 2009 19:23:53 -0800 (PST)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 25 Feb 2009 11:24:06 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 25 Feb 2009 11:24:06 +0800 (CST)
Received: from [10.85.203.87] by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 25 Feb 2009 11:24:06 +0800 (CST)
Date: Wed, 25 Feb 2009 11:24:06 +0800
From: Robins George <[e-mail]>
To: ECRIT IETF <[e-mail]>
Message-id: <[e-mail]>
Organization: Huawei Technologies Co. Ltd
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
Subject: [Ecrit] draft-george-ecrit-lamp-post-00]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 03:23:58 -0000

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.





                       







-- 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B2A3A6A07 for <[e-mail]>; Tue, 24 Feb 2009 19:56:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH280vfooSBj for <[e-mail]>; Tue, 24 Feb 2009 19:56:31 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 4C0423A69BA for <[e-mail]>; Tue, 24 Feb 2009 19:56:31 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2009_02_24_22_16_23
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 24 Feb 2009 22:16:23 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 21:56:50 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Feb 2009 21:56:48 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] draft-george-ecrit-lamp-post-00]
Thread-Index: AcmW+I5jS2UNGmJ0SzCe6mCWqB0oCQABEtgw
References: <[e-mail]>
From: "Winterbottom, James" <[e-mail]>
To: <[e-mail]>, "ECRIT IETF" <[e-mail]>
X-OriginalArrivalTime: 25 Feb 2009 03:56:50.0128 (UTC) FILETIME=[1644F500:01C996FD]
Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 03:56:32 -0000

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: [e-mail] [mailto:[e-mail]] 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=
[e-mail]=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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAE973A67DD for <[e-mail]>; Tue, 24 Feb 2009 20:00:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7ttuJXHjOg2 for <[e-mail]>; Tue, 24 Feb 2009 20:00:10 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 1A6C93A67CF for <[e-mail]>; Tue, 24 Feb 2009 20:00:09 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2009_02_24_22_20_02
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 24 Feb 2009 22:20:02 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 22:00:29 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Feb 2009 22:00:28 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] draft-george-ecrit-lamp-post-00]
Thread-Index: AcmW+I5jS2UNGmJ0SzCe6mCWqB0oCQABLA5g
References: <[e-mail]>
From: "Winterbottom, James" <[e-mail]>
To: <[e-mail]>, "ECRIT IETF" <[e-mail]>
X-OriginalArrivalTime: 25 Feb 2009 04:00:29.0336 (UTC) FILETIME=[98ED7180:01C996FD]
Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 04:00:11 -0000

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=
[e-mail] [mailto:[e-mail]] 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=[e-mail]=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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66BDF28C19C for <[e-mail]>; Wed, 25 Feb 2009 09:16:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.136
X-Spam-Level: 
X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.113,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzTZOcwgzpE0 for <[e-mail]>; Wed, 25 Feb 2009 09:15:59 -0800 (PST)
Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 7720D28C247 for <[e-mail]>; Wed, 25 Feb 2009 09:15:59 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1PHGIe8018520 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Wed, 25 Feb 2009 18:16:18 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 25 Feb 2009 18:16:18 +0100
From: "DRAGE, Keith (Keith)" <[e-mail]>
To: ECRIT <[e-mail]>
Date: Wed, 25 Feb 2009 18:16:17 +0100
Thread-Topic: ECRIT interim meeting
Thread-Index: AcmXazTenS7wUGfMRK6q60QME7uaMg==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84
Subject: [Ecrit] ECRIT interim meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 17:16:00 -0000

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=


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EBCC3A68CB for <[e-mail]>; Wed, 25 Feb 2009 09:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.297
X-Spam-Level: 
X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kreoWWIFkIJ for <[e-mail]>; Wed, 25 Feb 2009 09:25:28 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5B08F3A687A for <[e-mail]>; Wed, 25 Feb 2009 09:25:23 -0800 (PST)
Received: (qmail invoked by alias); 25 Feb 2009 17:25:37 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp047) with SMTP; 25 Feb 2009 18:25:37 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+kvUcF5HqkzXuaAp4nkOdTx9ITuMMwL52IAcuLcg MVCXOT6JMTuZZN
From: "Hannes Tschofenig" <[e-mail]>
To: "'DRAGE, Keith \(Keith\)'" <[e-mail]>, "'ECRIT'" <[e-mail]>
References: <[e-mail]>
Date: Wed, 25 Feb 2009 19:26:36 +0200
Message-ID: <006401c9976e$373e0d20$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcmXazTenS7wUGfMRK6q60QME7uaMgAAi/cg
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.62
Subject: [Ecrit] REMINDER: ECRIT interim meeting - 26th February, 2:00 PM EST
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 17:25:29 -0000

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: [e-mail] [mailto:[e-mail]] 
>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7141A3A6923 for <[e-mail]>; Wed, 25 Feb 2009 10:46:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.373
X-Spam-Level: 
X-Spam-Status: No, score=-1.373 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ze7ccrcTzKfq for <[e-mail]>; Wed, 25 Feb 2009 10:46:31 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CDA883A6848 for <[e-mail]>; Wed, 25 Feb 2009 10:46:30 -0800 (PST)
Received: (qmail invoked by alias); 25 Feb 2009 18:46:46 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp008) with SMTP; 25 Feb 2009 19:46:46 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18aSWIQbZkapd7BjLDc5qZ8XadS2AdM+/4WjlC4j+ yaRWpFJE9AEHYU
From: "Hannes Tschofenig" <[e-mail]>
To: "'ECRIT'" <[e-mail]>
Date: Wed, 25 Feb 2009 20:47:46 +0200
Message-ID: <00ab01c99779$8d516ad0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcmXeYzAy+YFJEnNSsKu3ZSIVh0zGw==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.82
Subject: [Ecrit] Slides, Please
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 18:46:32 -0000

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




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C6728C334 for <[e-mail]>; Wed, 25 Feb 2009 12:26:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0O6KTrCTiH1C for <[e-mail]>; Wed, 25 Feb 2009 12:26:05 -0800 (PST)
Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 8D86928C2E2 for <[e-mail]>; Wed, 25 Feb 2009 12:26:04 -0800 (PST)
Received: by ewy25 with SMTP id 25so297043ewy.37 for <[e-mail]>; Wed, 25 Feb 2009 12:26:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BkpTisnrn/sheNpGNT6sbNEXGDlWGcm/Yv9WMvppAPY=; b=v246bx1uXVr8a6tl/X+JCJsYusftkF4saVYm4KmSmm606PNNqF1fEKYHdTg2oLwD62 feuQE1UqP1B94jxK6hAxC4+BxKej2fja8CNBiBrc4rHACGgnc+FvuZvMrr5WeNeia2do p36vTsd+FIQKjONRXaPjJBH4FaAjQyTSFi+A0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WEU+5rfIjcQuWAmV/JpwZzVqcoiLW+zZ+MhfUFVabJSoMrPYs8NZv7cvzwQesI2UdP 6azS84ftFRoabjPkwe6w9mdm3pUXJYT+VICWnCRoEo9I5GyqtyHLNNli7wHc80lUK2IB TdXKW/naIE9V9kHPrNcVfYRUse82oQMQTDzQE=
MIME-Version: 1.0
Received: by 10.220.95.202 with SMTP id e10mr470795vcn.12.1235593583477; Wed,  25 Feb 2009 12:26:23 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Wed, 25 Feb 2009 15:26:23 -0500
Message-ID: <[e-mail]>
From: Karl Heinz Wolf <[e-mail]>
To: "Winterbottom, James" <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ECRIT IETF <[e-mail]>
Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 20:26:05 -0000

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
<[e-mail]> 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: [e-mail] [mailto:[e-mail]] 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46D763A6B85; Wed, 25 Feb 2009 16:40:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.021
X-Spam-Level: 
X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiWCEFGSw15r; Wed, 25 Feb 2009 16:40:18 -0800 (PST)
Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 472603A6B1B; Wed, 25 Feb 2009 16:40:18 -0800 (PST)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Thu, 26 Feb 2009 08:40:28 +0800 (CST)
Received: from huawei.com ([172.24.1.12]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Thu, 26 Feb 2009 08:40:28 +0800 (CST)
Received: from [10.85.203.87] by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <[e-mail]>; Thu, 26 Feb 2009 08:40:28 +0800 (CST)
Date: Thu, 26 Feb 2009 08:40:30 +0800
From: Robins George <[e-mail]>
In-reply-to: <[e-mail]>
To: Karl Heinz Wolf <[e-mail]>
Message-id: <[e-mail]>
Organization: Huawei Technologies Co. Ltd
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Cc: GEOPRIV <[e-mail]>, ECRIT IETF <[e-mail]>
Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2009 00:40:19 -0000

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
> <[e-mail]> 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: [e-mail] [mailto:[e-mail]] 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.
>>
>>
>>
>>
>>     



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E8728C178; Wed, 25 Feb 2009 17:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC8PIOwp9MjD; Wed, 25 Feb 2009 17:01:40 -0800 (PST)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id DFA6328C112; Wed, 25 Feb 2009 17:01:39 -0800 (PST)
Received: from [128.89.254.78] (helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1LcUdT-0000yn-Dz; Wed, 25 Feb 2009 20:01:59 -0500
Message-ID: <[e-mail]>
Date: Wed, 25 Feb 2009 20:01:58 -0500
From: Richard Barnes <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: GEOPRIV <[e-mail]>, ECRIT IETF <[e-mail]>
Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2009 01:01:41 -0000

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
>> <[e-mail]> 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: [e-mail] [mailto:[e-mail]] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
> 


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C537F28C280 for <[e-mail]>; Wed, 25 Feb 2009 18:12:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level: 
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQKx3TAzsjay for <[e-mail]>; Wed, 25 Feb 2009 18:12:38 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 836E43A6BC2 for <[e-mail]>; Wed, 25 Feb 2009 18:12:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[e-mail]; q=dns/txt; s=qcdkim; t=1235614380; x=1267150380; 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<[e-mail]>|To:=20B rian=20Rosen=20<[e-mail]>,=20"'ECRIT'"=20<ecrit@ ietf.org>|Date:=20Wed,=2025=20Feb=202009=2018:10:51=20-08 00|Subject:=20RE:=20[Ecrit]=20Comments=20on=20Framework =20Draft|Thread-Topic:=20[Ecrit]=20Comments=20on=20Framew ork=20Draft|Thread-Index:=20AcmHZkcFqEtDIGTNRMy2Xqm0XoWoX wKeEe+gADZBfMA=3D|Message-ID:=20<1288E74A73964940B132A0B9 [e-mail]>|References: =20<1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04. na.qualcomm.com>=0D=0A=20<0a8d01c991ff$fd063420$f7129c60$ @net>|In-Reply-To:=20<0a8d01c991ff$fd063420$f7129c60$@net >|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"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5536"=3B=20a=3D"15807688"; bh=S3FVPKrjxosR5XTea53KMrbRscsfOlVLarhLF1IJ9JA=; b=yE6MJ0tZQyMRiJs9nZkCv/7BkZlWyiLcPpVAUh3UjkzRW4x7WLxwpY1q o5bZQuKjPmYZZ8bw9bi3QGQlziI85JBWHVtqWr6lbgCydP6v97tEGMiiF 6fQQmm1ZdSjEsei2AhhqeI17F4CJMDXP4IDNgCPP2BZdLntlWjj47An6y k=;
X-IronPort-AV: E=McAfee;i="5300,2777,5536"; a="15807688"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Feb 2009 18:12:58 -0800
Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1Q2CvOk016090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Feb 2009 18:12:58 -0800
Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1Q2CmLd025684 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Feb 2009 18:12:57 -0800
Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Wed, 25 Feb 2009 18:12:48 -0800
From: "Edge, Stephen" <[e-mail]>
To: Brian Rosen <[e-mail]>, "'ECRIT'" <[e-mail]>
Date: Wed, 25 Feb 2009 18:10:51 -0800
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+gADZBfMA=
Message-ID: <[e-mail]>
References: <[e-mail]> <0a8d01c991ff$fd063420$f7129c60$@net>
In-Reply-To: <0a8d01c991ff$fd063420$f7129c60$@net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2009 02:12:40 -0000

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:[e-mail]]=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: [e-mail] [mailto:[e-mail]] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0128928C2A7 for <[e-mail]>; Wed, 25 Feb 2009 18:29:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NQWil9EETWg for <[e-mail]>; Wed, 25 Feb 2009 18:29:47 -0800 (PST)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 717FB3A6783 for <[e-mail]>; Wed, 25 Feb 2009 18:29:47 -0800 (PST)
Received: from [128.89.254.78] (helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1LcW0k-0001W0-Fd; Wed, 25 Feb 2009 21:30:07 -0500
Message-ID: <[e-mail]>
Date: Wed, 25 Feb 2009 21:30:06 -0500
From: Richard Barnes <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: "Edge, Stephen" <[e-mail]>
References: <[e-mail]>	<0a8d01c991ff$fd063420$f7129c60$@net> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'ECRIT' <[e-mail]>
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2009 02:29:49 -0000

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:[e-mail]] 
> 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: [e-mail] [mailto:[e-mail]] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
> 


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258413A699E for <[e-mail]>; Wed, 25 Feb 2009 20:48:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3V-dX6GJFcOv for <[e-mail]>; Wed, 25 Feb 2009 20:47:59 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 834CC3A696D for <[e-mail]>; Wed, 25 Feb 2009 20:47:41 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2009_02_25_23_07_36
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 25 Feb 2009 23:07:35 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 22:48:02 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 25 Feb 2009 22:47:59 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Comments on Framework Draft
Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+gADZBfMABQDsYoA==
References: <[e-mail]><0a8d01c991ff$fd063420$f7129c60$@net> <[e-mail]>
From: "Winterbottom, James" <[e-mail]>
To: "Edge, Stephen" <[e-mail]>, "Brian Rosen" <[e-mail]>, "ECRIT" <[e-mail]>
X-OriginalArrivalTime: 26 Feb 2009 04:48:02.0023 (UTC) FILETIME=[67ACAF70:01C997CD]
Subject: Re: [Ecrit] Comments on Framework Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2009 04:48:01 -0000

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=
[e-mail] [mailto:[e-mail]] 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:[e-mail]]=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: [e-mail] [mailto:[e-mail]] 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> [e-mail]=0D=0A> https:=
//www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A__________________________=
_____________________=0D=0AEcrit mailing list=0D=[e-mail]=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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0423A6BAA; Thu, 26 Feb 2009 04:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGF21dPwamdJ; Thu, 26 Feb 2009 04:35:22 -0800 (PST)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 6C9C83A6A8C; Thu, 26 Feb 2009 04:35:19 -0800 (PST)
Received: from 12-198-63-152att-inc.com (12-198-63-152att-inc.com [12.198.63.152] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n1QCZXLF021449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Feb 2009 07:35:35 -0500 (EST)
Message-Id: <[e-mail]>
From: Henning Schulzrinne <[e-mail]>
To: Richard Barnes <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Thu, 26 Feb 2009 07:35:33 -0500
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8
Cc: GEOPRIV <[e-mail]>, ECRIT IETF <[e-mail]>
Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2009 12:35:23 -0000

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
>>> <[e-mail]> 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: [e-mail] [mailto:[e-mail]] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524753A6784; Thu, 26 Feb 2009 11:39:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WJ0fnBvJbIZ; Thu, 26 Feb 2009 11:38:59 -0800 (PST)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3D8583A677C; Thu, 26 Feb 2009 11:38:59 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,272,1233532800"; d="scan'208";a="137879810"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 26 Feb 2009 19:39:21 +0000
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n1QJdL39028061;  Thu, 26 Feb 2009 11:39:21 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n1QJdGhL002045; Thu, 26 Feb 2009 19:39:21 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 26 Feb 2009 11:39:17 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.23.24]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 26 Feb 2009 11:39:17 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 26 Feb 2009 13:39:12 -0600
To: Janet P Gunn <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <OF5FF02369.092E58AD-ON85257567.00735259-85257567.00744C3C@ csc.com>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 26 Feb 2009 19:39:17.0319 (UTC) FILETIME=[E96F4D70:01C99849]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16743; t=1235677161; x=1236541161; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20draft-ietf-ecrit-local-emerge ncy-rph-namespace-01=0A=20=20submitted |Sender:=20; bh=hiKRKh+o64SI5iTdqQAq/Uc1oFXvEx1GdFtWH5b6kuM=; b=OsLHvsAF5rroWkFutgdujPAyn9j81Co1ndQfzTIkTd+xBJe4jT7Fq8f+mz RghmJ03IWfMIT5BUVpTVkQpRwFc5mUUOOpt7YvZKQsm7aKWdHiYJb8SZ2MBY NKnWQjGBbF;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: 'ECRIT' <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2009 19:39:01 -0000

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" <[e-mail]>
>Sent by: [e-mail]
>
>02/19/2009 09:32 PM
>To
>"'ECRIT'" <[e-mail]>
>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 <[e-mail]>
> >To: [e-mail]
> >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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586BB28C2F3 for <[e-mail]>; Thu, 26 Feb 2009 12:59:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level: 
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.039,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk8XMD049REJ for <[e-mail]>; Thu, 26 Feb 2009 12:59:53 -0800 (PST)
Received: from blu0-omc3-s4.blu0.hotmail.com (blu0-omc3-s4.blu0.hotmail.com [65.55.116.79]) by core3.amsl.com (Postfix) with ESMTP id E26843A67A7 for <[e-mail]>; Thu, 26 Feb 2009 12:59:52 -0800 (PST)
Received: from BLU137-W24 ([65.55.116.72]) by blu0-omc3-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 26 Feb 2009 13:00:14 -0800
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_4b5be22a-e6cb-49e0-8b6a-7db62790b04e_"
X-Originating-IP: [24.16.117.112]
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Date: Thu, 26 Feb 2009 13:00:14 -0800
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Feb 2009 21:00:14.0535 (UTC) FILETIME=[388FA570:01C99855]
Subject: [Ecrit] Comments on "Extensions for dealing with Unauthenticated and Unauthorized Devices"
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2009 20:59:54 -0000

--_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_--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EFC33A6C15; Thu, 26 Feb 2009 13:52:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.448
X-Spam-Level: 
X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LOW=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+gOPwezTeYT; Thu, 26 Feb 2009 13:52:05 -0800 (PST)
Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by core3.amsl.com (Postfix) with ESMTP id 824B03A6C10; Thu, 26 Feb 2009 13:52:04 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-2.tower-85.messagelabs.com!1235685144!46234341!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 26323 invoked from network); 26 Feb 2009 21:52:24 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-2.tower-85.messagelabs.com with AES256-SHA encrypted SMTP; 26 Feb 2009 21:52:24 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n1QLqOda017986; Thu, 26 Feb 2009 16:52:24 -0500
In-Reply-To: <[e-mail]>
To: "James M. Polk" <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 26 Feb 2009 16:52:20 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 02/26/2009 04:54:43 PM, Serialize complete at 02/26/2009 04:54:43 PM
Content-Type: multipart/alternative; boundary="=_alternative 0078257E85257569_="
Cc: 'ECRIT' <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2009 21:52:08 -0000

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" <[e-mail]> 
02/26/2009 02:39 PM

To
Janet P Gunn/FED/CSC@CSC
cc
"'ECRIT'" <[e-mail]>, [e-mail]
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" <[e-mail]>
>Sent by: [e-mail]
>
>02/19/2009 09:32 PM
>To
>"'ECRIT'" <[e-mail]>
>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 <[e-mail]>
> >To: [e-mail]
> >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
>[e-mail]
>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;[e-mail]&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;[e-mail]&gt;,
[e-mail]</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;[e-mail]&gt;<br>
&gt;Sent by: [e-mail]<br>
&gt;<br>
&gt;02/19/2009 09:32 PM<br>
&gt;To<br>
&gt;&quot;'ECRIT'&quot; &lt;[e-mail]&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;[e-mail]&gt;<br>
&gt; &gt;To: [e-mail]<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;[e-mail]<br>
&gt;https://www.ietf.org/mailman/listinfo/ecrit<br>
<br>
</tt></font>
<br>
--=_alternative 0078257E85257569_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69ADC3A67EE; Thu, 26 Feb 2009 15:00:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.449
X-Spam-Level: 
X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LOW=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSXcocRiOpal; Thu, 26 Feb 2009 15:00:01 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id ED4D33A6835; Thu, 26 Feb 2009 15:00:00 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,273,1233532800"; d="scan'208";a="135784921"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 26 Feb 2009 23:00:22 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1QN0MoE014708;  Thu, 26 Feb 2009 15:00:22 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1QN0Mjx015852; Thu, 26 Feb 2009 23:00:22 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 26 Feb 2009 15:00:22 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.23.24]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 26 Feb 2009 15:00:21 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 26 Feb 2009 17:00:20 -0600
To: Janet P Gunn <[e-mail]>
From: "James M. Polk" <[e-mail]>
In-Reply-To: <OF4FC30562.46AC4B30-ON85257569.00740D33-85257569.00782613@ csc.com>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 26 Feb 2009 23:00:21.0976 (UTC) FILETIME=[0087DD80:01C99866]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23157; t=1235689222; x=1236553222; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22James=20M.=20Polk=22=20<[e-mail]> |Subject:=20Re=3A=20[Ecrit]=20draft-ietf-ecrit-local-emerge ncy-rph-namespace-01=20=0A=20=20submitted |Sender:=20; bh=oVjRmpppEvd9LLxiocA6EyCeVZOI7+fl7UdAUVzhw3Y=; b=A5FegGdWho3lS6cc4lfsqAUFmM8/LQRQgTvAjmogWqqYPPQmz52umfbf9Z EyBzxDVwWyQHjpI8OR09Xnckx9B7A134d6+zteQ/vv1GtG10gGCKaj6WJZxq azU7MzlKBY;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Cc: 'ECRIT' <[e-mail]>, [e-mail]
Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2009 23:00:03 -0000

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" <[e-mail]>
>
>02/26/2009 02:39 PM
>To
>Janet P Gunn/FED/CSC@CSC
>cc
>"'ECRIT'" <[e-mail]>, [e-mail]
>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" <[e-mail]>
> >Sent by: [e-mail]
> >
> >02/19/2009 09:32 PM
> >To
> >"'ECRIT'" <[e-mail]>
> >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 <[e-mail]>
> > >To: [e-mail]
> > >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
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ecrit
>