From mlinsner@cisco.com Wed Oct 10 10:54:28 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6796621F8735 for ; Wed, 10 Oct 2012 10:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meG6iOnCq0n3 for ; Wed, 10 Oct 2012 10:54:26 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2CD21F860F for ; Wed, 10 Oct 2012 10:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1082; q=dns/txt; s=iport; t=1349891664; x=1351101264; h=date:subject:from:to:message-id:mime-version; bh=/GcPbzlaxyTHlGHRq5PsF1ERVjLWRT1C1PfksFo92zQ=; b=OvuI5SE+viB2g0QtGiIsUJnU/iHTmhFudlXlz8j1WdT/O/XgAC571UpN PtenSP7/8+128m6U66slLotFXOAalRtyEEBZVAsILeI6LFK5cE5zNItEQ OHHLSAjl7Gr90QG41n08OJC3FkBwwP6g8C7LrsksktiaojfnOrmJ7oYvH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMO0dVCQ/khN/2dsb2JhbABEgku8ZoEIghcQEgEqTwsBAoEdNYdiliSBKKAgkWcDlWyFYohjgWuDCYFH X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; d="scan'208,217";a="8716538" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 10 Oct 2012 17:54:23 +0000 Received: from [10.61.100.147] (dhcp-10-61-100-147.cisco.com [10.61.100.147]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9AHsM6j023248 for ; Wed, 10 Oct 2012 17:54:22 GMT User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Wed, 10 Oct 2012 13:54:20 -0400 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: Draft Agenda for Atlanta Meeting Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3432722062_580088" Subject: [Ecrit] Draft Agenda for Atlanta Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 17:54:28 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3432722062_580088 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit We're putting together the agenda for the Atlanta WG meeting, if you have a presentation and want agenda time, please let us know. An email to the list will suffice. Thanks, Marc & Roger --B_3432722062_580088 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
We're putting together the a= genda for the Atlanta WG meeting, if you have a presentation and want agenda= time, please let us know.  An email to the list will suffice.

Thanks,

Marc & Roger
--B_3432722062_580088-- From christer.holmberg@ericsson.com Wed Oct 10 11:20:59 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AE921F84FD for ; Wed, 10 Oct 2012 11:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.109 X-Spam-Level: X-Spam-Status: No, score=-6.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us0maP5TFVsf for ; Wed, 10 Oct 2012 11:20:58 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 44F2A21F8551 for ; Wed, 10 Oct 2012 11:20:58 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-3a-5075bc89db84 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EE.0E.11467.98CB5705; Wed, 10 Oct 2012 20:20:57 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 10 Oct 2012 20:20:57 +0200 From: Christer Holmberg To: Marc Linsner , "ecrit@ietf.org" Date: Wed, 10 Oct 2012 20:19:04 +0200 Thread-Topic: Draft Agenda for Atlanta Meeting Thread-Index: Ac2nEE7V2WEhVdsdRRCA5dKe38niMAAA2vgk Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6F@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrW7nntIAgzn3JC0aFz1ltTh7+Tqj A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXRsY2rYAFrxZWd99gbGOexdDFyckgImEj8 OdTLDGGLSVy4t56ti5GLQ0jgFKPEwuVfmCCchYwSnU8fAVVxcLAJWEh0/9MGaRAR8JDY8uUI 2CAWAVWJ5y0f2EFKhAV0Ja7ODIUo0ZPYMOsuI4RtJLH8xTV2EJtXIFzi56EFTCC2kIC+xOJF m8BqOAUMJA5fuwkWZwS65/upNWA2s4C4xK0n85kg7hSQWLLnPNTNohIvH/9jhagXlbjTvp4R ol5P4sbUKWwQtrbEsoWvmSH2CkqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGIVzEzNz0ssN 9VKLMpOLi/Pz9IpTNzEC4+Pglt+6OxhPnRM5xCjNwaIkzsuVtN9fSCA9sSQ1OzW1ILUovqg0 J7X4ECMTB6dUA2NmdnNIfbnZqspF120cuW681+2fn6Zx5F7e9Pp7zjEdv88w+Gae7dgieEnd 2PjwrC6dc5aOPV0ZKd6cM69KOzTdP8h8MMVgb1jIjuo9V49Nc3zyKT3g0ZfD9dXexzNjmg4k /dZymyTRLOfN3CAqdCcgWIkz/GWuQ/NZRoHA3wH7XH7tuFjOrMRSnJFoqMVcVJwIAIDIxaVd AgAA Subject: Re: [Ecrit] Draft Agenda for Atlanta Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 18:20:59 -0000 Hi, We'd like to have time for the PSAP callback indicator. Pretty much adminis= trative issues, I guess, e.g. whether the new Priority header field value w= ill be a 3261 update etc. Regards, Christer ________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Marc Lin= sner [mlinsner@cisco.com] Sent: Wednesday, October 10, 2012 8:54 PM To: ecrit@ietf.org Subject: [Ecrit] Draft Agenda for Atlanta Meeting We're putting together the agenda for the Atlanta WG meeting, if you have a= presentation and want agenda time, please let us know. An email to the li= st will suffice. Thanks, Marc & Roger From James.Winterbottom@commscope.com Wed Oct 10 14:51:19 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3280F1F040A for ; Wed, 10 Oct 2012 14:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXAPgHRQ1dUc for ; Wed, 10 Oct 2012 14:51:18 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAC721F8661 for ; Wed, 10 Oct 2012 14:51:18 -0700 (PDT) X-AuditID: 0a0404e8-b7c1dae0000009ce-39-5075edfe8b02 Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id D8.E0.02510.EFDE5705; Wed, 10 Oct 2012 16:51:58 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 10 Oct 2012 16:51:17 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 11 Oct 2012 05:51:14 +0800 From: "Winterbottom, James" To: Marc Linsner , "ecrit@ietf.org" Date: Thu, 11 Oct 2012 05:51:13 +0800 Thread-Topic: Draft Agenda for Atlanta Meeting Thread-Index: Ac2nEFMLYDCpLA5DSPKkOye+4OfcbgAIL4SA Message-ID: <5A55A45AE77F5941B18E5457ECAC818801212C3D8460@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC818801212C3D8460SISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAhlX8kscKIYB Subject: Re: [Ecrit] Draft Agenda for Atlanta Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 21:51:19 -0000 --_000_5A55A45AE77F5941B18E5457ECAC818801212C3D8460SISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marc and Roger, We would like some time to talk about draft-winterbottom-ecrit-priv-loc. We plan to have an update before the draft submission deadline. Cheers James From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= arc Linsner Sent: Thursday, 11 October 2012 4:54 AM To: ecrit@ietf.org Subject: [Ecrit] Draft Agenda for Atlanta Meeting We're putting together the agenda for the Atlanta WG meeting, if you have a= presentation and want agenda time, please let us know. An email to the li= st will suffice. Thanks, Marc & Roger --_000_5A55A45AE77F5941B18E5457ECAC818801212C3D8460SISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Marc a= nd Roger,

 

We would like some time to talk abo= ut draft-winterbottom-ecrit-priv-loc.

 

We plan= to have an update before the draft submission deadline.<= /p>

 

Cheers

James

 

From: ecrit-bounces@ietf.org [mailto:ecri= t-bounces@ietf.org] On Behalf Of Marc Linsner
Sent: Thursd= ay, 11 October 2012 4:54 AM
To: ecrit@ietf.org
Subject:= [Ecrit] Draft Agenda for Atlanta Meeting

=

 

We'= re putting together the agenda for the Atlanta WG meeting, if you have a pr= esentation and want agenda time, please let us know.  An email to the = list will suffice.

 

Thanks,

 

Marc & Roger

= --_000_5A55A45AE77F5941B18E5457ECAC818801212C3D8460SISPE7MB1co_-- From brian.rosen@neustar.biz Thu Oct 11 03:25:53 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5462B21F867F for ; Thu, 11 Oct 2012 03:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrW+MxucwCQJ for ; Thu, 11 Oct 2012 03:25:52 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id A849121F867C for ; Thu, 11 Oct 2012 03:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1349951094; x=1665287802; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=CUW8hoEXrXPoADmCz5eO2IzQHqdYQgpbEEOog7L9DfI=; b=C/Ra2OfsBjHhvAj+qjvypodmcBSCl4bIFCFENNq6Vjv9hF3+sBtMWN77hsmiim I+l1/Mk3XEGvLV2Hu5SdaWkA== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.10535930; Thu, 11 Oct 2012 06:24:52 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 11 Oct 2012 06:25:46 -0400 From: "Rosen, Brian" To: Marc Linsner Date: Thu, 11 Oct 2012 06:25:46 -0400 Thread-Topic: [Ecrit] Draft Agenda for Atlanta Meeting Thread-Index: Ac2nmsZ7+XAr/9v8Swey9tt1CHWHLQ== Message-ID: <416315AD-495A-4198-BE7F-467DC65AFF4C@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: V8UfiOYsvqv4Um+RhgsY1w== Content-Type: multipart/alternative; boundary="_000_416315AD495A4198BE7F467DC65AFF4Cneustarbiz_" MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft Agenda for Atlanta Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 10:25:53 -0000 --_000_416315AD495A4198BE7F467DC65AFF4Cneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Additional-Data time, please, I'll have a revision out this week. Brian On Oct 10, 2012, at 1:54 PM, Marc Linsner > wrote: We're putting together the agenda for the Atlanta WG meeting, if you have a= presentation and want agenda time, please let us know. An email to the li= st will suffice. Thanks, Marc & Roger _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_416315AD495A4198BE7F467DC65AFF4Cneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Additional-Data time, ple= ase, I'll have a revision out this week.

Brian

On Oct 10, 2012, at 1:54 PM, Marc Linsner <mlinsner@cisco.com> wrote:

We'r= e putting together the agenda for the Atlanta WG meeting, if you have a pre= sentation and want agenda time, please let us know.  An email to the l= ist will suffice.

Thanks,

Marc & Roger
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit

= --_000_416315AD495A4198BE7F467DC65AFF4Cneustarbiz_-- From hannes.tschofenig@gmx.net Sun Oct 14 04:34:05 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF6C21F846A for ; Sun, 14 Oct 2012 04:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW5vwgUNqHgm for ; Sun, 14 Oct 2012 04:34:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 93EDD21F8442 for ; Sun, 14 Oct 2012 04:34:04 -0700 (PDT) Received: (qmail invoked by alias); 14 Oct 2012 11:34:02 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.216.191] by mail.gmx.net (mp035) with SMTP; 14 Oct 2012 13:34:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18OkaNmkVwOSecjJhCw+leRh1e9Iq+BR/JH4vXgPL lzoa3zUewSzF7d Message-ID: <507AA329.10209@gmx.net> Date: Sun, 14 Oct 2012 14:34:01 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [Ecrit] PSAP Callback Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 11:34:05 -0000 Hi all, after reaching a conclusion regarding the marking Christer indicated that we are going to provide a draft update before the submission deadline. The security consideration section is currently empty and I have tried to come up with some text. Here is my proposal: -------- 5. Security Considerations 5.1. Security Threat The PSAP callback functionality described in this document allows marked calls to bypass blacklists, ignore call forwarding procedures and similar features to contact emergency callers and to raise their attention. Regarding the latter aspect a callback, if understood by the SIP UA would allow to override user interface configurations, such as vibrate-only mode, to alert the caller of the incoming call. 5.2. Security Requirements The requirement is to ensure that the mechanisms described in this document can not be used for malicious purposes, including telemarketing. Furthermore, if the newly defined extension is not recognized, not verified adequately, or not obeyed by SIP intermediaries or SIP endpoints then it must not lead to a failure of the call handling procedure. Such call must be treated like a call that does not have any marking attached. 5.3. Security Solution Figure 6 shows the architecture that utilizes the identity of the PSAP to decide whether a preferential treatment of callbacks should be provided. To make this policy decision the identity of the PSAP is compared with a whitelist of valid PSAPs available to the SIP entity. The identity assurance in SIP can come in different forms, such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325]. The former technique relies on a cryptographic assurance and the latter on a chain of trust. Also the usage of TLS between neighboring SIP entities may provide useful identity information. +----------+ | List of |+ | valid || | PSAPs || +----------+| +----------+ * * whitelist * V Incoming +----------+ Normal SIP Msg | SIP |+ Treatment -------------->| Entity ||======================> + Identity | ||(if not in whitelist) Info +----------+| +----------+ || || || Preferential || Treatment ++========================> (if successfully verified) Figure 6: Identity-based Authorization An important aspect from a security point of view is the relationship between the emergency services network (containing PSAPs) and the VSP (assuming that the emergency call travels via the VSP and not directly between the SIP UA and the PSAP). If there is some form of relationship between the emergency services operator and the VSP then the identification of a PSAP call back is less problematic than in the case where the two entities have not entered in some form of relationship that would allow the VSP to verify whether the marked callback message indeed came from a legitimate source. The establishment of a whitelist with PSAP identities maybe be operationally complex. When there is a local relationship between the VSP/ASP and the PSAP then populating the whitelist is fairly simple. For SIP UAs there is no need to maintain a list of PSAPs. Instead SIP UAs are assumed to trust the correct processing of their VSP/ASP, i.e., the VSP/ASP processes the PSAP callback marking and, if it cannot be verified, the PSAP callback marking is removed. If it is left untouched then the SIP UA should assume that it has been verified successfully by the VSP/ASP and it should therefore be obeyed. -------- Feedback welcome! Ciao Hannes From pkyzivat@alum.mit.edu Sun Oct 14 11:53:44 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092AC21F8444 for ; Sun, 14 Oct 2012 11:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hWe28xyU4qN for ; Sun, 14 Oct 2012 11:53:43 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 0440721F8438 for ; Sun, 14 Oct 2012 11:53:42 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta01.westchester.pa.mail.comcast.net with comcast id B6FE1k0050vyq2s516tn3E; Sun, 14 Oct 2012 18:53:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id B6p71k00B3ZTu2S3R6p7M6; Sun, 14 Oct 2012 18:49:07 +0000 Message-ID: <507B0908.5080808@alum.mit.edu> Date: Sun, 14 Oct 2012 14:48:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: ecrit@ietf.org References: <507AA329.10209@gmx.net> In-Reply-To: <507AA329.10209@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] PSAP Callback Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 18:53:44 -0000 Hi Hannes, IMO it is not necessary, and not even desirable, the the nodes in the middle of the network to do this level of screening. Rather, I think it would be better for the phone the make the emergency call to remember that it did, and set up an interval during which it is willing to accept an emergency callback. * During that interval, if it gets a call marked as a psap callback it should apply whatever special policies it has to such calls. If it is not still engaged in the emergency call it had made, then it might use priority alerting, drop any other call it might be in, etc. (If it *is* still in the original emergency call then it gets complicated. I don't know what it does.) * If a call marked as a psap callback comes when not in an interval when it is expecting one, it should either treat it as an ordinary call, or reject it altogether. * The phone could persist the record of the emergency call so that it will still remember after a reboot. If it chooses not to do that, then it can simply assume after a reboot that it might have initiated an emergency call just before the reboot, and so establish an interval for accepting emergency callbacks starting immediately after the reboot. This is relatively safe because to exploit it a caller would need to know when the callee reboots his phone. This does mean that someone aware that an emergency call has been made could exploit that to get a priority call through to the phone. This seems a minor issue to me. The benefit is that it eliminates all the complications of establishing whitelists for large numbers of otherwise unknown entities, or the need to federate many psaps in order to minimize the size of whitelists. Thanks, Paul On 10/14/12 7:34 AM, Hannes Tschofenig wrote: > Hi all, > > after reaching a conclusion regarding the marking Christer indicated > that we are going to provide a draft update before the submission deadline. > > The security consideration section is currently empty and I have tried > to come up with some text. Here is my proposal: > > -------- > > 5. Security Considerations > > 5.1. Security Threat > > The PSAP callback functionality described in this document allows > marked calls to bypass blacklists, ignore call forwarding procedures > and similar features to contact emergency callers and to raise their > attention. Regarding the latter aspect a callback, if understood by > the SIP UA would allow to override user interface configurations, > such as vibrate-only mode, to alert the caller of the incoming call. > > 5.2. Security Requirements > > The requirement is to ensure that the mechanisms described in this > document can not be used for malicious purposes, including > telemarketing. > > Furthermore, if the newly defined extension is not recognized, not > verified adequately, or not obeyed by SIP intermediaries or SIP > endpoints then it must not lead to a failure of the call handling > procedure. Such call must be treated like a call that does not have > any marking attached. > > 5.3. Security Solution > > Figure 6 shows the architecture that utilizes the identity of the > PSAP to decide whether a preferential treatment of callbacks should > be provided. To make this policy decision the identity of the PSAP > is compared with a whitelist of valid PSAPs available to the SIP > entity. The identity assurance in SIP can come in different forms, > such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325]. > The former technique relies on a cryptographic assurance and the > latter on a chain of trust. Also the usage of TLS between > neighboring SIP entities may provide useful identity information. > > > +----------+ > | List of |+ > | valid || > | PSAPs || > +----------+| > +----------+ > * > * whitelist > * > V > Incoming +----------+ Normal > SIP Msg | SIP |+ Treatment > -------------->| Entity ||======================> > + Identity | ||(if not in whitelist) > Info +----------+| > +----------+ > || > || > || Preferential > || Treatment > ++========================> > (if successfully verified) > > Figure 6: Identity-based Authorization > > An important aspect from a security point of view is the relationship > between the emergency services network (containing PSAPs) and the VSP > (assuming that the emergency call travels via the VSP and not > directly between the SIP UA and the PSAP). > > If there is some form of relationship between the emergency services > operator and the VSP then the identification of a PSAP call back is > less problematic than in the case where the two entities have not > entered in some form of relationship that would allow the VSP to > verify whether the marked callback message indeed came from a > legitimate source. > > The establishment of a whitelist with PSAP identities maybe be > operationally complex. When there is a local relationship between > the VSP/ASP and the PSAP then populating the whitelist is fairly > simple. For SIP UAs there is no need to maintain a list of PSAPs. > Instead SIP UAs are assumed to trust the correct processing of their > VSP/ASP, i.e., the VSP/ASP processes the PSAP callback marking and, > if it cannot be verified, the PSAP callback marking is removed. If > it is left untouched then the SIP UA should assume that it has been > verified successfully by the VSP/ASP and it should therefore be > obeyed. > > > -------- > > Feedback welcome! > > Ciao > Hannes > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From hannes.tschofenig@gmx.net Sun Oct 14 12:55:29 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA63621F8489 for ; Sun, 14 Oct 2012 12:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.416 X-Spam-Level: X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGmXmYgPo9qP for ; Sun, 14 Oct 2012 12:55:28 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 006C521F8484 for ; Sun, 14 Oct 2012 12:55:27 -0700 (PDT) Received: (qmail invoked by alias); 14 Oct 2012 19:55:26 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.100]) [88.115.216.191] by mail.gmx.net (mp016) with SMTP; 14 Oct 2012 21:55:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18iNSUo5WIiAUvEeHRnN80NhbaiL75P57cTxdqtba R4U/+WEsVZZ8JO Date: Sun, 14 Oct 2012 22:55:23 +0300 Message-ID: From: Hannes Tschofenig To: Paul Kyzivat MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 19:55:29 -0000 SGkgUGF1bCwgCgp0aGFua3MgZm9yIHRoZSBxdWljayBmZWVkYmFjay4gCgpCYXNlZCBvbiBvdXIg ZGlzY3Vzc2lvbnMgZWFybGllciBhYm91dCB0aGUgUFNBUCBjYWxsYmFjayB0aGVyZSBhcmUgY2Fz ZXMgd2hlcmUgbmV0d29yayBpbnRlcm1lZGlhcmllcyBuZWVkIHRvIHBlcmZvcm0gdGhpcyBzY3Jl ZW5pbmcuIFRoaW5rIGFib3V0IGF1dGhvcml6YXRpb24gcG9saWNpZXMgYW5kIHN1cHBsZW1lbnRh cnkgc2VydmljZXMgKGxpa2UgY2FsbCBmb3J3YXJkaW5nKS4gVGhlIGVhcmxpZXIgc2VjdGlvbnMg b2YgdGhlIGRyYWZ0IGRlc2NyaWJlIHRoZXNlIHNjZW5hcmlvcyBpbiBkZXRhaWwuCgpUaGUgaWRl YSBvZiB1c2luZyBzb21lIHRpbWVyIGludGVydmFsIGluIHdoaWNoIHRoZSBjYWxsYmFjayBtdXN0 IGNvbWUgd2FzIHJhaXNlZCBiZWZvcmUgYW5kIHdlIGhhdmUgdGhhdCBjb25jZXB0IGluIFBob25l QkNQLiBUaGUgY2hhbGxlbmdlIHdpdGggdGhpcyBpZGVhIGlzIHRoYXQgaXQgaXMgZGlmZmljdWx0 IHRvIHBpY2sgYSBzcGVjaWZpYyB0aW1lLiAKClRoZSBjYXNlIHRoYXQgdGhlIGVtZXJnZW5jeSBj YWxsZXIgaXMgc3RpbGwgaGF2aW5nIHRoZSBlbWVyZ2VuY3kgY2FsbCB3aGVuIGl0IHJlY2VpdmVz IHRoZSBjYWxsYmFjayBzZWVtcyByYXRoZXIgdW5saWtlbHkuIFRoZW9yZXRpY2FsbHksIHRoYXQn cyBwb3NzaWJsZS4gU2hvdWxkIHdlIGluZGljYXRlIHRoYXQgYW4gb25nb2luZyBjYWxsIHNob3Vs ZCBub3QgYmUgaW50ZXJydXB0ZWQ/CgpXaGF0IGhhcHBlbnMsIGhvd2V2ZXIsIHRvIGFuIG9uZ29p bmcgbm9uLWVtZXJnZW5jeSBjYWxsIHdoZW4gYW4gaW5jb21pbmcgY2FsbGJhY2sgYXJyaXZlcyBp cyBpbmRlZWQgYSBnb29kIHF1ZXN0aW9uLiBXb3VsZCB5b3Ugc2F5IHRoYXQgdGhlIHJlZ3VsYXIg Y2FsbCBzaG91bGQgYmUgcHJlZW1wdGVkIG9yIHNob3VsZCB3ZSBiZXR0ZXIgc2F5IG5vdGhpbmc/ CiAKRm9yIHRoZSBlbmQgZGV2aWNlIEkgd2FzIGFyZ3VpbmcgaW4gdGhlIGRyYWZ0IHRoYXQgd2hp dGVsaXN0cyBhcmUgbm90IG5lZWRlZCBzaW5jZSB0aGUgc2NyZWVuaW5nIHdpbGwgaGF2ZSB0byBi ZSBkb25lIGJ5IHRoZSBWU1AuIAoKQ2lhbwpIYW5uZXMKClNlbnQgZnJvbSBteSBBU1VTIFBhZAoK UGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3RlOgoKPkhpIEhhbm5lcywK Pgo+SU1PIGl0IGlzIG5vdCBuZWNlc3NhcnksIGFuZCBub3QgZXZlbiBkZXNpcmFibGUsIHRoZSB0 aGUgbm9kZXMgaW4gdGhlIAo+bWlkZGxlIG9mIHRoZSBuZXR3b3JrIHRvIGRvIHRoaXMgbGV2ZWwg b2Ygc2NyZWVuaW5nLgo+Cj5SYXRoZXIsIEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIGZvciB0 aGUgcGhvbmUgdGhlIG1ha2UgdGhlIGVtZXJnZW5jeSAKPmNhbGwgdG8gcmVtZW1iZXIgdGhhdCBp dCBkaWQsIGFuZCBzZXQgdXAgYW4gaW50ZXJ2YWwgZHVyaW5nIHdoaWNoIGl0IGlzIAo+d2lsbGlu ZyB0byBhY2NlcHQgYW4gZW1lcmdlbmN5IGNhbGxiYWNrLgo+Cj4qIER1cmluZyB0aGF0IGludGVy dmFsLCBpZiBpdCBnZXRzIGEgY2FsbCBtYXJrZWQgYXMgYSBwc2FwIGNhbGxiYWNrIGl0IAo+c2hv dWxkIGFwcGx5IHdoYXRldmVyIHNwZWNpYWwgcG9saWNpZXMgaXQgaGFzIHRvIHN1Y2ggY2FsbHMu IElmIGl0IGlzIAo+bm90IHN0aWxsIGVuZ2FnZWQgaW4gdGhlIGVtZXJnZW5jeSBjYWxsIGl0IGhh ZCBtYWRlLCB0aGVuIGl0IG1pZ2h0IHVzZSAKPnByaW9yaXR5IGFsZXJ0aW5nLCBkcm9wIGFueSBv dGhlciBjYWxsIGl0IG1pZ2h0IGJlIGluLCBldGMuIChJZiBpdCAqaXMqIAo+c3RpbGwgaW4gdGhl IG9yaWdpbmFsIGVtZXJnZW5jeSBjYWxsIHRoZW4gaXQgZ2V0cyBjb21wbGljYXRlZC4gSSBkb24n dCAKPmtub3cgd2hhdCBpdCBkb2VzLikKPgo+KiBJZiBhIGNhbGwgbWFya2VkIGFzIGEgcHNhcCBj YWxsYmFjayBjb21lcyB3aGVuIG5vdCBpbiBhbiBpbnRlcnZhbCB3aGVuIAo+aXQgaXMgZXhwZWN0 aW5nIG9uZSwgaXQgc2hvdWxkIGVpdGhlciB0cmVhdCBpdCBhcyBhbiBvcmRpbmFyeSBjYWxsLCBv ciAKPnJlamVjdCBpdCBhbHRvZ2V0aGVyLgo+Cj4qIFRoZSBwaG9uZSBjb3VsZCBwZXJzaXN0IHRo ZSByZWNvcmQgb2YgdGhlIGVtZXJnZW5jeSBjYWxsIHNvIHRoYXQgaXQgCj53aWxsIHN0aWxsIHJl bWVtYmVyIGFmdGVyIGEgcmVib290LiBJZiBpdCBjaG9vc2VzIG5vdCB0byBkbyB0aGF0LCB0aGVu IAo+aXQgY2FuIHNpbXBseSBhc3N1bWUgYWZ0ZXIgYSByZWJvb3QgdGhhdCBpdCBtaWdodCBoYXZl IGluaXRpYXRlZCBhbiAKPmVtZXJnZW5jeSBjYWxsIGp1c3QgYmVmb3JlIHRoZSByZWJvb3QsIGFu ZCBzbyBlc3RhYmxpc2ggYW4gaW50ZXJ2YWwgZm9yIAo+YWNjZXB0aW5nIGVtZXJnZW5jeSBjYWxs YmFja3Mgc3RhcnRpbmcgaW1tZWRpYXRlbHkgYWZ0ZXIgdGhlIHJlYm9vdC4gCj5UaGlzIGlzIHJl bGF0aXZlbHkgc2FmZSBiZWNhdXNlIHRvIGV4cGxvaXQgaXQgYSBjYWxsZXIgd291bGQgbmVlZCB0 byAKPmtub3cgd2hlbiB0aGUgY2FsbGVlIHJlYm9vdHMgaGlzIHBob25lLgo+Cj5UaGlzIGRvZXMg bWVhbiB0aGF0IHNvbWVvbmUgYXdhcmUgdGhhdCBhbiBlbWVyZ2VuY3kgY2FsbCBoYXMgYmVlbiBt YWRlIAo+Y291bGQgZXhwbG9pdCB0aGF0IHRvIGdldCBhIHByaW9yaXR5IGNhbGwgdGhyb3VnaCB0 byB0aGUgcGhvbmUuIFRoaXMgCj5zZWVtcyBhIG1pbm9yIGlzc3VlIHRvIG1lLiBUaGUgYmVuZWZp dCBpcyB0aGF0IGl0IGVsaW1pbmF0ZXMgYWxsIHRoZSAKPmNvbXBsaWNhdGlvbnMgb2YgZXN0YWJs aXNoaW5nIHdoaXRlbGlzdHMgZm9yIGxhcmdlIG51bWJlcnMgb2Ygb3RoZXJ3aXNlIAo+dW5rbm93 biBlbnRpdGllcywgb3IgdGhlIG5lZWQgdG8gZmVkZXJhdGUgbWFueSBwc2FwcyBpbiBvcmRlciB0 byAKPm1pbmltaXplIHRoZSBzaXplIG9mIHdoaXRlbGlzdHMuCj4KPglUaGFua3MsCj4JUGF1bAo+ Cj5PbiAxMC8xNC8xMiA3OjM0IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyB3cm90ZToKPj4gSGkgYWxs LAo+Pgo+PiBhZnRlciByZWFjaGluZyBhIGNvbmNsdXNpb24gcmVnYXJkaW5nIHRoZSBtYXJraW5n IENocmlzdGVyIGluZGljYXRlZAo+PiB0aGF0IHdlIGFyZSBnb2luZyB0byBwcm92aWRlIGEgZHJh ZnQgdXBkYXRlIGJlZm9yZSB0aGUgc3VibWlzc2lvbiBkZWFkbGluZS4KPj4KPj4gVGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBpcyBjdXJyZW50bHkgZW1wdHkgYW5kIEkgaGF2ZSB0 cmllZAo+PiB0byBjb21lIHVwIHdpdGggc29tZSB0ZXh0LiBIZXJlIGlzIG15IHByb3Bvc2FsOgo+ Pgo+PiAtLS0tLS0tLQo+Pgo+PiA1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKPj4KPj4gNS4x LiAgU2VjdXJpdHkgVGhyZWF0Cj4+Cj4+ICAgICBUaGUgUFNBUCBjYWxsYmFjayBmdW5jdGlvbmFs aXR5IGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGFsbG93cwo+PiAgICAgbWFya2VkIGNhbGxz IHRvIGJ5cGFzcyBibGFja2xpc3RzLCBpZ25vcmUgY2FsbCBmb3J3YXJkaW5nIHByb2NlZHVyZXMK Pj4gICAgIGFuZCBzaW1pbGFyIGZlYXR1cmVzIHRvIGNvbnRhY3QgZW1lcmdlbmN5IGNhbGxlcnMg YW5kIHRvIHJhaXNlIHRoZWlyCj4+ICAgICBhdHRlbnRpb24uICBSZWdhcmRpbmcgdGhlIGxhdHRl ciBhc3BlY3QgYSBjYWxsYmFjaywgaWYgdW5kZXJzdG9vZCBieQo+PiAgICAgdGhlIFNJUCBVQSB3 b3VsZCBhbGxvdyB0byBvdmVycmlkZSB1c2VyIGludGVyZmFjZSBjb25maWd1cmF0aW9ucywKPj4g ICAgIHN1Y2ggYXMgdmlicmF0ZS1vbmx5IG1vZGUsIHRvIGFsZXJ0IHRoZSBjYWxsZXIgb2YgdGhl IGluY29taW5nIGNhbGwuCj4+Cj4+IDUuMi4gIFNlY3VyaXR5IFJlcXVpcmVtZW50cwo+Pgo+PiAg ICAgVGhlIHJlcXVpcmVtZW50IGlzIHRvIGVuc3VyZSB0aGF0IHRoZSBtZWNoYW5pc21zIGRlc2Ny aWJlZCBpbiB0aGlzCj4+ICAgICBkb2N1bWVudCBjYW4gbm90IGJlIHVzZWQgZm9yIG1hbGljaW91 cyBwdXJwb3NlcywgaW5jbHVkaW5nCj4+ICAgICB0ZWxlbWFya2V0aW5nLgo+Pgo+PiAgICAgRnVy dGhlcm1vcmUsIGlmIHRoZSBuZXdseSBkZWZpbmVkIGV4dGVuc2lvbiBpcyBub3QgcmVjb2duaXpl ZCwgbm90Cj4+ICAgICB2ZXJpZmllZCBhZGVxdWF0ZWx5LCBvciBub3Qgb2JleWVkIGJ5IFNJUCBp bnRlcm1lZGlhcmllcyBvciBTSVAKPj4gICAgIGVuZHBvaW50cyB0aGVuIGl0IG11c3Qgbm90IGxl YWQgdG8gYSBmYWlsdXJlIG9mIHRoZSBjYWxsIGhhbmRsaW5nCj4+ICAgICBwcm9jZWR1cmUuICBT dWNoIGNhbGwgbXVzdCBiZSB0cmVhdGVkIGxpa2UgYSBjYWxsIHRoYXQgZG9lcyBub3QgaGF2ZQo+ PiAgICAgYW55IG1hcmtpbmcgYXR0YWNoZWQuCj4+Cj4+IDUuMy4gIFNlY3VyaXR5IFNvbHV0aW9u Cj4+Cj4+ICAgICBGaWd1cmUgNiBzaG93cyB0aGUgYXJjaGl0ZWN0dXJlIHRoYXQgdXRpbGl6ZXMg dGhlIGlkZW50aXR5IG9mIHRoZQo+PiAgICAgUFNBUCB0byBkZWNpZGUgd2hldGhlciBhIHByZWZl cmVudGlhbCB0cmVhdG1lbnQgb2YgY2FsbGJhY2tzIHNob3VsZAo+PiAgICAgYmUgcHJvdmlkZWQu ICBUbyBtYWtlIHRoaXMgcG9saWN5IGRlY2lzaW9uIHRoZSBpZGVudGl0eSBvZiB0aGUgUFNBUAo+ PiAgICAgaXMgY29tcGFyZWQgd2l0aCBhIHdoaXRlbGlzdCBvZiB2YWxpZCBQU0FQcyBhdmFpbGFi bGUgdG8gdGhlIFNJUAo+PiAgICAgZW50aXR5LiAgVGhlIGlkZW50aXR5IGFzc3VyYW5jZSBpbiBT SVAgY2FuIGNvbWUgaW4gZGlmZmVyZW50IGZvcm1zLAo+PiAgICAgc3VjaCBhcyBTSVAgSWRlbnRp dHkgW1JGQzQ0NzRdIG9yIHdpdGggUC1Bc3NlcnRlZC1JZGVudGl0eSBbUkZDMzMyNV0uCj4+ICAg ICBUaGUgZm9ybWVyIHRlY2huaXF1ZSByZWxpZXMgb24gYSBjcnlwdG9ncmFwaGljIGFzc3VyYW5j ZSBhbmQgdGhlCj4+ICAgICBsYXR0ZXIgb24gYSBjaGFpbiBvZiB0cnVzdC4gIEFsc28gdGhlIHVz YWdlIG9mIFRMUyBiZXR3ZWVuCj4+ICAgICBuZWlnaGJvcmluZyBTSVAgZW50aXRpZXMgbWF5IHBy b3ZpZGUgdXNlZnVsIGlkZW50aXR5IGluZm9ybWF0aW9uLgo+Pgo+Pgo+PiAgICAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLSsKPj4gICAgICAgICAgICAgICAgICAgICAgICAgfCBMaXN0 IG9mICB8Kwo+PiAgICAgICAgICAgICAgICAgICAgICAgICB8IHZhbGlkICAgIHx8Cj4+ICAgICAg ICAgICAgICAgICAgICAgICAgIHwgUFNBUHMgICAgfHwKPj4gICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0rfAo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0r Cj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKgo+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICogd2hpdGVsaXN0Cj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKgo+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFYKPj4gICAgICAgICAgIEluY29taW5nICAg ICAgKy0tLS0tLS0tLS0rICAgIE5vcm1hbAo+PiAgICAgICAgICAgU0lQIE1zZyAgICAgICB8IFNJ UCAgICAgIHwrICAgVHJlYXRtZW50Cj4+ICAgICAgICAgIC0tLS0tLS0tLS0tLS0tPnwgRW50aXR5 ICAgfHw9PT09PT09PT09PT09PT09PT09PT09Pgo+PiAgICAgICAgICAgKyBJZGVudGl0eSAgICB8 ICAgICAgICAgIHx8KGlmIG5vdCBpbiB3aGl0ZWxpc3QpCj4+ICAgICAgICAgICAgIEluZm8gICAg ICAgICstLS0tLS0tLS0tK3wKPj4gICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0r Cj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHwKPj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8fAo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHx8IFByZWZlcmVu dGlhbAo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHx8IFRyZWF0bWVudAo+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICsrPT09PT09PT09PT09PT09PT09PT09PT09Pgo+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGlmIHN1Y2Nlc3NmdWxseSB2ZXJpZmllZCkK Pj4KPj4gICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA2OiBJZGVudGl0eS1iYXNlZCBBdXRob3Jp emF0aW9uCj4+Cj4+ICAgICBBbiBpbXBvcnRhbnQgYXNwZWN0IGZyb20gYSBzZWN1cml0eSBwb2lu dCBvZiB2aWV3IGlzIHRoZSByZWxhdGlvbnNoaXAKPj4gICAgIGJldHdlZW4gdGhlIGVtZXJnZW5j eSBzZXJ2aWNlcyBuZXR3b3JrIChjb250YWluaW5nIFBTQVBzKSBhbmQgdGhlIFZTUAo+PiAgICAg KGFzc3VtaW5nIHRoYXQgdGhlIGVtZXJnZW5jeSBjYWxsIHRyYXZlbHMgdmlhIHRoZSBWU1AgYW5k IG5vdAo+PiAgICAgZGlyZWN0bHkgYmV0d2VlbiB0aGUgU0lQIFVBIGFuZCB0aGUgUFNBUCkuCj4+ Cj4+ICAgICBJZiB0aGVyZSBpcyBzb21lIGZvcm0gb2YgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhl IGVtZXJnZW5jeSBzZXJ2aWNlcwo+PiAgICAgb3BlcmF0b3IgYW5kIHRoZSBWU1AgdGhlbiB0aGUg aWRlbnRpZmljYXRpb24gb2YgYSBQU0FQIGNhbGwgYmFjayBpcwo+PiAgICAgbGVzcyBwcm9ibGVt YXRpYyB0aGFuIGluIHRoZSBjYXNlIHdoZXJlIHRoZSB0d28gZW50aXRpZXMgaGF2ZSBub3QKPj4g ICAgIGVudGVyZWQgaW4gc29tZSBmb3JtIG9mIHJlbGF0aW9uc2hpcCB0aGF0IHdvdWxkIGFsbG93 IHRoZSBWU1AgdG8KPj4gICAgIHZlcmlmeSB3aGV0aGVyIHRoZSBtYXJrZWQgY2FsbGJhY2sgbWVz c2FnZSBpbmRlZWQgY2FtZSBmcm9tIGEKPj4gICAgIGxlZ2l0aW1hdGUgc291cmNlLgo+Pgo+PiAg ICAgVGhlIGVzdGFibGlzaG1lbnQgb2YgYSB3aGl0ZWxpc3Qgd2l0aCBQU0FQIGlkZW50aXRpZXMg bWF5YmUgYmUKPj4gICAgIG9wZXJhdGlvbmFsbHkgY29tcGxleC4gIFdoZW4gdGhlcmUgaXMgYSBs b2NhbCByZWxhdGlvbnNoaXAgYmV0d2Vlbgo+PiAgICAgdGhlIFZTUC9BU1AgYW5kIHRoZSBQU0FQ IHRoZW4gcG9wdWxhdGluZyB0aGUgd2hpdGVsaXN0IGlzIGZhaXJseQo+PiAgICAgc2ltcGxlLiAg Rm9yIFNJUCBVQXMgdGhlcmUgaXMgbm8gbmVlZCB0byBtYWludGFpbiBhIGxpc3Qgb2YgUFNBUHMu Cj4+ICAgICBJbnN0ZWFkIFNJUCBVQXMgYXJlIGFzc3VtZWQgdG8gdHJ1c3QgdGhlIGNvcnJlY3Qg cHJvY2Vzc2luZyBvZiB0aGVpcgo+PiAgICAgVlNQL0FTUCwgaS5lLiwgdGhlIFZTUC9BU1AgcHJv Y2Vzc2VzIHRoZSBQU0FQIGNhbGxiYWNrIG1hcmtpbmcgYW5kLAo+PiAgICAgaWYgaXQgY2Fubm90 IGJlIHZlcmlmaWVkLCB0aGUgUFNBUCBjYWxsYmFjayBtYXJraW5nIGlzIHJlbW92ZWQuICBJZgo+ PiAgICAgaXQgaXMgbGVmdCB1bnRvdWNoZWQgdGhlbiB0aGUgU0lQIFVBIHNob3VsZCBhc3N1bWUg dGhhdCBpdCBoYXMgYmVlbgo+PiAgICAgdmVyaWZpZWQgc3VjY2Vzc2Z1bGx5IGJ5IHRoZSBWU1Av QVNQIGFuZCBpdCBzaG91bGQgdGhlcmVmb3JlIGJlCj4+ICAgICBvYmV5ZWQuCj4+Cj4+Cj4+IC0t LS0tLS0tCj4+Cj4+IEZlZWRiYWNrIHdlbGNvbWUhCj4+Cj4+IENpYW8KPj4gSGFubmVzCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+IEVjcml0IG1h aWxpbmcgbGlzdAo+PiBFY3JpdEBpZXRmLm9yZwo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Vjcml0Cj4+Cj4KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCj5FY3JpdCBtYWlsaW5nIGxpc3QKPkVjcml0QGlldGYub3JnCj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0Cg== From pkyzivat@alum.mit.edu Sun Oct 14 13:17:40 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FB121F849D for ; Sun, 14 Oct 2012 13:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.355 X-Spam-Level: X-Spam-Status: No, score=-0.355 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjIY731kr-vd for ; Sun, 14 Oct 2012 13:17:39 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 8848B21F849C for ; Sun, 14 Oct 2012 13:17:39 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id Azw91k00B0EZKEL538HjxZ; Sun, 14 Oct 2012 20:17:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id B8Cy1k00b3ZTu2S3M8CzGa; Sun, 14 Oct 2012 20:12:59 +0000 Message-ID: <507B1CB5.6000603@alum.mit.edu> Date: Sun, 14 Oct 2012 16:12:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 20:17:40 -0000 On 10/14/12 3:55 PM, Hannes Tschofenig wrote: > Hi Paul, > > thanks for the quick feedback. > > Based on our discussions earlier about the PSAP callback there are cases where network intermediaries need to perform this screening. Think about authorization policies and supplementary services (like call forwarding). The earlier sections of the draft describe these scenarios in detail. My feeling is still that the network should get out of the way in these cases - just trust the caller and let the callee deal with it. The one case I know of where that doesn't work is when the callee has been barred, say for non-payment. It could be permissive even in that case, and just log it as an exception. Some backend system could check for abuse and do some blacklisting. But I'll acknowledge that this is one case where the approach you propose is attractive. But it concerns me that whitelisting PSAPs could be difficult, especially for roaming devices that end up talking to a PSAP on the other side of the world from their provider's location. > The idea of using some timer interval in which the callback must come was raised before and we have that concept in PhoneBCP. The challenge with this idea is that it is difficult to pick a specific time. So make it big - an hour, or 24 hours. > The case that the emergency caller is still having the emergency call when it receives the callback seems rather unlikely. Theoretically, that's possible. Should we indicate that an ongoing call should not be interrupted? It seems possible to me. The call may have dropped somewhere along the path and the UAC doesn't yet know it. ISTM this is hard. You don't want to drop the existing call to take the new one if there is any possibility that the old one is still functional. Perhaps treat it as an extra call coming in and let the user switch between them. (But that is worrisome since it is fairly easy to lose both with common fat fingering.) Or the two could be mixed. I have no good ideas here. > What happens, however, to an ongoing non-emergency call when an incoming callback arrives is indeed a good question. Would you say that the regular call should be preempted or should we better say nothing? Similar to above, but with more preference for dropping the existing call. Maybe it could be treated like a call waiting case but with authomatic switching to the emergency callback - leaving the other one up but pending. > For the end device I was arguing in the draft that whitelists are not needed since the screening will have to be done by the VSP. Certainly I'm not suggesting whitelists here either. Thanks, Paul > Ciao > Hannes > > Sent from my ASUS Pad > > Paul Kyzivat wrote: > >> Hi Hannes, >> >> IMO it is not necessary, and not even desirable, the the nodes in the >> middle of the network to do this level of screening. >> >> Rather, I think it would be better for the phone the make the emergency >> call to remember that it did, and set up an interval during which it is >> willing to accept an emergency callback. >> >> * During that interval, if it gets a call marked as a psap callback it >> should apply whatever special policies it has to such calls. If it is >> not still engaged in the emergency call it had made, then it might use >> priority alerting, drop any other call it might be in, etc. (If it *is* >> still in the original emergency call then it gets complicated. I don't >> know what it does.) >> >> * If a call marked as a psap callback comes when not in an interval when >> it is expecting one, it should either treat it as an ordinary call, or >> reject it altogether. >> >> * The phone could persist the record of the emergency call so that it >> will still remember after a reboot. If it chooses not to do that, then >> it can simply assume after a reboot that it might have initiated an >> emergency call just before the reboot, and so establish an interval for >> accepting emergency callbacks starting immediately after the reboot. >> This is relatively safe because to exploit it a caller would need to >> know when the callee reboots his phone. >> >> This does mean that someone aware that an emergency call has been made >> could exploit that to get a priority call through to the phone. This >> seems a minor issue to me. The benefit is that it eliminates all the >> complications of establishing whitelists for large numbers of otherwise >> unknown entities, or the need to federate many psaps in order to >> minimize the size of whitelists. >> >> Thanks, >> Paul >> >> On 10/14/12 7:34 AM, Hannes Tschofenig wrote: >>> Hi all, >>> >>> after reaching a conclusion regarding the marking Christer indicated >>> that we are going to provide a draft update before the submission deadline. >>> >>> The security consideration section is currently empty and I have tried >>> to come up with some text. Here is my proposal: >>> >>> -------- >>> >>> 5. Security Considerations >>> >>> 5.1. Security Threat >>> >>> The PSAP callback functionality described in this document allows >>> marked calls to bypass blacklists, ignore call forwarding procedures >>> and similar features to contact emergency callers and to raise their >>> attention. Regarding the latter aspect a callback, if understood by >>> the SIP UA would allow to override user interface configurations, >>> such as vibrate-only mode, to alert the caller of the incoming call. >>> >>> 5.2. Security Requirements >>> >>> The requirement is to ensure that the mechanisms described in this >>> document can not be used for malicious purposes, including >>> telemarketing. >>> >>> Furthermore, if the newly defined extension is not recognized, not >>> verified adequately, or not obeyed by SIP intermediaries or SIP >>> endpoints then it must not lead to a failure of the call handling >>> procedure. Such call must be treated like a call that does not have >>> any marking attached. >>> >>> 5.3. Security Solution >>> >>> Figure 6 shows the architecture that utilizes the identity of the >>> PSAP to decide whether a preferential treatment of callbacks should >>> be provided. To make this policy decision the identity of the PSAP >>> is compared with a whitelist of valid PSAPs available to the SIP >>> entity. The identity assurance in SIP can come in different forms, >>> such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325]. >>> The former technique relies on a cryptographic assurance and the >>> latter on a chain of trust. Also the usage of TLS between >>> neighboring SIP entities may provide useful identity information. >>> >>> >>> +----------+ >>> | List of |+ >>> | valid || >>> | PSAPs || >>> +----------+| >>> +----------+ >>> * >>> * whitelist >>> * >>> V >>> Incoming +----------+ Normal >>> SIP Msg | SIP |+ Treatment >>> -------------->| Entity ||======================> >>> + Identity | ||(if not in whitelist) >>> Info +----------+| >>> +----------+ >>> || >>> || >>> || Preferential >>> || Treatment >>> ++========================> >>> (if successfully verified) >>> >>> Figure 6: Identity-based Authorization >>> >>> An important aspect from a security point of view is the relationship >>> between the emergency services network (containing PSAPs) and the VSP >>> (assuming that the emergency call travels via the VSP and not >>> directly between the SIP UA and the PSAP). >>> >>> If there is some form of relationship between the emergency services >>> operator and the VSP then the identification of a PSAP call back is >>> less problematic than in the case where the two entities have not >>> entered in some form of relationship that would allow the VSP to >>> verify whether the marked callback message indeed came from a >>> legitimate source. >>> >>> The establishment of a whitelist with PSAP identities maybe be >>> operationally complex. When there is a local relationship between >>> the VSP/ASP and the PSAP then populating the whitelist is fairly >>> simple. For SIP UAs there is no need to maintain a list of PSAPs. >>> Instead SIP UAs are assumed to trust the correct processing of their >>> VSP/ASP, i.e., the VSP/ASP processes the PSAP callback marking and, >>> if it cannot be verified, the PSAP callback marking is removed. If >>> it is left untouched then the SIP UA should assume that it has been >>> verified successfully by the VSP/ASP and it should therefore be >>> obeyed. >>> >>> >>> -------- >>> >>> Feedback welcome! >>> >>> Ciao >>> Hannes >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit From martin.thomson@gmail.com Mon Oct 15 09:10:53 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B6F1F042A for ; Mon, 15 Oct 2012 09:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.893 X-Spam-Level: X-Spam-Status: No, score=-3.893 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc99QM50WSir for ; Mon, 15 Oct 2012 09:10:53 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAD221F867A for ; Mon, 15 Oct 2012 09:10:52 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so4054548lbo.31 for ; Mon, 15 Oct 2012 09:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YOjHhCQR5r2wQFaLeD6XZrp1F7zHjt/jXu8NBDsfkmU=; b=libvaKYsMQEQPpMPBqtU4V6qyEJ0W1SuJc0BD8IJQvecAg3GD4/ARoLVuI6UgenYIp HySobfQ83v5aiUeWDXo147w+UKQ0t0KY/K1hQ63RVKJrF+QCLA9JzimYHtZVUXJZLCZT 0wYDZawnS8DVnBBy7OdR4//7MjF0H0hVfCyacC1/sHNVthRN0iSEa/Nf0kTF40CjHEMh wUYwuzjgorh7kyS2AWnn490lQnWAIXBgaQccuyCyl0JnMSdbE+GCRSKD9sor1Q7sz5XE oqVEhrps7NgKDPOuhn3xDE8702Y/fKFlzs6DX3urL6K/LBJivxFx8D6o7etIA6L79uYt UfZQ== MIME-Version: 1.0 Received: by 10.112.47.228 with SMTP id g4mr4180272lbn.21.1350317449896; Mon, 15 Oct 2012 09:10:49 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Mon, 15 Oct 2012 09:10:49 -0700 (PDT) In-Reply-To: <507B1CB5.6000603@alum.mit.edu> References: <507B1CB5.6000603@alum.mit.edu> Date: Mon, 15 Oct 2012 09:10:49 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 16:10:53 -0000 On 14 October 2012 13:12, Paul Kyzivat wrote: > My feeling is still that the network should get out of the way in these > cases - just trust the caller and let the callee deal with it. Getting out of the way could be an extraordinary action. If the entity changes its behaviour as a result of the marking, then the marking could be exploited. Limiting the possibility for abuse is the key. For an end device, special treatment might be enabled for a period after an emergency call is made. A service provider might use whitelisting. I expect that they will. From pkyzivat@alum.mit.edu Mon Oct 15 09:37:37 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C61A21F878B for ; Mon, 15 Oct 2012 09:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGYHc25X98LM for ; Mon, 15 Oct 2012 09:37:37 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 9109621F8786 for ; Mon, 15 Oct 2012 09:37:36 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta03.westchester.pa.mail.comcast.net with comcast id BTWr1k03D0vyq2s53Udh92; Mon, 15 Oct 2012 16:37:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id BUZ11k00F3ZTu2S3RUZ1wy; Mon, 15 Oct 2012 16:33:01 +0000 Message-ID: <507C3AA3.4010107@alum.mit.edu> Date: Mon, 15 Oct 2012 12:32:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Martin Thomson References: <507B1CB5.6000603@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 16:37:37 -0000 I've said what I have to say on this. You that work on this all the time have more insight than I do. Thanks, Paul On 10/15/12 12:10 PM, Martin Thomson wrote: > On 14 October 2012 13:12, Paul Kyzivat wrote: >> My feeling is still that the network should get out of the way in these >> cases - just trust the caller and let the callee deal with it. > > Getting out of the way could be an extraordinary action. > > If the entity changes its behaviour as a result of the marking, then > the marking could be exploited. Limiting the possibility for abuse is > the key. > > For an end device, special treatment might be enabled for a period > after an emergency call is made. > > A service provider might use whitelisting. I expect that they will. > From hannes.tschofenig@gmx.net Tue Oct 16 03:58:15 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B83D21F88B2 for ; Tue, 16 Oct 2012 03:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsoToR7IR5jp for ; Tue, 16 Oct 2012 03:58:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A7E2921F8862 for ; Tue, 16 Oct 2012 03:58:13 -0700 (PDT) Received: (qmail invoked by alias); 16 Oct 2012 10:58:03 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.104]) [88.115.216.191] by mail.gmx.net (mp038) with SMTP; 16 Oct 2012 12:58:03 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX181yUJ8FiE1LT2Dg7GghsTatnvOlXhPYeHeN+kq5i 3Afh+pGmlrCs9r From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Oct 2012 13:58:01 +0300 Message-Id: <3A8B21E8-F6BC-46C0-A040-F61479EE7019@gmx.net> To: "ecrit@ietf.org Org" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [Ecrit] Status of draft-ietf-ecrit-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 10:58:15 -0000 Just wanted to check the status of PhoneBCP. The document was pending = the completion of=20 draft-ietf-mmusic-media-loopback-15, which still lists 3 DISCUSSes:=20 https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/ From hannes.tschofenig@gmx.net Tue Oct 16 04:30:10 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA69621F86B5 for ; Tue, 16 Oct 2012 04:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+zxCCg0WQBc for ; Tue, 16 Oct 2012 04:30:09 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id C7F0B21F8811 for ; Tue, 16 Oct 2012 04:30:08 -0700 (PDT) Received: (qmail invoked by alias); 16 Oct 2012 11:30:07 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.104]) [88.115.216.191] by mail.gmx.net (mp039) with SMTP; 16 Oct 2012 13:30:07 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18zDptiamEz3pFCvI7XpTWAPdZneZaFYOHkuDK5UK g2Cx0dc4sMf89L Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Tue, 16 Oct 2012 14:30:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <507B1CB5.6000603@alum.mit.edu> To: Martin Thomson X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 11:30:10 -0000 Martin, Paul,=20 I am wondering whether my response has helped to clarify and whether I = can go ahead and put the text into the draft?=20 Ciao Hannes On Oct 15, 2012, at 7:10 PM, Martin Thomson wrote: > On 14 October 2012 13:12, Paul Kyzivat wrote: >> My feeling is still that the network should get out of the way in = these >> cases - just trust the caller and let the callee deal with it. >=20 > Getting out of the way could be an extraordinary action. >=20 > If the entity changes its behaviour as a result of the marking, then > the marking could be exploited. Limiting the possibility for abuse is > the key. >=20 > For an end device, special treatment might be enabled for a period > after an emergency call is made. >=20 > A service provider might use whitelisting. I expect that they will. From christer.holmberg@ericsson.com Tue Oct 16 04:57:38 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3450E21F88AB for ; Tue, 16 Oct 2012 04:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klbLlm9URFNb for ; Tue, 16 Oct 2012 04:57:37 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7A69521F88C2 for ; Tue, 16 Oct 2012 04:57:36 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-9d-507d4baec5d5 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A4.D3.04547.EAB4D705; Tue, 16 Oct 2012 13:57:35 +0200 (CEST) Received: from ESESSHC017.ericsson.se (153.88.183.69) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 16 Oct 2012 13:57:34 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 13:57:34 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: PSAP Callback: New SIP Priority header field 'psap-callback' value Thread-Index: Ac2rlQ2+7f0UwzM6TiOcL/XJdUzS/w== Date: Tue, 16 Oct 2012 11:57:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B016BF0@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B016BF0ESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvre5679oAg50veS0aFz1ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxstvf1gLHhhW3Jy1l7mB8YB2FyMnh4SAiUTDoR2MELaYxIV7 69m6GLk4hAROMUo8nv2PGcLZySix//0PdghnCaPE11UzWLsYOTjYBCwkuv+BTRIRUJXYcGYl 2CRhAW+Jxgl32UFKRASCJLZe14Qw9SSau3RBKliAqg/e2MsEYvMCVZ/oW8IMYjMC3fD91Bqw OLOAuMStJ/OZIG4TkFiy5zwzhC0q8fLxP1YIW1Fi59l2Zoj6fIk/v/qgZgpKnJz5hAXEFhLQ lmhZPIF9AqPILCRjZyFpmYWkBSKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9iFM5NzMxJ LzfSSy3KTC4uzs/TK07dxAiMnoNbfqvuYLxzTuQQozQHi5I4r/XWPf5CAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGLu/Kk/KCLrnfEp3VvF2xj0NK/V50nm72NnKGudcVF3wp6Z83kH/iss8 AbZm4SZn6uQ1mF9uSb7isulq9Kz1T54LCc1Ykv7RLf7ek5kZBiJ2NdM/BH1Lunh4W9JERq2Z d9O/MwhnrfaeEsG/ssnK7DJfkMNZ2ZvvCwNTP/zwunTFwY9t5qs8AyWW4oxEQy3mouJEAJ+G 99ZsAgAA Subject: [Ecrit] PSAP Callback: New SIP Priority header field 'psap-callback' value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 11:57:38 -0000 --_000_7594FB04B1934943A5C02806D1A2204B016BF0ESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I drafted some initial text regarding the new SIP Priority header field 'ps= ap-callback' value. Feel free to comment :) ----------------------- X. PSAP Callback Indicator. X.1 General This section defines a new header field value, "psap-callback", for the SIP= Priority header field [RFC3261]. The value is used by a SIP entity to inform downstream entities that the re= quest is associated with a PSAP callback SIP session. x.2 Usage SIP entities that receive the header field value within an initial request = for a SIP session, or within a standalone SIP request, can, depending on local policies, apply PSAP callback specific= procedures for the session or request. PSAP callback specific procedures might be applied both by network entities= and by the callee. The specific procedures are outside the scope of this document, but typically include bypassing ser= vices and barring procedures. x.3 Syntax x.3.1 General This Section defines the ABNF for the new SIP Priority header field valu= e, "psap-callback". x.3.2 ABNF priority-value /=3D "psap-callback" ----------------------- Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B016BF0ESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I drafted some initial text regarding the new SIP Pr= iority header field ’psap-callback’ value.

 

Feel free to comment :)

 

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

 

X.        &n= bsp;   PSAP Callback Indicator.

 

X.1        &= nbsp; General

 

This section defines a new header field value, "= ;psap-callback", for the SIP Priority header field [RFC3261].

The value is used by a SIP entity to inform downstre= am entities that the request is associated with a PSAP callback

SIP session.

 

x.2        &= nbsp; Usage

 

SIP entities that receive the header field value wit= hin an initial request for a SIP session, or within a standalone

SIP request, can, depending on local policies, apply= PSAP callback specific procedures for the session or request.

 

PSAP callback specific procedures might be applied b= oth by network entities and by the callee. The specific procedures

are outside the scope of this document, but typicall= y include bypassing services and barring procedures.

 

x.3        &= nbsp; Syntax

 

x.3.1      General

 

   This Section defines the ABNF for the n= ew SIP Priority header field value, "psap-callback".

 

x.3.2      ABNF<= /p>

 

priority-value  /=3D  "psap-callback&= quot;

 

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

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B016BF0ESESSMB209ericsso_-- From brian.rosen@neustar.biz Tue Oct 16 11:47:40 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE6D21F8A25 for ; Tue, 16 Oct 2012 11:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs5O4U8FnRnF for ; Tue, 16 Oct 2012 11:47:39 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id E4E9E21F8A2F for ; Tue, 16 Oct 2012 11:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1350413561; x=1665773253; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=l0H6Fn41mbW7IgK00NhwG Vv82ZLCqUgGLOnakDh/HCs=; b=c4+V4/djjePoDMvpeW/lU7tYbXOZNbDtVpiWj 1rRU1M/74ORIkO4YVKUGZE38ge7WIW2Qfh8x6dWhBUwl6Otlw== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.15473532; Tue, 16 Oct 2012 14:51:28 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Tue, 16 Oct 2012 14:46:20 -0400 From: "Rosen, Brian" To: Hannes Tschofenig Date: Tue, 16 Oct 2012 14:46:18 -0400 Thread-Topic: [Ecrit] Status of draft-ietf-ecrit-phonebcp Thread-Index: Ac2rzog4v5RO4xmLTv+TDIwYMWAA8w== Message-ID: <73721872-2DAD-4E57-BE8E-45EE3D4271AF@neustar.biz> References: <3A8B21E8-F6BC-46C0-A040-F61479EE7019@gmx.net> In-Reply-To: <3A8B21E8-F6BC-46C0-A040-F61479EE7019@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: LTP2TtduLSgSQH85w6+TSA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Status of draft-ietf-ecrit-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:47:40 -0000 I'll check. On Oct 16, 2012, at 12:58 PM, Hannes Tschofenig = wrote: > Just wanted to check the status of PhoneBCP. The document was pending the= completion of=20 > draft-ietf-mmusic-media-loopback-15, which still lists 3 DISCUSSes:=20 > https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/ >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Hannes.Tschofenig@gmx.net Thu Oct 18 01:56:34 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BA821F8618 for ; Thu, 18 Oct 2012 01:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V5krrHMbKA2 for ; Thu, 18 Oct 2012 01:56:33 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 40E9221F8619 for ; Thu, 18 Oct 2012 01:56:32 -0700 (PDT) Received: (qmail invoked by alias); 18 Oct 2012 08:49:11 -0000 Received: from unknown (EHLO [10.255.128.97]) [194.251.119.201] by mail.gmx.net (mp039) with SMTP; 18 Oct 2012 10:49:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18e2FpxUtUe4LDJTx8m5aUME3hnczSgywiRmRUzT7 5HQPNlnYVSRkbV From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Oct 2012 11:49:10 +0300 Message-Id: <9AD32CC3-069E-4FBD-A021-2EF5FC5E7D4E@gmx.net> To: "ecrit@ietf.org Org" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 08:56:34 -0000 Hi all,=20 Christer and I had put the new text into the (not-yet-submitted) draft. = Here is the current snapshot: = https://github.com/hannestschofenig/tschofenig-ids/blob/master/psap-callba= ck/draft-ietf-ecrit-psap-callback-06.txt Feedback we can be incorporated before the submission deadline.=20 Ciao Hannes From pkyzivat@alum.mit.edu Thu Oct 18 10:05:12 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8CF21F87A0 for ; Thu, 18 Oct 2012 10:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QIiPktzDPlB for ; Thu, 18 Oct 2012 10:05:12 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 2230421F877D for ; Thu, 18 Oct 2012 10:05:11 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta13.westchester.pa.mail.comcast.net with comcast id Ce5r1k0090bG4ec5Dh5GqC; Thu, 18 Oct 2012 17:05:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id Ch4y1k00V3ZTu2S3Ph4yXR; Thu, 18 Oct 2012 17:04:59 +0000 Message-ID: <508036C6.7070200@alum.mit.edu> Date: Thu, 18 Oct 2012 13:05:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: ecrit@ietf.org References: <9AD32CC3-069E-4FBD-A021-2EF5FC5E7D4E@gmx.net> In-Reply-To: <9AD32CC3-069E-4FBD-A021-2EF5FC5E7D4E@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore-chairs@tools.ietf.org" , "rai-ads@tools.ietf.org" Subject: Re: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:05:12 -0000 Hannes, Christer, ecrit wg, Robert, Adam and I have been discussing how best to handle the updating of the Priority header to include a new value. Ideally there would already be an IANA registry with defined procedures for adding new values. But there isn't. So we have two alternatives: 1) Simply mark this draft as an update to 3261. Provide ABNF that extends the syntax of the Priority header. (As your planned draft does.) 2) Make an update to 3261 that establishes a new IANA registry for Priority header field values, and populate it with all the values included in 3261. Set the rules for adding new values to that registry. Then set your new draft to follow those rules to add the new value to the registry. The 2nd way is clearly more work, but it is the "cleaner" way to do it. Robert has concerns that if we don't do that, and go with (1), then we will have some difficulty getting it through IESG. So we would prefer to do (2). Adam already put together a draft of a draft to do the revision to 3261. We can have that ready to submit when submissions are opened up again the first day in Atlanta. It is quite a straightforward thing to do so we expect we can have it approved and ready for the IESG soon enough that it won't slow your work up. Once that draft is filed you will be able to reference it in your draft so they can be wrapped up in parallel. Is ecrit ok with that direction? Thanks, Paul (as sipcore co-chair) On 10/18/12 4:49 AM, Hannes Tschofenig wrote: > Hi all, > > Christer and I had put the new text into the (not-yet-submitted) draft. Here is the current snapshot: > https://github.com/hannestschofenig/tschofenig-ids/blob/master/psap-callback/draft-ietf-ecrit-psap-callback-06.txt > > Feedback we can be incorporated before the submission deadline. > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From hannes.tschofenig@gmx.net Thu Oct 18 10:31:36 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA6B21F876D for ; Thu, 18 Oct 2012 10:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80CG9S-UwyAv for ; Thu, 18 Oct 2012 10:31:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0C42421F876A for ; Thu, 18 Oct 2012 10:31:34 -0700 (PDT) Received: (qmail invoked by alias); 18 Oct 2012 17:31:33 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.216.191] by mail.gmx.net (mp071) with SMTP; 18 Oct 2012 19:31:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Uqqg6GC0UAhh+xEIl5V+16ry2ugZ/KdvY2jpdOB dJx0+Az0T8kfan Message-ID: <50803CEF.6010703@gmx.net> Date: Thu, 18 Oct 2012 20:31:27 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <9AD32CC3-069E-4FBD-A021-2EF5FC5E7D4E@gmx.net> <508036C6.7070200@alum.mit.edu> In-Reply-To: <508036C6.7070200@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "rai-ads@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" , ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:31:36 -0000 I am curious why you need a separate draft just to create an additional registry. We still have "space left" in the current PSAP callback draft... On 10/18/2012 08:05 PM, Paul Kyzivat wrote: > Hannes, Christer, ecrit wg, > > Robert, Adam and I have been discussing how best to handle the updating > of the Priority header to include a new value. Ideally there would > already be an IANA registry with defined procedures for adding new > values. But there isn't. > > So we have two alternatives: > > 1) Simply mark this draft as an update to 3261. Provide ABNF that > extends the syntax of the Priority header. (As your planned draft does.) > > 2) Make an update to 3261 that establishes a new IANA registry for > Priority header field values, and populate it with all the values > included in 3261. Set the rules for adding new values to that registry. > Then set your new draft to follow those rules to add the new value to > the registry. > > The 2nd way is clearly more work, but it is the "cleaner" way to do it. > Robert has concerns that if we don't do that, and go with (1), then we > will have some difficulty getting it through IESG. > > So we would prefer to do (2). Adam already put together a draft of a > draft to do the revision to 3261. We can have that ready to submit when > submissions are opened up again the first day in Atlanta. It is quite a > straightforward thing to do so we expect we can have it approved and > ready for the IESG soon enough that it won't slow your work up. Once > that draft is filed you will be able to reference it in your draft so > they can be wrapped up in parallel. > > Is ecrit ok with that direction? > > Thanks, > Paul (as sipcore co-chair) > > On 10/18/12 4:49 AM, Hannes Tschofenig wrote: >> Hi all, >> >> Christer and I had put the new text into the (not-yet-submitted) >> draft. Here is the current snapshot: >> https://github.com/hannestschofenig/tschofenig-ids/blob/master/psap-callback/draft-ietf-ecrit-psap-callback-06.txt >> >> >> Feedback we can be incorporated before the submission deadline. >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Thu Oct 18 11:14:08 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C866721F84DB for ; Thu, 18 Oct 2012 11:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaiJRJdCQc2v for ; Thu, 18 Oct 2012 11:14:08 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7923021F84DA for ; Thu, 18 Oct 2012 11:14:07 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-66-508046ed55a1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FB.25.11467.DE640805; Thu, 18 Oct 2012 20:14:06 +0200 (CEST) Received: from ESESSHC007.ericsson.se (153.88.183.39) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 18 Oct 2012 20:14:05 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 20:14:05 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , "ecrit@ietf.org" Thread-Topic: [Ecrit] PSAP Callback Draft Thread-Index: AQHNrQ5+WsJqUqLqEkmjg04voM/cMZe/KdEAgAAzPyA= Date: Thu, 18 Oct 2012 18:14:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B019271@ESESSMB209.ericsson.se> References: <9AD32CC3-069E-4FBD-A021-2EF5FC5E7D4E@gmx.net> <508036C6.7070200@alum.mit.edu> In-Reply-To: <508036C6.7070200@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM+Jvre47t4YAg/c3WC0aFz1ltVix4QCr xd7t8xgtTr06zezA4vH3/QcmjyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoEr4+KD+4wFX8Qr mnunMzUwzhTuYuTkkBAwkXgw9SAzhC0mceHeerYuRi4OIYFTjBLbzn1iA0kICexklJh1qgwi sYRR4tazQ0AJDg42AQuJ7n/aIDUiAr4S6zq7wAYxC1RI/Nn9ggnEFhbQkFg57xw7RI2mxNHd jUwQtpXEz6XfwMawCKhKND1xAgnzCnhLXJ14DmptjET3hu/MICWcAjoSX3/mgIQZgc78fmoN E8QmcYlbT+YzQZwvILFkz3moV0QlXj7+xwphK0p8fLWPEaJeR2LBboivmAW0JZYtfM0MsVZQ 4uTMJywQa7UlWhZPYJ8A9DOSFbOQtM9C0j4LSfsCRpZVjMK5iZk56eWGeqlFmcnFxfl5esWp mxiBUXhwy2/dHYynzokcYpTmYFES5+VK2u8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTGk zUTh7Q+7vl22vQHXBJ20g/JOfOdWcisPWbzOQPyIrA+PcaWnv55PzMqP+ZGmiWfead++Fbau oXunbJRckcnLn6fUQx7cEp2yyvTUS5uLuvM5F03XzHq74Y5B6I7W2XHnmuwi2DeGC5pnygr+ sriQKDn5c+q3eZNaflncLi1VdQpb77ZzkxJLcUaioRZzUXEiAANyHYKQAgAA Cc: "rai-ads@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" Subject: Re: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:14:08 -0000 Hi, I am ok with (2). Does anyone have a problem with taking such approach (we = obviously still need to sort out the details)? Now, regarding the documentation. As Hannes also asked, do we really need a separate draft in order to create= the registry? I don't really care if we create a separate draft or not, bu= t I would like to have a decision soon. I don't think we need to spend f2f = time in Atlanta to discuss the documentation. But, separate draft or not, we can still work on the procedure text that I = suggested. So, please read and comment :) Regards, Christer =20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of P= aul Kyzivat Sent: 18. lokakuuta 2012 20:05 To: ecrit@ietf.org Cc: sipcore-chairs@tools.ietf.org; rai-ads@tools.ietf.org Subject: Re: [Ecrit] PSAP Callback Draft Hannes, Christer, ecrit wg, Robert, Adam and I have been discussing how best to handle the updating of = the Priority header to include a new value. Ideally there would already be = an IANA registry with defined procedures for adding new values. But there i= sn't. So we have two alternatives: 1) Simply mark this draft as an update to 3261. Provide ABNF that extends t= he syntax of the Priority header. (As your planned draft does.) 2) Make an update to 3261 that establishes a new IANA registry for Priority= header field values, and populate it with all the values included in 3261.= Set the rules for adding new values to that registry.=20 Then set your new draft to follow those rules to add the new value to the r= egistry. The 2nd way is clearly more work, but it is the "cleaner" way to do it.=20 Robert has concerns that if we don't do that, and go with (1), then we will= have some difficulty getting it through IESG. So we would prefer to do (2). Adam already put together a draft of a draft = to do the revision to 3261. We can have that ready to submit when submissio= ns are opened up again the first day in Atlanta. It is quite a straightforw= ard thing to do so we expect we can have it approved and ready for the IESG= soon enough that it won't slow your work up. Once that draft is filed you = will be able to reference it in your draft so they can be wrapped up in par= allel. Is ecrit ok with that direction? Thanks, Paul (as sipcore co-chair) On 10/18/12 4:49 AM, Hannes Tschofenig wrote: > Hi all, > > Christer and I had put the new text into the (not-yet-submitted) draft. H= ere is the current snapshot: > https://github.com/hannestschofenig/tschofenig-ids/blob/master/psap-ca > llback/draft-ietf-ecrit-psap-callback-06.txt > > Feedback we can be incorporated before the submission deadline. > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Thu Oct 18 11:32:37 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BACF21F8436 for ; Thu, 18 Oct 2012 11:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN8VXBKUUEyE for ; Thu, 18 Oct 2012 11:32:30 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 831E721F84BD for ; Thu, 18 Oct 2012 11:32:30 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta13.westchester.pa.mail.comcast.net with comcast id CdaD1k0021ap0As5DiYaXv; Thu, 18 Oct 2012 18:32:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id CiZ41k00Q3ZTu2S3iiZ4YQ; Thu, 18 Oct 2012 18:33:05 +0000 Message-ID: <50804B3C.9070106@alum.mit.edu> Date: Thu, 18 Oct 2012 14:32:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <9AD32CC3-069E-4FBD-A021-2EF5FC5E7D4E@gmx.net> <508036C6.7070200@alum.mit.edu> <50803CEF.6010703@gmx.net> In-Reply-To: <50803CEF.6010703@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rai-ads@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" , ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:32:37 -0000 On 10/18/12 1:31 PM, Hannes Tschofenig wrote: > I am curious why you need a separate draft just to create an additional > registry. We still have "space left" in the current PSAP callback draft... Oh, I thought it was "full". :-) We did discuss putting all the stuff to establish the IANA registry and grandfather the existing values into your draft. We just think that seems like a poor organization. (Sort of a layering violation.) We also aren't out of RFC numbers yet. :-) Thanks, Paul > On 10/18/2012 08:05 PM, Paul Kyzivat wrote: >> Hannes, Christer, ecrit wg, >> >> Robert, Adam and I have been discussing how best to handle the updating >> of the Priority header to include a new value. Ideally there would >> already be an IANA registry with defined procedures for adding new >> values. But there isn't. >> >> So we have two alternatives: >> >> 1) Simply mark this draft as an update to 3261. Provide ABNF that >> extends the syntax of the Priority header. (As your planned draft does.) >> >> 2) Make an update to 3261 that establishes a new IANA registry for >> Priority header field values, and populate it with all the values >> included in 3261. Set the rules for adding new values to that registry. >> Then set your new draft to follow those rules to add the new value to >> the registry. >> >> The 2nd way is clearly more work, but it is the "cleaner" way to do it. >> Robert has concerns that if we don't do that, and go with (1), then we >> will have some difficulty getting it through IESG. >> >> So we would prefer to do (2). Adam already put together a draft of a >> draft to do the revision to 3261. We can have that ready to submit when >> submissions are opened up again the first day in Atlanta. It is quite a >> straightforward thing to do so we expect we can have it approved and >> ready for the IESG soon enough that it won't slow your work up. Once >> that draft is filed you will be able to reference it in your draft so >> they can be wrapped up in parallel. >> >> Is ecrit ok with that direction? >> >> Thanks, >> Paul (as sipcore co-chair) >> >> On 10/18/12 4:49 AM, Hannes Tschofenig wrote: >>> Hi all, >>> >>> Christer and I had put the new text into the (not-yet-submitted) >>> draft. Here is the current snapshot: >>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/psap-callback/draft-ietf-ecrit-psap-callback-06.txt >>> >>> >>> >>> Feedback we can be incorporated before the submission deadline. >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From christer.holmberg@ericsson.com Thu Oct 18 13:22:13 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D2821F84B8 for ; Thu, 18 Oct 2012 13:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUXTgbn-sWxa for ; Thu, 18 Oct 2012 13:22:12 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6236C21F8430 for ; Thu, 18 Oct 2012 13:22:11 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-82-508064f2d1c2 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1A.8D.11467.2F460805; Thu, 18 Oct 2012 22:22:10 +0200 (CEST) Received: from ESESSHC004.ericsson.se (153.88.183.30) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 18 Oct 2012 22:22:10 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 22:22:09 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , Hannes Tschofenig Thread-Topic: [Ecrit] PSAP Callback Draft Thread-Index: AQHNrQ5+WsJqUqLqEkmjg04voM/cMZe/KdEAgAAHWICAABENAIAAP71g Date: Thu, 18 Oct 2012 20:22:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0193CB@ESESSMB209.ericsson.se> References: <9AD32CC3-069E-4FBD-A021-2EF5FC5E7D4E@gmx.net> <508036C6.7070200@alum.mit.edu> <50803CEF.6010703@gmx.net> <50804B3C.9070106@alum.mit.edu> In-Reply-To: <50804B3C.9070106@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGfG3VvdTSkOAwbYmGYvGRU9ZLZbuvMdq sWLDAVaLvdvnMVqcenWa2YHV4+/7D0weizftZ/NYsuQnk8eXy5/ZAliiuGxSUnMyy1KL9O0S uDI65mUVLJSpWHi+l7mB8bNYFyMnh4SAicTkXc+YIGwxiQv31rN1MXJxCAmcYpS48vIOlLOT UeLWwW2sEM4SRomnjXtYuhg5ONgELCS6/2mDdIsIREv03VkA1sAsMJdR4v33GewgCWEBDYmV 886xQxRpShzd3cgEYbtJbNu9nxXEZhFQlZh7fRoLiM0r4C3R1n8UavNMRokpTxYxgyQ4BXQk +vdPBWtgBLr1+6k1YIOYBcQlbj2ZD/WDgMSSPeeZIWxRiZeP/7FC2IoSH1/tY4So15FYsPsT G4StLbFs4WtmiMWCEidnPgE7Qggo3rJ4AvsERolZSFbMQtI+C0n7LCTtCxhZVjEK5yZm5qSX G+qlFmUmFxfn5+kVp25iBEbowS2/dXcwnjoncohRmoNFSZyXK2m/v5BAemJJanZqakFqUXxR aU5q8SFGJg5OqQbGxrDtXbnKtwRZxTmfSl3VmvuyQU7p5P23i2e78xbPrn+a22Cy6OovpYdn Pkx98cu736XS6OEHi8dJ8y6rfks92t7dEx8WbhM5x4ApIyn964pr0i42T9wvnjcSClnor964 yvHdGbb7n7LN7l9mizWdvSI7nt/yU4P1DqOomwYbOd5ePKRQkfBaiaU4I9FQi7moOBEAd7kD rZ4CAAA= Cc: "sipcore-chairs@tools.ietf.org" , "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 20:22:13 -0000 Hi, So, just to clarify: Adam is working on a draft which will create the IANA = registry for Priority header field values, and the psap-callback draft will= then define and register a new header field value into that registry? Regards, Christer -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of P= aul Kyzivat Sent: 18. lokakuuta 2012 21:32 To: Hannes Tschofenig Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback Draft On 10/18/12 1:31 PM, Hannes Tschofenig wrote: > I am curious why you need a separate draft just to create an=20 > additional registry. We still have "space left" in the current PSAP callb= ack draft... Oh, I thought it was "full". :-) We did discuss putting all the stuff to establish the IANA registry and gra= ndfather the existing values into your draft. We just think that seems like= a poor organization. (Sort of a layering violation.) We also aren't out of= RFC numbers yet. :-) Thanks, Paul > On 10/18/2012 08:05 PM, Paul Kyzivat wrote: >> Hannes, Christer, ecrit wg, >> >> Robert, Adam and I have been discussing how best to handle the=20 >> updating of the Priority header to include a new value. Ideally there=20 >> would already be an IANA registry with defined procedures for adding=20 >> new values. But there isn't. >> >> So we have two alternatives: >> >> 1) Simply mark this draft as an update to 3261. Provide ABNF that=20 >> extends the syntax of the Priority header. (As your planned draft=20 >> does.) >> >> 2) Make an update to 3261 that establishes a new IANA registry for=20 >> Priority header field values, and populate it with all the values=20 >> included in 3261. Set the rules for adding new values to that registry. >> Then set your new draft to follow those rules to add the new value to=20 >> the registry. >> >> The 2nd way is clearly more work, but it is the "cleaner" way to do it. >> Robert has concerns that if we don't do that, and go with (1), then=20 >> we will have some difficulty getting it through IESG. >> >> So we would prefer to do (2). Adam already put together a draft of a=20 >> draft to do the revision to 3261. We can have that ready to submit=20 >> when submissions are opened up again the first day in Atlanta. It is=20 >> quite a straightforward thing to do so we expect we can have it=20 >> approved and ready for the IESG soon enough that it won't slow your=20 >> work up. Once that draft is filed you will be able to reference it in=20 >> your draft so they can be wrapped up in parallel. >> >> Is ecrit ok with that direction? >> >> Thanks, >> Paul (as sipcore co-chair) >> >> On 10/18/12 4:49 AM, Hannes Tschofenig wrote: >>> Hi all, >>> >>> Christer and I had put the new text into the (not-yet-submitted)=20 >>> draft. Here is the current snapshot: >>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/psap- >>> callback/draft-ietf-ecrit-psap-callback-06.txt >>> >>> >>> >>> Feedback we can be incorporated before the submission deadline. >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Thu Oct 18 18:26:26 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1050A21F852C for ; Thu, 18 Oct 2012 18:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW3OH8usTmmS for ; Thu, 18 Oct 2012 18:26:25 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 27B4821F84FE for ; Thu, 18 Oct 2012 18:26:25 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta02.westchester.pa.mail.comcast.net with comcast id Cb1t1k0080xGWP851pSVav; Fri, 19 Oct 2012 01:26:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id CpRR1k0013ZTu2S3YpRRvT; Fri, 19 Oct 2012 01:25:25 +0000 Message-ID: <5080AC3E.8080403@alum.mit.edu> Date: Thu, 18 Oct 2012 21:26:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <9AD32CC3-069E-4FBD-A021-2EF5FC5E7D4E@gmx.net> <508036C6.7070200@alum.mit.edu> <50803CEF.6010703@gmx.net> <50804B3C.9070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0193CB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0193CB@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore-chairs@tools.ietf.org" , "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 01:26:26 -0000 On 10/18/12 4:22 PM, Christer Holmberg wrote: > > Hi, > > So, just to clarify: Adam is working on a draft which will create the IANA registry for Priority header field values, and the psap-callback draft will then define and register a new header field value into that registry? Yes! Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 18. lokakuuta 2012 21:32 > To: Hannes Tschofenig > Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback Draft > > On 10/18/12 1:31 PM, Hannes Tschofenig wrote: >> I am curious why you need a separate draft just to create an >> additional registry. We still have "space left" in the current PSAP callback draft... > > Oh, I thought it was "full". :-) > > We did discuss putting all the stuff to establish the IANA registry and grandfather the existing values into your draft. We just think that seems like a poor organization. (Sort of a layering violation.) We also aren't out of RFC numbers yet. :-) > > Thanks, > Paul > >> On 10/18/2012 08:05 PM, Paul Kyzivat wrote: >>> Hannes, Christer, ecrit wg, >>> >>> Robert, Adam and I have been discussing how best to handle the >>> updating of the Priority header to include a new value. Ideally there >>> would already be an IANA registry with defined procedures for adding >>> new values. But there isn't. >>> >>> So we have two alternatives: >>> >>> 1) Simply mark this draft as an update to 3261. Provide ABNF that >>> extends the syntax of the Priority header. (As your planned draft >>> does.) >>> >>> 2) Make an update to 3261 that establishes a new IANA registry for >>> Priority header field values, and populate it with all the values >>> included in 3261. Set the rules for adding new values to that registry. >>> Then set your new draft to follow those rules to add the new value to >>> the registry. >>> >>> The 2nd way is clearly more work, but it is the "cleaner" way to do it. >>> Robert has concerns that if we don't do that, and go with (1), then >>> we will have some difficulty getting it through IESG. >>> >>> So we would prefer to do (2). Adam already put together a draft of a >>> draft to do the revision to 3261. We can have that ready to submit >>> when submissions are opened up again the first day in Atlanta. It is >>> quite a straightforward thing to do so we expect we can have it >>> approved and ready for the IESG soon enough that it won't slow your >>> work up. Once that draft is filed you will be able to reference it in >>> your draft so they can be wrapped up in parallel. >>> >>> Is ecrit ok with that direction? >>> >>> Thanks, >>> Paul (as sipcore co-chair) >>> >>> On 10/18/12 4:49 AM, Hannes Tschofenig wrote: >>>> Hi all, >>>> >>>> Christer and I had put the new text into the (not-yet-submitted) >>>> draft. Here is the current snapshot: >>>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/psap- >>>> callback/draft-ietf-ecrit-psap-callback-06.txt >>>> >>>> >>>> >>>> Feedback we can be incorporated before the submission deadline. >>>> >>>> Ciao >>>> Hannes >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From mlinsner@cisco.com Fri Oct 19 05:42:38 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E511721F86A4 for ; Fri, 19 Oct 2012 05:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.815 X-Spam-Level: X-Spam-Status: No, score=-9.815 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmWc3iOw74D1 for ; Fri, 19 Oct 2012 05:42:37 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A9AA521F8632 for ; Fri, 19 Oct 2012 05:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4603; q=dns/txt; s=iport; t=1350650556; x=1351860156; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=8KoofON6rcEMLehW5s06QVL1p4mzstcVtLMiQsCd1gg=; b=Rt6MMBRghLMkRXmQhQxvNM5DoBRGuOP1/JV5h6lu9Q3xCB24l3ITM66I spxgwNPxcO7WRPMWnNtNAl5wYv6t5T1W2uS3Kv27dtQ/+vtmCSNsJD8bJ EoL0tgjnIJjH9qIwNESpn6GIR/EBYk4lxf19181BzApgOPRihoDWaOekE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABdJgVCtJV2Y/2dsb2JhbABFDsBTgQiCIAEBAQQBAQEPAScCATELDAcIDgMDAQEBAScuHwkIBgENBSKHYgucaKApBItYhm8DlW+FZIhpgWuCMlk X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="133396984" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 19 Oct 2012 12:42:35 +0000 Received: from [10.116.195.115] (rtp-mlinsner-8712.cisco.com [10.116.195.115]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9JCgVOl005506; Fri, 19 Oct 2012 12:42:32 GMT User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Fri, 19 Oct 2012 08:42:30 -0400 From: Marc Linsner To: Paul Kyzivat , Christer Holmberg Message-ID: Thread-Topic: [Ecrit] PSAP Callback Draft In-Reply-To: <5080AC3E.8080403@alum.mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "rai-ads@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 12:42:38 -0000 Paul, So do we have a commitment to progress both drafts expeditiously?? (Or at least in lockstep so PSAP-Callback doesn't sit in the RFC Editor blackhole due to dependencies) Thanks, -Marc- -----Original Message----- From: Paul Kyzivat Date: Thursday, October 18, 2012 9:26 PM To: Christer Holmberg Cc: "sipcore-chairs@tools.ietf.org" , "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback Draft >On 10/18/12 4:22 PM, Christer Holmberg wrote: >> >> Hi, >> >> So, just to clarify: Adam is working on a draft which will create the >>IANA registry for Priority header field values, and the psap-callback >>draft will then define and register a new header field value into that >>registry? > >Yes! > > Thanks, > Paul > >> Regards, >> >> Christer >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>Of Paul Kyzivat >> Sent: 18. lokakuuta 2012 21:32 >> To: Hannes Tschofenig >> Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; >>ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback Draft >> >> On 10/18/12 1:31 PM, Hannes Tschofenig wrote: >>> I am curious why you need a separate draft just to create an >>> additional registry. We still have "space left" in the current PSAP >>>callback draft... >> >> Oh, I thought it was "full". :-) >> >> We did discuss putting all the stuff to establish the IANA registry and >>grandfather the existing values into your draft. We just think that >>seems like a poor organization. (Sort of a layering violation.) We also >>aren't out of RFC numbers yet. :-) >> >> Thanks, >> Paul >> >>> On 10/18/2012 08:05 PM, Paul Kyzivat wrote: >>>> Hannes, Christer, ecrit wg, >>>> >>>> Robert, Adam and I have been discussing how best to handle the >>>> updating of the Priority header to include a new value. Ideally there >>>> would already be an IANA registry with defined procedures for adding >>>> new values. But there isn't. >>>> >>>> So we have two alternatives: >>>> >>>> 1) Simply mark this draft as an update to 3261. Provide ABNF that >>>> extends the syntax of the Priority header. (As your planned draft >>>> does.) >>>> >>>> 2) Make an update to 3261 that establishes a new IANA registry for >>>> Priority header field values, and populate it with all the values >>>> included in 3261. Set the rules for adding new values to that >>>>registry. >>>> Then set your new draft to follow those rules to add the new value to >>>> the registry. >>>> >>>> The 2nd way is clearly more work, but it is the "cleaner" way to do >>>>it. >>>> Robert has concerns that if we don't do that, and go with (1), then >>>> we will have some difficulty getting it through IESG. >>>> >>>> So we would prefer to do (2). Adam already put together a draft of a >>>> draft to do the revision to 3261. We can have that ready to submit >>>> when submissions are opened up again the first day in Atlanta. It is >>>> quite a straightforward thing to do so we expect we can have it >>>> approved and ready for the IESG soon enough that it won't slow your >>>> work up. Once that draft is filed you will be able to reference it in >>>> your draft so they can be wrapped up in parallel. >>>> >>>> Is ecrit ok with that direction? >>>> >>>> Thanks, >>>> Paul (as sipcore co-chair) >>>> >>>> On 10/18/12 4:49 AM, Hannes Tschofenig wrote: >>>>> Hi all, >>>>> >>>>> Christer and I had put the new text into the (not-yet-submitted) >>>>> draft. Here is the current snapshot: >>>>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/psap- >>>>> callback/draft-ietf-ecrit-psap-callback-06.txt >>>>> >>>>> >>>>> >>>>> Feedback we can be incorporated before the submission deadline. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Fri Oct 19 05:57:10 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD9721F85F7 for ; Fri, 19 Oct 2012 05:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.38 X-Spam-Level: X-Spam-Status: No, score=-106.38 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrKTH1INibVf for ; Fri, 19 Oct 2012 05:57:09 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFEA21F85ED for ; Fri, 19 Oct 2012 05:57:08 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q9JCuvZa031590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Oct 2012 14:56:57 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q9JCup47003340; Fri, 19 Oct 2012 14:56:52 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Oct 2012 14:56:28 +0200 Received: from 10.159.32.94 ([10.159.32.94]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) with Microsoft Exchange Server HTTP-DAV ; Fri, 19 Oct 2012 12:56:27 +0000 MIME-Version: 1.0 Message-ID: <377901cdadf9$2713c4a7$5e209f0a@nsnintra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" Thread-Topic: [Ecrit] PSAP Callback Draft Thread-Index: Ac2t+ScTEIPXH+7JQrucnMCsH/HnvA== Date: Fri, 19 Oct 2012 15:57:54 +0300 To: "ext Marc Linsner" , "Paul Kyzivat" , "Christer Holmberg" Content-Type: multipart/alternative; boundary="_5C8C3CE7-5F78-C375-C7F3-A653772323CB_"; charset="iso-8859-1" X-OriginalArrivalTime: 19 Oct 2012 12:56:28.0032 (UTC) FILETIME=[273C0800:01CDADF9] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 13328 X-purgate-ID: 151667::1350651418-000048BF-B93C814C/0-0/0-0 Cc: sipcore-chairs@tools.ietf.org, rai-ads@tools.ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 12:57:10 -0000 --_5C8C3CE7-5F78-C375-C7F3-A653772323CB_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Experience tells me to put the stuff in one document. Just think about Phon= e BCP... Sent from my Windows Phone -----Original Message----- From: ext Marc Linsner Sent: 10/19/2012 3:42 PM To: Paul Kyzivat; Christer Holmberg Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback Draft Paul, So do we have a commitment to progress both drafts expeditiously?? (Or at least in lockstep so PSAP-Callback doesn't sit in the RFC Editor blackhole due to dependencies) Thanks, -Marc- -----Original Message----- From: Paul Kyzivat Date: Thursday, October 18, 2012 9:26 PM To: Christer Holmberg Cc: "sipcore-chairs@tools.ietf.org" , "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback Draft >On 10/18/12 4:22 PM, Christer Holmberg wrote: >> >> Hi, >> >> So, just to clarify: Adam is working on a draft which will create the >>IANA registry for Priority header field values, and the psap-callback >>draft will then define and register a new header field value into that >>registry? > >Yes! > > Thanks, > Paul > >> Regards, >> >> Christer >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>Of Paul Kyzivat >> Sent: 18. lokakuuta 2012 21:32 >> To: Hannes Tschofenig >> Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; >>ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback Draft >> >> On 10/18/12 1:31 PM, Hannes Tschofenig wrote: >>> I am curious why you need a separate draft just to create an >>> additional registry. We still have "space left" in the current PSAP >>>callback draft... >> >> Oh, I thought it was "full". :-) >> >> We did discuss putting all the stuff to establish the IANA registry and >>grandfather the existing values into your draft. We just think that >>seems like a poor organization. (Sort of a layering violation.) We also >>aren't out of RFC numbers yet. :-) >> >> Thanks, >> Paul >> >>> On 10/18/2012 08:05 PM, Paul Kyzivat wrote: >>>> Hannes, Christer, ecrit wg, >>>> >>>> Robert, Adam and I have been discussing how best to handle the >>>> updating of the Priority header to include a new value. Ideally there >>>> would already be an IANA registry with defined procedures for adding >>>> new values. But there isn't. >>>> >>>> So we have two alternatives: >>>> >>>> 1) Simply mark this draft as an update to 3261. Provide ABNF that >>>> extends the syntax of the Priority header. (As your planned draft >>>> does.) >>>> >>>> 2) Make an update to 3261 that establishes a new IANA registry for >>>> Priority header field values, and populate it with all the values >>>> included in 3261. Set the rules for adding new values to that >>>>registry. >>>> Then set your new draft to follow those rules to add the new value to >>>> the registry. >>>> >>>> The 2nd way is clearly more work, but it is the "cleaner" way to do >>>>it. >>>> Robert has concerns that if we don't do that, and go with (1), then >>>> we will have some difficulty getting it through IESG. >>>> >>>> So we would prefer to do (2). Adam already put together a draft of a >>>> draft to do the revision to 3261. We can have that ready to submit >>>> when submissions are opened up again the first day in Atlanta. It is >>>> quite a straightforward thing to do so we expect we can have it >>>> approved and ready for the IESG soon enough that it won't slow your >>>> work up. Once that draft is filed you will be able to reference it in >>>> your draft so they can be wrapped up in parallel. >>>> >>>> Is ecrit ok with that direction? >>>> >>>> Thanks, >>>> Paul (as sipcore co-chair) >>>> >>>> On 10/18/12 4:49 AM, Hannes Tschofenig wrote: >>>>> Hi all, >>>>> >>>>> Christer and I had put the new text into the (not-yet-submitted) >>>>> draft. Here is the current snapshot: >>>>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/psap- >>>>> callback/draft-ietf-ecrit-psap-callback-06.txt >>>>> >>>>> >>>>> >>>>> Feedback we can be incorporated before the submission deadline. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_5C8C3CE7-5F78-C375-C7F3-A653772323CB_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Experience tells me to put the stuff in one document. = Just think about Phone BCP...

Sent from my Windows Phone

From: ext Marc Linsner
Sent: 10/19/2012 3:42 = PM
To: Paul Kyzivat; Christer Holmberg
C= c: = rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; ecrit@ietf.org
Subject: Re: [Ecrit] PSAP Callback Draft

Paul,
=
So do we have a commitment to progress both drafts expeditiously?? = ; (Or at
least in lockstep so PSAP-Callback doesn't sit in the RFC Edito= r blackhole
due to dependencies)

Thanks,

-Marc-




-----Original Message-----
From: Paul Kyzivat <pkyzivat@= alum.mit.edu>
Date: Thursday, October 18, 2012 9:26 PM
To: Christe= r Holmberg <christer.holmberg@ericsson.com>
Cc: "sipcore-chairs@to= ols.ietf.org" <sipcore-chairs@tools.ietf.org>,
"rai-ads@tools.ietf= .org" <rai-ads@tools.ietf.org>, "ecrit@ietf.org"
<ecrit@ietf.or= g>
Subject: Re: [Ecrit] PSAP Callback Draft

>On 10/18/12 4:= 22 PM, Christer Holmberg wrote:
>>
>> Hi,
>>
= >> So, just to clarify: Adam is working on a draft which will create = the
>>IANA registry for Priority header field values, and the psap= -callback
>>draft will then define and register a new header field= value into that
>>registry?
>
>Yes!
>
> T= hanks,
> Paul
>
>> Regards,
>>
>> Ch= rister
>>
>> -----Original Message-----
>> From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf
>&g= t;Of Paul Kyzivat
>> Sent: 18. lokakuuta 2012 21:32
>> To= : Hannes Tschofenig
>> Cc: rai-ads@tools.ietf.org; sipcore-chairs@= tools.ietf.org;
>>ecrit@ietf.org
>> Subject: Re: [Ecrit] = PSAP Callback Draft
>>
>> On 10/18/12 1:31 PM, Hannes Tsc= hofenig wrote:
>>> I am curious why you need a separate draft j= ust to create an
>>> additional registry. We still have "space = left" in the current PSAP
>>>callback draft...
>>
&= gt;> Oh, I thought it was "full". :-)
>>
>> We did dis= cuss putting all the stuff to establish the IANA registry and
>>gr= andfather the existing values into your draft. We just think that
>&g= t;seems like a poor organization. (Sort of a layering violation.) We also>>aren't out of RFC numbers yet. :-)
>>
>> Thank= s,
>> Paul
>>
>>> On 10/18/2012 08:05 PM, Pa= ul Kyzivat wrote:
>>>> Hannes, Christer, ecrit wg,
>&g= t;>>
>>>> Robert, Adam and I have been discussing how = best to handle the
>>>> updating of the Priority header to i= nclude a new value. Ideally there
>>>> would already be an I= ANA registry with defined procedures for adding
>>>> new val= ues. But there isn't.
>>>>
>>>> So we have tw= o alternatives:
>>>>
>>>> 1) Simply mark this= draft as an update to 3261. Provide ABNF that
>>>> extends = the syntax of the Priority header. (As your planned draft
>>>&g= t; does.)
>>>>
>>>> 2) Make an update to 3261= that establishes a new IANA registry for
>>>> Priority head= er field values, and populate it with all the values
>>>> in= cluded in 3261. Set the rules for adding new values to that
>>>= >registry.
>>>> Then set your new draft to follow those r= ules to add the new value to
>>>> the registry.
>>&= gt;>
>>>> The 2nd way is clearly more work, but it is the= "cleaner" way to do
>>>>it.
>>>> Robert has = concerns that if we don't do that, and go with (1), then
>>>>= ; we will have some difficulty getting it through IESG.
>>>>=
>>>> So we would prefer to do (2). Adam already put togethe= r a draft of a
>>>> draft to do the revision to 3261. We can= have that ready to submit
>>>> when submissions are opened = up again the first day in Atlanta. It is
>>>> quite a straig= htforward thing to do so we expect we can have it
>>>> appro= ved and ready for the IESG soon enough that it won't slow your
>>&= gt;> work up. Once that draft is filed you will be able to reference it = in
>>>> your draft so they can be wrapped up in parallel.>>>>
>>>> Is ecrit ok with that direction?
&= gt;>>>
>>>>       Tha= nks,
>>>>       Paul (as sipco= re co-chair)
>>>>
>>>> On 10/18/12 4:49 AM, H= annes Tschofenig wrote:
>>>>> Hi all,
>>>>= >
>>>>> Christer and I had put the new text into the (= not-yet-submitted)
>>>>> draft. Here is the current snaps= hot:
>>>>> https://github.com/hannestschofenig/tschofenig= -ids/blob/master/psap-
>>>>> callback/draft-ietf-ecrit-ps= ap-callback-06.txt
>>>>>
>>>>>
>&= gt;>>>
>>>>> Feedback we can be incorporated bef= ore the submission deadline.
>>>>>
>>>>>= ; Ciao
>>>>> Hannes
>>>>>
>>&g= t;>> _______________________________________________
>>>&= gt;> Ecrit mailing list
>>>>> Ecrit@ietf.org
>&g= t;>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>&= gt;>
>>>>
>>>> ___________________________= ____________________
>>>> Ecrit mailing list
>>>= > Ecrit@ietf.org
>>>> https://www.ietf.org/mailman/listin= fo/ecrit
>>>
>>>
>>
>> __________= _____________________________________
>> Ecrit mailing list
>= ;> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecri= t
>>
>
>______________________________________________= _
>Ecrit mailing list
>Ecrit@ietf.org
>https://www.ietf.o= rg/mailman/listinfo/ecrit


______________________________________= _________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/m= ailman/listinfo/ecrit
= --_5C8C3CE7-5F78-C375-C7F3-A653772323CB_-- From pkyzivat@alum.mit.edu Fri Oct 19 08:38:56 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDD421F84D8 for ; Fri, 19 Oct 2012 08:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wd2PLDznvVu for ; Fri, 19 Oct 2012 08:38:55 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 818FE21F8462 for ; Fri, 19 Oct 2012 08:38:55 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta02.westchester.pa.mail.comcast.net with comcast id CzRk1k0031uE5Es513ezxh; Fri, 19 Oct 2012 15:38:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id D3fB1k00l3ZTu2S3c3fBNy; Fri, 19 Oct 2012 15:39:12 +0000 Message-ID: <5081740C.3020802@alum.mit.edu> Date: Fri, 19 Oct 2012 11:38:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Marc Linsner References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rai-ads@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:38:56 -0000 On 10/19/12 8:42 AM, Marc Linsner wrote: > Paul, > > So do we have a commitment to progress both drafts expeditiously?? (Or at > least in lockstep so PSAP-Callback doesn't sit in the RFC Editor blackhole > due to dependencies) Yes, that is the plan. Thanks, Paul > Thanks, > > -Marc- > > > > > > -----Original Message----- > From: Paul Kyzivat > Date: Thursday, October 18, 2012 9:26 PM > To: Christer Holmberg > Cc: "sipcore-chairs@tools.ietf.org" , > "rai-ads@tools.ietf.org" , "ecrit@ietf.org" > > Subject: Re: [Ecrit] PSAP Callback Draft > >> On 10/18/12 4:22 PM, Christer Holmberg wrote: >>> >>> Hi, >>> >>> So, just to clarify: Adam is working on a draft which will create the >>> IANA registry for Priority header field values, and the psap-callback >>> draft will then define and register a new header field value into that >>> registry? >> >> Yes! >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: 18. lokakuuta 2012 21:32 >>> To: Hannes Tschofenig >>> Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] PSAP Callback Draft >>> >>> On 10/18/12 1:31 PM, Hannes Tschofenig wrote: >>>> I am curious why you need a separate draft just to create an >>>> additional registry. We still have "space left" in the current PSAP >>>> callback draft... >>> >>> Oh, I thought it was "full". :-) >>> >>> We did discuss putting all the stuff to establish the IANA registry and >>> grandfather the existing values into your draft. We just think that >>> seems like a poor organization. (Sort of a layering violation.) We also >>> aren't out of RFC numbers yet. :-) >>> >>> Thanks, >>> Paul >>> >>>> On 10/18/2012 08:05 PM, Paul Kyzivat wrote: >>>>> Hannes, Christer, ecrit wg, >>>>> >>>>> Robert, Adam and I have been discussing how best to handle the >>>>> updating of the Priority header to include a new value. Ideally there >>>>> would already be an IANA registry with defined procedures for adding >>>>> new values. But there isn't. >>>>> >>>>> So we have two alternatives: >>>>> >>>>> 1) Simply mark this draft as an update to 3261. Provide ABNF that >>>>> extends the syntax of the Priority header. (As your planned draft >>>>> does.) >>>>> >>>>> 2) Make an update to 3261 that establishes a new IANA registry for >>>>> Priority header field values, and populate it with all the values >>>>> included in 3261. Set the rules for adding new values to that >>>>> registry. >>>>> Then set your new draft to follow those rules to add the new value to >>>>> the registry. >>>>> >>>>> The 2nd way is clearly more work, but it is the "cleaner" way to do >>>>> it. >>>>> Robert has concerns that if we don't do that, and go with (1), then >>>>> we will have some difficulty getting it through IESG. >>>>> >>>>> So we would prefer to do (2). Adam already put together a draft of a >>>>> draft to do the revision to 3261. We can have that ready to submit >>>>> when submissions are opened up again the first day in Atlanta. It is >>>>> quite a straightforward thing to do so we expect we can have it >>>>> approved and ready for the IESG soon enough that it won't slow your >>>>> work up. Once that draft is filed you will be able to reference it in >>>>> your draft so they can be wrapped up in parallel. >>>>> >>>>> Is ecrit ok with that direction? >>>>> >>>>> Thanks, >>>>> Paul (as sipcore co-chair) >>>>> >>>>> On 10/18/12 4:49 AM, Hannes Tschofenig wrote: >>>>>> Hi all, >>>>>> >>>>>> Christer and I had put the new text into the (not-yet-submitted) >>>>>> draft. Here is the current snapshot: >>>>>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/psap- >>>>>> callback/draft-ietf-ecrit-psap-callback-06.txt >>>>>> >>>>>> >>>>>> >>>>>> Feedback we can be incorporated before the submission deadline. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > From christer.holmberg@ericsson.com Fri Oct 19 12:01:11 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD55E21F8839 for ; Fri, 19 Oct 2012 12:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.13 X-Spam-Level: X-Spam-Status: No, score=-6.13 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBE2ObgaxznR for ; Fri, 19 Oct 2012 12:01:10 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6757A21F87FB for ; Fri, 19 Oct 2012 12:01:04 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-39-5081a36e8be9 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B7.C1.04547.E63A1805; Fri, 19 Oct 2012 21:01:02 +0200 (CEST) Received: from ESESSHC007.ericsson.se (153.88.183.39) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 19 Oct 2012 21:01:02 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 21:01:02 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , Marc Linsner Thread-Topic: [Ecrit] PSAP Callback Draft Thread-Index: AQHNrQ5+WsJqUqLqEkmjg04voM/cMZe/KdEAgAAHWICAABENAIAAP71ggAAz5wCAALzpAIAAMUcAgABZSyA= Date: Fri, 19 Oct 2012 19:01:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B01A2E9@ESESSMB209.ericsson.se> References: <5081740C.3020802@alum.mit.edu> In-Reply-To: <5081740C.3020802@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3VjdvcWOAwZI/1haNi56yWpy9fJ3R YsWGA6wWe7fPY7Q49eo0swOrx9/3H5g8pvzeyOqxZMlPJo8vlz+zBbBEcdmkpOZklqUW6dsl cGVMXr+PqeCsdsWef73MDYxXlLsYOTkkBEwkDu2ezARhi0lcuLeerYuRi0NI4BSjRMvM/1DO TkaJaSd/sYFUCQksYZT4ebKqi5GDg03AQqL7nzZIWETAV2Lhij+MIPXMAnMZJVY/mgs2VVhA Q2LlvHPsEEWaEkd3NzJB2EkS89a1gc1kEVCV+HPzCyuIzSvgLbF73TNmiF2BEtuPzgWLcwro SKw5vQbMZgS69PupNWBzmAXEJW49mQ/1gYDEkj3nmSFsUYmXj/+xQtiKEh9f7WOEqNeRWLD7 ExuErS2xbOFrZoi9ghInZz5hgdirLdGyeAL7BEaJWUhWzELSPgtJ+ywk7QsYWVYxCucmZuak lxvppRZlJhcX5+fpFaduYgTG58Etv1V3MN45J3KIUZqDRUmc13rrHn8hgfTEktTs1NSC1KL4 otKc1OJDjEwcnFINjHyGv4SuhzYsvMs4iYM96GHNPN9ehYdL/epYFxQoLDy0vjKfVWByY7fl itjgX1eO8F3K/2kT8uCDoBzTCjnxhZnx/x3E3swXmms++frqatWjedN2GB2PiBPtbLzz19Pu ypyTvzfYNXVJ8vv8eXH08rH/B4snF3cVr12s3227ZNJ0lR1l9w7dY1JiKc5INNRiLipOBAB7 oQjYnQIAAA== Cc: "rai-ads@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 19:01:11 -0000 Hi, I support moving ahead with two drafts.=20 Because, that means we can keep the psap-callback draft in ECRIT, while I a= ssume the Privacy registry draft will be produced in SIPCORE. Assuming, of course, that SIPCORE will agree to produce such draft. I hope = such agreement can come asap. Regards, Christer =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 19. lokakuuta 2012 18:39 To: Marc Linsner Cc: Christer Holmberg; sipcore-chairs@tools.ietf.org; rai-ads@tools.ietf.or= g; ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback Draft On 10/19/12 8:42 AM, Marc Linsner wrote: > Paul, > > So do we have a commitment to progress both drafts expeditiously?? =20 > (Or at least in lockstep so PSAP-Callback doesn't sit in the RFC=20 > Editor blackhole due to dependencies) Yes, that is the plan. Thanks, Paul > Thanks, > > -Marc- > > > > > > -----Original Message----- > From: Paul Kyzivat > Date: Thursday, October 18, 2012 9:26 PM > To: Christer Holmberg > Cc: "sipcore-chairs@tools.ietf.org" ,=20 > "rai-ads@tools.ietf.org" , "ecrit@ietf.org" > > Subject: Re: [Ecrit] PSAP Callback Draft > >> On 10/18/12 4:22 PM, Christer Holmberg wrote: >>> >>> Hi, >>> >>> So, just to clarify: Adam is working on a draft which will create=20 >>> the IANA registry for Priority header field values, and the=20 >>> psap-callback draft will then define and register a new header field=20 >>> value into that registry? >> >> Yes! >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >>> Behalf Of Paul Kyzivat >>> Sent: 18. lokakuuta 2012 21:32 >>> To: Hannes Tschofenig >>> Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org;=20 >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] PSAP Callback Draft >>> >>> On 10/18/12 1:31 PM, Hannes Tschofenig wrote: >>>> I am curious why you need a separate draft just to create an=20 >>>> additional registry. We still have "space left" in the current PSAP=20 >>>> callback draft... >>> >>> Oh, I thought it was "full". :-) >>> >>> We did discuss putting all the stuff to establish the IANA registry=20 >>> and grandfather the existing values into your draft. We just think=20 >>> that seems like a poor organization. (Sort of a layering violation.)=20 >>> We also aren't out of RFC numbers yet. :-) >>> >>> Thanks, >>> Paul >>> >>>> On 10/18/2012 08:05 PM, Paul Kyzivat wrote: >>>>> Hannes, Christer, ecrit wg, >>>>> >>>>> Robert, Adam and I have been discussing how best to handle the=20 >>>>> updating of the Priority header to include a new value. Ideally=20 >>>>> there would already be an IANA registry with defined procedures=20 >>>>> for adding new values. But there isn't. >>>>> >>>>> So we have two alternatives: >>>>> >>>>> 1) Simply mark this draft as an update to 3261. Provide ABNF that=20 >>>>> extends the syntax of the Priority header. (As your planned draft >>>>> does.) >>>>> >>>>> 2) Make an update to 3261 that establishes a new IANA registry for=20 >>>>> Priority header field values, and populate it with all the values=20 >>>>> included in 3261. Set the rules for adding new values to that=20 >>>>> registry. >>>>> Then set your new draft to follow those rules to add the new value=20 >>>>> to the registry. >>>>> >>>>> The 2nd way is clearly more work, but it is the "cleaner" way to=20 >>>>> do it. >>>>> Robert has concerns that if we don't do that, and go with (1),=20 >>>>> then we will have some difficulty getting it through IESG. >>>>> >>>>> So we would prefer to do (2). Adam already put together a draft of=20 >>>>> a draft to do the revision to 3261. We can have that ready to=20 >>>>> submit when submissions are opened up again the first day in=20 >>>>> Atlanta. It is quite a straightforward thing to do so we expect we=20 >>>>> can have it approved and ready for the IESG soon enough that it=20 >>>>> won't slow your work up. Once that draft is filed you will be able=20 >>>>> to reference it in your draft so they can be wrapped up in parallel. >>>>> >>>>> Is ecrit ok with that direction? >>>>> >>>>> Thanks, >>>>> Paul (as sipcore co-chair) >>>>> >>>>> On 10/18/12 4:49 AM, Hannes Tschofenig wrote: >>>>>> Hi all, >>>>>> >>>>>> Christer and I had put the new text into the (not-yet-submitted)=20 >>>>>> draft. Here is the current snapshot: >>>>>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/ps >>>>>> ap- callback/draft-ietf-ecrit-psap-callback-06.txt >>>>>> >>>>>> >>>>>> >>>>>> Feedback we can be incorporated before the submission deadline. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > From jmpolk@cisco.com Fri Oct 19 12:47:08 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E9321F878A for ; Fri, 19 Oct 2012 12:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNkGLQPMwqGg for ; Fri, 19 Oct 2012 12:47:07 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 43B4821F874B for ; Fri, 19 Oct 2012 12:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6041; q=dns/txt; s=iport; t=1350676027; x=1351885627; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=SdYDn4cmqNcbrWU45WVa0ZPbdJmTq5UsTQY8ONo6+Ro=; b=TF0zMhc7HQcMP2+nTtgrBy5STYlsSe5svLRpUuvuCkpJCWH+iFhj85sW 0iH6jfQRjLST7I0R33k2hc27RYSYgtZyoiA3S1ZpSkeII++PzrLgdP2TX fkLO6Bu+NygO5N2t1R2Flx3uxEkNnW08hhReSSgwz16f2OXenU5fFqNck Y=; X-IronPort-AV: E=Sophos;i="4.80,615,1344211200"; d="scan'208";a="133585827" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 19 Oct 2012 19:46:44 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) (authenticated bits=0) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9JJkiWA016351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 19:46:44 GMT Message-Id: <201210191946.q9JJkiWA016351@rcdn-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 19 Oct 2012 14:46:44 -0500 To: Christer Holmberg , "'Paul Kyzivat'" , Marc Linsner From: James Polk In-Reply-To: <7594FB04B1934943A5C02806D1A2204B01A2E9@ESESSMB209.ericsson .se> References: <5081740C.3020802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B01A2E9@ESESSMB209.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: "sipcore-chairs@tools.ietf.org" , "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 19:47:08 -0000 At 02:01 PM 10/19/2012, Christer Holmberg wrote: >Hi, > >I support moving ahead with two drafts. > >Because, that means we can keep the psap-callback draft in ECRIT, >while I assume the Privacy s/privacy/priority >registry draft will be produced in SIPCORE. > >Assuming, of course, that SIPCORE will agree to produce such draft. >I hope such agreement can come asap. > >Regards, > >Christer > > > > >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >Sent: 19. lokakuuta 2012 18:39 >To: Marc Linsner >Cc: Christer Holmberg; sipcore-chairs@tools.ietf.org; >rai-ads@tools.ietf.org; ecrit@ietf.org >Subject: Re: [Ecrit] PSAP Callback Draft > >On 10/19/12 8:42 AM, Marc Linsner wrote: > > Paul, > > > > So do we have a commitment to progress both drafts expeditiously?? > > (Or at least in lockstep so PSAP-Callback doesn't sit in the RFC > > Editor blackhole due to dependencies) > >Yes, that is the plan. > > Thanks, > Paul > > > Thanks, > > > > -Marc- > > > > > > > > > > > > -----Original Message----- > > From: Paul Kyzivat > > Date: Thursday, October 18, 2012 9:26 PM > > To: Christer Holmberg > > Cc: "sipcore-chairs@tools.ietf.org" , > > "rai-ads@tools.ietf.org" , "ecrit@ietf.org" > > > > Subject: Re: [Ecrit] PSAP Callback Draft > > > >> On 10/18/12 4:22 PM, Christer Holmberg wrote: > >>> > >>> Hi, > >>> > >>> So, just to clarify: Adam is working on a draft which will create > >>> the IANA registry for Priority header field values, and the > >>> psap-callback draft will then define and register a new header field > >>> value into that registry? > >> > >> Yes! > >> > >> Thanks, > >> Paul > >> > >>> Regards, > >>> > >>> Christer > >>> > >>> -----Original Message----- > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>> Behalf Of Paul Kyzivat > >>> Sent: 18. lokakuuta 2012 21:32 > >>> To: Hannes Tschofenig > >>> Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; > >>> ecrit@ietf.org > >>> Subject: Re: [Ecrit] PSAP Callback Draft > >>> > >>> On 10/18/12 1:31 PM, Hannes Tschofenig wrote: > >>>> I am curious why you need a separate draft just to create an > >>>> additional registry. We still have "space left" in the current PSAP > >>>> callback draft... > >>> > >>> Oh, I thought it was "full". :-) > >>> > >>> We did discuss putting all the stuff to establish the IANA registry > >>> and grandfather the existing values into your draft. We just think > >>> that seems like a poor organization. (Sort of a layering violation.) > >>> We also aren't out of RFC numbers yet. :-) > >>> > >>> Thanks, > >>> Paul > >>> > >>>> On 10/18/2012 08:05 PM, Paul Kyzivat wrote: > >>>>> Hannes, Christer, ecrit wg, > >>>>> > >>>>> Robert, Adam and I have been discussing how best to handle the > >>>>> updating of the Priority header to include a new value. Ideally > >>>>> there would already be an IANA registry with defined procedures > >>>>> for adding new values. But there isn't. > >>>>> > >>>>> So we have two alternatives: > >>>>> > >>>>> 1) Simply mark this draft as an update to 3261. Provide ABNF that > >>>>> extends the syntax of the Priority header. (As your planned draft > >>>>> does.) > >>>>> > >>>>> 2) Make an update to 3261 that establishes a new IANA registry for > >>>>> Priority header field values, and populate it with all the values > >>>>> included in 3261. Set the rules for adding new values to that > >>>>> registry. > >>>>> Then set your new draft to follow those rules to add the new value > >>>>> to the registry. > >>>>> > >>>>> The 2nd way is clearly more work, but it is the "cleaner" way to > >>>>> do it. > >>>>> Robert has concerns that if we don't do that, and go with (1), > >>>>> then we will have some difficulty getting it through IESG. > >>>>> > >>>>> So we would prefer to do (2). Adam already put together a draft of > >>>>> a draft to do the revision to 3261. We can have that ready to > >>>>> submit when submissions are opened up again the first day in > >>>>> Atlanta. It is quite a straightforward thing to do so we expect we > >>>>> can have it approved and ready for the IESG soon enough that it > >>>>> won't slow your work up. Once that draft is filed you will be able > >>>>> to reference it in your draft so they can be wrapped up in parallel. > >>>>> > >>>>> Is ecrit ok with that direction? > >>>>> > >>>>> Thanks, > >>>>> Paul (as sipcore co-chair) > >>>>> > >>>>> On 10/18/12 4:49 AM, Hannes Tschofenig wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> Christer and I had put the new text into the (not-yet-submitted) > >>>>>> draft. Here is the current snapshot: > >>>>>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/ps > >>>>>> ap- callback/draft-ietf-ecrit-psap-callback-06.txt > >>>>>> > >>>>>> > >>>>>> > >>>>>> Feedback we can be incorporated before the submission deadline. > >>>>>> > >>>>>> Ciao > >>>>>> Hannes > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Ecrit mailing list > >>>>>> Ecrit@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Fri Oct 19 14:47:39 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D5221F87DD for ; Fri, 19 Oct 2012 14:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.131 X-Spam-Level: X-Spam-Status: No, score=-6.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JExVC5hhIbMo for ; Fri, 19 Oct 2012 14:47:38 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 92DC721F8816 for ; Fri, 19 Oct 2012 14:47:37 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-a3-5081ca77c169 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 92.3E.17130.77AC1805; Fri, 19 Oct 2012 23:47:36 +0200 (CEST) Received: from ESESSHC014.ericsson.se (153.88.183.60) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 19 Oct 2012 23:47:35 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 23:47:35 +0200 From: Christer Holmberg To: 'James Polk' , 'Paul Kyzivat' , Marc Linsner Thread-Topic: [Ecrit] PSAP Callback Draft Thread-Index: AQHNrQ5+WsJqUqLqEkmjg04voM/cMZe/KdEAgAAHWICAABENAIAAP71ggAAz5wCAALzpAIAAMUcAgABZSyCAAA2F9YAAIawg Date: Fri, 19 Oct 2012 21:47:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B01A3C2@ESESSMB209.ericsson.se> References: <5081740C.3020802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B01A2E9@ESESSMB209.ericsson.se> <201210191946.q9JJkiWA016351@rcdn-core-5.cisco.com> In-Reply-To: <201210191946.q9JJkiWA016351@rcdn-core-5.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3VrfiVGOAwduLPBaNi56yWuxYU2hx 9vJ1RosVGw6wWuzdPo/R4tSr08wObB5/339g8pjyeyOrx5IlP5k8vlz+zBbAEsVlk5Kak1mW WqRvl8CVsbt9HkvBJaOKJ2+2MDUw3tDoYuTkkBAwkTjc2ssIYYtJXLi3nq2LkYtDSOAUo8SH tXOYIJydjBLfP81gBakSEljCKHF1fVIXIwcHm4CFRPc/bZCwiECBxNt789lB6pkF5jJKvP8+ gx0kISygIbFy3jl2iCJNiaO7G5kg7DyJ35t/g9ksAqoSf3ftB7N5Bbwllu59ygyx+CSjxLyp 28EWcwo4SCzcdRNsECPQqd9PrQFrYBYQl7j1ZD4TxAsCEkv2nGeGsEUlXj7+xwphK0p8fLWP EaJeR2LB7k9sELa2xLKFr5khFgtKnJz5hAXiSW2JlsUT2CcwSsxCsmIWkvZZSNpnIWlfwMiy ilE4NzEzJ73cXC+1KDO5uDg/T684dRMjMFIPbvltsINx032xQ4zSHCxK4rx6qvv9hQTSE0tS s1NTC1KL4otKc1KLDzEycXBKNTDmVUe1hq37U2PTt3FiysTXW1rqBT71nePUMi96Hyl1+O36 hayPcuz0+F0OSWjeUGB8H/pCYKcln3bJt82rD/MJfdTnCJTZ8YNZYY7Dn2N8B+W23uuWCtOb ltm75brxkzOcttwfMuU3iQQnM01UexxZ+WIjy+8O44eMCV+ufOHunaDjLnztj78SS3FGoqEW c1FxIgA3JiiPogIAAA== Cc: "sipcore-chairs@tools.ietf.org" , "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 21:47:39 -0000 Correct :) Regards, Christer=20 -----Original Message----- From: James Polk [mailto:jmpolk@cisco.com]=20 Sent: 19. lokakuuta 2012 22:47 To: Christer Holmberg; 'Paul Kyzivat'; Marc Linsner Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback Draft At 02:01 PM 10/19/2012, Christer Holmberg wrote: >Hi, > >I support moving ahead with two drafts. > >Because, that means we can keep the psap-callback draft in ECRIT, while=20 >I assume the Privacy s/privacy/priority >registry draft will be produced in SIPCORE. > >Assuming, of course, that SIPCORE will agree to produce such draft.=20 >I hope such agreement can come asap. > >Regards, > >Christer > > > > >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >Sent: 19. lokakuuta 2012 18:39 >To: Marc Linsner >Cc: Christer Holmberg; sipcore-chairs@tools.ietf.org;=20 >rai-ads@tools.ietf.org; ecrit@ietf.org >Subject: Re: [Ecrit] PSAP Callback Draft > >On 10/19/12 8:42 AM, Marc Linsner wrote: > > Paul, > > > > So do we have a commitment to progress both drafts expeditiously?? > > (Or at least in lockstep so PSAP-Callback doesn't sit in the RFC=20 > > Editor blackhole due to dependencies) > >Yes, that is the plan. > > Thanks, > Paul > > > Thanks, > > > > -Marc- > > > > > > > > > > > > -----Original Message----- > > From: Paul Kyzivat > > Date: Thursday, October 18, 2012 9:26 PM > > To: Christer Holmberg > > Cc: "sipcore-chairs@tools.ietf.org" ,=20 > > "rai-ads@tools.ietf.org" , "ecrit@ietf.org" > > > > Subject: Re: [Ecrit] PSAP Callback Draft > > > >> On 10/18/12 4:22 PM, Christer Holmberg wrote: > >>> > >>> Hi, > >>> > >>> So, just to clarify: Adam is working on a draft which will create=20 > >>> the IANA registry for Priority header field values, and the=20 > >>> psap-callback draft will then define and register a new header=20 > >>> field value into that registry? > >> > >> Yes! > >> > >> Thanks, > >> Paul > >> > >>> Regards, > >>> > >>> Christer > >>> > >>> -----Original Message----- > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >>> Behalf Of Paul Kyzivat > >>> Sent: 18. lokakuuta 2012 21:32 > >>> To: Hannes Tschofenig > >>> Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org;=20 > >>> ecrit@ietf.org > >>> Subject: Re: [Ecrit] PSAP Callback Draft > >>> > >>> On 10/18/12 1:31 PM, Hannes Tschofenig wrote: > >>>> I am curious why you need a separate draft just to create an=20 > >>>> additional registry. We still have "space left" in the current=20 > >>>> PSAP callback draft... > >>> > >>> Oh, I thought it was "full". :-) > >>> > >>> We did discuss putting all the stuff to establish the IANA=20 > >>> registry and grandfather the existing values into your draft. We=20 > >>> just think that seems like a poor organization. (Sort of a=20 > >>> layering violation.) We also aren't out of RFC numbers yet. :-) > >>> > >>> Thanks, > >>> Paul > >>> > >>>> On 10/18/2012 08:05 PM, Paul Kyzivat wrote: > >>>>> Hannes, Christer, ecrit wg, > >>>>> > >>>>> Robert, Adam and I have been discussing how best to handle the=20 > >>>>> updating of the Priority header to include a new value. Ideally=20 > >>>>> there would already be an IANA registry with defined procedures=20 > >>>>> for adding new values. But there isn't. > >>>>> > >>>>> So we have two alternatives: > >>>>> > >>>>> 1) Simply mark this draft as an update to 3261. Provide ABNF=20 > >>>>> that extends the syntax of the Priority header. (As your planned=20 > >>>>> draft > >>>>> does.) > >>>>> > >>>>> 2) Make an update to 3261 that establishes a new IANA registry=20 > >>>>> for Priority header field values, and populate it with all the=20 > >>>>> values included in 3261. Set the rules for adding new values to=20 > >>>>> that registry. > >>>>> Then set your new draft to follow those rules to add the new=20 > >>>>> value to the registry. > >>>>> > >>>>> The 2nd way is clearly more work, but it is the "cleaner" way to=20 > >>>>> do it. > >>>>> Robert has concerns that if we don't do that, and go with (1),=20 > >>>>> then we will have some difficulty getting it through IESG. > >>>>> > >>>>> So we would prefer to do (2). Adam already put together a draft=20 > >>>>> of a draft to do the revision to 3261. We can have that ready to=20 > >>>>> submit when submissions are opened up again the first day in=20 > >>>>> Atlanta. It is quite a straightforward thing to do so we expect=20 > >>>>> we can have it approved and ready for the IESG soon enough that=20 > >>>>> it won't slow your work up. Once that draft is filed you will be=20 > >>>>> able to reference it in your draft so they can be wrapped up in par= allel. > >>>>> > >>>>> Is ecrit ok with that direction? > >>>>> > >>>>> Thanks, > >>>>> Paul (as sipcore co-chair) > >>>>> > >>>>> On 10/18/12 4:49 AM, Hannes Tschofenig wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> Christer and I had put the new text into the=20 > >>>>>> (not-yet-submitted) draft. Here is the current snapshot: > >>>>>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/ > >>>>>> ps > >>>>>> ap- callback/draft-ietf-ecrit-psap-callback-06.txt > >>>>>> > >>>>>> > >>>>>> > >>>>>> Feedback we can be incorporated before the submission deadline. > >>>>>> > >>>>>> Ciao > >>>>>> Hannes > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Ecrit mailing list > >>>>>> Ecrit@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From internet-drafts@ietf.org Mon Oct 22 00:27:10 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C528921F8A3A; Mon, 22 Oct 2012 00:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NwFLp3uzkAY; Mon, 22 Oct 2012 00:27:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1C71F0424; Mon, 22 Oct 2012 00:27:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022072709.1129.45132.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 00:27:09 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-trustworthy-location-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 07:27:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Trustworthy Location Author(s) : Hannes Tschofenig Henning Schulzrinne Bernard Aboba Filename : draft-ietf-ecrit-trustworthy-location-04.txt Pages : 21 Date : 2012-10-22 Abstract: For some location-based applications, such as emergency calling or roadside assistance, the trustworthiness of location information is critically important. This document describes the problem of "trustworthy location" as well as potential solutions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-trustworthy-location-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-trustworthy-location-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 03:41:16 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0DA21F8A6B; Mon, 22 Oct 2012 03:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aaKQmIUWdTt; Mon, 22 Oct 2012 03:41:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D0A21F8466; Mon, 22 Oct 2012 03:41:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022104115.4196.53509.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 03:41:15 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-psap-callback-06.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 10:41:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Public Safety Answering Point (PSAP) Callback Author(s) : Henning Schulzrinne Hannes Tschofenig Christer Holmberg Milan Patel Filename : draft-ietf-ecrit-psap-callback-06.txt Pages : 20 Date : 2012-10-22 Abstract: After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call taker) it is possible that the call taker feels the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current situation of a wounded person. A call taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and as a consequence it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture specification already offers a solution approach for allowing PSAP callbacks to bypass authorization policies to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than- normal call treatment behavior would be desirable. Note that this version of the document does not yet specify a solution due to the lack of the working group participants agreeing on the requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-psap-callback-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 04:14:24 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD5221F84D6; Mon, 22 Oct 2012 04:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWhFDqZcDYAW; Mon, 22 Oct 2012 04:14:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7893821F84AB; Mon, 22 Oct 2012 04:14:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022111423.30549.14799.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 04:14:23 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-05.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 11:14:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Filename : draft-ietf-ecrit-additional-data-05.txt Pages : 55 Date : 2012-10-22 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any service provider in the path of the call, or access network through which the call originated may have information about the call which the PSAP may be able to use. This document describes an XML data structure to contains such data and a Uniform Resource Identifier (URI) for conveying the data to the PSAP. The URI may point to either an external resource, or the body of the SIP message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adam@nostrum.com Fri Oct 19 12:26:03 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8463321F886E for ; Fri, 19 Oct 2012 12:26:02 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3860D-BW9GEu for ; Fri, 19 Oct 2012 12:26:00 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 421D821F875A for ; Fri, 19 Oct 2012 12:26:00 -0700 (PDT) Received: from Svantevit.local ([64.134.176.157]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9JJPq0Y018635 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 14:25:53 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5081A93C.9040103@nostrum.com> Date: Fri, 19 Oct 2012 14:25:48 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <377901cdadf9$2713c4a7$5e209f0a@nsnintra.net> In-Reply-To: <377901cdadf9$2713c4a7$5e209f0a@nsnintra.net> Content-Type: multipart/alternative; boundary="------------050204030800020304080504" Received-SPF: pass (nostrum.com: 64.134.176.157 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 23 Oct 2012 08:11:53 -0700 Cc: sipcore-chairs@tools.ietf.org, ecrit@ietf.org, rai-ads@tools.ietf.org Subject: Re: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 19:26:03 -0000 This is a multi-part message in MIME format. --------------050204030800020304080504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [speaking as SIPCORE chair] Hannes: I understand the concern -- but the counter is that fixing what appears to be a bug in the core SIP spec* seems a bit out of charter for ECRIT. I'm not entirely certain you'd have review from the SIP community at large for creation of the registry, and I think that such visibility is necessary. The SIPCORE document would be a very short one. The only issue that is likely (in my personal opinion) to generate significant discussion is IANA registration policy. Given that SIPCORE doesn't have a ton on its plate right now, I'm pretty comfortable that we can get such a document pubreq'd fast enough that it won't get in the way of ECRIT's document being published. /a * To wit: I consider it a bug that we have defined a clear extension point in the protocol without also defining a registry for values. On 10/19/12 7:57 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Experience tells me to put the stuff in one document. Just think about > Phone BCP... > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: ext Marc Linsner > Sent: 10/19/2012 3:42 PM > To: Paul Kyzivat; Christer Holmberg > Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback Draft > > Paul, > > So do we have a commitment to progress both drafts expeditiously?? (Or at > least in lockstep so PSAP-Callback doesn't sit in the RFC Editor blackhole > due to dependencies) > > Thanks, > > -Marc- > > > > > > -----Original Message----- > From: Paul Kyzivat > Date: Thursday, October 18, 2012 9:26 PM > To: Christer Holmberg > Cc: "sipcore-chairs@tools.ietf.org" , > "rai-ads@tools.ietf.org" , "ecrit@ietf.org" > > Subject: Re: [Ecrit] PSAP Callback Draft > > >On 10/18/12 4:22 PM, Christer Holmberg wrote: > >> > >> Hi, > >> > >> So, just to clarify: Adam is working on a draft which will create the > >>IANA registry for Priority header field values, and the psap-callback > >>draft will then define and register a new header field value into that > >>registry? > > > >Yes! > > > > Thanks, > > Paul > > > >> Regards, > >> > >> Christer > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >>Of Paul Kyzivat > >> Sent: 18. lokakuuta 2012 21:32 > >> To: Hannes Tschofenig > >> Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; > >>ecrit@ietf.org > >> Subject: Re: [Ecrit] PSAP Callback Draft > >> > >> On 10/18/12 1:31 PM, Hannes Tschofenig wrote: > >>> I am curious why you need a separate draft just to create an > >>> additional registry. We still have "space left" in the current PSAP > >>>callback draft... > >> > >> Oh, I thought it was "full". :-) > >> > >> We did discuss putting all the stuff to establish the IANA registry and > >>grandfather the existing values into your draft. We just think that > >>seems like a poor organization. (Sort of a layering violation.) We also > >>aren't out of RFC numbers yet. :-) > >> > >> Thanks, > >> Paul > >> > >>> On 10/18/2012 08:05 PM, Paul Kyzivat wrote: > >>>> Hannes, Christer, ecrit wg, > >>>> > >>>> Robert, Adam and I have been discussing how best to handle the > >>>> updating of the Priority header to include a new value. Ideally there > >>>> would already be an IANA registry with defined procedures for adding > >>>> new values. But there isn't. > >>>> > >>>> So we have two alternatives: > >>>> > >>>> 1) Simply mark this draft as an update to 3261. Provide ABNF that > >>>> extends the syntax of the Priority header. (As your planned draft > >>>> does.) > >>>> > >>>> 2) Make an update to 3261 that establishes a new IANA registry for > >>>> Priority header field values, and populate it with all the values > >>>> included in 3261. Set the rules for adding new values to that > >>>>registry. > >>>> Then set your new draft to follow those rules to add the new value to > >>>> the registry. > >>>> > >>>> The 2nd way is clearly more work, but it is the "cleaner" way to do > >>>>it. > >>>> Robert has concerns that if we don't do that, and go with (1), then > >>>> we will have some difficulty getting it through IESG. > >>>> > >>>> So we would prefer to do (2). Adam already put together a draft of a > >>>> draft to do the revision to 3261. We can have that ready to submit > >>>> when submissions are opened up again the first day in Atlanta. It is > >>>> quite a straightforward thing to do so we expect we can have it > >>>> approved and ready for the IESG soon enough that it won't slow your > >>>> work up. Once that draft is filed you will be able to reference it in > >>>> your draft so they can be wrapped up in parallel. > >>>> > >>>> Is ecrit ok with that direction? > >>>> > >>>> Thanks, > >>>> Paul (as sipcore co-chair) > >>>> > >>>> On 10/18/12 4:49 AM, Hannes Tschofenig wrote: > >>>>> Hi all, > >>>>> > >>>>> Christer and I had put the new text into the (not-yet-submitted) > >>>>> draft. Here is the current snapshot: > >>>>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/psap- > >>>>> callback/draft-ietf-ecrit-psap-callback-06.txt > >>>>> > >>>>> > >>>>> > >>>>> Feedback we can be incorporated before the submission deadline. > >>>>> > >>>>> Ciao > >>>>> Hannes > >>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>> > >>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --------------050204030800020304080504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
[speaking as SIPCORE chair]

Hannes:

I understand the concern -- but the counter is that fixing what appears to be a bug in the core SIP spec* seems a bit out of charter for ECRIT. I'm not entirely certain you'd have review from the SIP community at large for creation of the registry, and I think that such visibility is necessary.

The SIPCORE document would be a very short one. The only issue that is likely (in my personal opinion) to generate significant discussion is IANA registration policy. Given that SIPCORE doesn't have a ton on its plate right now, I'm pretty comfortable that we can get such a document pubreq'd fast enough that it won't get in the way of ECRIT's document being published.

/a


* To wit: I consider it a bug that we have defined a clear extension point in the protocol without also defining a registry for values.



On 10/19/12 7:57 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
Experience tells me to put the stuff in one document. Just think about Phone BCP...

Sent from my Windows Phone

From: ext Marc Linsner
Sent: 10/19/2012 3:42 PM
To: Paul Kyzivat; Christer Holmberg
Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; ecrit@ietf.org
Subject: Re: [Ecrit] PSAP Callback Draft

Paul,

So do we have a commitment to progress both drafts expeditiously??  (Or at
least in lockstep so PSAP-Callback doesn't sit in the RFC Editor blackhole
due to dependencies)

Thanks,

-Marc-





-----Original Message-----
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Date: Thursday, October 18, 2012 9:26 PM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "sipcore-chairs@tools.ietf.org" <sipcore-chairs@tools.ietf.org>,
"rai-ads@tools.ietf.org" <rai-ads@tools.ietf.org>, "ecrit@ietf.org"
<ecrit@ietf.org>
Subject: Re: [Ecrit] PSAP Callback Draft

>On 10/18/12 4:22 PM, Christer Holmberg wrote:
>>
>> Hi,
>>
>> So, just to clarify: Adam is working on a draft which will create the
>>IANA registry for Priority header field values, and the psap-callback
>>draft will then define and register a new header field value into that
>>registry?
>
>Yes!
>
> Thanks,
> Paul
>
>> Regards,
>>
>> Christer
>>
>> -----Original Message-----
>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf
>>Of Paul Kyzivat
>> Sent: 18. lokakuuta 2012 21:32
>> To: Hannes Tschofenig
>> Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org;
>>ecrit@ietf.org
>> Subject: Re: [Ecrit] PSAP Callback Draft
>>
>> On 10/18/12 1:31 PM, Hannes Tschofenig wrote:
>>> I am curious why you need a separate draft just to create an
>>> additional registry. We still have "space left" in the current PSAP
>>>callback draft...
>>
>> Oh, I thought it was "full". :-)
>>
>> We did discuss putting all the stuff to establish the IANA registry and
>>grandfather the existing values into your draft. We just think that
>>seems like a poor organization. (Sort of a layering violation.) We also
>>aren't out of RFC numbers yet. :-)
>>
>> Thanks,
>> Paul
>>
>>> On 10/18/2012 08:05 PM, Paul Kyzivat wrote:
>>>> Hannes, Christer, ecrit wg,
>>>>
>>>> Robert, Adam and I have been discussing how best to handle the
>>>> updating of the Priority header to include a new value. Ideally there
>>>> would already be an IANA registry with defined procedures for adding
>>>> new values. But there isn't.
>>>>
>>>> So we have two alternatives:
>>>>
>>>> 1) Simply mark this draft as an update to 3261. Provide ABNF that
>>>> extends the syntax of the Priority header. (As your planned draft
>>>> does.)
>>>>
>>>> 2) Make an update to 3261 that establishes a new IANA registry for
>>>> Priority header field values, and populate it with all the values
>>>> included in 3261. Set the rules for adding new values to that
>>>>registry.
>>>> Then set your new draft to follow those rules to add the new value to
>>>> the registry.
>>>>
>>>> The 2nd way is clearly more work, but it is the "cleaner" way to do
>>>>it.
>>>> Robert has concerns that if we don't do that, and go with (1), then
>>>> we will have some difficulty getting it through IESG.
>>>>
>>>> So we would prefer to do (2). Adam already put together a draft of a
>>>> draft to do the revision to 3261. We can have that ready to submit
>>>> when submissions are opened up again the first day in Atlanta. It is
>>>> quite a straightforward thing to do so we expect we can have it
>>>> approved and ready for the IESG soon enough that it won't slow your
>>>> work up. Once that draft is filed you will be able to reference it in
>>>> your draft so they can be wrapped up in parallel.
>>>>
>>>> Is ecrit ok with that direction?
>>>>
>>>>       Thanks,
>>>>       Paul (as sipcore co-chair)
>>>>
>>>> On 10/18/12 4:49 AM, Hannes Tschofenig wrote:
>>>>> Hi all,
>>>>>
>>>>> Christer and I had put the new text into the (not-yet-submitted)
>>>>> draft. Here is the current snapshot:
>>>>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/psap-
>>>>> callback/draft-ietf-ecrit-psap-callback-06.txt
>>>>>
>>>>>
>>>>>
>>>>> Feedback we can be incorporated before the submission deadline.
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>>
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> Ecrit@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> Ecrit@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


--------------050204030800020304080504-- From adam@nostrum.com Fri Oct 19 12:27:57 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B8521F8748 for ; Fri, 19 Oct 2012 12:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lcj-amMeXglu for ; Fri, 19 Oct 2012 12:27:56 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 644B121F875A for ; Fri, 19 Oct 2012 12:27:56 -0700 (PDT) Received: from Svantevit.local ([64.134.176.157]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9JJRXFw018785 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 14:27:33 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5081A9A1.6000001@nostrum.com> Date: Fri, 19 Oct 2012 14:27:29 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <9AD32CC3-069E-4FBD-A021-2EF5FC5E7D4E@gmx.net> <508036C6.7070200@alum.mit.edu> <50803CEF.6010703@gmx.net> <50804B3C.9070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0193CB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0193CB@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 64.134.176.157 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 23 Oct 2012 08:11:54 -0700 Cc: "sipcore-chairs@tools.ietf.org" , "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 19:27:57 -0000 On 10/18/12 3:22 PM, Christer Holmberg wrote: > Hi, > > So, just to clarify: Adam is working on a draft which will create the IANA registry for Priority header field values, and the psap-callback draft will then define and register a new header field value into that registry? That's the plan. I have one ready, and will be submitting it Monday of the IETF meeting, in order to start the ball rolling in SIPCORE as soon as possible. /a From brian.rosen@neustar.biz Tue Oct 23 08:35:37 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795401F0C59 for ; Tue, 23 Oct 2012 08:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghny1NGk8izd for ; Tue, 23 Oct 2012 08:35:36 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 84C7B1F0C51 for ; Tue, 23 Oct 2012 08:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1351006482; x=1666357463; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=T/4hSrYJf6mdgJuPjY4UAgVjTQkJ9VvKonbi5918GpI=; b=grIJoYAuJ3/lBnfacw/XpKWLjZFimT+oW3Ygo6R7lCY2FWfL9urimQFxXfGlKV McBrKC+jLtESeu1DhE6pTWQw== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.10947556; Tue, 23 Oct 2012 11:34:41 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Tue, 23 Oct 2012 11:35:28 -0400 From: "Rosen, Brian" To: "ecrit@ietf.org Org" Date: Tue, 23 Oct 2012 11:35:27 -0400 Thread-Topic: I-D Action: draft-ietf-ecrit-additional-data-05.txt Thread-Index: Ac2xNAcafKUlgbMcTNiY41pR25xl+A== Message-ID: References: <20121022111423.30549.14799.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: cJYc0tnO8Logc+BlZT+xTw== Content-Type: multipart/alternative; boundary="_000_CE6BCD6BD7D34F20B038D7051C90FC12neustarbiz_" MIME-Version: 1.0 Subject: [Ecrit] Fwd: I-D Action: draft-ietf-ecrit-additional-data-05.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:35:37 -0000 --_000_CE6BCD6BD7D34F20B038D7051C90FC12neustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have revved additional-data I have implemented the suggestions provided by NENA via Matt Serra, the edi= torial suggestions from Randy, changed the way multiple blocks are pointed = to per the last meeting discussion, added a comment block and changed refe= rences from vCard to xCard. I believe this draft is ready for WGLC. Brian Begin forwarded message: From: internet-drafts@ietf.org Subject: I-D Action: draft-ietf-ecrit-additional-data-05.txt Date: October 22, 2012 7:14:23 AM EDT To: i-d-announce@ietf.org Cc: ecrit@ietf.org Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Internet= Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Filename : draft-ietf-ecrit-additional-data-05.txt Pages : 55 Date : 2012-10-22 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any service provider in the path of the call, or access network through which the call originated may have information about the call which the PSAP may be able to use. This document describes an XML data structure to contains such data and a Uniform Resource Identifier (URI) for conveying the data to the PSAP. The URI may point to either an external resource, or the body of the SIP message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org 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 --_000_CE6BCD6BD7D34F20B038D7051C90FC12neustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have revved additional-= data

I have implemented the suggestions provided by NENA= via Matt Serra, the editorial suggestions from Randy, changed the way mult= iple blocks are pointed to per the last meeting discussion, added a comment= block and  changed references from vCard to xCard.

I believe this draft is ready for WGLC.

Bri= an


Begin forwarded message:

Reply-To: internet-drafts@ietf.org


A New Internet-Draft is available from the on-line Internet-D= rafts directories.
This draft is a work item of the Emergency Context R= esolution with Internet Technologies Working Group of the IETF.

Title  &n= bsp;        : Additional Data relat= ed to an Emergency Call
Author(s)       : Brian Rose= n
           &nb= sp;            =  Hannes Tschofenig
        = ;            &n= bsp;    Roger Marshall
Filename      =   : draft-ietf-ecrit-additional-data-05.txt
Pages    &nbs= p;      : 55
Date      &nbs= p;     : 2012-10-22

Abstract:
 &nb= sp;When an emergency call is sent to a Public Safety Answering Point
&n= bsp; (PSAP), the device that sends it, as well as any service provider= in
  the path of the call, or access network through which t= he call
  originated may have information about the call whic= h the PSAP may be
  able to use.  This document describe= s an XML data structure to
  contains such data and a Uniform= Resource Identifier (URI) for
  conveying the data to the PS= AP.  The URI may point to either an
  external resource,= or the body of the SIP message.


The IETF datatracker status pag= e for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecri= t-additional-data

There's also a htmlized version available at:<= br>http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-05

A = diff from the previous version is available at:
http://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-ecrit-additional-data-05


Internet-Drafts a= re also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-draft= s/

_______________________________________________
I-D-Announce m= ailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listin= fo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.h= tml
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<= /div>
= --_000_CE6BCD6BD7D34F20B038D7051C90FC12neustarbiz_-- From RMarshall@telecomsys.com Tue Oct 23 14:45:15 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D321F0C42 for ; Tue, 23 Oct 2012 14:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkLNbw9t4ns4 for ; Tue, 23 Oct 2012 14:45:15 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id DEB881F0424 for ; Tue, 23 Oct 2012 14:45:14 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-02.telecomsys.com (8.14.1/8.14.1) with ESMTP id q9NLj5os010547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 23 Oct 2012 14:45:05 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.171]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Tue, 23 Oct 2012 14:45:05 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: ECRIT Milestone update Thread-Index: Ac2xZ6kEH3hOnyozTA2fQ/A2fO4Tgg== Date: Tue, 23 Oct 2012 21:45:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC15E70CSEAEXMB1telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] ECRIT Milestone update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 21:45:16 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC15E70CSEAEXMB1telecomsy_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpQZXIgdGhlIElFVEY4NCBWYW5jb3V2ZXLigJlzIG1lZXRpbmcgbWludXRlcywgTWFyYyAmIEkg aGF2ZSBwcm9wb3NlZCB1cGRhdGVkIG1pbGVzdG9uZSBkYXRlcyBhcyBiZWxvdy4NCg0KUGxlYXNl IG1ha2UgYSBub3RlIG9mIGVhY2ggcmV2aXNlZCBtaWxlc3RvbmUgZGF0ZSwgYW5kIGxldCB1cyBr bm93IG9mIGFueSBlcnJvcnMgb3IgcmVhc29ucyBvdGhlcndpc2UgdGhhdCB3b3VsZCB3YXJyYW50 IGEgY2hhbmdlIGZyb20gdGhlc2UgcHJvcG9zZWQgZGF0ZXMuDQoNCg0KTUlMRVNUT05FIHVwZGF0 ZXM6DQoNCg0KT2N0IDIwMTAgLSBTdWJtaXQgJ1N5bmNocm9uaXppbmcgTG9jYXRpb24tdG8tU2Vy dmljZSBUcmFuc2xhdGlvbiAoTG9TVCkgUHJvdG9jb2wgYmFzZWQgU2VydmljZSBCb3VuZGFyaWVz IGFuZCBNYXBwaW5nIEVsZW1lbnRzJyB0byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBh biBFeHBlcmltZW50YWwgUkZDDQoNCg0KDQpDaGFuZ2UgdG86DQoNCkRvbmUgLSBTdWJtaXQgJ1N5 bmNocm9uaXppbmcgTG9jYXRpb24tdG8tU2VydmljZSBUcmFuc2xhdGlvbiAoTG9TVCkgUHJvdG9j b2wgYmFzZWQgU2VydmljZSBCb3VuZGFyaWVzIGFuZCBNYXBwaW5nIEVsZW1lbnRzJyB0byB0aGUg SUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBhbiBFeHBlcmltZW50YWwgUkZDDQoNCg0KDQoNCg0K Tm92IDIwMTAgLSBTdWJtaXQgJ1VzaW5nIEltcHJlY2lzZSBMb2NhdGlvbiBmb3IgRW1lcmdlbmN5 IENhbGwgUm91dGluZycgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMgYW4gSW5mb3Jt YXRpb25hbCBSRkMNCg0KDQoNCkNoYW5nZSB0bzoNCg0KTWFyIDIwMTMgLSBTdWJtaXQgJ1VzaW5n IEltcHJlY2lzZSBMb2NhdGlvbiBmb3IgRW1lcmdlbmN5IENhbGwgUm91dGluZycgdG8gdGhlIElF U0cgZm9yIGNvbnNpZGVyYXRpb24gYXMgYW4gSW5mb3JtYXRpb25hbCBSRkMNCg0KDQoNCg0KDQpN YXIgMjAxMSAtIFN1Ym1pdCAnQWRkaXRpb25hbCBEYXRhIHJlbGF0ZWQgdG8gYSBDYWxsIGZvciBF bWVyZ2VuY3kgQ2FsbCBQdXJwb3NlcycgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMg YSBTdGFuZGFyZHMgVHJhY2sgUkZDDQoNCg0KDQpDaGFuZ2UgdG86DQoNCk1hciAyMDEzIC0gU3Vi bWl0ICdBZGRpdGlvbmFsIERhdGEgcmVsYXRlZCB0byBhIENhbGwgZm9yIEVtZXJnZW5jeSBDYWxs IFB1cnBvc2VzJyB0byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBhIFN0YW5kYXJkcyBU cmFjayBSRkMNCg0KDQoNCg0KDQpBcHIgMjAxMSAtIFN1Ym1pdCAnQ29tbW9uIEFsZXJ0aW5nIFBy b3RvY29sIChDQVApIGJhc2VkIERhdGEtT25seSBFbWVyZ2VuY3kgQWxlcnRzIHVzaW5nIHRoZSBT ZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCknIHRvIHRoZSBJRVNHIGZvciBjb25zaWRl cmF0aW9uIGFzIGFuIEV4cGVyaW1lbnRhbCBSRkMNCg0KDQoNCkNoYW5nZSB0bzoNCg0KQXByIDIw MTMgLSBTdWJtaXQgJ0NvbW1vbiBBbGVydGluZyBQcm90b2NvbCAoQ0FQKSBiYXNlZCBEYXRhLU9u bHkgRW1lcmdlbmN5IEFsZXJ0cyB1c2luZyB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29s IChTSVApJyB0byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBhbiBFeHBlcmltZW50YWwg UkZDDQoNCg0KDQoNCg0KRGVjIDIwMTEgLSBTdWJtaXQgJ0V4dGVuc2lvbnMgdG8gdGhlIEVtZXJn ZW5jeSBTZXJ2aWNlcyBBcmNoaXRlY3R1cmUgZm9yIGRlYWxpbmcgd2l0aCBVbmF1dGhlbnRpY2F0 ZWQgYW5kIFVuYXV0aG9yaXplZCBEZXZpY2VzJyB0byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlv biBhcyBhIFN0YW5kYXJkcyBUcmFjayBSRkMNCg0KDQoNCkNoYW5nZSB0bzoNCg0KRGVjIDIwMTMg LSBTdWJtaXQgJ0V4dGVuc2lvbnMgdG8gdGhlIEVtZXJnZW5jeSBTZXJ2aWNlcyBBcmNoaXRlY3R1 cmUgZm9yIGRlYWxpbmcgd2l0aCBVbmF1dGhlbnRpY2F0ZWQgYW5kIFVuYXV0aG9yaXplZCBEZXZp Y2VzJyB0byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBhIFN0YW5kYXJkcyBUcmFjayBS RkMNCg0KDQoNCg0KDQpKYW4gMjAxMiAtIFN1Ym1pdCAnVHJ1c3R3b3J0aHkgTG9jYXRpb24gSW5m b3JtYXRpb24nIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIGFuIEluZm9ybWF0aW9u YWwgUkZDDQoNCg0KDQpDaGFuZ2UgdG86DQoNCkp1biAyMDEzIC0gU3VibWl0ICdUcnVzdHdvcnRo eSBMb2NhdGlvbiBJbmZvcm1hdGlvbicgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMg YW4gSW5mb3JtYXRpb25hbCBSRkMNCg0KDQoNCg0KDQpNYXIgMjAxMiAtIFN1Ym1pdCAnUHVibGlj IFNhZmV0eSBBbnN3ZXJpbmcgUG9pbnQgKFBTQVApIENhbGxiYWNrcycgdG8gdGhlIElFU0cgZm9y IGNvbnNpZGVyYXRpb24gYXMgYW4gSW5mb3JtYXRpb25hbCBSRkMNCg0KDQoNCkNoYW5nZSB0bzoN Cg0KTWFyIDIwMTMgLSBTdWJtaXQgJ1B1YmxpYyBTYWZldHkgQW5zd2VyaW5nIFBvaW50IChQU0FQ KSBDYWxsYmFja3MnIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIGFuIEluZm9ybWF0 aW9uYWwgUkZDDQoNCg0KDQoNCg0KQXByIDIwMTMgLSBTdWJtaXQgYSBkcmFmdCAnUG9saWN5IGZv ciBkZWZpbmluZyBuZXcgc2VydmljZcODwqLDguKCrMOC4oCcaWRlbnRpZnlpbmcgbGFiZWxzJyB0 byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBCQ1ANCg0KDQoNCihubyBjaGFuZ2UpDQoN Cg0KUm9nZXIgTWFyc2hhbGwgJiBNYXJjIExpbnNuZXINCkVDUklUIENoYWlycw0KDQoNCg0KQ09O RklERU5USUFMSVRZIE5PVElDRTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1l c3NhZ2UgbWF5IGJlIHByaXZpbGVnZWQgYW5kL29yIGNvbmZpZGVudGlhbC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgb3IgcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcg dGhpcyBtZXNzYWdlIHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSByZXZpZXcsIGZvcndh cmRpbmcsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29t bXVuaWNhdGlvbiBvciBhbnkgYXR0YWNobWVudChzKSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSwgYW5kIGRlbGV0ZSBpdCBhbmQgYWxsIGF0dGFjaG1lbnRz IGZyb20geW91ciBjb21wdXRlciBhbmQgbmV0d29yay4NCg== --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC15E70CSEAEXMB1telecomsy_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBlciB0aGUgSUVURjg0IFZhbmNvdXZlcuKAmXMg bWVldGluZyBtaW51dGVzLCBNYXJjICZhbXA7IEkgaGF2ZSBwcm9wb3NlZCB1cGRhdGVkIG1pbGVz dG9uZSBkYXRlcyBhcyBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIG1ha2Ug YSBub3RlIG9mIGVhY2ggcmV2aXNlZCBtaWxlc3RvbmUgZGF0ZSwgYW5kIGxldCB1cyBrbm93IG9m IGFueSBlcnJvcnMgb3IgcmVhc29ucyBvdGhlcndpc2UgdGhhdCB3b3VsZCB3YXJyYW50IGEgY2hh bmdlIGZyb20gdGhlc2UgcHJvcG9zZWQgZGF0ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5NSUxFU1RPTkUgdXBkYXRlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5PY3QgMjAxMCAt IFN1Ym1pdCAnU3luY2hyb25pemluZyBMb2NhdGlvbi10by1TZXJ2aWNlIFRyYW5zbGF0aW9uIChM b1NUKSBQcm90b2NvbCBiYXNlZCBTZXJ2aWNlIEJvdW5kYXJpZXMgYW5kIE1hcHBpbmcgRWxlbWVu dHMnIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIGFuIEV4cGVyaW1lbnRhbCBSRkM8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5DaGFuZ2UgdG86PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+RG9uZSAtIFN1Ym1pdCAnU3luY2hyb25pemluZyBMb2NhdGlvbi10by1T ZXJ2aWNlIFRyYW5zbGF0aW9uIChMb1NUKSBQcm90b2NvbCBiYXNlZCBTZXJ2aWNlIEJvdW5kYXJp ZXMgYW5kIE1hcHBpbmcgRWxlbWVudHMnIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFz IGFuIEV4cGVyaW1lbnRhbCBSRkM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Ob3YgMjAxMCAtIFN1Ym1pdCAnVXNpbmcg SW1wcmVjaXNlIExvY2F0aW9uIGZvciBFbWVyZ2VuY3kgQ2FsbCBSb3V0aW5nJyB0byB0aGUgSUVT RyBmb3IgY29uc2lkZXJhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQzxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkNoYW5nZSB0 bzo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5NYXIgMjAxMyAtIFN1Ym1pdCAnVXNpbmcgSW1wcmVjaXNlIExvY2F0aW9uIGZvciBFbWVyZ2Vu Y3kgQ2FsbCBSb3V0aW5nJyB0byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBhbiBJbmZv cm1hdGlvbmFsIFJGQzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1hciAyMDExIC0gU3VibWl0ICdBZGRpdGlvbmFsIERh dGEgcmVsYXRlZCB0byBhIENhbGwgZm9yIEVtZXJnZW5jeSBDYWxsIFB1cnBvc2VzJyB0byB0aGUg SUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBhIFN0YW5kYXJkcyBUcmFjayBSRkM8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5DaGFu Z2UgdG86PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+TWFyIDIwMTMgLSBTdWJtaXQgJ0FkZGl0aW9uYWwgRGF0YSByZWxhdGVkIHRvIGEgQ2Fs bCBmb3IgRW1lcmdlbmN5IENhbGwgUHVycG9zZXMnIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0 aW9uIGFzIGEgU3RhbmRhcmRzIFRyYWNrIFJGQzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFwciAyMDExIC0gU3VibWl0 ICdDb21tb24gQWxlcnRpbmcgUHJvdG9jb2wgKENBUCkgYmFzZWQgRGF0YS1Pbmx5IEVtZXJnZW5j eSBBbGVydHMgdXNpbmcgdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKScgdG8g dGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMgYW4gRXhwZXJpbWVudGFsIFJGQzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkNo YW5nZSB0bzo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5BcHIgMjAxMyAtIFN1Ym1pdCAnQ29tbW9uIEFsZXJ0aW5nIFByb3RvY29sIChDQVAp IGJhc2VkIERhdGEtT25seSBFbWVyZ2VuY3kgQWxlcnRzIHVzaW5nIHRoZSBTZXNzaW9uIEluaXRp YXRpb24gUHJvdG9jb2wgKFNJUCknIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIGFu IEV4cGVyaW1lbnRhbCBSRkM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5EZWMgMjAxMSAtIFN1Ym1pdCAnRXh0ZW5zaW9u cyB0byB0aGUgRW1lcmdlbmN5IFNlcnZpY2VzIEFyY2hpdGVjdHVyZSBmb3IgZGVhbGluZyB3aXRo IFVuYXV0aGVudGljYXRlZCBhbmQgVW5hdXRob3JpemVkIERldmljZXMnIHRvIHRoZSBJRVNHIGZv ciBjb25zaWRlcmF0aW9uIGFzIGEgU3RhbmRhcmRzIFRyYWNrIFJGQzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkNoYW5nZSB0bzo8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5E ZWMgMjAxMyAtIFN1Ym1pdCAnRXh0ZW5zaW9ucyB0byB0aGUgRW1lcmdlbmN5IFNlcnZpY2VzIEFy Y2hpdGVjdHVyZSBmb3IgZGVhbGluZyB3aXRoIFVuYXV0aGVudGljYXRlZCBhbmQgVW5hdXRob3Jp emVkIERldmljZXMnIHRvIHRoZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIGEgU3RhbmRhcmRz IFRyYWNrIFJGQzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkphbiAyMDEyIC0gU3VibWl0ICdUcnVzdHdvcnRoeSBMb2Nh dGlvbiBJbmZvcm1hdGlvbicgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMgYW4gSW5m b3JtYXRpb25hbCBSRkM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5DaGFuZ2UgdG86PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SnVuIDIwMTMgLSBTdWJtaXQgJ1RydXN0d29y dGh5IExvY2F0aW9uIEluZm9ybWF0aW9uJyB0byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBh cyBhbiBJbmZvcm1hdGlvbmFsIFJGQzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1hciAyMDEyIC0gU3VibWl0ICdQdWJs aWMgU2FmZXR5IEFuc3dlcmluZyBQb2ludCAoUFNBUCkgQ2FsbGJhY2tzJyB0byB0aGUgSUVTRyBm b3IgY29uc2lkZXJhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkNoYW5nZSB0bzo8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5N YXIgMjAxMyAtIFN1Ym1pdCAnUHVibGljIFNhZmV0eSBBbnN3ZXJpbmcgUG9pbnQgKFBTQVApIENh bGxiYWNrcycgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMgYW4gSW5mb3JtYXRpb25h bCBSRkM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5BcHIgMjAxMyAtIFN1Ym1pdCBhIGRyYWZ0ICdQb2xpY3kgZm9yIGRl ZmluaW5nIG5ldyBzZXJ2aWNlw4PCosOC4oKsw4LigJxpZGVudGlmeWluZyBsYWJlbHMnIHRvIHRo ZSBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIEJDUDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPihubyBjaGFuZ2UpPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Um9nZXIgTWFyc2hhbGwgJmFtcDsgTWFyYyBMaW5zbmVyPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FQ1JJVCBDaGFpcnM8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTonQXJpYWwnO2ZvbnQtc2l6ZTo4cHQ7Ij5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgcHJpdmlsZWdl ZCBhbmQvb3IgY29uZmlkZW50aWFsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCBvciByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0aGlzIG1lc3NhZ2UgdG8gdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgYW55IHJldmlldywgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwg ZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIG9yIGFueSBhdHRh Y2htZW50KHMpIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 LCBhbmQgZGVsZXRlIGl0IGFuZCBhbGwgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyIGFu ZCBuZXR3b3JrLjwvc3Bhbj48L3A+PC9ib2R5Pg0KPC9odG1sPg0K --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC15E70CSEAEXMB1telecomsy_-- From RMarshall@telecomsys.com Tue Oct 23 14:49:41 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CCA11E8099 for ; Tue, 23 Oct 2012 14:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6kgjTnFh31h for ; Tue, 23 Oct 2012 14:49:41 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id E272B11E80D9 for ; Tue, 23 Oct 2012 14:49:37 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.1/8.14.1) with ESMTP id q9NLnUkW002601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 23 Oct 2012 14:49:30 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.171]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.01.0355.002; Tue, 23 Oct 2012 14:49:30 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: IETF85 - ECRIT agenda posted. Comments? Thread-Index: Ac2xaEbekoq62vQlTfuGlPvH6UphbA== Date: Tue, 23 Oct 2012 21:49:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC15E77FSEAEXMB1telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] IETF85 - ECRIT agenda posted. Comments? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 21:49:41 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC15E77FSEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The ECRIT proposed agenda has been uploaded and can be viewed at: http://www.ietf.org/proceedings/85/agenda/agenda-85-ecrit.txt Please send your comments for change before the start of IETF85. Regards, Roger Marshall & Marc Linsner, ECRIT Chairs CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC15E77FSEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The ECRIT proposed agenda has been uploaded and c= an be viewed at:

http://www.ietf.org/proceedings/85/agenda/agenda-8= 5-ecrit.txt

 

Please send your comments for change before the s= tart of IETF85.

 

 

Regards,

 

Roger Marshall & Marc Linsner, ECRIT Chairs

 

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC15E77FSEAEXMB1telecomsy_-- From James.Winterbottom@commscope.com Tue Oct 23 15:07:48 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5D21F0424 for ; Tue, 23 Oct 2012 15:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3YqAcvzikhn for ; Tue, 23 Oct 2012 15:07:48 -0700 (PDT) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 045871F0C92 for ; Tue, 23 Oct 2012 15:07:47 -0700 (PDT) X-AuditID: 0a0404e9-b7ce8ae0000009e2-0f-508714d4046b Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id E9.21.02530.4D417805; Tue, 23 Oct 2012 17:06:12 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.279.5; Tue, 23 Oct 2012 17:07:46 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 24 Oct 2012 06:07:44 +0800 From: "Winterbottom, James" To: Roger Marshall , "ecrit@ietf.org" Date: Wed, 24 Oct 2012 06:07:43 +0800 Thread-Topic: IETF85 - ECRIT agenda posted. Comments? Thread-Index: Ac2xaEbekoq62vQlTfuGlPvH6UphbAAAkI+w Message-ID: <5A55A45AE77F5941B18E5457ECAC818801213307C0DC@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC818801213307C0DCSISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAhlX8kscKIYB Subject: Re: [Ecrit] IETF85 - ECRIT agenda posted. Comments? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 22:07:48 -0000 --_000_5A55A45AE77F5941B18E5457ECAC818801213307C0DCSISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roger, I had requested time for draft-winterbottom-ecrit-priv-loc-03 which is not = covered in the agenda. Cheers James From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= oger Marshall Sent: Wednesday, 24 October 2012 8:49 AM To: ecrit@ietf.org Subject: [Ecrit] IETF85 - ECRIT agenda posted. Comments? The ECRIT proposed agenda has been uploaded and can be viewed at: http://www.ietf.org/proceedings/85/agenda/agenda-85-ecrit.txt Please send your comments for change before the start of IETF85. Regards, Roger Marshall & Marc Linsner, ECRIT Chairs CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_5A55A45AE77F5941B18E5457ECAC818801213307C0DCSISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roger,

 

I had requested time for draft-winterbottom-ecrit-= priv-loc-03 which is not covered in the agenda.

 

Cheers

James

 

 

From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Se= nt: Wednesday, 24 October 2012 8:49 AM
To: ecrit@ietf.org
= Subject: [Ecrit] IETF85 - ECRIT agenda posted. Comments?<= /span>

 

The ECRIT proposed agenda has been uploaded and can be viewed = at:

http://www.ietf.org/proceedings/8= 5/agenda/agenda-85-ecrit.txt

 

Please send your comments for chan= ge before the start of IETF85.

&= nbsp;

 

Regards,

 

Roger Marshall & Marc Linsner, ECRIT Chairs

 

CONFIDENTIALITY NOTICE: The= information contained in this message may be privileged and/or confidentia= l. If you are not the intended recipient, or responsible for delivering thi= s message to the intended recipient, any review, forwarding, dissemination,= distribution or copying of this communication or any attachment(s) is stri= ctly prohibited. If you have received this message in error, please notify = the sender immediately, and delete it and all attachments from your compute= r and network.

= --_000_5A55A45AE77F5941B18E5457ECAC818801213307C0DCSISPE7MB1co_-- From RMarshall@telecomsys.com Tue Oct 23 15:16:00 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E7811E80A3 for ; Tue, 23 Oct 2012 15:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWTULr2Ic5or for ; Tue, 23 Oct 2012 15:15:59 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id 61F141F0C96 for ; Tue, 23 Oct 2012 15:15:59 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-01.telecomsys.com (8.14.1/8.14.1) with ESMTP id q9NMFqHu003292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 23 Oct 2012 15:15:53 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.171]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.01.0355.002; Tue, 23 Oct 2012 15:15:52 -0700 From: Roger Marshall To: "Winterbottom, James" , "ecrit@ietf.org" Thread-Topic: IETF85 - ECRIT agenda posted. Comments? Thread-Index: Ac2xaEbekoq62vQlTfuGlPvH6UphbAAAkI+wAABSEKA= Date: Tue, 23 Oct 2012 22:15:51 +0000 Message-ID: References: <5A55A45AE77F5941B18E5457ECAC818801213307C0DC@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC818801213307C0DC@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC15E862SEAEXMB1telecomsy_" MIME-Version: 1.0 Subject: Re: [Ecrit] IETF85 - ECRIT agenda posted. Comments? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 22:16:00 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC15E862SEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James: Yes, you did. I apologize for missing it. I've just reposted the agenda with a slot added for draft-winterbottom-ecri= t-priv-loc-03. -roger. From: Winterbottom, James [mailto:James.Winterbottom@commscope.com] Sent: Tuesday, October 23, 2012 3:08 PM To: Roger Marshall; ecrit@ietf.org Subject: RE: IETF85 - ECRIT agenda posted. Comments? Hi Roger, I had requested time for draft-winterbottom-ecrit-priv-loc-03 which is not = covered in the agenda. Cheers James From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Roger Marshall Sent: Wednesday, 24 October 2012 8:49 AM To: ecrit@ietf.org Subject: [Ecrit] IETF85 - ECRIT agenda posted. Comments? The ECRIT proposed agenda has been uploaded and can be viewed at: http://www.ietf.org/proceedings/85/agenda/agenda-85-ecrit.txt Please send your comments for change before the start of IETF85. Regards, Roger Marshall & Marc Linsner, ECRIT Chairs CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC15E862SEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

James:

Yes, you did.  I = apologize for missing it. 

 

I’ve just repost= ed the agenda with a slot added for draft-winterbottom-ecrit-priv-loc-03.<= o:p>

 

-roger.

 

From: Winterbo= ttom, James [mailto:James.Winterbottom@commscope.com]
Sent: Tuesday, October 23, 2012 3:08 PM
To: Roger Marshall; ecrit@ietf.org
Subject: RE: IETF85 - ECRIT agenda posted. Comments?

 

Hi Roger,

 

I had requested time f= or draft-winterbottom-ecrit-priv-loc-03 which is not covered in the agenda.=

 

Cheers

James

 

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: Wednesday, 24 October 2012 8:49 AM
To: ecrit@ietf.org
Subject: [Ecrit] IETF85 - ECRIT agenda posted. Comments?<= /span>

 

The ECRIT proposed agenda has been uploaded and c= an be viewed at:

http://www.ietf.org/proceedings/85/agenda/agenda-8= 5-ecrit.txt

 

Please send your comments for change before the s= tart of IETF85.

 

 

Regards,

 

Roger Marshall & Marc Linsner, ECRIT Chairs

 

CONFIDENTIALITY NOTICE: The information contained in this mess= age may be privileged and/or confidential. If you are not the intended reci= pient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or= copying of this communication or any attachment(s) is strictly prohibited.= If you have received this message in error, please notify the sender immed= iately, and delete it and all attachments from your computer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC15E862SEAEXMB1telecomsy_-- From James.Winterbottom@commscope.com Tue Oct 23 15:17:47 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D481F0C95 for ; Tue, 23 Oct 2012 15:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNXtfOFBc5oQ for ; Tue, 23 Oct 2012 15:17:45 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id ABB4B1F0424 for ; Tue, 23 Oct 2012 15:17:45 -0700 (PDT) X-AuditID: 0a0404e8-b7c1dae0000009ce-70-508717bc1e43 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id CE.64.02510.CB717805; Tue, 23 Oct 2012 17:18:36 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.279.5; Tue, 23 Oct 2012 17:17:44 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 24 Oct 2012 06:17:41 +0800 From: "Winterbottom, James" To: Roger Marshall , "ecrit@ietf.org" Date: Wed, 24 Oct 2012 06:17:40 +0800 Thread-Topic: IETF85 - ECRIT agenda posted. Comments? Thread-Index: Ac2xaEbekoq62vQlTfuGlPvH6UphbAAAkI+wAABSEKAAABijQA== Message-ID: <5A55A45AE77F5941B18E5457ECAC818801213307C0DD@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC818801213307C0DC@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC818801213307C0DDSISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAhlX8kscKIYB Subject: Re: [Ecrit] IETF85 - ECRIT agenda posted. Comments? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 22:17:47 -0000 --_000_5A55A45AE77F5941B18E5457ECAC818801213307C0DDSISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Roger. From: Roger Marshall [mailto:RMarshall@telecomsys.com] Sent: Wednesday, 24 October 2012 9:16 AM To: Winterbottom, James; ecrit@ietf.org Subject: RE: IETF85 - ECRIT agenda posted. Comments? James: Yes, you did. I apologize for missing it. I've just reposted the agenda with a slot added for draft-winterbottom-ecri= t-priv-loc-03. -roger. From: Winterbottom, James [mailto:James.Winterbottom@commscope.com] Sent: Tuesday, October 23, 2012 3:08 PM To: Roger Marshall; ecrit@ietf.org Subject: RE: IETF85 - ECRIT agenda posted. Comments? Hi Roger, I had requested time for draft-winterbottom-ecrit-priv-loc-03 which is not = covered in the agenda. Cheers James From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Roger Marshall Sent: Wednesday, 24 October 2012 8:49 AM To: ecrit@ietf.org Subject: [Ecrit] IETF85 - ECRIT agenda posted. Comments? The ECRIT proposed agenda has been uploaded and can be viewed at: http://www.ietf.org/proceedings/85/agenda/agenda-85-ecrit.txt Please send your comments for change before the start of IETF85. Regards, Roger Marshall & Marc Linsner, ECRIT Chairs CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_5A55A45AE77F5941B18E5457ECAC818801213307C0DDSISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Roger.

 

<= span style=3D'color:#1F497D'> 

From: Roger Marshall [mailto:RMarshall@telecomsys.com]
<= b>Sent: Wednesday, 24 October 2012 9:16 AM
To: Winterbottom, = James; ecrit@ietf.org
Subject: RE: IETF85 - ECRIT agenda posted. = Comments?

 =

James:

Yes, you d= id.  I apologize for missing it. 

 

I’ve just reposted the= agenda with a slot added for draft-winterbottom-ecrit-priv-loc-03.

 = ;

-roger= .

<= o:p> 

From: Winterbot= tom, James [mailto:Jame= s.Winterbottom@commscope.com]
Sent: Tuesday, October 23, 201= 2 3:08 PM
To: Roger Marshall; e= crit@ietf.org
Subject: RE: IETF85 - ECRIT agenda posted. Comm= ents?

 

Hi Roger,

 =

I had r= equested time for draft-winterbottom-ecrit-priv-loc-03 which is not covered= in the agenda.

 

Cheers

James

 

=  

<= p class=3DMsoNormal>From: ecrit-bou= nces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Roger Marshall
Sent: Wed= nesday, 24 October 2012 8:49 AM
To: ecrit@ietf.org
Subject: [Ecrit] IETF85 - ECRIT agenda po= sted. Comments?

=  

The ECRIT proposed agenda has been = uploaded and can be viewed at:

http:/= /www.ietf.org/proceedings/85/agenda/agenda-85-ecrit.txt

<= p class=3DMsoPlainText> 

Please = send your comments for change before the start of IETF85.

 

&nbs= p;

Regards,

 

Roger Marshall & M= arc Linsner, ECRIT Chairs

 

= CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network.

= --_000_5A55A45AE77F5941B18E5457ECAC818801213307C0DDSISPE7MB1co_-- From wwwrun@rfc-editor.org Wed Oct 24 21:20:44 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0395B21F8540; Wed, 24 Oct 2012 21:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtsUT9GmSE1T; Wed, 24 Oct 2012 21:20:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8205121F84BF; Wed, 24 Oct 2012 21:20:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2140F72E038; Wed, 24 Oct 2012 21:14:57 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121025041457.2140F72E038@rfc-editor.org> Date: Wed, 24 Oct 2012 21:14:57 -0700 (PDT) Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] RFC 6739 on Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 04:20:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6739 Title: Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol Author: H. Schulzrinne, H. Tschofenig Status: Experimental Stream: IETF Date: October 2012 Mailbox: hgs+ecrit@cs.columbia.edu, Hannes.Tschofenig@gmx.net Pages: 25 Characters: 52011 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ecrit-lost-sync-18.txt URL: http://www.rfc-editor.org/rfc/rfc6739.txt 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 element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol. This document defines an Experimental Protocol for the Internet community. This document is a product of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Thu Oct 25 14:50:48 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC1F21F8757 for ; Thu, 25 Oct 2012 14:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-IrrTmI3-xg for ; Thu, 25 Oct 2012 14:50:47 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 96CE621F858F for ; Thu, 25 Oct 2012 14:50:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5A14F72E038; Thu, 25 Oct 2012 14:45:00 -0700 (PDT) To: hgs+ecrit@cs.columbia.edu, Hannes.Tschofenig@gmx.net, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, marc.linsner@cisco.com, rmarshall@telecomsys.com From: RFC Errata System Message-Id: <20121025214500.5A14F72E038@rfc-editor.org> Date: Thu, 25 Oct 2012 14:45:00 -0700 (PDT) Cc: drafts-update-ref@iana.org, ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] [Editorial Errata Reported] RFC6739 (3393) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 21:50:48 -0000 The following errata report has been submitted for RFC6739, "Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6739&eid=3393 -------------------------------------- Type: Editorial Reported by: Pearl Liang Section: 10.3 Original Text -------------

See RFC 6739 .

Corrected Text --------------

See RFC 6739 .

Notes ----- RFC Editor should have updated this text before publication. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6739 (draft-ietf-ecrit-lost-sync-18) -------------------------------------- Title : Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol Publication Date : October 2012 Author(s) : H. Schulzrinne, H. Tschofenig Category : EXPERIMENTAL Source : Emergency Context Resolution with Internet Technologies Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From iana-shared@icann.org Thu Oct 25 21:09:20 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F9E21F84F1 for ; Thu, 25 Oct 2012 21:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtyXGm0R1PKI for ; Thu, 25 Oct 2012 21:09:20 -0700 (PDT) Received: from pechora1.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id 8280221F84ED for ; Thu, 25 Oct 2012 21:09:20 -0700 (PDT) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id q9Q48iHq003228; Fri, 26 Oct 2012 04:09:06 GMT Received: from request1.lax.icann.org (localhost.localdomain [127.0.0.1]) by request1.lax.icann.org (8.13.8/8.13.8) with ESMTP id q9Q48iDJ019052; Fri, 26 Oct 2012 04:08:44 GMT Received: (from apache@localhost) by request1.lax.icann.org (8.13.8/8.13.8/Submit) id q9Q48hSf019046; Fri, 26 Oct 2012 04:08:43 GMT RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20121025214500.5A14F72E038@rfc-editor.org> References: <20121025214500.5A14F72E038@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #623333 Managed-by: RT 3.8.8 (http://www.bestpractical.com/rt/) RT-Originator: pearl.liang@icann.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Fri, 26 Oct 2012 04:08:43 +0000 X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Fri, 26 Oct 2012 04:09:08 +0000 (UTC) X-Mailman-Approved-At: Fri, 26 Oct 2012 08:03:59 -0700 Cc: marc.linsner@cisco.com, ecrit@ietf.org, hgs+ecrit@cs.columbia.edu, rfc-editor@rfc-editor.org Subject: [Ecrit] [IANA #623333] [Editorial Errata Reported] RFC6739 (3393) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: iana-matrix@iana.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 04:09:21 -0000 Hi Sandy, Thank you for taking care of this. I believe that there is no action required on my end. Please let me know if there is any actions required from us. Cheers, ~pearl On Thu Oct 25 14:51:12 2012, rfc-editor@rfc-editor.org wrote: > > The following errata report has been submitted for RFC6739, > "Synchronizing Service Boundaries and Elements Based on the > Location-to-Service Translation (LoST) Protocol". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6739&eid=3393 > > -------------------------------------- > Type: Editorial > Reported by: Pearl Liang > > Section: 10.3 > > Original Text > ------------- >

See RFC 6739 > .

> > Corrected Text > -------------- >

See RFC 6739 > .

> > Notes > ----- > RFC Editor should have updated this text before publication. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6739 (draft-ietf-ecrit-lost-sync-18) > -------------------------------------- > Title : Synchronizing Service Boundaries and > Elements Based on the Location-to-Service Translation (LoST) Protocol > Publication Date : October 2012 > Author(s) : H. Schulzrinne, H. Tschofenig > Category : EXPERIMENTAL > Source : Emergency Context Resolution with Internet > Technologies > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG >