From Internet-Drafts@ietf.org Sat Jan 15 11:00:03 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698333A6E0C; Sat, 15 Jan 2011 11:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6H-OGOf4YJk; Sat, 15 Jan 2011 11:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3703A6E0A; Sat, 15 Jan 2011 11:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110115190001.18610.17937.idtracker@localhost> Date: Sat, 15 Jan 2011 11:00:01 -0800 Cc: earlywarning@ietf.org Subject: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 19:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authority-to-Citizen Alert Working Group of the IETF. Title : Requirements, Terminology and Framework for Exigent Communications Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-atoca-requirements-01.txt Pages : 14 Date : 2011-01-15 Before, during and after emergency situations various agencies need to provide information to a group of persons or to the public within a geographical area. While many aspects of such systems are specific to national or local jurisdictions, emergencies span such boundaries and notifications need to reach visitors from other jurisdictions. This document provides terminology, requirements and an architectural description for protocols exchanging alerts between IP-based end points. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atoca-requirements-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-atoca-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-15105907.I-D@ietf.org> --NextPart-- From hannes.tschofenig@gmx.net Sat Jan 15 11:27:40 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE39E3A6E22 for ; Sat, 15 Jan 2011 11:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ef9mtWziZ0LX for ; Sat, 15 Jan 2011 11:27:39 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id AFF0C3A6E21 for ; Sat, 15 Jan 2011 11:27:38 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2011 19:30:05 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.7]) [88.115.222.204] by mail.gmx.net (mp060) with SMTP; 15 Jan 2011 20:30:05 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18WHTtFgLIWaVQtzuKsyuWVZjc82iuYSCqzl7fmIu lgYOZA9+DIiDoa From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Jan 2011 21:30:05 +0200 Message-Id: To: earlywarning@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Subject: [Atoca] Updated Requirements and Terminology Draft X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 19:27:40 -0000 Hi all,=20 we went through the meeting minutes=20 http://www.ietf.org/proceedings/79/minutes/atoca.txt and the recording=20 http://79archive.dyndns.org/ietf79/ietf79-ch5-fri-noon.mp3 in order to address the feedback we had gotten at IETF#79.=20 As a result, we have updated the draft: http://www.ietf.org/internet-drafts/draft-ietf-atoca-requirements-01.txt The changes are:=20 * In Section 1.2 we talk about the two steps "subscription" and "alert = delivery" as a way to classify the protocol interaction. As a = consequence we also changed the subject headings of the requirements = section. These are editorial changes.=20 * We shorted Section 3. This is the description of the alert delivery = architecture.=20 * The requirements in Section 4 have not changed but they were = re-grouped. I added an editorial clarification to Req-D1 regarding = congestion. This was mentioned during the meeting by Keith.=20 * The security consideration section now has a longer introduction.=20 * Acknowledged those people who provided feedback at IETF#79.=20 There are a few open issues. I will post separate mails to discuss = those.=20 Ciao Hannes & Brian= From hannes.tschofenig@gmx.net Sat Jan 15 11:27:45 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BECE28B56A for ; Sat, 15 Jan 2011 11:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZQMxA+g22T1 for ; Sat, 15 Jan 2011 11:27:44 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 0EAAB3A6E25 for ; Sat, 15 Jan 2011 11:27:43 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2011 19:30:12 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.7]) [88.115.222.204] by mail.gmx.net (mp060) with SMTP; 15 Jan 2011 20:30:12 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+G5PQLc9uG7KfwApx6EpOLrf65zoDKtz5Iinhfr4 3B377KZdv3p+w0 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Jan 2011 21:30:11 +0200 Message-Id: To: earlywarning@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Subject: [Atoca] Language and Media Type X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 19:27:45 -0000 Hi all,=20 Keeping Li (if the meeting minutes reflect his name correctly) noticed = that we had a language requirement in the requirements draft but = provided no corresponding solution in the SIP-CAP document.=20 For subscriptions we currently have the following requirements: --------------------- Req-S1: The protocol solution MUST allow a potential Recipient to indicate the language used by alert messages. Req-S2: The protocol solution MUST allow a potential Recipient to express the geographical area it wants to receive alerts about. Req-S3: The protocol solution MUST allow a potential Recipient to indicate preferences about the type of alerts it wants to receive. Req-S4: The protocol solution MUST allow a potential Recipient to express preference for certain media types. The support for different media types depends on the content of the warning message but also impacts the communication protocol. This functionality is, for example, useful for hearing and vision impaired persons. --------------------- No doubts have been raised about the usefulness of requirement S2 and S3 = but with the requirements S1 and S4 it is not quite the same.=20 Do we expect that a system will allow a subscriber to indicate language = preferences and the ability to receive certain media types?=20 Are there other parameters that would be more useful?=20 Ciao Hannes From hannes.tschofenig@gmx.net Sat Jan 15 11:28:00 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3350828C0DB for ; Sat, 15 Jan 2011 11:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpLPOka2mFWm for ; Sat, 15 Jan 2011 11:27:59 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id E20263A6E25 for ; Sat, 15 Jan 2011 11:27:58 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2011 19:30:27 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.7]) [88.115.222.204] by mail.gmx.net (mp060) with SMTP; 15 Jan 2011 20:30:27 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/kA+M1Durkc3n3zeLQa6Exxlwi/NSf8Hg+sc+wUM hf8Pu0BKGE5n1N From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Jan 2011 21:30:24 +0200 Message-Id: To: earlywarning@ietf.org, Igor Faynberg Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Subject: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 19:28:00 -0000 Hi all,=20 during the ATOCA meeting at IETF#79 Igor raised a question regarding = requirement D2: " Req-D2: The protocol solution MUST allow delivery of messages simultaneously to a large audience. " He was asking whether there is a need to put a number for large audience = there. Maybe Igor has a specific number in mind that would matter from a = protocol design perspective but I do not have such a number that would = provide a meaningful distinction.=20 There is, however, the question what types of problems we expect with = very large number of alert message receivers and how we document this = aspect in the requirements document.=20 Suggestions? Thoughts?=20 Ciao Hannes From hannes.tschofenig@gmx.net Sat Jan 15 11:28:07 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCD23A6E26 for ; Sat, 15 Jan 2011 11:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGcsJT7NKrCD for ; Sat, 15 Jan 2011 11:28:06 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id D1A263A6E23 for ; Sat, 15 Jan 2011 11:28:05 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2011 19:30:34 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.7]) [88.115.222.204] by mail.gmx.net (mp060) with SMTP; 15 Jan 2011 20:30:34 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Vz6x8ARNV9y7TBRTm1y0cFbincP4NZOzVsUb94R ZQzoLzBbY66C+P From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Jan 2011 21:30:33 +0200 Message-Id: To: earlywarning@ietf.org, Igor Faynberg Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Subject: [Atoca] Requirement for Originator Authentication? X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 19:28:07 -0000 Hi all,=20 Igor raised an interesting question during the meeting in context of the = security threats, namely:=20 " Do we have the requirement to authenticate the originator? " I couldn't provide him an answer during the meeting because I was not = quite sure whether he was asking the question in the style of=20 "Do we need end-to-end security or is a hop-by-hop security solution = good enough?" So, I am not quite sure how to interpret the question.=20 Ciao Hannes From hannes.tschofenig@gmx.net Sat Jan 15 11:28:50 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799443A6E24 for ; Sat, 15 Jan 2011 11:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3j5ZUWDtbX3 for ; Sat, 15 Jan 2011 11:28:49 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 29DE23A6E23 for ; Sat, 15 Jan 2011 11:28:49 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2011 19:31:17 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.7]) [88.115.222.204] by mail.gmx.net (mp060) with SMTP; 15 Jan 2011 20:31:17 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19zDJJBaMVzjCzxyeIWwFQ4ey5DVIZKhdtbdubsnk NZDTEUNz7NWWs2 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Jan 2011 21:31:16 +0200 Message-Id: <9C2879D3-CDE1-48A6-B4F0-DC98B6EF1E0C@gmx.net> To: earlywarning@ietf.org, Igor Faynberg Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Subject: [Atoca] What information is used for authorization? X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 19:28:50 -0000 Hi all,=20 it was Igor again who raised a question regarding authorization at the = IETF#79 ATOCA meeting. He was wondering whether we would only consider = the identity of the originator for authorization or some other = information as well. =20 Are we considering trait-based authorization, see = http://www.rfc-editor.org/rfc/rfc4484.txt, to be utilized in this = context?=20 So, what model do we envision?=20 What other information is useful in the context of an authorization = decision?=20 Ciao Hannes From hannes.tschofenig@gmx.net Sun Jan 16 07:17:39 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A813A6D4C for ; Sun, 16 Jan 2011 07:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXTKs2sD4Kgx for ; Sun, 16 Jan 2011 07:17:38 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 23D5B3A6BD7 for ; Sun, 16 Jan 2011 07:17:37 -0800 (PST) Received: (qmail invoked by alias); 16 Jan 2011 15:20:08 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.7]) [88.115.222.204] by mail.gmx.net (mp061) with SMTP; 16 Jan 2011 16:20:08 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19v53Zop3pv53UNgSpF2+7a/fT6T0RgQOJ81yviHG +oF15+sUzv+wIg Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sun, 16 Jan 2011 17:20:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C2879D3-CDE1-48A6-B4F0-DC98B6EF1E0C@gmx.net> To: Art Botterell X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Igor Faynberg , "earlywarning@ietf.org" Subject: Re: [Atoca] What information is used for authorization? X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 15:17:40 -0000 Hi Art,=20 I think it would be useful to have an example here.=20 For example, it would be important to know to whom the individual (in = our terminology the Author of the Alert message) would authenticate = himself to. Also, it might be useful to know what a gateway, relay or even a = Receiver (not to talk about a Recipient) would do with this information.=20= Then, with 'credentialling agency' you mean the entity that issued the = credentials to the individual (the Author). For example, in a public key = based system we are talking about the certificate authority here. Right? Ciao Hannes On Jan 15, 2011, at 11:51 PM, Art Botterell wrote: > I'd suggest requiring credible identification of the individual and of = the credentialling agency. (Not every gateway will necessarily honor = credentials from every issuer.) Different gateways could then apply = different policies based on those and on message contents, including = potentially special CAP parameters or other fields as desired locally. >=20 > Thanks! >=20 > - Art >=20 > On Jan 15, 2011, at 11:31 AM, Hannes Tschofenig = wrote: >=20 >> Hi all,=20 >>=20 >> it was Igor again who raised a question regarding authorization at = the IETF#79 ATOCA meeting. He was wondering whether we would only = consider the identity of the originator for authorization or some other = information as well. >>=20 >> Are we considering trait-based authorization, see = http://www.rfc-editor.org/rfc/rfc4484.txt, to be utilized in this = context?=20 >>=20 >> So, what model do we envision?=20 >> What other information is useful in the context of an authorization = decision?=20 >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning From hannes.tschofenig@gmx.net Sun Jan 16 07:19:36 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C733A6D45 for ; Sun, 16 Jan 2011 07:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o3a2J6nVCFF for ; Sun, 16 Jan 2011 07:19:35 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 01D533A6BD7 for ; Sun, 16 Jan 2011 07:19:34 -0800 (PST) Received: (qmail invoked by alias); 16 Jan 2011 15:22:05 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.7]) [88.115.222.204] by mail.gmx.net (mp064) with SMTP; 16 Jan 2011 16:22:05 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/mJJhiYLnmoFpE6mPrdicWz+nzm6gE/KRlcCR2rh TkBrCs5YQIdn6c Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sun, 16 Jan 2011 17:22:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1285F7FB-FFBE-4B49-87F8-FCDCDF1F1AD3@gmx.net> References: To: Art Botterell X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Igor Faynberg , "earlywarning@ietf.org" Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 15:19:36 -0000 Hi Art,=20 that's an interesting comment particularly since we do not have a = requirement for responses by receivers (or Recipients) of alert = messages. I am not sure to whom they would sent their response to. To = the originator, to some gateway, etc?=20 Ciao Hannes On Jan 15, 2011, at 11:58 PM, Art Botterell wrote: > One difference in "broadcast" delivery is that it's frequntly = impractical and/or undesirable to try to track individual deliveries or = process individual responses. >=20 > Thanks! >=20 > - Art >=20 > On Jan 15, 2011, at 11:30 AM, Hannes Tschofenig = wrote: >=20 >> Hi all,=20 >>=20 >> during the ATOCA meeting at IETF#79 Igor raised a question regarding = requirement D2: >> " >> Req-D2: >>=20 >> The protocol solution MUST allow delivery of messages >> simultaneously to a large audience. >> " >>=20 >> He was asking whether there is a need to put a number for large = audience there. >>=20 >> Maybe Igor has a specific number in mind that would matter from a = protocol design perspective but I do not have such a number that would = provide a meaningful distinction.=20 >>=20 >> There is, however, the question what types of problems we expect with = very large number of alert message receivers and how we document this = aspect in the requirements document.=20 >>=20 >> Suggestions? Thoughts?=20 >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning From artbotterell@gmail.com Sat Jan 15 13:45:17 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796673A6D64 for ; Sat, 15 Jan 2011 13:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaEpL7SPu+5B for ; Sat, 15 Jan 2011 13:45:16 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 0D00E3A6D63 for ; Sat, 15 Jan 2011 13:45:15 -0800 (PST) Received: by qwi2 with SMTP id 2so3912800qwi.31 for ; Sat, 15 Jan 2011 13:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-type:message-id:content-transfer-encoding:cc:x-mailer:from :subject:date:to; bh=QYRInVwW6b5hsWR/l8Mih2E0A2dnuumEnQyZdU3MwKE=; b=DMbneJOaC/9g9OuWj0p+1f3mfj6hLOLWSjRSqV3YjYp7NZcrMT9l7urBphkXZMIG/L RuIvRihpem7ybeNyAZojAWdoR2sObtS7ggrA6HxtTLrCDtSPEWFRDb9pKYWj7p+Om+LF 8RxG8XKqgGv/vxDNU9YjEzTrb7/48/Cb3Z4wg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=jMF0V4w+6GzX99bWodVXV9BhMDI0+9yR0gVY5MFmmKHBLw2ACMdideOUwFDSEHrz9o m2lYkc3u4+4A4LMJt2OmFzHmD/B4C+gukTmQneHYwBkIaNSlC8vi/xVy6KRZMU7WJdkH MQnQcd7z2/NPiaG1sqBan9+VvbPMEb9FjLNmU= Received: by 10.224.19.207 with SMTP id c15mr2244528qab.50.1295128063381; Sat, 15 Jan 2011 13:47:43 -0800 (PST) Received: from [172.18.65.6] ([12.185.22.226]) by mx.google.com with ESMTPS id p13sm1790891qcu.29.2011.01.15.13.47.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 15 Jan 2011 13:47:41 -0800 (PST) References: <9C2879D3-CDE1-48A6-B4F0-DC98B6EF1E0C@gmx.net> In-Reply-To: <9C2879D3-CDE1-48A6-B4F0-DC98B6EF1E0C@gmx.net> Mime-Version: 1.0 (iPad Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8C148) From: Art Botterell Date: Sat, 15 Jan 2011 13:51:21 -0800 To: Hannes Tschofenig X-Mailman-Approved-At: Sun, 16 Jan 2011 14:55:04 -0800 Cc: Igor Faynberg , "earlywarning@ietf.org" Subject: Re: [Atoca] What information is used for authorization? X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 21:45:17 -0000 I'd suggest requiring credible identification of the individual and of the c= redentialling agency. (Not every gateway will necessarily honor credentials= from every issuer.) Different gateways could then apply different policie= s based on those and on message contents, including potentially special CAP p= arameters or other fields as desired locally. Thanks! - Art On Jan 15, 2011, at 11:31 AM, Hannes Tschofenig w= rote: > Hi all,=20 >=20 > it was Igor again who raised a question regarding authorization at the IET= F#79 ATOCA meeting. He was wondering whether we would only consider the iden= tity of the originator for authorization or some other information as well. >=20 > Are we considering trait-based authorization, see http://www.rfc-editor.or= g/rfc/rfc4484.txt, to be utilized in this context?=20 >=20 > So, what model do we envision?=20 > What other information is useful in the context of an authorization decisi= on?=20 >=20 > Ciao > Hannes >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From artbotterell@gmail.com Sat Jan 15 13:54:30 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716D43A6D49 for ; Sat, 15 Jan 2011 13:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yn4kxeizX6Uc for ; Sat, 15 Jan 2011 13:54:29 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id A4D673A6C53 for ; Sat, 15 Jan 2011 13:54:29 -0800 (PST) Received: by qyk34 with SMTP id 34so620190qyk.10 for ; Sat, 15 Jan 2011 13:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-type:message-id:content-transfer-encoding:cc:x-mailer:from :subject:date:to; bh=uSYS/+iQ543H7+4pLelK6AfEAbmSg8mv9eUxmtpaY5o=; b=apqhkALURsI14nzFHEhDf5kchic0SX+cG2nJ+DgmVY8qOqMzTBAoa3n2YWzxwgOlSe mhk/6DMfEQ7pkyoVZrtRWqjYGmshRV2LVfP9sZ16EspzheCfyyYIv+t+0Kzwn8XZgfi0 33M91VpD5JhBQSzzt7sbexFgEzAGoDO98IBTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=Li1EfhJa8VdgaWKHpogIbPw6NxVIsKRN++E+ATwnUAEhz01GAIm6JC4gWRpfWEAI70 s/O9/tl6j8m4swUlxSggrLlkqGoEmlPmOQ9SBhMfbXLszqqS5VStJLjBxKjYy1L7yg4A DoHx/2Ny9VnONyICpW+FVWzhVe6crjtv6o2lE= Received: by 10.229.83.198 with SMTP id g6mr2134098qcl.157.1295128476673; Sat, 15 Jan 2011 13:54:36 -0800 (PST) Received: from [172.18.65.6] ([12.185.22.226]) by mx.google.com with ESMTPS id q12sm1792227qcu.42.2011.01.15.13.54.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 15 Jan 2011 13:54:35 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8C148) From: Art Botterell Date: Sat, 15 Jan 2011 13:58:14 -0800 To: Hannes Tschofenig X-Mailman-Approved-At: Sun, 16 Jan 2011 14:55:04 -0800 Cc: Igor Faynberg , "earlywarning@ietf.org" Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 21:54:30 -0000 One difference in "broadcast" delivery is that it's frequntly impractical an= d/or undesirable to try to track individual deliveries or process individual= responses. Thanks! - Art On Jan 15, 2011, at 11:30 AM, Hannes Tschofenig w= rote: > Hi all,=20 >=20 > during the ATOCA meeting at IETF#79 Igor raised a question regarding requi= rement D2: > " > Req-D2: >=20 > The protocol solution MUST allow delivery of messages > simultaneously to a large audience. > " >=20 > He was asking whether there is a need to put a number for large audience t= here. >=20 > Maybe Igor has a specific number in mind that would matter from a protocol= design perspective but I do not have such a number that would provide a mea= ningful distinction.=20 >=20 > There is, however, the question what types of problems we expect with very= large number of alert message receivers and how we document this aspect in t= he requirements document.=20 >=20 > Suggestions? Thoughts?=20 >=20 > Ciao > Hannes >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From Martin.Thomson@andrew.com Sun Jan 16 15:05:51 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D61F3A6C43 for ; Sun, 16 Jan 2011 15:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJcaNyk-ra7f for ; Sun, 16 Jan 2011 15:05:50 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 9C6E43A6B74 for ; Sun, 16 Jan 2011 15:05:50 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:53966 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S41425848Ab1APXIW (ORCPT ); Sun, 16 Jan 2011 17:08:22 -0600 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.137.0; Sun, 16 Jan 2011 17:08:22 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 17 Jan 2011 07:08:19 +0800 From: "Thomson, Martin" To: Hannes Tschofenig , "earlywarning@ietf.org" Date: Mon, 17 Jan 2011 07:08:17 +0800 Thread-Topic: [Atoca] Language and Media Type Thread-Index: Acu06qUlqBz98b/eS+WzPqkeJnWTvgA5FkSw Message-ID: <8B0A9FCBB9832F43971E38010638454F03F52595D2@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Atoca] Language and Media Type X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 23:05:51 -0000 T24gMjAxMS0wMS0xNiBhdCAwNjozMDoxMSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+IEtl ZXBpbmcgTGkgKGlmIHRoZSBtZWV0aW5nIG1pbnV0ZXMgcmVmbGVjdCBoaXMgbmFtZSBjb3JyZWN0 bHkpIG5vdGljZWQNCj4gdGhhdCB3ZSBoYWQgYSBsYW5ndWFnZSByZXF1aXJlbWVudCBpbiB0aGUg cmVxdWlyZW1lbnRzIGRyYWZ0IGJ1dA0KPiBwcm92aWRlZCBubyBjb3JyZXNwb25kaW5nIHNvbHV0 aW9uIGluIHRoZSBTSVAtQ0FQIGRvY3VtZW50Lg0KDQpBIHNvbHV0aW9uIGRvZXMgc2VlbSBkZXNp cmFibGUuICBUaG91Z2ggSSBzdXNwZWN0IHRoYXQgbWFueSBhbGVydGluZyBzeXN0ZW1zIHdpbGwg YmUgZGVwbG95ZWQgd2l0aCBvbmUgbGFuZ3VhZ2Ugb3Igd2l0aCBhbGwgb2YgdGhlIHNtYWxsIG51 bWJlciBvZiAib2ZmaWNpYWwiIG9yICJzdXBwb3J0ZWQiIGxhbmd1YWdlcyBwcmVzZW50IGluIHRo ZSBtZXNzYWdlLiAgVGhpcyBpcyBwcm9iYWJseSBnb2luZyB0byBiZSBuZWNlc3NhcnkgZm9yIGFs bCAiaW1wbGljaXQiIHN1YnNjcmlwdGlvbnMgYW55aG93Lg0KDQpJbiBIVFRQLWxhbmQsIHRoZSBB Y2NlcHQtTGFuZ3VhZ2UgaGVhZGVyIGlzIHVzZWQgZm9yIHRoYXQgc29ydCBvZiB0aGluZy4gIFRo ZSBoZWFkZXIgaXMgcHJlc2VudCBpbiBTSVAsIGJ1dCBpdCdzIHVzZSBzZWVtcyBsaW1pdGVkIC0g YW5kIHdoYXQgZXZpZGVuY2UgSSBoYXZlIHN1cHBvcnRzIHRoZSBub3Rpb24gdGhhdCBtb3N0IHNl cnZlcnMgaWdub3JlIGl0Lg0KDQpXZSBjb3VsZCBkZWZpbmUgYSB1c2UgZm9yIEFjY2VwdC1MYW5n dWFnZSBhbmQgc2VlIGhvdyB0aGF0IGZsaWVzLg0KDQo= From Martin.Thomson@andrew.com Sun Jan 16 15:12:38 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D740E3A6E60 for ; Sun, 16 Jan 2011 15:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEkkGQnU7SRW for ; Sun, 16 Jan 2011 15:12:38 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 228C33A6CEF for ; Sun, 16 Jan 2011 15:12:38 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:41264 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S531655Ab1APXPK (ORCPT ); Sun, 16 Jan 2011 17:15:10 -0600 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.137.0; Sun, 16 Jan 2011 17:15:10 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 17 Jan 2011 07:15:06 +0800 From: "Thomson, Martin" To: Hannes Tschofenig , Art Botterell Date: Mon, 17 Jan 2011 07:15:04 +0800 Thread-Topic: [Atoca] Requirement D2: "Large Audience" Thread-Index: Acu1kSZx02LQzsaJR2maLToInGbJVQAPvVXA Message-ID: <8B0A9FCBB9832F43971E38010638454F03F52595D3@SISPE7MB1.commscope.com> References: <1285F7FB-FFBE-4B49-87F8-FCDCDF1F1AD3@gmx.net> In-Reply-To: <1285F7FB-FFBE-4B49-87F8-FCDCDF1F1AD3@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Igor Faynberg , "earlywarning@ietf.org" Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 23:12:38 -0000 T24gSmFuIDE1LCAyMDExLCBhdCAxMTo1OCBQTSwgQXJ0IEJvdHRlcmVsbCB3cm90ZToNCj4gT25l IGRpZmZlcmVuY2UgaW4gImJyb2FkY2FzdCIgZGVsaXZlcnkgaXMgdGhhdCBpdCdzIGZyZXF1bnRs eQ0KPiBpbXByYWN0aWNhbCBhbmQvb3IgdW5kZXNpcmFibGUgdG8gdHJ5IHRvIHRyYWNrIGluZGl2 aWR1YWwgZGVsaXZlcmllcyBvcg0KPiBwcm9jZXNzIGluZGl2aWR1YWwgcmVzcG9uc2VzLg0KDQpJ ZiBTSVAgaXMgb3VyIGRlbGl2ZXJ5IG1lY2hhbmlzbSwgY2FuIGFueXRoaW5nIGJlIGRvbmUgdG8g c3VwcHJlc3MgMjAwIHJlc3BvbnNlcyB0byBOT1RJRlkgcmVxdWVzdHM/ICBJcyB0aGVyZSBhbnkg cG9pbnQgaWYgd2UncmUgdXNpbmcgYWNrbm93bGVkZ2VkIHRyYW5zcG9ydCBsaWtlIFRDUD8gIElz IHRoZXJlIGEgY29uY2VybiB0aGF0IHVuYWNrbm93bGVkZ2VkIHBhY2tldHMgKFVEUCkgd2lsbCBn ZXQgZHJvcHBlZD8NCg0KVGhlIHBvdGVudGlhbCB0byBjcmVhdGUgY29uZ2VzdGlvbiB3b3JyaWVz IG1lLg0KDQotLU1hcnRpbg0K From Martin.Thomson@andrew.com Sun Jan 16 15:29:52 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD0728C0CE for ; Sun, 16 Jan 2011 15:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20GvoK1mOJxe for ; Sun, 16 Jan 2011 15:29:51 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 1A12B3A6E63 for ; Sun, 16 Jan 2011 15:29:50 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:51837 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S41426324Ab1APXcU (ORCPT ); Sun, 16 Jan 2011 17:32:20 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Sun, 16 Jan 2011 17:32:20 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 17 Jan 2011 07:32:17 +0800 From: "Thomson, Martin" To: Hannes Tschofenig , "earlywarning@ietf.org" , Igor Faynberg Date: Mon, 17 Jan 2011 07:32:09 +0800 Thread-Topic: [Atoca] Requirement for Originator Authentication? Thread-Index: Acu06rVOLwvhgOa0T5WSS8cq4sczfAA5M37g Message-ID: <8B0A9FCBB9832F43971E38010638454F03F52595D6@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {9C5849DE-E27E-47CA-91DA-C7378CB587E0} x-cr-hashedpuzzle: EmeP E7q9 Fv9Y LByE O0vN O9+p RBKH RYyZ SnfP Ss3c XfEX alrI bw89 cAyw cqSV dm31; 3; ZQBhAHIAbAB5AHcAYQByAG4AaQBuAGcAQABpAGUAdABmAC4AbwByAGcAOwBoAGEAbgBuAGUAcwAuAHQAcwBjAGgAbwBmAGUAbgBpAGcAQABnAG0AeAAuAG4AZQB0ADsAaQBnAG8AcgAuAGYAYQB5AG4AYgBlAHIAZwBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBlAG4AdAAuAGMAbwBtAA==; Sosha1_v1; 7; {9C5849DE-E27E-47CA-91DA-C7378CB587E0}; bQBhAHIAdABpAG4ALgB0AGgAbwBtAHMAbwBuAEAAYQBuAGQAcgBlAHcALgBjAG8AbQA=; Sun, 16 Jan 2011 23:32:09 GMT; UgBFADoAIABbAEEAdABvAGMAYQBdACAAUgBlAHEAdQBpAHIAZQBtAGUAbgB0ACAAZgBvAHIAIABPAHIAaQBnAGkAbgBhAHQAbwByACAAQQB1AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuAD8A acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Atoca] Requirement for Originator Authentication? X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 23:29:52 -0000 T24gMjAxMS0wMS0xNiBhdCAwNjozMDozMywgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+IEln b3IgcmFpc2VkIGFuIGludGVyZXN0aW5nIHF1ZXN0aW9uIGR1cmluZyB0aGUgbWVldGluZyBpbiBj b250ZXh0IG9mDQo+IHRoZSBzZWN1cml0eSB0aHJlYXRzLCBuYW1lbHk6DQo+IA0KPiAiIERvIHdl IGhhdmUgdGhlIHJlcXVpcmVtZW50IHRvIGF1dGhlbnRpY2F0ZSB0aGUgb3JpZ2luYXRvcj8gIg0K DQpUaGUgcXVlc3Rpb24gdGhhdCBJIGhlYXJkIHdhcyBub3Qgc28gbXVjaCByZWxhdGVkIHRvIGF1 dGhlbnRpY2F0aW9uIGFzIGl0IHdhcyB0byBhdXRob3JpemF0aW9uLiAgVGhlcmUgd2FzIGFsc28g YSBxdWVzdGlvbiBhYm91dCB3aGV0aGVyIGF1dGhlbnRpY2F0aW9uIHdhcyBpZGVudGl0eS1iYXNl ZCBvciBvbiBzb21lIG90aGVyIHByb3BlcnR5LCBsaWtlIHNvbWUgYXNzZXJ0ZWQgdHJhaXQuDQoN CldoYXQgc3RhdGVtZW50cyBjYW4gd2UgbWFrZSBhYm91dCBob3cgcmVjaXBpZW50cyAoYW5kIHJl bGF5cykgYXV0aG9yaXplIHRoZSByZWNlaXB0IChhbmQgc2VuZGluZykgb2YgYWxlcnQgbWVzc2Fn ZXM/DQogDQo+IEkgY291bGRuJ3QgcHJvdmlkZSBoaW0gYW4gYW5zd2VyIGR1cmluZyB0aGUgbWVl dGluZyBiZWNhdXNlIEkgd2FzIG5vdA0KPiBxdWl0ZSBzdXJlIHdoZXRoZXIgaGUgd2FzIGFza2lu ZyB0aGUgcXVlc3Rpb24gaW4gdGhlIHN0eWxlIG9mDQo+IA0KPiAiRG8gd2UgbmVlZCBlbmQtdG8t ZW5kIHNlY3VyaXR5IG9yIGlzIGEgaG9wLWJ5LWhvcCBzZWN1cml0eSBzb2x1dGlvbg0KPiBnb29k IGVub3VnaD8iDQoNCkluIHRoZSBjb250ZXh0IG9mIHRoaXMgaW50ZXJwcmV0YXRpb24sIEkgdGhp bmsgdGhhdCB0aGVyZSdzIGEgcmVhbCBuZWVkIHRvIGRlbGVnYXRlIGFsZXJ0IGRpc3RyaWJ1dGlv bi4gIFRoZSBzY2FsZSBvZiBkaXN0cmlidXRpb24gbWFrZXMgaW50ZXJtZWRpYXJpZXMgYSB2YWx1 YWJsZSBhZGRpdGlvbi4gIFJlbHlpbmcgb24gdGhlIGludGVncml0eSBvZiByZWxheXMgbWFrZXMg dGhlIGF1dGhvcml6YXRpb24gcXVlc3Rpb24gbW9yZSBkaWZmaWN1bHQgdG8gcmVzb2x2ZS4NCg0K Rm9yIHNvbWV0aGluZyBjb25jcmV0ZSwgdGhlIHJlbGF5IGNhc2UgaXMgcHJvYmFibHkgdGhlIHNp bXBsZXN0LiAgSSBtaWdodCB0cnVzdCBteSBzaWduYWxsaW5nIHBlZXIgdG8gYSBjZXJ0YWluIGV4 dGVudC4gIEkgY2VydGFpbmx5IGRvbid0IHRydXN0IHRoZW0gZW5vdWdoIHRvIGdlbmVyYXRlIHRo ZSBtYXNzaXZlIHBhY2tldCBzdG9ybSByZXF1ZXN0ZWQgYnkgYW4gYWxlcnQgbWVzc2FnZS4gIFRo ZXkgbWlnaHQgc2F5IHRoZSBhbGVydCBjb21lcyBmcm9tIHRoZSBnb3Zlcm5tZW50LCBidXQgSSBt aWdodCByZXF1aXJlIGJldHRlciBwcm9vZiB0aGFuIHRoZWlyIHNheS1zbyBhbG9uZS4gIERpc3Ry aWJ1dGluZyBhbiBhbGVydCB3aWxsIGNvc3QgbWUgbW9uZXkgYW5kIEkgd2FudCBwcm9vZi4NCg0K VGhhdCdzIG9uZSBhcmd1bWVudC4gIFRoZSBvdGhlciBhcmd1bWVudCBzYXlzIHRoYXQgcGVlcmlu ZyByZWxhdGlvbnNoaXBzIHJlcXVpcmUgYSBkZWdyZWUgb2YgdHJ1c3QgdGhhdCB3b3VsZCBub3Qg YmUgYnJva2VuIHdpdGhvdXQgc2VyaW91cyByYW1pZmljYXRpb25zIC0gZW5vdWdoIHRvIGRpc2Nv dXJhZ2UgaXRzIGFidXNlLg0KDQpUaGUgcmVjaXBpZW50IGNhc2UgbWlnaHQgaGF2ZSBzb21lIGlu dGVyZXN0aW5nIHF1aXJrcy4gIFBhcnRpY3VsYXJseSBpbiB3aG9sZXNhbGUvcmVzZWxsZXIgYXJy YW5nZW1lbnRzLiAgQSByZWNpcGllbnQgdGhhdCByZWxpZXMgb24gaG9wLWJ5LWhvcCBtaWdodCBy ZWNlaXZlIGFuIGFsZXJ0IGZyb20gdGhlIG5ldHdvcmsgb3BlcmF0b3I6IGFuIGVudGl0eSB3aXRo IHdob20gdGhleSBoYXZlIG5vIGRpcmVjdCByZWxhdGlvbnNoaXAuICBGb3IgaW5zdGFuY2UsIG5v IGZld2VyIHRoYW4gdHdvIGRpZmZlcmVudCBvcGVyYXRvcnMgYXJlIGludm9sdmVkIGluIGdldHRp bmcgcGFja2V0cyB0byBteSBob3VzZSwgbmVpdGhlciBvZiB3aGljaCBJIGhhdmUgYSBidXNpbmVz cyByZWxhdGlvbnNoaXAgd2l0aC4gIEhvdyB3b3VsZCBzb21lb25lIC0gaWdub3JhbnQgb2YgdGhl IGNvbnZvbHV0ZWQgYnVzaW5lc3MgYXJyYW5nZW1lbnRzIHRoYXQgdW5kZXJwaW4gdGhlaXIgSW50 ZXJuZXQgc2VydmljZSAtIGRlY2lkZSB0byBhdXRob3JpemUgYW4gYWxlcnQgdGhhdCBpcyByZWxh eWVkIGJ5IGVpdGhlciBwYXJ0eT8NCg0KLS1NYXJ0aW4NCg== From Martin.Thomson@andrew.com Sun Jan 16 15:34:17 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5CC13A6E63 for ; Sun, 16 Jan 2011 15:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2r0bYFbgJgK7 for ; Sun, 16 Jan 2011 15:34:17 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id E448C3A6BA5 for ; Sun, 16 Jan 2011 15:34:16 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:8464 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S41426556Ab1APXgt (ORCPT ); Sun, 16 Jan 2011 17:36:49 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Sun, 16 Jan 2011 17:36:49 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 17 Jan 2011 07:36:45 +0800 From: "Thomson, Martin" To: Hannes Tschofenig , "earlywarning@ietf.org" Date: Mon, 17 Jan 2011 07:36:43 +0800 Thread-Topic: [Atoca] Updated Requirements and Terminology Draft Thread-Index: Acu06rT5jfVf8ArgSJWU9fRKhOjgWwA5Eoog Message-ID: <8B0A9FCBB9832F43971E38010638454F03F52595D8@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Atoca] Updated Requirements and Terminology Draft X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 23:34:18 -0000 T24gMjAxMS0wMS0xNiBhdCAwNjozMDowNSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+IEFz IGEgcmVzdWx0LCB3ZSBoYXZlIHVwZGF0ZWQgdGhlIGRyYWZ0Og0KPiBodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWF0b2NhLXJlcXVpcmVtZW50cy0NCj4gMDEu dHh0DQoNClRoYW5rcyBIYW5uZXMgYW5kIEJyaWFuLg0K From mark.wood@drcf.net Sun Jan 16 16:17:12 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B313A6B9B for ; Sun, 16 Jan 2011 16:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0rFmUMhLJQl for ; Sun, 16 Jan 2011 16:17:11 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id DCE493A67C0 for ; Sun, 16 Jan 2011 16:17:10 -0800 (PST) X-Trace: 342964949/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Outlook 14.0 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFQZM01RVitW/2dsb2JhbACkXnS8XYVQBI43hG8 X-IronPort-AV: E=Sophos;i="4.60,331,1291593600"; d="scan'208";a="342964949" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO host15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 17 Jan 2011 00:19:39 +0000 From: Sender: "mark.wood" To: References: <8B0A9FCBB9832F43971E38010638454F03F52595D2@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F52595D2@SISPE7MB1.commscope.com> Date: Mon, 17 Jan 2011 00:20:17 -0000 Message-ID: <003101cbb5dc$51816c20$f4844460$@engineer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKwAdYj/uAV0fN1Gt7Mi4f1EUG7oAJHmEn7kfls9sA= Content-Language: en-us Subject: Re: [Atoca] Language and Media Type X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 00:31:57 -0000 Hi Switzerland is a 'worst case scenario' example,By law they need to transmit in German, French, Italian and "Romanshe". They will also probably transmit in English as well to reach tourists, especially at airports. There may be other special cases such as Japanese in Zermat, where large groups of Japanese often congregate. I expect there to be very few cases where more than half a dozen languages would be sent for each alert message, though civic information messages are a different matter and may either be language specific or in some cases sent in a dozen languages. However information messages are much less time critical than alert messages so some extra delay is tolerable. The matter of language is a very hotly sensitive one in many regions. For example, in Wales you must send official communications in Welsh and English, even though most Welsh speak good English. This problem is very sensitive indeed in many parts of the world, to such an extent that a solution that does not have some solution to multiple languages is a non-starter due to the political heat it would cause if anyone in the other ethnic group died due to not getting a message. Conversely, politicians like the idea of being able to reach out to ethnic groups in this way as a way of building trust, this is why almost all of them insist on a multi-language capability from the start. In some cases indigenous populations text each other in a 'Latinized font version' of their own language. Therefore the problem of fonts is not always as big a problem as we may think, but clearly a more capable roadmap is needed in the future. In Cell Broadcast, for example, we are proposing at least three different mechanisms for distinguishing one from the other, because a clear winner has not appeared yet and the debate is very contentious. Very likely, at some point, a clear winner will emerge and I hope only one mechanism will suffice. Meantime, governments are wanting to keep their options open so this is why they are proposing all three mechanisms in parallel for now, for later review. Because the matter is now seen as urgent, they would rather start now with something imperfect than wait for the perfect solution to eventually appear before making a move. Warm Regards, Mark Wood DRCF. -----Original Message----- From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] On Behalf Of Thomson, Martin Sent: Sunday, January 16, 2011 11:08 PM To: Hannes Tschofenig; earlywarning@ietf.org Subject: Re: [Atoca] Language and Media Type On 2011-01-16 at 06:30:11, Hannes Tschofenig wrote: > Keeping Li (if the meeting minutes reflect his name correctly) noticed > that we had a language requirement in the requirements draft but > provided no corresponding solution in the SIP-CAP document. A solution does seem desirable. Though I suspect that many alerting systems will be deployed with one language or with all of the small number of "official" or "supported" languages present in the message. This is probably going to be necessary for all "implicit" subscriptions anyhow. In HTTP-land, the Accept-Language header is used for that sort of thing. The header is present in SIP, but it's use seems limited - and what evidence I have supports the notion that most servers ignore it. We could define a use for Accept-Language and see how that flies. _______________________________________________ earlywarning mailing list earlywarning@ietf.org https://www.ietf.org/mailman/listinfo/earlywarning From art.botterell@west.cmu.edu Sun Jan 16 15:49:48 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F6E3A6C41 for ; Sun, 16 Jan 2011 15:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqdHfwIz0K8M for ; Sun, 16 Jan 2011 15:49:46 -0800 (PST) Received: from mail-yi0-f42.google.com (mail-yi0-f42.google.com [209.85.218.42]) by core3.amsl.com (Postfix) with ESMTP id 1BA853A6BA5 for ; Sun, 16 Jan 2011 15:49:46 -0800 (PST) Received: by yia28 with SMTP id 28so2445447yia.15 for ; Sun, 16 Jan 2011 15:52:18 -0800 (PST) Received: by 10.151.113.4 with SMTP id q4mr3568319ybm.156.1295221938431; Sun, 16 Jan 2011 15:52:18 -0800 (PST) Received: from [10.10.1.90] ([200.6.58.236]) by mx.google.com with ESMTPS id u3sm1770862yba.4.2011.01.16.15.52.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Jan 2011 15:52:17 -0800 (PST) References: <8B0A9FCBB9832F43971E38010638454F03F52595D6@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F52595D6@SISPE7MB1.commscope.com> Mime-Version: 1.0 (iPad Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <915FDCF5-7C3E-4758-B6EB-38F0BDF09A84@west.cmu.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8C148) From: Art Botterell Date: Sun, 16 Jan 2011 19:55:57 -0400 To: "Thomson, Martin" X-Mailman-Approved-At: Sun, 16 Jan 2011 21:03:52 -0800 Cc: Igor Faynberg , "earlywarning@ietf.org" Subject: Re: [Atoca] Requirement for Originator Authentication? X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 23:54:21 -0000 I suspect we'll find that different carriers/gateways will insist on being a= ble to apply their own authorization rules, and thus that end of things will= be distributed perforce. By the same token, I don't foresee a single globa= l identification/credentialling scheme. The best we can hope for, I suspect= , is a reasonable degree of reciprocity among authorities. The first question, I think, is whether there's a use case for anonymity in a= uthority-to-public alerting; not sure what that would be. The next question is how far it makes sense to go in specifying the form of a= n identification scheme. Thanks! - Art On Jan 16, 2011, at 7:32 PM, "Thomson, Martin" w= rote: > On 2011-01-16 at 06:30:33, Hannes Tschofenig wrote: >> Igor raised an interesting question during the meeting in context of >> the security threats, namely: >>=20 >> " Do we have the requirement to authenticate the originator? " >=20 > The question that I heard was not so much related to authentication as it w= as to authorization. There was also a question about whether authentication= was identity-based or on some other property, like some asserted trait. >=20 > What statements can we make about how recipients (and relays) authorize th= e receipt (and sending) of alert messages? >=20 >> I couldn't provide him an answer during the meeting because I was not >> quite sure whether he was asking the question in the style of >>=20 >> "Do we need end-to-end security or is a hop-by-hop security solution >> good enough?" >=20 > In the context of this interpretation, I think that there's a real need to= delegate alert distribution. The scale of distribution makes intermediarie= s a valuable addition. Relying on the integrity of relays makes the authori= zation question more difficult to resolve. >=20 > For something concrete, the relay case is probably the simplest. I might t= rust my signalling peer to a certain extent. I certainly don't trust them e= nough to generate the massive packet storm requested by an alert message. T= hey might say the alert comes from the government, but I might require bette= r proof than their say-so alone. Distributing an alert will cost me money a= nd I want proof. >=20 > That's one argument. The other argument says that peering relationships r= equire a degree of trust that would not be broken without serious ramificati= ons - enough to discourage its abuse. >=20 > The recipient case might have some interesting quirks. Particularly in wh= olesale/reseller arrangements. A recipient that relies on hop-by-hop might r= eceive an alert from the network operator: an entity with whom they have no d= irect relationship. For instance, no fewer than two different operators are= involved in getting packets to my house, neither of which I have a business= relationship with. How would someone - ignorant of the convoluted business= arrangements that underpin their Internet service - decide to authorize an a= lert that is relayed by either party? >=20 > --Martin > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From artbotterell@gmail.com Sun Jan 16 19:43:44 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35A543A6E6F for ; Sun, 16 Jan 2011 19:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQdg-bxrhGJs for ; Sun, 16 Jan 2011 19:43:42 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id DB8CD3A6DA6 for ; Sun, 16 Jan 2011 19:43:41 -0800 (PST) Received: by yxt33 with SMTP id 33so2024978yxt.31 for ; Sun, 16 Jan 2011 19:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-type:message-id:content-transfer-encoding:cc:from:subject :date:to:x-mailer; bh=JSAcpfhbSo42vq7O42WcsWsism9U4rWlQdGxQI3MWTE=; b=PQrxWc0DLBInUd11e/kHKK9kw5hkaDS85BukMdYUTiQu0sQRfp0CZJ5CcpQ8CRLJGI Y/yn9LJELRKqNvWplUeOJgut6r6+3febSTZNqZR7nKQokblOk2WU62A45GY0S6Oo7cNI V6bv15S+SED1PVX9XnYl/zdhUyZ6AQmcdal9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=eXlPL+mi69OEQnowy0j786FKsdHlXtkLZMouO77vuZGynQWmE9FcnHZ2AhO5VDbwPY +9z20tJ/daDajrY/Cp+dcE1l5XxngNawA/xIAQI9lrVz/cGgMl3Yjbp5hcZvbWHAThCk l3ZJCd6BUfSKtqilAGTJZOiHVp33frgC7LLQ0= Received: by 10.150.198.7 with SMTP id v7mr3784479ybf.328.1295235973320; Sun, 16 Jan 2011 19:46:13 -0800 (PST) Received: from [10.10.1.90] ([200.6.58.236]) by mx.google.com with ESMTPS id w24sm1896188ybk.9.2011.01.16.19.46.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Jan 2011 19:46:11 -0800 (PST) References: <1285F7FB-FFBE-4B49-87F8-FCDCDF1F1AD3@gmx.net> In-Reply-To: <1285F7FB-FFBE-4B49-87F8-FCDCDF1F1AD3@gmx.net> Mime-Version: 1.0 (iPad Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <8DB1F455-6444-4FC6-841A-60242CAAE0BC@gmail.com> Content-Transfer-Encoding: quoted-printable From: Art Botterell Date: Sun, 16 Jan 2011 23:20:37 -0400 To: Hannes Tschofenig X-Mailer: iPad Mail (8C148) X-Mailman-Approved-At: Sun, 16 Jan 2011 21:03:52 -0800 Cc: Igor Faynberg , "earlywarning@ietf.org" Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 03:43:44 -0000 Mainly I was just suggesting one way of looking at the "how large is 'large'= " question. Although it does highlight some of Martin's questions about how= to adapt a session initiation protocol to a one-to-very-many application, i= f that's what we have in mind. As he rightly points out, responses don't on= ly happen at the application level. Thanks! - Art On Jan 16, 2011, at 11:22 AM, Hannes Tschofenig w= rote: > Hi Art,=20 >=20 > that's an interesting comment particularly since we do not have a requirem= ent for responses by receivers (or Recipients) of alert messages. I am not s= ure to whom they would sent their response to. To the originator, to some ga= teway, etc?=20 >=20 > Ciao > Hannes >=20 > On Jan 15, 2011, at 11:58 PM, Art Botterell wrote: >=20 >> One difference in "broadcast" delivery is that it's frequntly impractical= and/or undesirable to try to track individual deliveries or process individ= ual responses. >>=20 >> Thanks! >>=20 >> - Art >>=20 >> On Jan 15, 2011, at 11:30 AM, Hannes Tschofenig wrote: >>=20 >>> Hi all,=20 >>>=20 >>> during the ATOCA meeting at IETF#79 Igor raised a question regarding req= uirement D2: >>> " >>> Req-D2: >>>=20 >>> The protocol solution MUST allow delivery of messages >>> simultaneously to a large audience. >>> " >>>=20 >>> He was asking whether there is a need to put a number for large audience= there. >>>=20 >>> Maybe Igor has a specific number in mind that would matter from a protoc= ol design perspective but I do not have such a number that would provide a m= eaningful distinction.=20 >>>=20 >>> There is, however, the question what types of problems we expect with ve= ry large number of alert message receivers and how we document this aspect i= n the requirements document.=20 >>>=20 >>> Suggestions? Thoughts?=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> _______________________________________________ >>> earlywarning mailing list >>> earlywarning@ietf.org >>> https://www.ietf.org/mailman/listinfo/earlywarning >=20 From artbotterell@gmail.com Sun Jan 16 19:45:11 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1184F3A6E70 for ; Sun, 16 Jan 2011 19:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guojP28XUc2K for ; Sun, 16 Jan 2011 19:45:10 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id E4E753A6DA2 for ; Sun, 16 Jan 2011 19:45:09 -0800 (PST) Received: by yxt33 with SMTP id 33so2025239yxt.31 for ; Sun, 16 Jan 2011 19:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-type:message-id:content-transfer-encoding:cc:x-mailer:from :subject:date:to; bh=GMUCMo0Xc0hysPF1lg/1wKgqb5771w7o+7NCixZqy9w=; b=h5Hj3Kv1XxPOPhhoNjSJO72OKxOHkcpDLtU24BhTWgAcogtCdftBSZSwpkuMixCBks iDkCrOalGKq+2PARfI4/2WL7R+fhtfcE6zCeBVwoHCbKAmgy9ELac5mEhj5OyxLlgD8q pGubK6fvijWE7EekRVkInaM5gvge6ckUwXynE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=TSayKbG+oc5s5P4uCnyz6kL7r6vUCoAE9ctQDDl7rmKqw0aYu+CJyK18LVjrQnom8e +fQBSXrsbwHRSWoCgdHCWKD1d4o/dxemP86vdXaloYormT8wcWU89IxmEmDxbprYl5Za RpY7Smgc4/ewaepywI9XWhla8Mh5PjZB0nF8E= Received: by 10.100.132.12 with SMTP id f12mr2249206and.7.1295236062729; Sun, 16 Jan 2011 19:47:42 -0800 (PST) Received: from [10.10.1.90] ([200.6.58.236]) by mx.google.com with ESMTPS id c34sm4941744anc.10.2011.01.16.19.47.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Jan 2011 19:47:40 -0800 (PST) References: <8B0A9FCBB9832F43971E38010638454F03F52595D2@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F52595D2@SISPE7MB1.commscope.com> Mime-Version: 1.0 (iPad Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <8B3C3AB2-6384-45C0-97A8-79DBE18831DA@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8C148) From: Art Botterell Date: Sun, 16 Jan 2011 23:51:23 -0400 To: "Thomson, Martin" X-Mailman-Approved-At: Sun, 16 Jan 2011 21:03:52 -0800 Cc: "earlywarning@ietf.org" Subject: Re: [Atoca] Language and Media Type X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 03:45:11 -0000 Would this be duplicative of the CAP language element? Thanks! - Art On Jan 16, 2011, at 7:08 PM, "Thomson, Martin" w= rote: > On 2011-01-16 at 06:30:11, Hannes Tschofenig wrote: >> Keeping Li (if the meeting minutes reflect his name correctly) noticed >> that we had a language requirement in the requirements draft but >> provided no corresponding solution in the SIP-CAP document. >=20 > A solution does seem desirable. Though I suspect that many alerting syste= ms will be deployed with one language or with all of the small number of "of= ficial" or "supported" languages present in the message. This is probably g= oing to be necessary for all "implicit" subscriptions anyhow. >=20 > In HTTP-land, the Accept-Language header is used for that sort of thing. T= he header is present in SIP, but it's use seems limited - and what evidence I= have supports the notion that most servers ignore it. >=20 > We could define a use for Accept-Language and see how that flies. >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From Martin.Thomson@andrew.com Sun Jan 16 21:09:40 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F49E3A6DAE for ; Sun, 16 Jan 2011 21:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOsZPuxwFEIs for ; Sun, 16 Jan 2011 21:09:39 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 3A6033A6DBF for ; Sun, 16 Jan 2011 21:09:39 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:15684 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S41433815Ab1AQFMM (ORCPT ); Sun, 16 Jan 2011 23:12:12 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Sun, 16 Jan 2011 23:12:12 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 17 Jan 2011 13:12:07 +0800 From: "Thomson, Martin" To: Art Botterell , Hannes Tschofenig Date: Mon, 17 Jan 2011 13:12:05 +0800 Thread-Topic: [Atoca] Requirement D2: "Large Audience" Thread-Index: Acu2BF5AO+s86cIvQzGY8TjhOO8dIAAADPpA Message-ID: <8B0A9FCBB9832F43971E38010638454F03F525968A@SISPE7MB1.commscope.com> References: <1285F7FB-FFBE-4B49-87F8-FCDCDF1F1AD3@gmx.net> <8DB1F455-6444-4FC6-841A-60242CAAE0BC@gmail.com> In-Reply-To: <8DB1F455-6444-4FC6-841A-60242CAAE0BC@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "earlywarning@ietf.org" Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 05:09:40 -0000 SW50ZXJlc3RpbmcgdGlkYml0IGZyb20gdGhlIEF1c3RyYWxpYW4gd2FybmluZyBzeXN0ZW0gZGlz Y3Vzc2lvbnM6IHRoZSBvcmlnaW5hdGluZyBzeXN0ZW1zICh0aGUgZmlyc3QgcmVsYXkpIHByb3Zp ZGVzIGEgcmVwb3J0IHRvIHRoZSBlbWVyZ2VuY3kgYXV0aG9yaXR5IG9uIHRoZSBudW1iZXIgb2Yg ZGVsaXZlcmllcy4gIFRoYXQgc3VnZ2VzdHMgdGhhdCBmZWVkYmFjayBvY2N1cnMgYXQgc29tZSBs ZXZlbC4NCg0KSSBkb24ndCBrbm93IHdoZXRoZXIgdGhpcyBzb3J0IG9mIHJlcG9ydGluZyBpcyBz b21ldGhpbmcgdGhhdCB3b3VsZCBiZSBwYXJ0IG9mIGEgcmVxdWlyZW1lbnQsIGJ1dCBJJ2xsIHRy eSB0byBmaW5kIG91dC4NCg0KLS1NYXJ0aW4NCg0KT24gMjAxMS0wMS0xNyBhdCAxNDoyMDozNywg QXJ0IEJvdHRlcmVsbCB3cm90ZToNCj4gTWFpbmx5IEkgd2FzIGp1c3Qgc3VnZ2VzdGluZyBvbmUg d2F5IG9mIGxvb2tpbmcgYXQgdGhlICJob3cgbGFyZ2UgaXMNCj4gJ2xhcmdlJyIgcXVlc3Rpb24u ICBBbHRob3VnaCBpdCBkb2VzIGhpZ2hsaWdodCBzb21lIG9mIE1hcnRpbidzDQo+IHF1ZXN0aW9u cyBhYm91dCBob3cgdG8gYWRhcHQgYSBzZXNzaW9uIGluaXRpYXRpb24gcHJvdG9jb2wgdG8gYSBv bmUtdG8tDQo+IHZlcnktbWFueSBhcHBsaWNhdGlvbiwgaWYgdGhhdCdzIHdoYXQgd2UgaGF2ZSBp biBtaW5kLiAgQXMgaGUgcmlnaHRseQ0KPiBwb2ludHMgb3V0LCByZXNwb25zZXMgZG9uJ3Qgb25s eSBoYXBwZW4gYXQgdGhlIGFwcGxpY2F0aW9uIGxldmVsLg0KPiANCj4gVGhhbmtzIQ0KPiANCj4g LSBBcnQNCj4gDQo+IE9uIEphbiAxNiwgMjAxMSwgYXQgMTE6MjIgQU0sIEhhbm5lcyBUc2Nob2Zl bmlnDQo+IDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90ZToNCj4gDQo+ID4gSGkgQXJ0 LA0KPiA+DQo+ID4gdGhhdCdzIGFuIGludGVyZXN0aW5nIGNvbW1lbnQgcGFydGljdWxhcmx5IHNp bmNlIHdlIGRvIG5vdCBoYXZlIGENCj4gcmVxdWlyZW1lbnQgZm9yIHJlc3BvbnNlcyBieSByZWNl aXZlcnMgKG9yIFJlY2lwaWVudHMpIG9mIGFsZXJ0DQo+IG1lc3NhZ2VzLiBJIGFtIG5vdCBzdXJl IHRvIHdob20gdGhleSB3b3VsZCBzZW50IHRoZWlyIHJlc3BvbnNlIHRvLiBUbw0KPiB0aGUgb3Jp Z2luYXRvciwgdG8gc29tZSBnYXRld2F5LCBldGM/DQo+ID4NCj4gPiBDaWFvDQo+ID4gSGFubmVz DQo+ID4NCj4gPiBPbiBKYW4gMTUsIDIwMTEsIGF0IDExOjU4IFBNLCBBcnQgQm90dGVyZWxsIHdy b3RlOg0KPiA+DQo+ID4+IE9uZSBkaWZmZXJlbmNlIGluICJicm9hZGNhc3QiIGRlbGl2ZXJ5IGlz IHRoYXQgaXQncyBmcmVxdW50bHkNCj4gaW1wcmFjdGljYWwgYW5kL29yIHVuZGVzaXJhYmxlIHRv IHRyeSB0byB0cmFjayBpbmRpdmlkdWFsIGRlbGl2ZXJpZXMgb3INCj4gcHJvY2VzcyBpbmRpdmlk dWFsIHJlc3BvbnNlcy4NCj4gPj4NCj4gPj4gVGhhbmtzIQ0KPiA+Pg0KPiA+PiAtIEFydA0KPiA+ Pg0KPiA+PiBPbiBKYW4gMTUsIDIwMTEsIGF0IDExOjMwIEFNLCBIYW5uZXMgVHNjaG9mZW5pZw0K PiA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4gd3JvdGU6DQo+ID4+DQo+ID4+PiBIaSBhbGws DQo+ID4+Pg0KPiA+Pj4gZHVyaW5nIHRoZSBBVE9DQSBtZWV0aW5nIGF0IElFVEYjNzkgSWdvciBy YWlzZWQgYSBxdWVzdGlvbg0KPiByZWdhcmRpbmcgcmVxdWlyZW1lbnQgRDI6DQo+ID4+PiAiDQo+ ID4+PiBSZXEtRDI6DQo+ID4+Pg0KPiA+Pj4gICAgVGhlIHByb3RvY29sIHNvbHV0aW9uIE1VU1Qg YWxsb3cgZGVsaXZlcnkgb2YgbWVzc2FnZXMNCj4gPj4+ICAgIHNpbXVsdGFuZW91c2x5IHRvIGEg bGFyZ2UgYXVkaWVuY2UuDQo+ID4+PiAiDQo+ID4+Pg0KPiA+Pj4gSGUgd2FzIGFza2luZyB3aGV0 aGVyIHRoZXJlIGlzIGEgbmVlZCB0byBwdXQgYSBudW1iZXIgZm9yIGxhcmdlDQo+IGF1ZGllbmNl IHRoZXJlLg0KPiA+Pj4NCj4gPj4+IE1heWJlIElnb3IgaGFzIGEgc3BlY2lmaWMgbnVtYmVyIGlu IG1pbmQgdGhhdCB3b3VsZCBtYXR0ZXIgZnJvbSBhDQo+IHByb3RvY29sIGRlc2lnbiBwZXJzcGVj dGl2ZSBidXQgSSBkbyBub3QgaGF2ZSBzdWNoIGEgbnVtYmVyIHRoYXQgd291bGQNCj4gcHJvdmlk ZSBhIG1lYW5pbmdmdWwgZGlzdGluY3Rpb24uDQo+ID4+Pg0KPiA+Pj4gVGhlcmUgaXMsIGhvd2V2 ZXIsIHRoZSBxdWVzdGlvbiB3aGF0IHR5cGVzIG9mIHByb2JsZW1zIHdlIGV4cGVjdA0KPiB3aXRo IHZlcnkgbGFyZ2UgbnVtYmVyIG9mIGFsZXJ0IG1lc3NhZ2UgcmVjZWl2ZXJzIGFuZCBob3cgd2Ug ZG9jdW1lbnQNCj4gdGhpcyBhc3BlY3QgaW4gdGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudC4NCj4g Pj4+DQo+ID4+PiBTdWdnZXN0aW9ucz8gVGhvdWdodHM/DQo+ID4+Pg0KPiA+Pj4gQ2lhbw0KPiA+ Pj4gSGFubmVzDQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4+IGVhcmx5d2FybmluZyBtYWlsaW5nIGxpc3QNCj4gPj4+IGVh cmx5d2FybmluZ0BpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9lYXJseXdhcm5pbmcNCj4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBlYXJseXdhcm5pbmcgbWFpbGluZyBsaXN0DQo+IGVhcmx5 d2FybmluZ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Vhcmx5d2FybmluZw0KDQoNCg== From BD2985@att.com Sun Jan 16 22:22:25 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B33283A6E7B for ; Sun, 16 Jan 2011 22:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.51 X-Spam-Level: X-Spam-Status: No, score=-104.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN2-hztRVYAU for ; Sun, 16 Jan 2011 22:22:23 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 18B653A6E75 for ; Sun, 16 Jan 2011 22:22:22 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: BD2985@att.com X-Msg-Ref: server-14.tower-146.messagelabs.com!1295245494!31663588!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 21283 invoked from network); 17 Jan 2011 06:24:55 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-14.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Jan 2011 06:24:55 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p0H6OsjJ005038; Mon, 17 Jan 2011 00:24:54 -0600 Received: from td03xsmtp005.US.Cingular.Net (td03xsmtp005.us.cingular.net [135.179.64.44]) by tlph064.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p0H6Om0I004966; Mon, 17 Jan 2011 00:24:48 -0600 Received: from bd01xsmtp004.US.Cingular.Net ([135.163.18.45]) by td03xsmtp005.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 00:24:48 -0600 Received: from BD01MSXMB016.US.Cingular.Net ([135.214.27.50]) by bd01xsmtp004.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Jan 2011 22:24:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 16 Jan 2011 22:24:46 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Atoca] Language and Media Type Thread-Index: AQKwAdYj/uAV0fN1Gt7Mi4f1EUG7oAJHmEn7kfls9sCAAHEU4Q== From: "DALY, BRIAN K (ATTCINW)" To: , X-OriginalArrivalTime: 17 Jan 2011 06:24:47.0800 (UTC) FILETIME=[3D377380:01CBB60F] Subject: Re: [Atoca] Language and Media Type X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 06:22:25 -0000 QWN0dWFsbHkgdGhlIGxhbmd1YWdlIGlzc3VlIGlzIGV4dHJlbWVseSBjb21wbGV4LiBJbiBhIGNp dHkgc3VjaCBhcyBTYW4gRnJhbmNpc2NvLCB0aGVyZSBjb3VsZCBiZSAxNSwgMjAgb3IgbW9yZSBs YW5ndWFnZXMgcmVxdWlyaW5nIGEgbnVtYmVyIG9mIGRpZmZlcmVudCBjaGFyYWN0ZXIgc2V0cyAo MTYpLiBUaGUgRkNDIENNU0FBQyBzdHVkaWVkIHRoaXMgaXNzdWUgYW5kIGNvbmNsdWRlZCB0aGF0 IHVudGlsIGEgbmF0aW9uYWwgcG9saWN5IGlzIGRldmVsb3BlZCwgb25seSBvbmUgbGFuZ3VhZ2Ug d291bGQgYmUgdXNlZCBmb3Igbm93Lg0KQnJpYW4gSy4gRGFseQ0KICAgU2VudCB0byB5b3UgYnkg QVQmVC4uLiANCiAgIEFtZXJpY2EncyBGYXN0ZXN0IE1vYmlsZSBCcm9hZGJhbmQNCiAgICAgICBO ZXR3b3JrLiAgUmV0aGluayBQb3NzaWJsZS4NCiAgICsxLjQyNS41ODAuNjg3Mw0KLS0tLS0tLQ0K U2VudCBmcm9tIG15IEJsYWNrYmVycnkNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0K RnJvbTogZWFybHl3YXJuaW5nLWJvdW5jZXNAaWV0Zi5vcmcgPGVhcmx5d2FybmluZy1ib3VuY2Vz QGlldGYub3JnPg0KVG86IGVhcmx5d2FybmluZ0BpZXRmLm9yZyA8ZWFybHl3YXJuaW5nQGlldGYu b3JnPg0KU2VudDogU3VuIEphbiAxNiAxNjoyMDoxNyAyMDExDQpTdWJqZWN0OiBSZTogW0F0b2Nh XSBMYW5ndWFnZSBhbmQgTWVkaWEgVHlwZQ0KDQpIaQ0KDQoNClN3aXR6ZXJsYW5kIGlzIGEgJ3dv cnN0IGNhc2Ugc2NlbmFyaW8nIGV4YW1wbGUsQnkgbGF3IHRoZXkgbmVlZCB0byB0cmFuc21pdA0K aW4gR2VybWFuLCBGcmVuY2gsIEl0YWxpYW4gYW5kICJSb21hbnNoZSIuIFRoZXkgd2lsbCBhbHNv IHByb2JhYmx5IHRyYW5zbWl0DQppbiBFbmdsaXNoIGFzIHdlbGwgdG8gcmVhY2ggdG91cmlzdHMs IGVzcGVjaWFsbHkgYXQgYWlycG9ydHMuIA0KDQpUaGVyZSBtYXkgYmUgb3RoZXIgc3BlY2lhbCBj YXNlcyBzdWNoIGFzIEphcGFuZXNlIGluIFplcm1hdCwgd2hlcmUgbGFyZ2UNCmdyb3VwcyBvZiBK YXBhbmVzZSBvZnRlbiBjb25ncmVnYXRlLiANCg0KSSBleHBlY3QgdGhlcmUgdG8gYmUgdmVyeSBm ZXcgY2FzZXMgd2hlcmUgbW9yZSB0aGFuIGhhbGYgYSBkb3plbiBsYW5ndWFnZXMNCndvdWxkIGJl IHNlbnQgZm9yIGVhY2ggYWxlcnQgbWVzc2FnZSwgdGhvdWdoIGNpdmljIGluZm9ybWF0aW9uIG1l c3NhZ2VzIGFyZQ0KYSBkaWZmZXJlbnQgbWF0dGVyIGFuZCBtYXkgZWl0aGVyIGJlIGxhbmd1YWdl IHNwZWNpZmljIG9yIGluIHNvbWUgY2FzZXMgc2VudA0KaW4gYSBkb3plbiBsYW5ndWFnZXMuIEhv d2V2ZXIgaW5mb3JtYXRpb24gbWVzc2FnZXMgYXJlIG11Y2ggbGVzcyB0aW1lDQpjcml0aWNhbCB0 aGFuIGFsZXJ0IG1lc3NhZ2VzIHNvIHNvbWUgZXh0cmEgZGVsYXkgaXMgdG9sZXJhYmxlLiAgDQoN ClRoZSBtYXR0ZXIgb2YgbGFuZ3VhZ2UgaXMgYSB2ZXJ5IGhvdGx5IHNlbnNpdGl2ZSBvbmUgaW4g bWFueSByZWdpb25zLiBGb3INCmV4YW1wbGUsIGluIFdhbGVzIHlvdSBtdXN0IHNlbmQgb2ZmaWNp YWwgY29tbXVuaWNhdGlvbnMgIGluIFdlbHNoIGFuZA0KRW5nbGlzaCwgZXZlbiB0aG91Z2ggbW9z dCBXZWxzaCBzcGVhayBnb29kIEVuZ2xpc2guIFRoaXMgcHJvYmxlbSBpcyB2ZXJ5DQpzZW5zaXRp dmUgaW5kZWVkIGluIG1hbnkgcGFydHMgb2YgdGhlIHdvcmxkLCB0byBzdWNoIGFuIGV4dGVudCB0 aGF0IGENCnNvbHV0aW9uIHRoYXQgZG9lcyBub3QgaGF2ZSBzb21lIHNvbHV0aW9uIHRvIG11bHRp cGxlIGxhbmd1YWdlcyBpcyBhDQpub24tc3RhcnRlciBkdWUgdG8gdGhlIHBvbGl0aWNhbCBoZWF0 IGl0IHdvdWxkIGNhdXNlIGlmIGFueW9uZSBpbiB0aGUgb3RoZXINCmV0aG5pYyBncm91cCBkaWVk IGR1ZSB0byBub3QgZ2V0dGluZyBhIG1lc3NhZ2UuIENvbnZlcnNlbHksIHBvbGl0aWNpYW5zIGxp a2UNCnRoZSBpZGVhIG9mIGJlaW5nIGFibGUgdG8gcmVhY2ggb3V0IHRvIGV0aG5pYyBncm91cHMg aW4gdGhpcyB3YXkgYXMgYSB3YXkgb2YNCmJ1aWxkaW5nIHRydXN0LCB0aGlzIGlzIHdoeSBhbG1v c3QgYWxsIG9mIHRoZW0gaW5zaXN0IG9uIGEgbXVsdGktbGFuZ3VhZ2UNCmNhcGFiaWxpdHkgZnJv bSB0aGUgc3RhcnQuIA0KDQogSW4gc29tZSBjYXNlcyBpbmRpZ2Vub3VzIHBvcHVsYXRpb25zIHRl eHQgZWFjaCBvdGhlciBpbiBhICdMYXRpbml6ZWQgZm9udA0KdmVyc2lvbicgb2YgdGhlaXIgb3du IGxhbmd1YWdlLiBUaGVyZWZvcmUgdGhlIHByb2JsZW0gb2YgZm9udHMgaXMgbm90IGFsd2F5cw0K YXMgYmlnIGEgcHJvYmxlbSBhcyB3ZSBtYXkgdGhpbmssIGJ1dCBjbGVhcmx5IGEgbW9yZSBjYXBh YmxlIHJvYWRtYXAgaXMNCm5lZWRlZCBpbiB0aGUgZnV0dXJlLiANCg0KDQpJbiBDZWxsIEJyb2Fk Y2FzdCwgZm9yIGV4YW1wbGUsIHdlIGFyZSBwcm9wb3NpbmcgYXQgbGVhc3QgdGhyZWUgZGlmZmVy ZW50DQptZWNoYW5pc21zIGZvciBkaXN0aW5ndWlzaGluZyBvbmUgZnJvbSB0aGUgb3RoZXIsIGJl Y2F1c2UgYSBjbGVhciB3aW5uZXIgaGFzDQpub3QgYXBwZWFyZWQgeWV0IGFuZCB0aGUgZGViYXRl IGlzIHZlcnkgY29udGVudGlvdXMuIFZlcnkgbGlrZWx5LCBhdCBzb21lDQpwb2ludCwgYSBjbGVh ciB3aW5uZXIgd2lsbCBlbWVyZ2UgYW5kIEkgaG9wZSBvbmx5IG9uZSAgbWVjaGFuaXNtIHdpbGwN CnN1ZmZpY2UuIE1lYW50aW1lLCBnb3Zlcm5tZW50cyBhcmUgd2FudGluZyB0byBrZWVwIHRoZWly IG9wdGlvbnMgb3BlbiBzbw0KdGhpcyBpcyB3aHkgdGhleSBhcmUgcHJvcG9zaW5nIGFsbCB0aHJl ZSBtZWNoYW5pc21zIGluIHBhcmFsbGVsIGZvciBub3csIGZvcg0KbGF0ZXIgcmV2aWV3LiAgQmVj YXVzZSB0aGUgbWF0dGVyIGlzIG5vdyBzZWVuIGFzIHVyZ2VudCwgdGhleSB3b3VsZCByYXRoZXIN CnN0YXJ0IG5vdyB3aXRoIHNvbWV0aGluZyBpbXBlcmZlY3QgdGhhbiB3YWl0IGZvciB0aGUgcGVy ZmVjdCBzb2x1dGlvbiB0bw0KZXZlbnR1YWxseSBhcHBlYXIgYmVmb3JlIG1ha2luZyBhIG1vdmUu IA0KDQpXYXJtIFJlZ2FyZHMsIE1hcmsgV29vZCBEUkNGLiANCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBlYXJseXdhcm5pbmctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OmVhcmx5d2FybmluZy1ib3VuY2VzQGlldGYub3JnXQ0KT24gQmVoYWxmIE9mIFRob21zb24sIE1h cnRpbg0KU2VudDogU3VuZGF5LCBKYW51YXJ5IDE2LCAyMDExIDExOjA4IFBNDQpUbzogSGFubmVz IFRzY2hvZmVuaWc7IGVhcmx5d2FybmluZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBdG9jYV0g TGFuZ3VhZ2UgYW5kIE1lZGlhIFR5cGUNCg0KT24gMjAxMS0wMS0xNiBhdCAwNjozMDoxMSwgSGFu bmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+IEtlZXBpbmcgTGkgKGlmIHRoZSBtZWV0aW5nIG1pbnV0 ZXMgcmVmbGVjdCBoaXMgbmFtZSBjb3JyZWN0bHkpIG5vdGljZWQgDQo+IHRoYXQgd2UgaGFkIGEg bGFuZ3VhZ2UgcmVxdWlyZW1lbnQgaW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCBidXQgDQo+IHBy b3ZpZGVkIG5vIGNvcnJlc3BvbmRpbmcgc29sdXRpb24gaW4gdGhlIFNJUC1DQVAgZG9jdW1lbnQu DQoNCkEgc29sdXRpb24gZG9lcyBzZWVtIGRlc2lyYWJsZS4gIFRob3VnaCBJIHN1c3BlY3QgdGhh dCBtYW55IGFsZXJ0aW5nIHN5c3RlbXMNCndpbGwgYmUgZGVwbG95ZWQgd2l0aCBvbmUgbGFuZ3Vh Z2Ugb3Igd2l0aCBhbGwgb2YgdGhlIHNtYWxsIG51bWJlciBvZg0KIm9mZmljaWFsIiBvciAic3Vw cG9ydGVkIiBsYW5ndWFnZXMgcHJlc2VudCBpbiB0aGUgbWVzc2FnZS4gIFRoaXMgaXMNCnByb2Jh Ymx5IGdvaW5nIHRvIGJlIG5lY2Vzc2FyeSBmb3IgYWxsICJpbXBsaWNpdCIgc3Vic2NyaXB0aW9u cyBhbnlob3cuDQoNCkluIEhUVFAtbGFuZCwgdGhlIEFjY2VwdC1MYW5ndWFnZSBoZWFkZXIgaXMg dXNlZCBmb3IgdGhhdCBzb3J0IG9mIHRoaW5nLg0KVGhlIGhlYWRlciBpcyBwcmVzZW50IGluIFNJ UCwgYnV0IGl0J3MgdXNlIHNlZW1zIGxpbWl0ZWQgLSBhbmQgd2hhdCBldmlkZW5jZQ0KSSBoYXZl IHN1cHBvcnRzIHRoZSBub3Rpb24gdGhhdCBtb3N0IHNlcnZlcnMgaWdub3JlIGl0Lg0KDQpXZSBj b3VsZCBkZWZpbmUgYSB1c2UgZm9yIEFjY2VwdC1MYW5ndWFnZSBhbmQgc2VlIGhvdyB0aGF0IGZs aWVzLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ZWFybHl3YXJuaW5nIG1haWxpbmcgbGlzdA0KZWFybHl3YXJuaW5nQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vhcmx5d2FybmluZw0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZWFybHl3YXJuaW5nIG1haWxp bmcgbGlzdA0KZWFybHl3YXJuaW5nQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Vhcmx5d2FybmluZw0K From BD2985@att.com Sun Jan 16 22:29:13 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0492D3A6E7D for ; Sun, 16 Jan 2011 22:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.555 X-Spam-Level: X-Spam-Status: No, score=-105.555 tagged_above=-999 required=5 tests=[AWL=1.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqTb85bKsffZ for ; Sun, 16 Jan 2011 22:29:11 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id A377F3A6E7B for ; Sun, 16 Jan 2011 22:29:11 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: BD2985@att.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1295245904!2642927!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 32067 invoked from network); 17 Jan 2011 06:31:44 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-14.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Jan 2011 06:31:44 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p0H6VhjT017308; Mon, 17 Jan 2011 00:31:43 -0600 Received: from td03xsmtp005.US.Cingular.Net (td03xsmtp005.us.cingular.net [135.179.64.44]) by tlph064.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p0H6VdKk017279; Mon, 17 Jan 2011 00:31:39 -0600 Received: from BD01XSMTP003.US.Cingular.Net ([135.163.18.44]) by td03xsmtp005.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 00:31:39 -0600 Received: from BD01MSXMB016.US.Cingular.Net ([135.214.27.50]) by BD01XSMTP003.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Jan 2011 22:31:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 16 Jan 2011 22:31:38 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Atoca] Requirement D2: "Large Audience" Thread-Index: Acu10Mo2lXT0+8UrT26QUiqTkoDwugAP2fwY From: "DALY, BRIAN K (ATTCINW)" To: , X-OriginalArrivalTime: 17 Jan 2011 06:31:39.0132 (UTC) FILETIME=[3263BBC0:01CBB610] Cc: igor.faynberg@alcatel-lucent.com, earlywarning@ietf.org Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 06:29:13 -0000 SWYgaXQgaXMgYnJvYWRjYXN0IHRoZW4gbm8gbnVtYmVyIGlzIHJlcXVpcmVkLg0KDQpJZiBzb21l IHJlc3BvbnNlIGlzIHJlcXVpcmVkIHRoZW4gaXQgYmVjb21lcyBhY2Nlc3MgbmV0d29yayBkZXBl bmRlbnQuDQpCcmlhbiBLLiBEYWx5DQogICBTZW50IHRvIHlvdSBieSBBVCZULi4uIA0KICAgQW1l cmljYSdzIEZhc3Rlc3QgTW9iaWxlIEJyb2FkYmFuZA0KICAgICAgIE5ldHdvcmsuICBSZXRoaW5r IFBvc3NpYmxlLg0KICAgKzEuNDI1LjU4MC42ODczDQotLS0tLS0tDQpTZW50IGZyb20gbXkgQmxh Y2tiZXJyeQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBlYXJseXdhcm5p bmctYm91bmNlc0BpZXRmLm9yZyA8ZWFybHl3YXJuaW5nLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzog SGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+DQpDYzogSWdvciBG YXluYmVyZyA8aWdvci5mYXluYmVyZ0BhbGNhdGVsLWx1Y2VudC5jb20+OyBlYXJseXdhcm5pbmdA aWV0Zi5vcmcgPGVhcmx5d2FybmluZ0BpZXRmLm9yZz4NClNlbnQ6IFNhdCBKYW4gMTUgMTM6NTg6 MTQgMjAxMQ0KU3ViamVjdDogUmU6IFtBdG9jYV0gUmVxdWlyZW1lbnQgRDI6ICJMYXJnZSBBdWRp ZW5jZSINCg0KT25lIGRpZmZlcmVuY2UgaW4gImJyb2FkY2FzdCIgZGVsaXZlcnkgaXMgdGhhdCBp dCdzIGZyZXF1bnRseSBpbXByYWN0aWNhbCBhbmQvb3IgdW5kZXNpcmFibGUgdG8gdHJ5IHRvIHRy YWNrIGluZGl2aWR1YWwgZGVsaXZlcmllcyBvciBwcm9jZXNzIGluZGl2aWR1YWwgcmVzcG9uc2Vz Lg0KDQpUaGFua3MhDQoNCi0gQXJ0DQoNCk9uIEphbiAxNSwgMjAxMSwgYXQgMTE6MzAgQU0sIEhh bm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90ZToNCg0KPiBI aSBhbGwsIA0KPiANCj4gZHVyaW5nIHRoZSBBVE9DQSBtZWV0aW5nIGF0IElFVEYjNzkgSWdvciBy YWlzZWQgYSBxdWVzdGlvbiByZWdhcmRpbmcgcmVxdWlyZW1lbnQgRDI6DQo+ICINCj4gICBSZXEt RDI6DQo+IA0KPiAgICAgIFRoZSBwcm90b2NvbCBzb2x1dGlvbiBNVVNUIGFsbG93IGRlbGl2ZXJ5 IG9mIG1lc3NhZ2VzDQo+ICAgICAgc2ltdWx0YW5lb3VzbHkgdG8gYSBsYXJnZSBhdWRpZW5jZS4N Cj4gIg0KPiANCj4gSGUgd2FzIGFza2luZyB3aGV0aGVyIHRoZXJlIGlzIGEgbmVlZCB0byBwdXQg YSBudW1iZXIgZm9yIGxhcmdlIGF1ZGllbmNlIHRoZXJlLg0KPiANCj4gTWF5YmUgSWdvciBoYXMg YSBzcGVjaWZpYyBudW1iZXIgaW4gbWluZCB0aGF0IHdvdWxkIG1hdHRlciBmcm9tIGEgcHJvdG9j b2wgZGVzaWduIHBlcnNwZWN0aXZlIGJ1dCBJIGRvIG5vdCBoYXZlIHN1Y2ggYSBudW1iZXIgdGhh dCB3b3VsZCBwcm92aWRlIGEgbWVhbmluZ2Z1bCBkaXN0aW5jdGlvbi4gDQo+IA0KPiBUaGVyZSBp cywgaG93ZXZlciwgdGhlIHF1ZXN0aW9uIHdoYXQgdHlwZXMgb2YgcHJvYmxlbXMgd2UgZXhwZWN0 IHdpdGggdmVyeSBsYXJnZSBudW1iZXIgb2YgYWxlcnQgbWVzc2FnZSByZWNlaXZlcnMgYW5kIGhv dyB3ZSBkb2N1bWVudCB0aGlzIGFzcGVjdCBpbiB0aGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50LiAN Cj4gDQo+IFN1Z2dlc3Rpb25zPyBUaG91Z2h0cz8gDQo+IA0KPiBDaWFvDQo+IEhhbm5lcw0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZWFy bHl3YXJuaW5nIG1haWxpbmcgbGlzdA0KPiBlYXJseXdhcm5pbmdAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lYXJseXdhcm5pbmcNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQplYXJseXdhcm5pbmcgbWFpbGlu ZyBsaXN0DQplYXJseXdhcm5pbmdAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWFybHl3YXJuaW5nDQo= From BD2985@att.com Sun Jan 16 22:31:56 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310733A6E7E for ; Sun, 16 Jan 2011 22:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.077 X-Spam-Level: X-Spam-Status: No, score=-106.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgUyeJuIUQKL for ; Sun, 16 Jan 2011 22:31:52 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 047E33A6E7B for ; Sun, 16 Jan 2011 22:31:51 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: BD2985@att.com X-Msg-Ref: server-14.tower-129.messagelabs.com!1295246064!34697765!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 32576 invoked from network); 17 Jan 2011 06:34:24 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-14.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Jan 2011 06:34:24 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p0H6YNis021917; Mon, 17 Jan 2011 00:34:23 -0600 Received: from td03xsmtp007.US.Cingular.Net (TD03XSMTP007.us.cingular.net [135.179.64.45]) by tlph064.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p0H6YJiY021864; Mon, 17 Jan 2011 00:34:19 -0600 Received: from BD01XSMTP003.US.Cingular.Net ([135.163.18.44]) by td03xsmtp007.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 00:34:19 -0600 Received: from BD01MSXMB016.US.Cingular.Net ([135.214.27.50]) by BD01XSMTP003.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Jan 2011 22:34:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 16 Jan 2011 22:34:18 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Atoca] Requirement for Originator Authentication? Thread-Index: Acu06rVOLwvhgOa0T5WSS8cq4sczfAA5M37gABBDhy0= From: "DALY, BRIAN K (ATTCINW)" To: , , , X-OriginalArrivalTime: 17 Jan 2011 06:34:18.0934 (UTC) FILETIME=[91A39560:01CBB610] Subject: Re: [Atoca] Requirement for Originator Authentication? X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 06:31:57 -0000 QXV0aG9yaXphdGlvbiB0byBpbml0aWF0ZSBhbGVydHMgIHNob3VsZCBiZSBwcm92aWRlZCBieSB0 aGUgZW50aXR5IHRoYXQgaXMgaW5pdGlhdGluZyB0aGUgYWxlcnRzIGFuZCBub3QgQVRPQ0EuIEFU T0NBIHNob3VsZCBhdXRoZW50aWNhdGUgdGhlIHJlY2VpcHQgb2YgdGhlIGFsZXJ0cyBpcyBmcm9t IGEgdHJ1c3RlZCBzb3VyY2UuDQpCcmlhbiBLLiBEYWx5DQogICBTZW50IHRvIHlvdSBieSBBVCZU Li4uIA0KICAgQW1lcmljYSdzIEZhc3Rlc3QgTW9iaWxlIEJyb2FkYmFuZA0KICAgICAgIE5ldHdv cmsuICBSZXRoaW5rIFBvc3NpYmxlLg0KICAgKzEuNDI1LjU4MC42ODczDQotLS0tLS0tDQpTZW50 IGZyb20gbXkgQmxhY2tiZXJyeQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9t OiBlYXJseXdhcm5pbmctYm91bmNlc0BpZXRmLm9yZyA8ZWFybHl3YXJuaW5nLWJvdW5jZXNAaWV0 Zi5vcmc+DQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+ OyBlYXJseXdhcm5pbmdAaWV0Zi5vcmcgPGVhcmx5d2FybmluZ0BpZXRmLm9yZz47IElnb3IgRmF5 bmJlcmcgPGlnb3IuZmF5bmJlcmdAYWxjYXRlbC1sdWNlbnQuY29tPg0KU2VudDogU3VuIEphbiAx NiAxNTozMjowOSAyMDExDQpTdWJqZWN0OiBSZTogW0F0b2NhXSBSZXF1aXJlbWVudCBmb3IgT3Jp Z2luYXRvciBBdXRoZW50aWNhdGlvbj8NCg0KT24gMjAxMS0wMS0xNiBhdCAwNjozMDozMywgSGFu bmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+IElnb3IgcmFpc2VkIGFuIGludGVyZXN0aW5nIHF1ZXN0 aW9uIGR1cmluZyB0aGUgbWVldGluZyBpbiBjb250ZXh0IG9mDQo+IHRoZSBzZWN1cml0eSB0aHJl YXRzLCBuYW1lbHk6DQo+IA0KPiAiIERvIHdlIGhhdmUgdGhlIHJlcXVpcmVtZW50IHRvIGF1dGhl bnRpY2F0ZSB0aGUgb3JpZ2luYXRvcj8gIg0KDQpUaGUgcXVlc3Rpb24gdGhhdCBJIGhlYXJkIHdh cyBub3Qgc28gbXVjaCByZWxhdGVkIHRvIGF1dGhlbnRpY2F0aW9uIGFzIGl0IHdhcyB0byBhdXRo b3JpemF0aW9uLiAgVGhlcmUgd2FzIGFsc28gYSBxdWVzdGlvbiBhYm91dCB3aGV0aGVyIGF1dGhl bnRpY2F0aW9uIHdhcyBpZGVudGl0eS1iYXNlZCBvciBvbiBzb21lIG90aGVyIHByb3BlcnR5LCBs aWtlIHNvbWUgYXNzZXJ0ZWQgdHJhaXQuDQoNCldoYXQgc3RhdGVtZW50cyBjYW4gd2UgbWFrZSBh Ym91dCBob3cgcmVjaXBpZW50cyAoYW5kIHJlbGF5cykgYXV0aG9yaXplIHRoZSByZWNlaXB0IChh bmQgc2VuZGluZykgb2YgYWxlcnQgbWVzc2FnZXM/DQogDQo+IEkgY291bGRuJ3QgcHJvdmlkZSBo aW0gYW4gYW5zd2VyIGR1cmluZyB0aGUgbWVldGluZyBiZWNhdXNlIEkgd2FzIG5vdA0KPiBxdWl0 ZSBzdXJlIHdoZXRoZXIgaGUgd2FzIGFza2luZyB0aGUgcXVlc3Rpb24gaW4gdGhlIHN0eWxlIG9m DQo+IA0KPiAiRG8gd2UgbmVlZCBlbmQtdG8tZW5kIHNlY3VyaXR5IG9yIGlzIGEgaG9wLWJ5LWhv cCBzZWN1cml0eSBzb2x1dGlvbg0KPiBnb29kIGVub3VnaD8iDQoNCkluIHRoZSBjb250ZXh0IG9m IHRoaXMgaW50ZXJwcmV0YXRpb24sIEkgdGhpbmsgdGhhdCB0aGVyZSdzIGEgcmVhbCBuZWVkIHRv IGRlbGVnYXRlIGFsZXJ0IGRpc3RyaWJ1dGlvbi4gIFRoZSBzY2FsZSBvZiBkaXN0cmlidXRpb24g bWFrZXMgaW50ZXJtZWRpYXJpZXMgYSB2YWx1YWJsZSBhZGRpdGlvbi4gIFJlbHlpbmcgb24gdGhl IGludGVncml0eSBvZiByZWxheXMgbWFrZXMgdGhlIGF1dGhvcml6YXRpb24gcXVlc3Rpb24gbW9y ZSBkaWZmaWN1bHQgdG8gcmVzb2x2ZS4NCg0KRm9yIHNvbWV0aGluZyBjb25jcmV0ZSwgdGhlIHJl bGF5IGNhc2UgaXMgcHJvYmFibHkgdGhlIHNpbXBsZXN0LiAgSSBtaWdodCB0cnVzdCBteSBzaWdu YWxsaW5nIHBlZXIgdG8gYSBjZXJ0YWluIGV4dGVudC4gIEkgY2VydGFpbmx5IGRvbid0IHRydXN0 IHRoZW0gZW5vdWdoIHRvIGdlbmVyYXRlIHRoZSBtYXNzaXZlIHBhY2tldCBzdG9ybSByZXF1ZXN0 ZWQgYnkgYW4gYWxlcnQgbWVzc2FnZS4gIFRoZXkgbWlnaHQgc2F5IHRoZSBhbGVydCBjb21lcyBm cm9tIHRoZSBnb3Zlcm5tZW50LCBidXQgSSBtaWdodCByZXF1aXJlIGJldHRlciBwcm9vZiB0aGFu IHRoZWlyIHNheS1zbyBhbG9uZS4gIERpc3RyaWJ1dGluZyBhbiBhbGVydCB3aWxsIGNvc3QgbWUg bW9uZXkgYW5kIEkgd2FudCBwcm9vZi4NCg0KVGhhdCdzIG9uZSBhcmd1bWVudC4gIFRoZSBvdGhl ciBhcmd1bWVudCBzYXlzIHRoYXQgcGVlcmluZyByZWxhdGlvbnNoaXBzIHJlcXVpcmUgYSBkZWdy ZWUgb2YgdHJ1c3QgdGhhdCB3b3VsZCBub3QgYmUgYnJva2VuIHdpdGhvdXQgc2VyaW91cyByYW1p ZmljYXRpb25zIC0gZW5vdWdoIHRvIGRpc2NvdXJhZ2UgaXRzIGFidXNlLg0KDQpUaGUgcmVjaXBp ZW50IGNhc2UgbWlnaHQgaGF2ZSBzb21lIGludGVyZXN0aW5nIHF1aXJrcy4gIFBhcnRpY3VsYXJs eSBpbiB3aG9sZXNhbGUvcmVzZWxsZXIgYXJyYW5nZW1lbnRzLiAgQSByZWNpcGllbnQgdGhhdCBy ZWxpZXMgb24gaG9wLWJ5LWhvcCBtaWdodCByZWNlaXZlIGFuIGFsZXJ0IGZyb20gdGhlIG5ldHdv cmsgb3BlcmF0b3I6IGFuIGVudGl0eSB3aXRoIHdob20gdGhleSBoYXZlIG5vIGRpcmVjdCByZWxh dGlvbnNoaXAuICBGb3IgaW5zdGFuY2UsIG5vIGZld2VyIHRoYW4gdHdvIGRpZmZlcmVudCBvcGVy YXRvcnMgYXJlIGludm9sdmVkIGluIGdldHRpbmcgcGFja2V0cyB0byBteSBob3VzZSwgbmVpdGhl ciBvZiB3aGljaCBJIGhhdmUgYSBidXNpbmVzcyByZWxhdGlvbnNoaXAgd2l0aC4gIEhvdyB3b3Vs ZCBzb21lb25lIC0gaWdub3JhbnQgb2YgdGhlIGNvbnZvbHV0ZWQgYnVzaW5lc3MgYXJyYW5nZW1l bnRzIHRoYXQgdW5kZXJwaW4gdGhlaXIgSW50ZXJuZXQgc2VydmljZSAtIGRlY2lkZSB0byBhdXRo b3JpemUgYW4gYWxlcnQgdGhhdCBpcyByZWxheWVkIGJ5IGVpdGhlciBwYXJ0eT8NCg0KLS1NYXJ0 aW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQplYXJs eXdhcm5pbmcgbWFpbGluZyBsaXN0DQplYXJseXdhcm5pbmdAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWFybHl3YXJuaW5nDQo= From BD2985@att.com Sun Jan 16 22:33:31 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C8F3A6E7D for ; Sun, 16 Jan 2011 22:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.251 X-Spam-Level: X-Spam-Status: No, score=-106.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OQYQp33C9w6 for ; Sun, 16 Jan 2011 22:33:28 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id D91713A6E7B for ; Sun, 16 Jan 2011 22:33:27 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: BD2985@att.com X-Msg-Ref: server-13.tower-161.messagelabs.com!1295246160!30297142!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 15263 invoked from network); 17 Jan 2011 06:36:00 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-13.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Jan 2011 06:36:00 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p0H6ZxJM025189; Mon, 17 Jan 2011 00:36:00 -0600 Received: from td03xsmtp008.US.Cingular.Net (td03xsmtp008.us.cingular.net [135.179.64.42]) by tlph064.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p0H6ZqLS024680; Mon, 17 Jan 2011 00:35:52 -0600 Received: from bd01xsmtp004.US.Cingular.Net ([135.163.18.45]) by td03xsmtp008.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 00:35:52 -0600 Received: from BD01MSXMB016.US.Cingular.Net ([135.214.27.50]) by bd01xsmtp004.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Jan 2011 22:35:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 16 Jan 2011 22:35:51 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Atoca] Requirement D2: "Large Audience" Thread-Index: Acu2BF5AO+s86cIvQzGY8TjhOO8dIAAADPpAAAMNqmY= From: "DALY, BRIAN K (ATTCINW)" To: , , X-OriginalArrivalTime: 17 Jan 2011 06:35:51.0824 (UTC) FILETIME=[C9017900:01CBB610] Cc: earlywarning@ietf.org Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 06:33:31 -0000 VGhhdCB3b3VsZCBoYXZlIHRvIGJlIGRlcGVuZGVudCBvbiB0aGUgcmVnaW9uYWwgcmVxdWlyZW1l bnQgYW5kIGRlbGl2ZXJ5IG1lY2hhbmlzbS4gRm9yIGV4YW1wbGUgaW4gdGhlIFVTIGl0IGlzIG5v dCBhIHJlcXVpcmVtZW50IGZvciBFQVMgb3IgQ01BUyBub3IgY2FuIGl0IGJlIHByb3ZpZGVkLg0K QnJpYW4gSy4gRGFseQ0KICAgU2VudCB0byB5b3UgYnkgQVQmVC4uLiANCiAgIEFtZXJpY2EncyBG YXN0ZXN0IE1vYmlsZSBCcm9hZGJhbmQNCiAgICAgICBOZXR3b3JrLiAgUmV0aGluayBQb3NzaWJs ZS4NCiAgICsxLjQyNS41ODAuNjg3Mw0KLS0tLS0tLQ0KU2VudCBmcm9tIG15IEJsYWNrYmVycnkN Cg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogZWFybHl3YXJuaW5nLWJvdW5j ZXNAaWV0Zi5vcmcgPGVhcmx5d2FybmluZy1ib3VuY2VzQGlldGYub3JnPg0KVG86IEFydCBCb3R0 ZXJlbGwgPGFydGJvdHRlcmVsbEBnbWFpbC5jb20+OyBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVz LnRzY2hvZmVuaWdAZ214Lm5ldD4NCkNjOiBlYXJseXdhcm5pbmdAaWV0Zi5vcmcgPGVhcmx5d2Fy bmluZ0BpZXRmLm9yZz4NClNlbnQ6IFN1biBKYW4gMTYgMjE6MTI6MDUgMjAxMQ0KU3ViamVjdDog UmU6IFtBdG9jYV0gUmVxdWlyZW1lbnQgRDI6ICJMYXJnZSBBdWRpZW5jZSINCg0KSW50ZXJlc3Rp bmcgdGlkYml0IGZyb20gdGhlIEF1c3RyYWxpYW4gd2FybmluZyBzeXN0ZW0gZGlzY3Vzc2lvbnM6 IHRoZSBvcmlnaW5hdGluZyBzeXN0ZW1zICh0aGUgZmlyc3QgcmVsYXkpIHByb3ZpZGVzIGEgcmVw b3J0IHRvIHRoZSBlbWVyZ2VuY3kgYXV0aG9yaXR5IG9uIHRoZSBudW1iZXIgb2YgZGVsaXZlcmll cy4gIFRoYXQgc3VnZ2VzdHMgdGhhdCBmZWVkYmFjayBvY2N1cnMgYXQgc29tZSBsZXZlbC4NCg0K SSBkb24ndCBrbm93IHdoZXRoZXIgdGhpcyBzb3J0IG9mIHJlcG9ydGluZyBpcyBzb21ldGhpbmcg dGhhdCB3b3VsZCBiZSBwYXJ0IG9mIGEgcmVxdWlyZW1lbnQsIGJ1dCBJJ2xsIHRyeSB0byBmaW5k IG91dC4NCg0KLS1NYXJ0aW4NCg0KT24gMjAxMS0wMS0xNyBhdCAxNDoyMDozNywgQXJ0IEJvdHRl cmVsbCB3cm90ZToNCj4gTWFpbmx5IEkgd2FzIGp1c3Qgc3VnZ2VzdGluZyBvbmUgd2F5IG9mIGxv b2tpbmcgYXQgdGhlICJob3cgbGFyZ2UgaXMNCj4gJ2xhcmdlJyIgcXVlc3Rpb24uICBBbHRob3Vn aCBpdCBkb2VzIGhpZ2hsaWdodCBzb21lIG9mIE1hcnRpbidzDQo+IHF1ZXN0aW9ucyBhYm91dCBo b3cgdG8gYWRhcHQgYSBzZXNzaW9uIGluaXRpYXRpb24gcHJvdG9jb2wgdG8gYSBvbmUtdG8tDQo+ IHZlcnktbWFueSBhcHBsaWNhdGlvbiwgaWYgdGhhdCdzIHdoYXQgd2UgaGF2ZSBpbiBtaW5kLiAg QXMgaGUgcmlnaHRseQ0KPiBwb2ludHMgb3V0LCByZXNwb25zZXMgZG9uJ3Qgb25seSBoYXBwZW4g YXQgdGhlIGFwcGxpY2F0aW9uIGxldmVsLg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gLSBBcnQNCj4g DQo+IE9uIEphbiAxNiwgMjAxMSwgYXQgMTE6MjIgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnDQo+IDxo YW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90ZToNCj4gDQo+ID4gSGkgQXJ0LA0KPiA+DQo+ ID4gdGhhdCdzIGFuIGludGVyZXN0aW5nIGNvbW1lbnQgcGFydGljdWxhcmx5IHNpbmNlIHdlIGRv IG5vdCBoYXZlIGENCj4gcmVxdWlyZW1lbnQgZm9yIHJlc3BvbnNlcyBieSByZWNlaXZlcnMgKG9y IFJlY2lwaWVudHMpIG9mIGFsZXJ0DQo+IG1lc3NhZ2VzLiBJIGFtIG5vdCBzdXJlIHRvIHdob20g dGhleSB3b3VsZCBzZW50IHRoZWlyIHJlc3BvbnNlIHRvLiBUbw0KPiB0aGUgb3JpZ2luYXRvciwg dG8gc29tZSBnYXRld2F5LCBldGM/DQo+ID4NCj4gPiBDaWFvDQo+ID4gSGFubmVzDQo+ID4NCj4g PiBPbiBKYW4gMTUsIDIwMTEsIGF0IDExOjU4IFBNLCBBcnQgQm90dGVyZWxsIHdyb3RlOg0KPiA+ DQo+ID4+IE9uZSBkaWZmZXJlbmNlIGluICJicm9hZGNhc3QiIGRlbGl2ZXJ5IGlzIHRoYXQgaXQn cyBmcmVxdW50bHkNCj4gaW1wcmFjdGljYWwgYW5kL29yIHVuZGVzaXJhYmxlIHRvIHRyeSB0byB0 cmFjayBpbmRpdmlkdWFsIGRlbGl2ZXJpZXMgb3INCj4gcHJvY2VzcyBpbmRpdmlkdWFsIHJlc3Bv bnNlcy4NCj4gPj4NCj4gPj4gVGhhbmtzIQ0KPiA+Pg0KPiA+PiAtIEFydA0KPiA+Pg0KPiA+PiBP biBKYW4gMTUsIDIwMTEsIGF0IDExOjMwIEFNLCBIYW5uZXMgVHNjaG9mZW5pZw0KPiA8aGFubmVz LnRzY2hvZmVuaWdAZ214Lm5ldD4gd3JvdGU6DQo+ID4+DQo+ID4+PiBIaSBhbGwsDQo+ID4+Pg0K PiA+Pj4gZHVyaW5nIHRoZSBBVE9DQSBtZWV0aW5nIGF0IElFVEYjNzkgSWdvciByYWlzZWQgYSBx dWVzdGlvbg0KPiByZWdhcmRpbmcgcmVxdWlyZW1lbnQgRDI6DQo+ID4+PiAiDQo+ID4+PiBSZXEt RDI6DQo+ID4+Pg0KPiA+Pj4gICAgVGhlIHByb3RvY29sIHNvbHV0aW9uIE1VU1QgYWxsb3cgZGVs aXZlcnkgb2YgbWVzc2FnZXMNCj4gPj4+ICAgIHNpbXVsdGFuZW91c2x5IHRvIGEgbGFyZ2UgYXVk aWVuY2UuDQo+ID4+PiAiDQo+ID4+Pg0KPiA+Pj4gSGUgd2FzIGFza2luZyB3aGV0aGVyIHRoZXJl IGlzIGEgbmVlZCB0byBwdXQgYSBudW1iZXIgZm9yIGxhcmdlDQo+IGF1ZGllbmNlIHRoZXJlLg0K PiA+Pj4NCj4gPj4+IE1heWJlIElnb3IgaGFzIGEgc3BlY2lmaWMgbnVtYmVyIGluIG1pbmQgdGhh dCB3b3VsZCBtYXR0ZXIgZnJvbSBhDQo+IHByb3RvY29sIGRlc2lnbiBwZXJzcGVjdGl2ZSBidXQg SSBkbyBub3QgaGF2ZSBzdWNoIGEgbnVtYmVyIHRoYXQgd291bGQNCj4gcHJvdmlkZSBhIG1lYW5p bmdmdWwgZGlzdGluY3Rpb24uDQo+ID4+Pg0KPiA+Pj4gVGhlcmUgaXMsIGhvd2V2ZXIsIHRoZSBx dWVzdGlvbiB3aGF0IHR5cGVzIG9mIHByb2JsZW1zIHdlIGV4cGVjdA0KPiB3aXRoIHZlcnkgbGFy Z2UgbnVtYmVyIG9mIGFsZXJ0IG1lc3NhZ2UgcmVjZWl2ZXJzIGFuZCBob3cgd2UgZG9jdW1lbnQN Cj4gdGhpcyBhc3BlY3QgaW4gdGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudC4NCj4gPj4+DQo+ID4+ PiBTdWdnZXN0aW9ucz8gVGhvdWdodHM/DQo+ID4+Pg0KPiA+Pj4gQ2lhbw0KPiA+Pj4gSGFubmVz DQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4+IGVhcmx5d2FybmluZyBtYWlsaW5nIGxpc3QNCj4gPj4+IGVhcmx5d2Fybmlu Z0BpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9l YXJseXdhcm5pbmcNCj4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBlYXJseXdhcm5pbmcgbWFpbGluZyBsaXN0DQo+IGVhcmx5d2FybmluZ0Bp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vhcmx5d2Fy bmluZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQplYXJseXdhcm5pbmcgbWFpbGluZyBsaXN0DQplYXJseXdhcm5pbmdAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWFybHl3YXJuaW5nDQo= From mark.wood@drcf.net Mon Jan 17 03:00:15 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297043A6E71 for ; Mon, 17 Jan 2011 03:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.364 X-Spam-Level: X-Spam-Status: No, score=-1.364 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOa5lxY6nv62 for ; Mon, 17 Jan 2011 03:00:14 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 0684A3A6DBE for ; Mon, 17 Jan 2011 03:00:13 -0800 (PST) X-Trace: 285702692/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Outlook 14.0 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkGADqwM01RVitW/2dsb2JhbACWQ44WdMAHhVAEjjeEbw X-IronPort-AV: E=Sophos;i="4.60,332,1291593600"; d="scan'208";a="285702692" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO host15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 17 Jan 2011 11:02:42 +0000 From: Sender: "mark.wood" To: References: In-Reply-To: Date: Mon, 17 Jan 2011 11:03:21 -0000 Message-ID: <002201cbb636$27cdf790$7769e6b0$@engineer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQF0pS6CAJ5dT1lIHb8TWmXb2B3iepSDGBPg Content-Language: en-us Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 11:00:15 -0000 Hello chaps, Yes, it's only possible to have any kind of delivery reports regarding specific terminals on a one-to-one kind of unicast delivery. The Australians were not considering Cell Broadcast or any other kind of multicast technology as they have selected a SMS based delivery system, so this is probably what they had in mind. I noticed that atoca language about this is reserved mostly for the 'subscription push' kind of distribution. We need to take care not to make it look like a mandated requirement for broadcast/multicast bearers. IMHO, the other special problems with multicast, mean that it needs different and special requirements and cannot be generalized with other 'push' or 'pull' technologies quite so easily, tempting though that is. I think this problem happens because most IT professionals are familiar with TCP and UDP but rarely use multicast so are unfamiliar with its very different attributes. Many vendors offer systems which do have a positive indication of who got what, and this is a good thing for applications of up to about 10,000 receivers. Netherlands studies showed that by the time you scale up to millions, the mass scale of all this becomes a problem, so large scale systems will have to reluctantly abandon the notion of individual confirmation. Besides, the police authority of a large city don't have the time, during an emergency, to check out millions of replies nor take any action if someone does not reply (they are too busy). On the other hand a smaller community may value such a facility, so it seems that they authority will need to choose whatever is appropriate for the circumstances at their discretion. There is no 'one size fits all' solution so we will have to blend many bearers in any real situation. For example the Norwegians take the opposite view. However, it is possible to confirm that the multicast was transmitted, as a network of feedback receivers is envisaged in conjunction with an outer loop reporter system, which would report of the message was transmitted on air. If it did not, then an alarm would be generated by the originating aggregator for the log file. So the positive indication of the fact of the transmission over the air is satisfied even though individual delivery is not. In summary, IMHO, Broadcast/multicast bearers will need special treatment as they don't neatly conform to the classic notions of 'push' or 'pull'. Warm regards, Mark Wood. From rbarnes@bbn.com Mon Jan 17 06:57:09 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8BB728C0FE for ; Mon, 17 Jan 2011 06:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-40IvOdJUNs for ; Mon, 17 Jan 2011 06:57:08 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 671F628C0DF for ; Mon, 17 Jan 2011 06:57:08 -0800 (PST) Received: from [128.89.253.241] (port=65237 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PeqYX-000EJc-RW; Mon, 17 Jan 2011 09:59:42 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <9C2879D3-CDE1-48A6-B4F0-DC98B6EF1E0C@gmx.net> Date: Mon, 17 Jan 2011 09:59:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1BE459C1-D2CC-4656-AD90-BE32529225CA@bbn.com> References: <9C2879D3-CDE1-48A6-B4F0-DC98B6EF1E0C@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1082) Cc: Igor Faynberg , earlywarning@ietf.org Subject: Re: [Atoca] What information is used for authorization? X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:57:09 -0000 At a high level, the question of what *information* is used for = authorization is not one for this group to consider. That's a policy = question, not an engineering question. Our focus should be specifying = *containers* for such information; at most, we specify what *can* be = used for authorization, not what *will* be. At a technological level, I would suggest that we take this in steps. =20= Identity-based access control is clearly low-hanging fruit: There are = long-standing mechanisms in several protocols (HTTP, SIP, XMPP, etc.) = for authenticating users either with shared secrets or with PKIX = certificates. =20 PKIX-based authentication in particular can also support some forms of = attribute-based authorization, e.g., based on CA identity, CP OID, or = extensions like the Clearance attribute [1]. This approach has the = benefit that several organizations already have the necessary = authentication/authorization infrastructure -- there's not necessarily a = need for any new credentials or processes. Once we have something basic in place based on these technologies, then = we can certainly look at ways of adding additional attributes, say using = SAML or attribute certificates. --Richard [1] On Jan 15, 2011, at 2:31 PM, Hannes Tschofenig wrote: > Hi all,=20 >=20 > it was Igor again who raised a question regarding authorization at the = IETF#79 ATOCA meeting. He was wondering whether we would only consider = the identity of the originator for authorization or some other = information as well. >=20 > Are we considering trait-based authorization, see = http://www.rfc-editor.org/rfc/rfc4484.txt, to be utilized in this = context?=20 >=20 > So, what model do we envision?=20 > What other information is useful in the context of an authorization = decision?=20 >=20 > Ciao > Hannes >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From rbarnes@bbn.com Mon Jan 17 07:13:09 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F351428C10A for ; Mon, 17 Jan 2011 07:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i3iBEi9ujjE for ; Mon, 17 Jan 2011 07:13:08 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0DA2728C0D7 for ; Mon, 17 Jan 2011 07:13:08 -0800 (PST) Received: from [128.89.253.241] (port=65273 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Peqo1-000EZ8-Q4; Mon, 17 Jan 2011 10:15:42 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <8B3C3AB2-6384-45C0-97A8-79DBE18831DA@gmail.com> Date: Mon, 17 Jan 2011 10:15:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B0A9FCBB9832F43971E38010638454F03F52595D2@SISPE7MB1.commscope.com> <8B3C3AB2-6384-45C0-97A8-79DBE18831DA@gmail.com> To: Art Botterell X-Mailer: Apple Mail (2.1082) Cc: "earlywarning@ietf.org" Subject: Re: [Atoca] Language and Media Type X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:13:09 -0000 Not really; they serve separate functions. The CAP language element = says what language the message uses. The Accept-Language header says = what languages the client can support. Putting on my wild-speculation hat for a moment, to add a little more = color to Martin's comment: If notifications were based on clients = registering over HTTP or SIP, clients could include an Accept-Language = header in their registration. This would allow the alert server to (1) = tell authorities what languages clients speak (useful forensically, if = not in real time), and (2) deliver a language-appropriate message to = each client. In pictures: -(en)-[American tourist] (en) / [CH ingress]--(fr)--[Geneva gateway]--+--(fr)-[Geneva native] (de) \ -(de)-[German tourist] Suggested text: -- Clients SHOULD include an Accept-Language header in their SUBSCRIBE = request to indicate which languages they support. =20 -- Clients SHOULD be able to process and render CAP responses containing = arbitrary UTF-8 data (subject to the limitations of user interface), = without regard to the CAP element or SIP Content-Language = header. Clients MUST NOT discard a CAP message because its = tag or Content-Language header contain illegal or unsupported values. -- Servers MUST indicate the language of a CAP message by setting the = CAP element and SIP Content-Language header to equivalent = values. -- Servers SHOULD send clients CAP messages only in the languages = specified in the Accept-Language header in the client's SUBSCRIBE = request, which an alert in this language is available. =20 On Jan 16, 2011, at 10:51 PM, Art Botterell wrote: > Would this be duplicative of the CAP language element? >=20 > Thanks! >=20 > - Art >=20 > On Jan 16, 2011, at 7:08 PM, "Thomson, Martin" = wrote: >=20 >> On 2011-01-16 at 06:30:11, Hannes Tschofenig wrote: >>> Keeping Li (if the meeting minutes reflect his name correctly) = noticed >>> that we had a language requirement in the requirements draft but >>> provided no corresponding solution in the SIP-CAP document. >>=20 >> A solution does seem desirable. Though I suspect that many alerting = systems will be deployed with one language or with all of the small = number of "official" or "supported" languages present in the message. = This is probably going to be necessary for all "implicit" subscriptions = anyhow. >>=20 >> In HTTP-land, the Accept-Language header is used for that sort of = thing. The header is present in SIP, but it's use seems limited - and = what evidence I have supports the notion that most servers ignore it. >>=20 >> We could define a use for Accept-Language and see how that flies. >>=20 >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From rbarnes@bbn.com Mon Jan 17 07:22:59 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4400B3A6F3E for ; Mon, 17 Jan 2011 07:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs3szxp+m5zu for ; Mon, 17 Jan 2011 07:22:58 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 15F6D3A6F40 for ; Mon, 17 Jan 2011 07:22:58 -0800 (PST) Received: from [128.89.253.241] (port=65284 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PeqxW-000Ekc-AH; Mon, 17 Jan 2011 10:25:30 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 17 Jan 2011 10:25:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <68CCBAD3-D453-4991-984A-AB649994B7BD@bbn.com> References: To: "DALY, BRIAN K (ATTCINW)" X-Mailer: Apple Mail (2.1082) Cc: igor.faynberg@alcatel-lucent.com, earlywarning@ietf.org Subject: Re: [Atoca] Requirement for Originator Authentication? X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:22:59 -0000 To say this differently: The authentication and authorization applied in = a given deployed system is decided by the entities operating that = deployment. The ATOCA framework should allow for strong authentication = and authorization, and provide appropriate mechanisms, but not require = any particular mechanism to be used. With regard to "end-to-end" vs. "hop-by-hop": Clearly hop-by-hop = authentication/authorization is critical -- especially on the first hop, = where the message is introduced. But it's also trivial: Just use TLS = with client authentication. =20 End-to-end is nice to have, but much harder in any sort of global = context because of the problems with establishing trust anchors. (Does = my phone have to have a TA for every emergency authority in the world?) = In this case, I think the optimal solution might be more of an = "end-to-middle" solution. The originators and relays are part of a = semi-closed system, at least to the degree that you could expect them to = coordinate on trust anchors. So you could enable every entity down to = the last gateway to validate the authorization for a message, even if = the client can't. That said, I think the required technology is probably the same as for = true end-to-end. The obvious answer, IMO, is simply to pass CAP in = S/MIME. --Richard On Jan 17, 2011, at 1:34 AM, DALY, BRIAN K (ATTCINW) wrote: > Authorization to initiate alerts should be provided by the entity = that is initiating the alerts and not ATOCA. ATOCA should authenticate = the receipt of the alerts is from a trusted source. > Brian K. Daly > Sent to you by AT&T...=20 > America's Fastest Mobile Broadband > Network. Rethink Possible. > +1.425.580.6873 > ------- > Sent from my Blackberry >=20 > ----- Original Message ----- > From: earlywarning-bounces@ietf.org > To: Hannes Tschofenig ; = earlywarning@ietf.org ; Igor Faynberg = > Sent: Sun Jan 16 15:32:09 2011 > Subject: Re: [Atoca] Requirement for Originator Authentication? >=20 > On 2011-01-16 at 06:30:33, Hannes Tschofenig wrote: >> Igor raised an interesting question during the meeting in context of >> the security threats, namely: >>=20 >> " Do we have the requirement to authenticate the originator? " >=20 > The question that I heard was not so much related to authentication as = it was to authorization. There was also a question about whether = authentication was identity-based or on some other property, like some = asserted trait. >=20 > What statements can we make about how recipients (and relays) = authorize the receipt (and sending) of alert messages? >=20 >> I couldn't provide him an answer during the meeting because I was not >> quite sure whether he was asking the question in the style of >>=20 >> "Do we need end-to-end security or is a hop-by-hop security solution >> good enough?" >=20 > In the context of this interpretation, I think that there's a real = need to delegate alert distribution. The scale of distribution makes = intermediaries a valuable addition. Relying on the integrity of relays = makes the authorization question more difficult to resolve. >=20 > For something concrete, the relay case is probably the simplest. I = might trust my signalling peer to a certain extent. I certainly don't = trust them enough to generate the massive packet storm requested by an = alert message. They might say the alert comes from the government, but = I might require better proof than their say-so alone. Distributing an = alert will cost me money and I want proof. >=20 > That's one argument. The other argument says that peering = relationships require a degree of trust that would not be broken without = serious ramifications - enough to discourage its abuse. >=20 > The recipient case might have some interesting quirks. Particularly = in wholesale/reseller arrangements. A recipient that relies on = hop-by-hop might receive an alert from the network operator: an entity = with whom they have no direct relationship. For instance, no fewer than = two different operators are involved in getting packets to my house, = neither of which I have a business relationship with. How would someone = - ignorant of the convoluted business arrangements that underpin their = Internet service - decide to authorize an alert that is relayed by = either party? >=20 > --Martin > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From br@brianrosen.net Mon Jan 17 07:25:58 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE3F33A6F42 for ; Mon, 17 Jan 2011 07:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.197 X-Spam-Level: X-Spam-Status: No, score=-103.197 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A84pb3ANsMcv for ; Mon, 17 Jan 2011 07:25:56 -0800 (PST) Received: from barmail3.idig.net (barmail3.idig.net [64.34.111.253]) by core3.amsl.com (Postfix) with ESMTP id DC1DB3A6F3E for ; Mon, 17 Jan 2011 07:25:56 -0800 (PST) X-ASG-Debug-ID: 1295276283-1aaf239a0004-3cgWCS Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail3.idig.net with ESMTP id OKYZfLE38A4WFEFt; Mon, 17 Jan 2011 06:58:06 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=ahof-lt510.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PeqJa-0005Xv-IF; Mon, 17 Jan 2011 06:44:18 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Atoca] Requirement D2: "Large Audience" Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <002201cbb636$27cdf790$7769e6b0$@engineer.com> Date: Mon, 17 Jan 2011 09:44:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net> References: <002201cbb636$27cdf790$7769e6b0$@engineer.com> To: X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1295276285 X-Barracuda-URL: http://64.34.111.253:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.52645 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: earlywarning@ietf.org Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:25:58 -0000 It may be, but I'd like to explore this a bit anyway. Millions of messages (acknowledgements) is a scale we can deal with = today. Hundreds of millions is probably beyond what we can deal with in = a response to a very large alert. Most systems consist of several smaller subsystems. The purpose of an = acknowledgement is to make sure everyone got the message. If the = subsystem can determine that every one of its clients got it, it can = report that up the line. It can save missed acks for later analysis, or = if there are few enough of them, report them up. This means messages national scale which have small effectivity times = can't reasonably ask for message acknowledgement. Anything smaller than = that probably can. Since most alerts really don't involve hundreds of millions of = notifications, most alerts probably can ask for them. If your delivery mechanism is multicast, the multicast mechanism itself = doesn't track who gets the alert in any way we can use. That implies = something else is tracking who gets the alert, a complication that could = loom large. Some systems do know who gets the alert (sometimes because = it knows who it is connected to, and all of them get the alert). = Certainly, anything with a subscription has the characteristic that the = sender knows who all the recipients are. =20 It's VERY valuable to know that every entity that should get the alert = got it. The only other mechanism we have is some repeating of the = sending in the hopes that everyone got it. In some cases you may have = more than one "path" to the same recipient. That might be multiple = devices, multiple services, or multiple logical or physical connections. = You may try one first, and if that doesn't get an ack, try another. = Although we often think of this mechanism as needing no more than = seconds to deploy, in fact many alerts would be fine with a few minutes, = and trying some things sequentially may make sense. So, yes, probably a Tsunami alert to all of East Asia can't ask for = acknowledgements. An "Amber Alert" (possible abducted child) to a = county might very well. Certainly, a snow emergency closing to the = parents of an elementary school could. Brian On Jan 17, 2011, at 6:03 AM, = wrote: > Hello chaps, >=20 > Yes, it's only possible to have any kind of delivery reports regarding > specific terminals on a one-to-one kind of unicast delivery. The = Australians > were not considering Cell Broadcast or any other kind of multicast > technology as they have selected a SMS based delivery system, so this = is > probably what they had in mind. I noticed that atoca language about = this is > reserved mostly for the 'subscription push' kind of distribution. We = need > to take care not to make it look like a mandated requirement for > broadcast/multicast bearers.=20 >=20 > IMHO, the other special problems with multicast, mean that it needs > different and special requirements and cannot be generalized with = other > 'push' or 'pull' technologies quite so easily, tempting though that = is. I > think this problem happens because most IT professionals are familiar = with > TCP and UDP but rarely use multicast so are unfamiliar with its very > different attributes. >=20 > Many vendors offer systems which do have a positive indication of who = got > what, and this is a good thing for applications of up to about 10,000 > receivers. Netherlands studies showed that by the time you scale up to > millions, the mass scale of all this becomes a problem, so large = scale > systems will have to reluctantly abandon the notion of individual > confirmation. >=20 > Besides, the police authority of a large city don't have the time, = during an > emergency, to check out millions of replies nor take any action if = someone > does not reply (they are too busy). On the other hand a smaller = community > may value such a facility, so it seems that they authority will need = to > choose whatever is appropriate for the circumstances at their = discretion. > There is no 'one size fits all' solution so we will have to blend many > bearers in any real situation. For example the Norwegians take the = opposite > view. >=20 > However, it is possible to confirm that the multicast was transmitted, = as a > network of feedback receivers is envisaged in conjunction with an = outer loop > reporter system, which would report of the message was transmitted on = air. > If it did not, then an alarm would be generated by the originating > aggregator for the log file. So the positive indication of the fact of = the > transmission over the air is satisfied even though individual delivery = is > not.=20 >=20 > In summary, IMHO, Broadcast/multicast bearers will need special = treatment > as they don't neatly conform to the classic notions of 'push' or = 'pull'.=20 >=20 > Warm regards, Mark Wood. >=20 >=20 >=20 >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From rbarnes@bbn.com Mon Jan 17 07:39:20 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D733A6F42 for ; Mon, 17 Jan 2011 07:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn0Qo13TVPmB for ; Mon, 17 Jan 2011 07:38:57 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 09B563A6F43 for ; Mon, 17 Jan 2011 07:38:57 -0800 (PST) Received: from [128.89.253.241] (port=65384 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PerD0-000F2O-6k; Mon, 17 Jan 2011 10:41:30 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net> Date: Mon, 17 Jan 2011 10:41:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <002201cbb636$27cdf790$7769e6b0$@engineer.com> <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1082) Cc: earlywarning@ietf.org Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:39:20 -0000 Just one brief comment: Mark's statement that "it's only possible to = have any kind of delivery reports regarding specific terminals on a = one-to-one kind of unicast delivery" is not necessarily true. The = availability of delivery reports depends entirely on the capabilities of = the terminals, and not the intervening access network. In particular, = terminals can send back delivery reports regardless of whether they are = sending or receiving over broadcast or unicast. =20 This pattern could actually be quite efficient in certain layer-2 = networks that have broadcast downstream, unicast upstream (e.g., PON, = DSL, maybe Cable IIRC). A notification to an entire subnet takes one = message, and all acknowledgements can be received in parallel. --Richard On Jan 17, 2011, at 9:44 AM, Brian Rosen wrote: > It may be, but I'd like to explore this a bit anyway. >=20 > Millions of messages (acknowledgements) is a scale we can deal with = today. Hundreds of millions is probably beyond what we can deal with in = a response to a very large alert. >=20 > Most systems consist of several smaller subsystems. The purpose of an = acknowledgement is to make sure everyone got the message. If the = subsystem can determine that every one of its clients got it, it can = report that up the line. It can save missed acks for later analysis, or = if there are few enough of them, report them up. >=20 > This means messages national scale which have small effectivity times = can't reasonably ask for message acknowledgement. Anything smaller than = that probably can. >=20 > Since most alerts really don't involve hundreds of millions of = notifications, most alerts probably can ask for them. >=20 > If your delivery mechanism is multicast, the multicast mechanism = itself doesn't track who gets the alert in any way we can use. That = implies something else is tracking who gets the alert, a complication = that could loom large. Some systems do know who gets the alert = (sometimes because it knows who it is connected to, and all of them get = the alert). Certainly, anything with a subscription has the = characteristic that the sender knows who all the recipients are. =20 >=20 > It's VERY valuable to know that every entity that should get the alert = got it. The only other mechanism we have is some repeating of the = sending in the hopes that everyone got it. In some cases you may have = more than one "path" to the same recipient. That might be multiple = devices, multiple services, or multiple logical or physical connections. = You may try one first, and if that doesn't get an ack, try another. = Although we often think of this mechanism as needing no more than = seconds to deploy, in fact many alerts would be fine with a few minutes, = and trying some things sequentially may make sense. >=20 > So, yes, probably a Tsunami alert to all of East Asia can't ask for = acknowledgements. An "Amber Alert" (possible abducted child) to a = county might very well. Certainly, a snow emergency closing to the = parents of an elementary school could. >=20 > Brian >=20 >=20 > On Jan 17, 2011, at 6:03 AM, = wrote: >=20 >> Hello chaps, >>=20 >> Yes, it's only possible to have any kind of delivery reports = regarding >> specific terminals on a one-to-one kind of unicast delivery. The = Australians >> were not considering Cell Broadcast or any other kind of multicast >> technology as they have selected a SMS based delivery system, so this = is >> probably what they had in mind. I noticed that atoca language about = this is >> reserved mostly for the 'subscription push' kind of distribution. We = need >> to take care not to make it look like a mandated requirement for >> broadcast/multicast bearers.=20 >>=20 >> IMHO, the other special problems with multicast, mean that it needs >> different and special requirements and cannot be generalized with = other >> 'push' or 'pull' technologies quite so easily, tempting though that = is. I >> think this problem happens because most IT professionals are familiar = with >> TCP and UDP but rarely use multicast so are unfamiliar with its very >> different attributes. >>=20 >> Many vendors offer systems which do have a positive indication of who = got >> what, and this is a good thing for applications of up to about = 10,000 >> receivers. Netherlands studies showed that by the time you scale up = to >> millions, the mass scale of all this becomes a problem, so large = scale >> systems will have to reluctantly abandon the notion of individual >> confirmation. >>=20 >> Besides, the police authority of a large city don't have the time, = during an >> emergency, to check out millions of replies nor take any action if = someone >> does not reply (they are too busy). On the other hand a smaller = community >> may value such a facility, so it seems that they authority will need = to >> choose whatever is appropriate for the circumstances at their = discretion. >> There is no 'one size fits all' solution so we will have to blend = many >> bearers in any real situation. For example the Norwegians take the = opposite >> view. >>=20 >> However, it is possible to confirm that the multicast was = transmitted, as a >> network of feedback receivers is envisaged in conjunction with an = outer loop >> reporter system, which would report of the message was transmitted on = air. >> If it did not, then an alarm would be generated by the originating >> aggregator for the log file. So the positive indication of the fact = of the >> transmission over the air is satisfied even though individual = delivery is >> not.=20 >>=20 >> In summary, IMHO, Broadcast/multicast bearers will need special = treatment >> as they don't neatly conform to the classic notions of 'push' or = 'pull'.=20 >>=20 >> Warm regards, Mark Wood. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From peter.sanders@one2many.eu Mon Jan 17 08:01:58 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 023A63A6D4E for ; Mon, 17 Jan 2011 08:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.26 X-Spam-Level: * X-Spam-Status: No, score=1.26 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MSGID_MULTIPLE_AT=1.449, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWbTbv0vIr+l for ; Mon, 17 Jan 2011 08:01:56 -0800 (PST) Received: from smtp.byte.nl (mailgw3.c1.byte.nl [82.94.214.67]) by core3.amsl.com (Postfix) with ESMTP id 9704B28C0D8 for ; Mon, 17 Jan 2011 08:01:55 -0800 (PST) Received: from peters (unknown [92.65.238.116]) (Authenticated sender: onema004) by smtp.byte.nl (Postfix) with ESMTPA id 812C68A91; Mon, 17 Jan 2011 17:04:28 +0100 (CET) From: "Peter Sanders" To: "'Brian Rosen'" , "'mark.wood@engineer.commark.wood@engineer.com'"@core3.amsl.com References: <002201cbb636$27cdf790$7769e6b0$@engineer.com> <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net> In-Reply-To: <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net> Date: Mon, 17 Jan 2011 17:04:28 +0100 Organization: one2many Message-ID: <00a301cbb660$37fdd9d0$a7f98d70$@sanders@one2many.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu2W0edznbrsth8RM6J7xxuNFSsZQAAnOyw Content-Language: nl Cc: earlywarning@ietf.org Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:01:58 -0000 Hi Brian and Mark, Brian, you state in your email the following: "It's VERY valuable to know that every entity that should get the alert got it" The authorities may not know who in particular needs to receive the alert message. They wish that everyone in a specific area receives it. However, the authorities may have no idea who is in the target area at that moment, so they can't ask for confirmation; they can, but they don't know if they miss a few acks. Finding out who is in a specific area is technically possible, but may generate far more network traffic than the acks you expect from a few million people, and it takes time too. I just wanted to add these remarks to the discussion. Best regards, Peter -----Original Message----- From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] On Behalf Of Brian Rosen Sent: maandag 17 januari 2011 15:44 To: mark.wood@engineer.commark.wood@engineer.com Cc: earlywarning@ietf.org Subject: Re: [Atoca] Requirement D2: "Large Audience" It may be, but I'd like to explore this a bit anyway. Millions of messages (acknowledgements) is a scale we can deal with today. Hundreds of millions is probably beyond what we can deal with in a response to a very large alert. Most systems consist of several smaller subsystems. The purpose of an acknowledgement is to make sure everyone got the message. If the subsystem can determine that every one of its clients got it, it can report that up the line. It can save missed acks for later analysis, or if there are few enough of them, report them up. This means messages national scale which have small effectivity times can't reasonably ask for message acknowledgement. Anything smaller than that probably can. Since most alerts really don't involve hundreds of millions of notifications, most alerts probably can ask for them. If your delivery mechanism is multicast, the multicast mechanism itself doesn't track who gets the alert in any way we can use. That implies something else is tracking who gets the alert, a complication that could loom large. Some systems do know who gets the alert (sometimes because it knows who it is connected to, and all of them get the alert). Certainly, anything with a subscription has the characteristic that the sender knows who all the recipients are. It's VERY valuable to know that every entity that should get the alert got it. The only other mechanism we have is some repeating of the sending in the hopes that everyone got it. In some cases you may have more than one "path" to the same recipient. That might be multiple devices, multiple services, or multiple logical or physical connections. You may try one first, and if that doesn't get an ack, try another. Although we often think of this mechanism as needing no more than seconds to deploy, in fact many alerts would be fine with a few minutes, and trying some things sequentially may make sense. So, yes, probably a Tsunami alert to all of East Asia can't ask for acknowledgements. An "Amber Alert" (possible abducted child) to a county might very well. Certainly, a snow emergency closing to the parents of an elementary school could. Brian On Jan 17, 2011, at 6:03 AM, wrote: > Hello chaps, > > Yes, it's only possible to have any kind of delivery reports regarding > specific terminals on a one-to-one kind of unicast delivery. The Australians > were not considering Cell Broadcast or any other kind of multicast > technology as they have selected a SMS based delivery system, so this is > probably what they had in mind. I noticed that atoca language about this is > reserved mostly for the 'subscription push' kind of distribution. We need > to take care not to make it look like a mandated requirement for > broadcast/multicast bearers. > > IMHO, the other special problems with multicast, mean that it needs > different and special requirements and cannot be generalized with other > 'push' or 'pull' technologies quite so easily, tempting though that is. I > think this problem happens because most IT professionals are familiar with > TCP and UDP but rarely use multicast so are unfamiliar with its very > different attributes. > > Many vendors offer systems which do have a positive indication of who got > what, and this is a good thing for applications of up to about 10,000 > receivers. Netherlands studies showed that by the time you scale up to > millions, the mass scale of all this becomes a problem, so large scale > systems will have to reluctantly abandon the notion of individual > confirmation. > > Besides, the police authority of a large city don't have the time, during an > emergency, to check out millions of replies nor take any action if someone > does not reply (they are too busy). On the other hand a smaller community > may value such a facility, so it seems that they authority will need to > choose whatever is appropriate for the circumstances at their discretion. > There is no 'one size fits all' solution so we will have to blend many > bearers in any real situation. For example the Norwegians take the opposite > view. > > However, it is possible to confirm that the multicast was transmitted, as a > network of feedback receivers is envisaged in conjunction with an outer loop > reporter system, which would report of the message was transmitted on air. > If it did not, then an alarm would be generated by the originating > aggregator for the log file. So the positive indication of the fact of the > transmission over the air is satisfied even though individual delivery is > not. > > In summary, IMHO, Broadcast/multicast bearers will need special treatment > as they don't neatly conform to the classic notions of 'push' or 'pull'. > > Warm regards, Mark Wood. > > > > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning _______________________________________________ earlywarning mailing list earlywarning@ietf.org https://www.ietf.org/mailman/listinfo/earlywarning From br@brianrosen.net Mon Jan 17 08:07:47 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA643A6F45 for ; Mon, 17 Jan 2011 08:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.357 X-Spam-Level: X-Spam-Status: No, score=-103.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkmZ7x10q263 for ; Mon, 17 Jan 2011 08:07:46 -0800 (PST) Received: from barmail2.idig.net (barmail2.idig.net [64.34.111.252]) by core3.amsl.com (Postfix) with ESMTP id 262A93A6F42 for ; Mon, 17 Jan 2011 08:07:46 -0800 (PST) X-ASG-Debug-ID: 1295279882-0f8330540007-3cgWCS Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail2.idig.net with ESMTP id cQl04iGHlfrm4Oyb; Mon, 17 Jan 2011 07:58:10 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=dstr-ltx301.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Per4x-0001kM-Sg; Mon, 17 Jan 2011 07:33:16 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Atoca] Requirement for Originator Authentication? Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <68CCBAD3-D453-4991-984A-AB649994B7BD@bbn.com> Date: Mon, 17 Jan 2011 10:33:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <68CCBAD3-D453-4991-984A-AB649994B7BD@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1295279889 X-Barracuda-URL: http://64.34.111.252:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.52648 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e Cc: igor.faynberg@alcatel-lucent.com, earlywarning@ietf.org Subject: Re: [Atoca] Requirement for Originator Authentication? X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:07:48 -0000 Interesting. Our experience is that it's hard to get S/MIME implementations, but = maybe we could do it for this one. In nearly every case, we don't want encryption. We want authentication = and probably integrity protection. So implementing S/MIME gets you = that, but you can ignore it if you want to. Might work. I do think hop by hop works also. Brian On Jan 17, 2011, at 10:25 AM, Richard L. Barnes wrote: > To say this differently: The authentication and authorization applied = in a given deployed system is decided by the entities operating that = deployment. The ATOCA framework should allow for strong authentication = and authorization, and provide appropriate mechanisms, but not require = any particular mechanism to be used. >=20 > With regard to "end-to-end" vs. "hop-by-hop": Clearly hop-by-hop = authentication/authorization is critical -- especially on the first hop, = where the message is introduced. But it's also trivial: Just use TLS = with client authentication. =20 >=20 > End-to-end is nice to have, but much harder in any sort of global = context because of the problems with establishing trust anchors. (Does = my phone have to have a TA for every emergency authority in the world?) = In this case, I think the optimal solution might be more of an = "end-to-middle" solution. The originators and relays are part of a = semi-closed system, at least to the degree that you could expect them to = coordinate on trust anchors. So you could enable every entity down to = the last gateway to validate the authorization for a message, even if = the client can't. >=20 > That said, I think the required technology is probably the same as for = true end-to-end. The obvious answer, IMO, is simply to pass CAP in = S/MIME. >=20 > --Richard >=20 >=20 >=20 > On Jan 17, 2011, at 1:34 AM, DALY, BRIAN K (ATTCINW) wrote: >=20 >> Authorization to initiate alerts should be provided by the entity = that is initiating the alerts and not ATOCA. ATOCA should authenticate = the receipt of the alerts is from a trusted source. >> Brian K. Daly >> Sent to you by AT&T...=20 >> America's Fastest Mobile Broadband >> Network. Rethink Possible. >> +1.425.580.6873 >> ------- >> Sent from my Blackberry >>=20 >> ----- Original Message ----- >> From: earlywarning-bounces@ietf.org >> To: Hannes Tschofenig ; = earlywarning@ietf.org ; Igor Faynberg = >> Sent: Sun Jan 16 15:32:09 2011 >> Subject: Re: [Atoca] Requirement for Originator Authentication? >>=20 >> On 2011-01-16 at 06:30:33, Hannes Tschofenig wrote: >>> Igor raised an interesting question during the meeting in context of >>> the security threats, namely: >>>=20 >>> " Do we have the requirement to authenticate the originator? " >>=20 >> The question that I heard was not so much related to authentication = as it was to authorization. There was also a question about whether = authentication was identity-based or on some other property, like some = asserted trait. >>=20 >> What statements can we make about how recipients (and relays) = authorize the receipt (and sending) of alert messages? >>=20 >>> I couldn't provide him an answer during the meeting because I was = not >>> quite sure whether he was asking the question in the style of >>>=20 >>> "Do we need end-to-end security or is a hop-by-hop security solution >>> good enough?" >>=20 >> In the context of this interpretation, I think that there's a real = need to delegate alert distribution. The scale of distribution makes = intermediaries a valuable addition. Relying on the integrity of relays = makes the authorization question more difficult to resolve. >>=20 >> For something concrete, the relay case is probably the simplest. I = might trust my signalling peer to a certain extent. I certainly don't = trust them enough to generate the massive packet storm requested by an = alert message. They might say the alert comes from the government, but = I might require better proof than their say-so alone. Distributing an = alert will cost me money and I want proof. >>=20 >> That's one argument. The other argument says that peering = relationships require a degree of trust that would not be broken without = serious ramifications - enough to discourage its abuse. >>=20 >> The recipient case might have some interesting quirks. Particularly = in wholesale/reseller arrangements. A recipient that relies on = hop-by-hop might receive an alert from the network operator: an entity = with whom they have no direct relationship. For instance, no fewer than = two different operators are involved in getting packets to my house, = neither of which I have a business relationship with. How would someone = - ignorant of the convoluted business arrangements that underpin their = Internet service - decide to authorize an alert that is relayed by = either party? >>=20 >> --Martin >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From rbarnes@bbn.com Mon Jan 17 08:18:48 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762EF28C0F1 for ; Mon, 17 Jan 2011 08:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRHo1c5LWtwn for ; Mon, 17 Jan 2011 08:18:47 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3285D3A6E4D for ; Mon, 17 Jan 2011 08:18:47 -0800 (PST) Received: from [128.89.253.241] (port=49451 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PerpY-000Ff0-Py; Mon, 17 Jan 2011 11:21:21 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 17 Jan 2011 11:21:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5C7FB2C5-9493-4297-B557-014BCEB49B32@bbn.com> References: <68CCBAD3-D453-4991-984A-AB649994B7BD@bbn.com> To: Brian Rosen X-Mailer: Apple Mail (2.1082) Cc: earlywarning@ietf.org Subject: Re: [Atoca] Requirement for Originator Authentication? X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:18:48 -0000 Note that you don't necessarily need S/MIME implementation in the SIP = stack. You can do it at the application layer -- pull the bits out of = the SIP body and do your thing. At that level, there are lots of S/MIME = libraries, all the typical ones: OpenSSL, BouncyCastle, MS CAPI/CNG. No doubt that hop-by-hop works, but it doesn't provide the guarantees = that end-to-end or end-to-middle does. There's room for both. --Richard On Jan 17, 2011, at 10:33 AM, Brian Rosen wrote: > Interesting. >=20 > Our experience is that it's hard to get S/MIME implementations, but = maybe we could do it for this one. >=20 > In nearly every case, we don't want encryption. We want = authentication and probably integrity protection. So implementing = S/MIME gets you that, but you can ignore it if you want to. Might work. >=20 > I do think hop by hop works also. >=20 > Brian >=20 > On Jan 17, 2011, at 10:25 AM, Richard L. Barnes wrote: >=20 >> To say this differently: The authentication and authorization applied = in a given deployed system is decided by the entities operating that = deployment. The ATOCA framework should allow for strong authentication = and authorization, and provide appropriate mechanisms, but not require = any particular mechanism to be used. >>=20 >> With regard to "end-to-end" vs. "hop-by-hop": Clearly hop-by-hop = authentication/authorization is critical -- especially on the first hop, = where the message is introduced. But it's also trivial: Just use TLS = with client authentication. =20 >>=20 >> End-to-end is nice to have, but much harder in any sort of global = context because of the problems with establishing trust anchors. (Does = my phone have to have a TA for every emergency authority in the world?) = In this case, I think the optimal solution might be more of an = "end-to-middle" solution. The originators and relays are part of a = semi-closed system, at least to the degree that you could expect them to = coordinate on trust anchors. So you could enable every entity down to = the last gateway to validate the authorization for a message, even if = the client can't. >>=20 >> That said, I think the required technology is probably the same as = for true end-to-end. The obvious answer, IMO, is simply to pass CAP in = S/MIME. >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Jan 17, 2011, at 1:34 AM, DALY, BRIAN K (ATTCINW) wrote: >>=20 >>> Authorization to initiate alerts should be provided by the entity = that is initiating the alerts and not ATOCA. ATOCA should authenticate = the receipt of the alerts is from a trusted source. >>> Brian K. Daly >>> Sent to you by AT&T...=20 >>> America's Fastest Mobile Broadband >>> Network. Rethink Possible. >>> +1.425.580.6873 >>> ------- >>> Sent from my Blackberry >>>=20 >>> ----- Original Message ----- >>> From: earlywarning-bounces@ietf.org >>> To: Hannes Tschofenig ; = earlywarning@ietf.org ; Igor Faynberg = >>> Sent: Sun Jan 16 15:32:09 2011 >>> Subject: Re: [Atoca] Requirement for Originator Authentication? >>>=20 >>> On 2011-01-16 at 06:30:33, Hannes Tschofenig wrote: >>>> Igor raised an interesting question during the meeting in context = of >>>> the security threats, namely: >>>>=20 >>>> " Do we have the requirement to authenticate the originator? " >>>=20 >>> The question that I heard was not so much related to authentication = as it was to authorization. There was also a question about whether = authentication was identity-based or on some other property, like some = asserted trait. >>>=20 >>> What statements can we make about how recipients (and relays) = authorize the receipt (and sending) of alert messages? >>>=20 >>>> I couldn't provide him an answer during the meeting because I was = not >>>> quite sure whether he was asking the question in the style of >>>>=20 >>>> "Do we need end-to-end security or is a hop-by-hop security = solution >>>> good enough?" >>>=20 >>> In the context of this interpretation, I think that there's a real = need to delegate alert distribution. The scale of distribution makes = intermediaries a valuable addition. Relying on the integrity of relays = makes the authorization question more difficult to resolve. >>>=20 >>> For something concrete, the relay case is probably the simplest. I = might trust my signalling peer to a certain extent. I certainly don't = trust them enough to generate the massive packet storm requested by an = alert message. They might say the alert comes from the government, but = I might require better proof than their say-so alone. Distributing an = alert will cost me money and I want proof. >>>=20 >>> That's one argument. The other argument says that peering = relationships require a degree of trust that would not be broken without = serious ramifications - enough to discourage its abuse. >>>=20 >>> The recipient case might have some interesting quirks. Particularly = in wholesale/reseller arrangements. A recipient that relies on = hop-by-hop might receive an alert from the network operator: an entity = with whom they have no direct relationship. For instance, no fewer than = two different operators are involved in getting packets to my house, = neither of which I have a business relationship with. How would someone = - ignorant of the convoluted business arrangements that underpin their = Internet service - decide to authorize an alert that is relayed by = either party? >>>=20 >>> --Martin >>> _______________________________________________ >>> earlywarning mailing list >>> earlywarning@ietf.org >>> https://www.ietf.org/mailman/listinfo/earlywarning >>> _______________________________________________ >>> earlywarning mailing list >>> earlywarning@ietf.org >>> https://www.ietf.org/mailman/listinfo/earlywarning >>=20 >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning >=20 From mark.wood@drcf.net Mon Jan 17 09:28:02 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1AB28C163 for ; Mon, 17 Jan 2011 09:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+pXQG+bIGDZ for ; Mon, 17 Jan 2011 09:27:59 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 23F8728C1A2 for ; Mon, 17 Jan 2011 09:27:58 -0800 (PST) X-Trace: 343225862/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Outlook 14.0 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMFAN8LNE1RVitW/2dsb2JhbACWO44XdME6hVAEjjeEbw X-IronPort-AV: E=Sophos;i="4.60,333,1291593600"; d="scan'208";a="343225862" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO host15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 17 Jan 2011 17:30:25 +0000 From: Sender: "mark.wood" To: References: <002201cbb636$27cdf790$7769e6b0$@engineer.com> <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net> In-Reply-To: Date: Mon, 17 Jan 2011 17:30:25 -0000 Message-ID: <008501cbb66c$39f82cc0$ade88640$@engineer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQF0pS6CAJ5dT1lIHb8TWmXb2B3iegJBN7VtAf32gfUCIt2H5wKL+Y6+lDwdK5A= Content-Language: en-us Subject: [Atoca] FW: Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 17:28:02 -0000 Yes, I stand corrected, Thanks Richard. -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com] Sent: Monday, January 17, 2011 3:41 PM To: Brian Rosen Cc: ; earlywarning@ietf.org Subject: Re: [Atoca] Requirement D2: "Large Audience" Just one brief comment: Mark's statement that "it's only possible to have any kind of delivery reports regarding specific terminals on a one-to-one kind of unicast delivery" is not necessarily true. The availability of delivery reports depends entirely on the capabilities of the terminals, and not the intervening access network. In particular, terminals can send back delivery reports regardless of whether they are sending or receiving over broadcast or unicast. This pattern could actually be quite efficient in certain layer-2 networks that have broadcast downstream, unicast upstream (e.g., PON, DSL, maybe Cable IIRC). A notification to an entire subnet takes one message, and all acknowledgements can be received in parallel. --Richard From keith.drage@alcatel-lucent.com Mon Jan 17 09:47:50 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42EC28C1D6 for ; Mon, 17 Jan 2011 09:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.623 X-Spam-Level: X-Spam-Status: No, score=-105.623 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x17WMeZwq-mi for ; Mon, 17 Jan 2011 09:47:49 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 8218F28C1A2 for ; Mon, 17 Jan 2011 09:47:49 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0HHoNfL005102 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 17 Jan 2011 18:50:23 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 17 Jan 2011 18:50:23 +0100 From: "DRAGE, Keith (Keith)" To: "earlywarning@ietf.org" Date: Mon, 17 Jan 2011 18:50:20 +0100 Thread-Topic: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt Thread-Index: Acu05stlidXWWaCaS4i9mac+KqYVAABhziGQ Message-ID: References: <20110115190001.18610.17937.idtracker@localhost> In-Reply-To: <20110115190001.18610.17937.idtracker@localhost> 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-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 17:47:50 -0000 I was scanning the charter to see if we had requirements for all items ment= ioned in the charter. For the following text: "Which devices should get alerts is primarily driven by location. The first set of recipients that must be catered for are those within the area identified by the alert originator to be affected by the emergency event. "=20 I could see the requiremnet for recipient control of this: Req-S2: The protocol solution MUST allow a potential Recipient to express the geographical area it wants to receive alerts about. But I could see no corresponding require for the sender to be able to indic= ate which geographic locations it wants its alerts to go to. I also looked at the following charter text: "The ATOCA effort is differentiated from and is not intended to replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the recipients of ATOCA alerts are the wide range of devices connected to the Internet and various private IP networks, which humans may have "at hand" to get such events, as well as automatons who may take action based on the alerts. This implies that the content of the alert contains some information, which is intended to be consumed by humans, and some which is intended to be consumed by automatons. " I could see nothing in the i-d that even mentioned this, let alone discusse= d it. Rather the text: "This problem has been illustrated by the London underground bombing on July 7, 2006, as described in a government report [July2005]. The UK authorities could only use broadcast media and could not, for example, easily announce to the "walking wounded" where to assemble." Could be be taken to imply that they intend to do exactly that, as I unders= tand the UK initiative as a result of that was directed to mobile phone sol= utions, as identified above. regards Keith > -----Original Message----- > From: earlywarning-bounces@ietf.org=20 > [mailto:earlywarning-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: Saturday, January 15, 2011 7:00 PM > To: i-d-announce@ietf.org > Cc: earlywarning@ietf.org > Subject: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Authority-to-Citizen Alert=20 > Working Group of the IETF. >=20 >=20 > Title : Requirements, Terminology and=20 > Framework for Exigent Communications > Author(s) : H. Schulzrinne, et al. > Filename : draft-ietf-atoca-requirements-01.txt > Pages : 14 > Date : 2011-01-15 >=20 > Before, during and after emergency situations various=20 > agencies need to provide information to a group of persons or=20 > to the public within a geographical area. While many aspects=20 > of such systems are specific to national or local=20 > jurisdictions, emergencies span such boundaries and=20 > notifications need to reach visitors from other jurisdictions. >=20 > This document provides terminology, requirements and an=20 > architectural description for protocols exchanging alerts=20 > between IP-based end points. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-atoca-requireme > nts-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. > = From mark.wood@drcf.net Mon Jan 17 08:10:47 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 075F028C0F0 for ; Mon, 17 Jan 2011 08:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQQxCVpMKSat for ; Mon, 17 Jan 2011 08:10:45 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 523AA28C0DD for ; Mon, 17 Jan 2011 08:10:43 -0800 (PST) X-Trace: 343198784/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Outlook 14.0 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB/5M01RVitW/2dsb2JhbACkUnTAX4VQBIsfgxiEbw X-IronPort-AV: E=Sophos;i="4.60,333,1291593600"; d="scan'208";a="343198784" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO host15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 17 Jan 2011 16:13:14 +0000 From: "mark.wood" To: References: <002201cbb636$27cdf790$7769e6b0$@engineer.com> <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net> In-Reply-To: Date: Mon, 17 Jan 2011 16:13:13 -0000 Message-ID: <007d01cbb661$7235ea10$56a1be30$@drcf.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQF0pS6CAJ5dT1lIHb8TWmXb2B3iegJBN7VtAf32gfUCIt2H55RQZ/Tw Content-Language: en-us X-Mailman-Approved-At: Mon, 17 Jan 2011 15:32:31 -0800 Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:10:47 -0000 Yes, I stand corrected, Thanks Richard. -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com] Sent: Monday, January 17, 2011 3:41 PM To: Brian Rosen Cc: ; earlywarning@ietf.org Subject: Re: [Atoca] Requirement D2: "Large Audience" Just one brief comment: Mark's statement that "it's only possible to have any kind of delivery reports regarding specific terminals on a one-to-one kind of unicast delivery" is not necessarily true. The availability of delivery reports depends entirely on the capabilities of the terminals, and not the intervening access network. In particular, terminals can send back delivery reports regardless of whether they are sending or receiving over broadcast or unicast. This pattern could actually be quite efficient in certain layer-2 networks that have broadcast downstream, unicast upstream (e.g., PON, DSL, maybe Cable IIRC). A notification to an entire subnet takes one message, and all acknowledgements can be received in parallel. --Richard On Jan 17, 2011, at 9:44 AM, Brian Rosen wrote: > It may be, but I'd like to explore this a bit anyway. > > Millions of messages (acknowledgements) is a scale we can deal with today. Hundreds of millions is probably beyond what we can deal with in a response to a very large alert. > > Most systems consist of several smaller subsystems. The purpose of an acknowledgement is to make sure everyone got the message. If the subsystem can determine that every one of its clients got it, it can report that up the line. It can save missed acks for later analysis, or if there are few enough of them, report them up. > > This means messages national scale which have small effectivity times can't reasonably ask for message acknowledgement. Anything smaller than that probably can. > > Since most alerts really don't involve hundreds of millions of notifications, most alerts probably can ask for them. > > If your delivery mechanism is multicast, the multicast mechanism itself doesn't track who gets the alert in any way we can use. That implies something else is tracking who gets the alert, a complication that could loom large. Some systems do know who gets the alert (sometimes because it knows who it is connected to, and all of them get the alert). Certainly, anything with a subscription has the characteristic that the sender knows who all the recipients are. > > It's VERY valuable to know that every entity that should get the alert got it. The only other mechanism we have is some repeating of the sending in the hopes that everyone got it. In some cases you may have more than one "path" to the same recipient. That might be multiple devices, multiple services, or multiple logical or physical connections. You may try one first, and if that doesn't get an ack, try another. Although we often think of this mechanism as needing no more than seconds to deploy, in fact many alerts would be fine with a few minutes, and trying some things sequentially may make sense. > > So, yes, probably a Tsunami alert to all of East Asia can't ask for acknowledgements. An "Amber Alert" (possible abducted child) to a county might very well. Certainly, a snow emergency closing to the parents of an elementary school could. > > Brian > > > On Jan 17, 2011, at 6:03 AM, wrote: > >> Hello chaps, >> >> Yes, it's only possible to have any kind of delivery reports >> regarding specific terminals on a one-to-one kind of unicast >> delivery. The Australians were not considering Cell Broadcast or any >> other kind of multicast technology as they have selected a SMS based >> delivery system, so this is probably what they had in mind. I noticed >> that atoca language about this is reserved mostly for the >> 'subscription push' kind of distribution. We need to take care not >> to make it look like a mandated requirement for broadcast/multicast bearers. >> >> IMHO, the other special problems with multicast, mean that it needs >> different and special requirements and cannot be generalized with >> other 'push' or 'pull' technologies quite so easily, tempting though >> that is. I think this problem happens because most IT professionals >> are familiar with TCP and UDP but rarely use multicast so are >> unfamiliar with its very different attributes. >> >> Many vendors offer systems which do have a positive indication of who >> got what, and this is a good thing for applications of up to about >> 10,000 receivers. Netherlands studies showed that by the time you >> scale up to millions, the mass scale of all this becomes a problem, >> so large scale systems will have to reluctantly abandon the notion of >> individual confirmation. >> >> Besides, the police authority of a large city don't have the time, >> during an emergency, to check out millions of replies nor take any >> action if someone does not reply (they are too busy). On the other >> hand a smaller community may value such a facility, so it seems that >> they authority will need to choose whatever is appropriate for the circumstances at their discretion. >> There is no 'one size fits all' solution so we will have to blend >> many bearers in any real situation. For example the Norwegians take >> the opposite view. >> >> However, it is possible to confirm that the multicast was >> transmitted, as a network of feedback receivers is envisaged in >> conjunction with an outer loop reporter system, which would report of the message was transmitted on air. >> If it did not, then an alarm would be generated by the originating >> aggregator for the log file. So the positive indication of the fact >> of the transmission over the air is satisfied even though individual >> delivery is not. >> >> In summary, IMHO, Broadcast/multicast bearers will need special >> treatment as they don't neatly conform to the classic notions of 'push' or 'pull'. >> >> Warm regards, Mark Wood. >> >> >> >> >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From Martin.Thomson@andrew.com Mon Jan 17 15:35:54 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532F128C0FD for ; Mon, 17 Jan 2011 15:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2LVqvhy-cXB for ; Mon, 17 Jan 2011 15:35:52 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id B395728C0CF for ; Mon, 17 Jan 2011 15:35:52 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:55446 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S41464708Ab1AQXi2 (ORCPT ); Mon, 17 Jan 2011 17:38:28 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 17 Jan 2011 17:38:27 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 18 Jan 2011 07:38:25 +0800 From: "Thomson, Martin" To: Brian Rosen , "mark.wood@engineer.com" Date: Tue, 18 Jan 2011 07:38:21 +0800 Thread-Topic: [Atoca] Requirement D2: "Large Audience" Thread-Index: Acu2WzarwJTuYuD+SZ22sGYMXgflaAARCo1w Message-ID: <8B0A9FCBB9832F43971E38010638454F03F5259796@SISPE7MB1.commscope.com> References: <002201cbb636$27cdf790$7769e6b0$@engineer.com> <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net> In-Reply-To: <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "earlywarning@ietf.org" Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 23:35:54 -0000 T24gMjAxMS0wMS0xOCBhdCAwMTo0NDowMiwgQnJpYW4gUm9zZW4gd3JvdGU6DQo+IE1vc3Qgc3lz dGVtcyBjb25zaXN0IG9mIHNldmVyYWwgc21hbGxlciBzdWJzeXN0ZW1zLiAgVGhlIHB1cnBvc2Ug b2YgYW4NCj4gYWNrbm93bGVkZ2VtZW50IGlzIHRvIG1ha2Ugc3VyZSBldmVyeW9uZSBnb3QgdGhl IG1lc3NhZ2UuICBJZiB0aGUNCj4gc3Vic3lzdGVtIGNhbiBkZXRlcm1pbmUgdGhhdCBldmVyeSBv bmUgb2YgaXRzIGNsaWVudHMgZ290IGl0LCBpdCBjYW4NCj4gcmVwb3J0IHRoYXQgdXAgdGhlIGxp bmUuICBJdCBjYW4gc2F2ZSBtaXNzZWQgYWNrcyBmb3IgbGF0ZXIgYW5hbHlzaXMsDQo+IG9yIGlm IHRoZXJlIGFyZSBmZXcgZW5vdWdoIG9mIHRoZW0sIHJlcG9ydCB0aGVtIHVwLg0KDQpJIHN1c3Bl Y3QgdGhhdCB0aGlzIHNvcnQgb2YgZGVsZWdhdGlvbiBzeXN0ZW0gaXMgb25lIHRoYXQgY2FuIHNj YWxlLiAgSGF2aW5nIHRoZSBvcmlnaW5hdG9yIGNvbGxlY3QgYWxsIHRoZSByZXBsaWVzIHByb2Jh Ymx5IHdvbnQuICBPZiBjb3Vyc2UsIHRoaXMgYWxsIGRlcGVuZHMgb24gdGhlIGV4YWN0IGNpcmN1 bXN0YW5jZXMsIGFzIHlvdSBvYnNlcnZlLg0KDQotLU1hcnRpbg0K From igor.faynberg@alcatel-lucent.com Mon Jan 17 17:06:37 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B5828C222 for ; Mon, 17 Jan 2011 17:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJRCfbBv3A5H for ; Mon, 17 Jan 2011 17:06:36 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 5CBFB28C16B for ; Mon, 17 Jan 2011 17:06:36 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p0I196mW026647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 19:09:06 -0600 (CST) Received: from [135.244.8.247] (faynberg.lra.lucent.com [135.244.8.247]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p0I195ZR011517; Mon, 17 Jan 2011 19:09:05 -0600 (CST) Message-ID: <4D34E831.2050402@alcatel-lucent.com> Date: Mon, 17 Jan 2011 20:09:05 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: earlywarning@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [Atoca] On broadcasting and authentication/authorization (was Re: Requirement D2: "Large Audience") X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 01:06:37 -0000 With many thanks to Hannes for a thorough follow-up on my humble questions, I just wanted to clarify that my question about "large audience" arose only because I was trained to test, and the word "large" is not something that any test can verify. Since the requirements has a MUST in it, it ought to be verifiable. (And I remember Scott echoed this by pointing to the word "simultaneously" as potentially problematic, too. To this end, I am happy with the proposal to use the term "broadcast." How about re-writing Req-D2 as follows: > > The protocol solution MUST allow broadcast delivery of messages > to the targeted audience. > > In this case, we avoid specification of the size of the audience as well as the issues of verifying simultaneity (broadcast takes care of it). On the issue of authentication/authorization, I actually meant exactly what Brian had said a while ago: The broadcaster has to be authenticated (lest a rogue entity creates panic or disrupts the network or both), and the network will deal with the authorization. Indeed, TLS with client authentication (preferably, PKI-based) is a solution that I think perfect. Igor From mark.wood@drcf.net Tue Jan 18 03:47:11 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2373A6FBD for ; Tue, 18 Jan 2011 03:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdOV-37xnQtP for ; Tue, 18 Jan 2011 03:47:10 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id B5D583A6FAD for ; Tue, 18 Jan 2011 03:47:09 -0800 (PST) X-Trace: 286049000/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Outlook 14.0 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK8NNU1RVitW/2dsb2JhbACkV3TCV4VQBI42hG8 X-IronPort-AV: E=Sophos;i="4.60,339,1291593600"; d="scan'208";a="286049000" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO host15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 18 Jan 2011 11:49:39 +0000 From: Sender: "mark.wood" To: References: <002201cbb636$27cdf790$7769e6b0$@engineer.com> <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net> In-Reply-To: <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net> Date: Tue, 18 Jan 2011 11:49:39 -0000 Message-ID: <002101cbb705$c9f3f900$5ddbeb00$@engineer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQF0pS6CAJ5dT1lIHb8TWmXb2B3iegJBN7VtAf32gfWUYrgE8A== Content-Language: en-us Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 11:47:11 -0000 Thanks Brian, Brian's point is well made and correct, thanks Brian, but there are some special issues that need to be borne in mind with some bearers. I first came into this project with the brief from the UN to "protect the (Mobile) mobile networks from catastrophic overload situations during disasters". When I "did the numbers" I discovered that the real problem is not what many think. The bottleneck is in the mobility management system (HLR/VLR/Paging/Access grant). EU sponsored Studies by Prof Sophocles Kiriazakos for the Greek government after the Athens earthquake and subsequent crash of the Greek networks, confirmed this. This is what lead me to work on cell broadcast (which does not use the mobility management system at all). I agree that it is reasonable to allow that the acknowledgments may indeed take much longer to 'traffic' than the outbound multicast message. Obviously the scale is the same both ways, but while the latency is critical going forward, the reverse path is not in the least bit time critical, so relatively slower 'best effort' bearers would be fine. The server which is wishing to know its subscribers got a message may send the message both by unicast and multicast (as mine do), but inevitably the acknowledgement will have to be unicast. There is no specific problem in allowing the acknowledgement of a multicast message by unicast means as long as we understand that the latency is indeterminate. (However since it's not clear when the ack may come, I send the message by both means simultaneously without waiting for acks.) My concern is really for the Mobile Network, at layer 2. For example if a large number of terminals all receive a multicast at the same time, then they will all want to acknowledge at the same time. This will result is a tsunami wave of random access bursts to the cells uplink timeslot, MSC call set up load, 'channel allocation algorithm' threads and SDCCH allocation attempts. Then there will be huge load on the SMS gateways. Mobiles that don't get an access grant message will obviously try again but for a while the whole mobility management system will be significantly loaded. This affects circuit switched voice just as much because the mobility management system is common for voice and SMS, (but maybe not GPRS?). Recall that in cellular network design, erlang calculations are done such that it's the assumption that only a small fraction of terminals will make random access burst attempts at any one time, so the mobility management system is designed for this load only. In other words, consider that a public warning message (such as a USA CMAS presidential message) will reach 100% of terminals simultaneously, rather than the small percentage that the signaling system can cope with. This is why both the CMAS and ETSI standards intentionally disallow embedded numbers or URLs for large scale (Public) warnings. So in fact the "scale" of the problem may not be as significant as the impact on the local infrastructure (such as a cell). Maybe "scale" is a less important factor than, let's say, penetration? On the other hand a smaller scale (of penetration) message would not have such a profound impact. So in some cases it may be reasonable to expect acknowledgements in 'best effort' time. Norway, for example, likes this approach. I am unclear as to if IP systems have such problems because there is not a 'stateful' mobility management system in the core and though acks are on a large scale, they represent very small packets of less than 1K each. Maybe the problem will go away in the future? Any comments on that? Warm regards Mark Wood DRCF. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, January 17, 2011 2:44 PM To: Cc: earlywarning@ietf.org Subject: Re: [Atoca] Requirement D2: "Large Audience" It may be, but I'd like to explore this a bit anyway. Millions of messages (acknowledgements) is a scale we can deal with today. Hundreds of millions is probably beyond what we can deal with in a response to a very large alert. Most systems consist of several smaller subsystems. The purpose of an acknowledgement is to make sure everyone got the message. If the subsystem can determine that every one of its clients got it, it can report that up the line. It can save missed acks for later analysis, or if there are few enough of them, report them up. This means messages national scale which have small effectivity times can't reasonably ask for message acknowledgement. Anything smaller than that probably can. Since most alerts really don't involve hundreds of millions of notifications, most alerts probably can ask for them. If your delivery mechanism is multicast, the multicast mechanism itself doesn't track who gets the alert in any way we can use. That implies something else is tracking who gets the alert, a complication that could loom large. Some systems do know who gets the alert (sometimes because it knows who it is connected to, and all of them get the alert). Certainly, anything with a subscription has the characteristic that the sender knows who all the recipients are. It's VERY valuable to know that every entity that should get the alert got it. The only other mechanism we have is some repeating of the sending in the hopes that everyone got it. In some cases you may have more than one "path" to the same recipient. That might be multiple devices, multiple services, or multiple logical or physical connections. You may try one first, and if that doesn't get an ack, try another. Although we often think of this mechanism as needing no more than seconds to deploy, in fact many alerts would be fine with a few minutes, and trying some things sequentially may make sense. So, yes, probably a Tsunami alert to all of East Asia can't ask for acknowledgements. An "Amber Alert" (possible abducted child) to a county might very well. Certainly, a snow emergency closing to the parents of an elementary school could. Brian From keith.drage@alcatel-lucent.com Tue Jan 18 04:50:15 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5C73A6FBB for ; Tue, 18 Jan 2011 04:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.63 X-Spam-Level: X-Spam-Status: No, score=-103.63 tagged_above=-999 required=5 tests=[AWL=-1.381, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5AEMkMFlsW9 for ; Tue, 18 Jan 2011 04:50:11 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 133A53A6FAD for ; Tue, 18 Jan 2011 04:50:10 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0ICqh0W007198 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 18 Jan 2011 13:52:43 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 18 Jan 2011 13:52:43 +0100 From: "DRAGE, Keith (Keith)" To: "earlywarning@ietf.org" Date: Tue, 18 Jan 2011 13:52:42 +0100 Thread-Topic: [Atoca] Requirement D2: "Large Audience" Thread-Index: Acu1kSZx02LQzsaJR2maLToInGbJVQAPvVXAAE+ImNA= Message-ID: References: <1285F7FB-FFBE-4B49-87F8-FCDCDF1F1AD3@gmx.net> <8B0A9FCBB9832F43971E38010638454F03F52595D3@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F52595D3@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 12:50:15 -0000 Surely if you supress the responses then it is no longer SIP, but some othe= r entirely new protocol. regards Keith=20 > -----Original Message----- > From: earlywarning-bounces@ietf.org=20 > [mailto:earlywarning-bounces@ietf.org] On Behalf Of Thomson, Martin > Sent: Sunday, January 16, 2011 11:15 PM > To: Hannes Tschofenig; Art Botterell > Cc: Faynberg, Igor (Igor); earlywarning@ietf.org > Subject: Re: [Atoca] Requirement D2: "Large Audience" >=20 > On Jan 15, 2011, at 11:58 PM, Art Botterell wrote: > > One difference in "broadcast" delivery is that it's frequntly=20 > > impractical and/or undesirable to try to track individual=20 > deliveries=20 > > or process individual responses. >=20 > If SIP is our delivery mechanism, can anything be done to=20 > suppress 200 responses to NOTIFY requests? Is there any=20 > point if we're using acknowledged transport like TCP? Is=20 > there a concern that unacknowledged packets (UDP) will get dropped? >=20 > The potential to create congestion worries me. >=20 > --Martin > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning > = From br@brianrosen.net Tue Jan 18 06:00:22 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E7428C125 for ; Tue, 18 Jan 2011 06:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCHYqdnEH4Up for ; Tue, 18 Jan 2011 06:00:20 -0800 (PST) Received: from barmail3.idig.net (barmail3.idig.net [64.34.111.253]) by core3.amsl.com (Postfix) with ESMTP id 3664928C10C for ; Tue, 18 Jan 2011 06:00:20 -0800 (PST) X-ASG-Debug-ID: 1295359376-0bbf1f930001-3cgWCS Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail3.idig.net with ESMTP id nolfizdk2zkdeZV7; Tue, 18 Jan 2011 06:02:56 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=dstr-ltx301.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PfC93-0002Fr-Na; Tue, 18 Jan 2011 06:02:55 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Atoca] Requirement D2: "Large Audience" Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <002101cbb705$c9f3f900$5ddbeb00$@engineer.com> Date: Tue, 18 Jan 2011 09:02:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <682E8C23-7988-4A4D-A03F-B00AB05CABF4@brianrosen.net> References: <002201cbb636$27cdf790$7769e6b0$@engineer.com> <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net> <002101cbb705$c9f3f900$5ddbeb00$@engineer.com> To: X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1295359376 X-Barracuda-URL: http://64.34.111.253:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.52732 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: earlywarning@ietf.org Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 14:00:22 -0000 I understand your concern. As I stated, in really, really large events, = it may not be practical to get confirmation. On the other hand, when = you have burst events that cause overload, we have developed techniques = for dealing with them. This specific problem is probably best addressed = by a random backoff delay. The devices, upon receiving a broadcast wait = a random time before attempting a reply, and if they encounter busy = conditions, increase the range of the delay and delay another random = time. Brian On Jan 18, 2011, at 6:49 AM, = wrote: >=20 > Thanks Brian, >=20 > Brian's point is well made and correct, thanks Brian, but there are = some > special issues that need to be borne in mind with some bearers. >=20 > I first came into this project with the brief from the UN to "protect = the > (Mobile) mobile networks from catastrophic overload situations during > disasters".=20 > When I "did the numbers" I discovered that the real problem is not = what many > think. The bottleneck is in the mobility management system > (HLR/VLR/Paging/Access grant). EU sponsored Studies by Prof Sophocles > Kiriazakos for the Greek government after the Athens earthquake and > subsequent crash of the Greek networks, confirmed this. This is what = lead > me to work on cell broadcast (which does not use the mobility = management > system at all). >=20 > I agree that it is reasonable to allow that the acknowledgments may = indeed > take much longer to 'traffic' than the outbound multicast message. = Obviously > the scale is the same both ways, but while the latency is critical = going > forward, the reverse path is not in the least bit time critical, so > relatively slower 'best effort' bearers would be fine. The server = which is > wishing to know its subscribers got a message may send the message = both by > unicast and multicast (as mine do), but inevitably the acknowledgement = will > have to be unicast. There is no specific problem in allowing the > acknowledgement of a multicast message by unicast means as long as we > understand that the latency is indeterminate. (However since it's not = clear > when the ack may come, I send the message by both means simultaneously > without waiting for acks.)=20 >=20 > My concern is really for the Mobile Network, at layer 2.=20 > For example if a large number of terminals all receive a multicast at = the > same time, then they will all want to acknowledge at the same time. = This > will result is a tsunami wave of random access bursts to the cells = uplink > timeslot, MSC call set up load, 'channel allocation algorithm' threads = and > SDCCH allocation attempts. Then there will be huge load on the SMS = gateways. > Mobiles that don't get an access grant message will obviously try = again but > for a while the whole mobility management system will be significantly > loaded. This affects circuit switched voice just as much because the > mobility management system is common for voice and SMS, (but maybe not > GPRS?). Recall that in cellular network design, erlang calculations = are done > such that it's the assumption that only a small fraction of terminals = will > make random access burst attempts at any one time, so the mobility > management system is designed for this load only. >=20 > In other words, consider that a public warning message (such as a USA = CMAS > presidential message) will reach 100% of terminals simultaneously, = rather > than the small percentage that the signaling system can cope with. = This is > why both the CMAS and ETSI standards intentionally disallow embedded = numbers > or URLs for large scale (Public) warnings. >=20 > So in fact the "scale" of the problem may not be as significant as the > impact on the local infrastructure (such as a cell). Maybe "scale" is = a less > important factor than, let's say, penetration? =20 >=20 > On the other hand a smaller scale (of penetration) message would not = have > such a profound impact. So in some cases it may be reasonable to = expect > acknowledgements in 'best effort' time. Norway, for example, likes = this > approach. >=20 > I am unclear as to if IP systems have such problems because there is = not a > 'stateful' mobility management system in the core and though acks are = on a > large scale, they represent very small packets of less than 1K each. = Maybe > the problem will go away in the future? Any comments on that? >=20 > Warm regards Mark Wood DRCF. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Monday, January 17, 2011 2:44 PM > To: > Cc: earlywarning@ietf.org > Subject: Re: [Atoca] Requirement D2: "Large Audience" >=20 > It may be, but I'd like to explore this a bit anyway. >=20 > Millions of messages (acknowledgements) is a scale we can deal with = today. > Hundreds of millions is probably beyond what we can deal with in a = response > to a very large alert. >=20 > Most systems consist of several smaller subsystems. The purpose of an > acknowledgement is to make sure everyone got the message. If the = subsystem > can determine that every one of its clients got it, it can report that = up > the line. It can save missed acks for later analysis, or if there are = few > enough of them, report them up. >=20 > This means messages national scale which have small effectivity times = can't > reasonably ask for message acknowledgement. Anything smaller than = that > probably can. >=20 > Since most alerts really don't involve hundreds of millions of > notifications, most alerts probably can ask for them. >=20 > If your delivery mechanism is multicast, the multicast mechanism = itself > doesn't track who gets the alert in any way we can use. That implies > something else is tracking who gets the alert, a complication that = could > loom large. Some systems do know who gets the alert (sometimes = because it > knows who it is connected to, and all of them get the alert). = Certainly, > anything with a subscription has the characteristic that the sender = knows > who all the recipients are. =20 >=20 > It's VERY valuable to know that every entity that should get the alert = got > it. The only other mechanism we have is some repeating of the sending = in > the hopes that everyone got it. In some cases you may have more than = one > "path" to the same recipient. That might be multiple devices, = multiple > services, or multiple logical or physical connections. You may try = one > first, and if that doesn't get an ack, try another. Although we often = think > of this mechanism as needing no more than seconds to deploy, in fact = many > alerts would be fine with a few minutes, and trying some things = sequentially > may make sense. >=20 > So, yes, probably a Tsunami alert to all of East Asia can't ask for > acknowledgements. An "Amber Alert" (possible abducted child) to a = county > might very well. Certainly, a snow emergency closing to the parents = of an > elementary school could. >=20 > Brian >=20 >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From BD2985@att.com Tue Jan 18 07:42:44 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A505C28C1BE for ; Tue, 18 Jan 2011 07:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.18 X-Spam-Level: X-Spam-Status: No, score=-106.18 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id two2ATzG3iWM for ; Tue, 18 Jan 2011 07:42:43 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 063C728C1BD for ; Tue, 18 Jan 2011 07:42:42 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: BD2985@att.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1295365519!2777691!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 11355 invoked from network); 18 Jan 2011 15:45:19 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-3.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Jan 2011 15:45:19 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p0IFjIhE018372; Tue, 18 Jan 2011 09:45:19 -0600 Received: from td03xsmtp005.US.Cingular.Net (td03xsmtp005.us.cingular.net [135.179.64.44]) by tlph064.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p0IFjCAi018175; Tue, 18 Jan 2011 09:45:12 -0600 Received: from bd01xsmtp004.US.Cingular.Net ([135.163.18.45]) by td03xsmtp005.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 09:45:11 -0600 Received: from BD01MSXMB016.US.Cingular.Net ([135.214.27.50]) by bd01xsmtp004.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 07:45:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 18 Jan 2011 07:45:09 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Atoca] Requirement D2: "Large Audience" Thread-Index: AQF0pS6CAJ5dT1lIHb8TWmXb2B3iegJBN7VtAf32gfWUYrgE8IAAUY3m From: "DALY, BRIAN K (ATTCINW)" To: , X-OriginalArrivalTime: 18 Jan 2011 15:45:10.0491 (UTC) FILETIME=[B050B2B0:01CBB726] Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:42:44 -0000 TWFyayAtIHlvdSBoYXZlIGRlc2NyaWJlZCB0aGUgbG9naWMgYmVoaW5kIHRoZSBkZXZlbG9wbWVu dCBvZiBDTUFTIGFuZCB3aGF0IHRoYXQgaXMgdGhlIGFsZXJ0aW5nIG1lY2hhbmlzbSB0aGF0IHdp bGwgYmUgdXNlZCBpbiB0aGUgVVMgb24gQ01SUyBuZXR3b3JrcyBhcyBkZWZpbmVkIHVuZGVyIEZD QyBydWxlcy4gSSB3YXMgdGhlIENoYWlyIG9mIHRoZSBDb21tdW5pY2F0aW9uIFRlY2hub2xvZ3kg R3JvdXAgdW5kZXIgdGhlIEZDQ3MgQ01TQUFDIHdoaWNoIGRldmVsb3BlZCBDTUFTTSBHbG9iYWxs eSB0aGlzIGlzIHRoZSBQdWJsaWMgV2FybmluZyBTeXN0ZW0gYXMgZGVmaW5lZCBpbiAzR1BQIHN0 YW5kYXJkcy4NCg0KU01TIGZvciBhbnkgdHlwZSBvZiBhY2tub3dsZWRnbWVudCBpbiBhIG1hc3Mg bm90aWZpY2F0aW9uIG5ldHdvcmsgd2lsbCBub3Qgd29yayBhbmQgd2lsbCBkbyBtb3JlIGhhcm0g dGhhbiBnb29kLiBUaGlzIGlzIHdlaHkgdGhlIEZDQyBydWxlcyBkbyBub3QgcmVxdWlyZSBhY2tu b3dsZWRnbWVudHMuIA0KQnJpYW4gSy4gRGFseQ0KICAgU2VudCB0byB5b3UgYnkgQVQmVC4uLiAN CiAgIEFtZXJpY2EncyBGYXN0ZXN0IE1vYmlsZSBCcm9hZGJhbmQNCiAgICAgICBOZXR3b3JrLiAg UmV0aGluayBQb3NzaWJsZS4NCiAgICsxLjQyNS41ODAuNjg3Mw0KLS0tLS0tLQ0KU2VudCBmcm9t IG15IEJsYWNrYmVycnkNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogZWFy bHl3YXJuaW5nLWJvdW5jZXNAaWV0Zi5vcmcgPGVhcmx5d2FybmluZy1ib3VuY2VzQGlldGYub3Jn Pg0KVG86IGVhcmx5d2FybmluZ0BpZXRmLm9yZyA8ZWFybHl3YXJuaW5nQGlldGYub3JnPg0KU2Vu dDogVHVlIEphbiAxOCAwMzo0OTozOSAyMDExDQpTdWJqZWN0OiBSZTogW0F0b2NhXSBSZXF1aXJl bWVudCBEMjogIkxhcmdlIEF1ZGllbmNlIg0KDQoNClRoYW5rcyBCcmlhbiwNCg0KQnJpYW4ncyBw b2ludCBpcyB3ZWxsIG1hZGUgYW5kIGNvcnJlY3QsIHRoYW5rcyBCcmlhbiwgYnV0IHRoZXJlIGFy ZSBzb21lDQpzcGVjaWFsIGlzc3VlcyB0aGF0IG5lZWQgdG8gYmUgYm9ybmUgaW4gbWluZCB3aXRo IHNvbWUgYmVhcmVycy4NCg0KSSBmaXJzdCBjYW1lIGludG8gdGhpcyBwcm9qZWN0IHdpdGggdGhl IGJyaWVmIGZyb20gdGhlIFVOICB0byAicHJvdGVjdCB0aGUNCihNb2JpbGUpIG1vYmlsZSBuZXR3 b3JrcyBmcm9tIGNhdGFzdHJvcGhpYyBvdmVybG9hZCBzaXR1YXRpb25zIGR1cmluZw0KZGlzYXN0 ZXJzIi4gDQpXaGVuIEkgImRpZCB0aGUgbnVtYmVycyIgSSBkaXNjb3ZlcmVkIHRoYXQgdGhlIHJl YWwgcHJvYmxlbSBpcyBub3Qgd2hhdCBtYW55DQp0aGluay4gVGhlIGJvdHRsZW5lY2sgaXMgaW4g dGhlIG1vYmlsaXR5IG1hbmFnZW1lbnQgc3lzdGVtDQooSExSL1ZMUi9QYWdpbmcvQWNjZXNzIGdy YW50KS4gRVUgc3BvbnNvcmVkIFN0dWRpZXMgYnkgUHJvZiBTb3Bob2NsZXMNCktpcmlhemFrb3Mg IGZvciB0aGUgR3JlZWsgZ292ZXJubWVudCBhZnRlciB0aGUgQXRoZW5zIGVhcnRocXVha2UgYW5k DQpzdWJzZXF1ZW50IGNyYXNoIG9mIHRoZSBHcmVlayBuZXR3b3JrcywgY29uZmlybWVkIHRoaXMu ICBUaGlzIGlzIHdoYXQgbGVhZA0KbWUgdG8gd29yayBvbiBjZWxsIGJyb2FkY2FzdCAod2hpY2gg ZG9lcyBub3QgdXNlIHRoZSBtb2JpbGl0eSBtYW5hZ2VtZW50DQpzeXN0ZW0gYXQgYWxsKS4NCg0K SSBhZ3JlZSB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gYWxsb3cgdGhhdCB0aGUgYWNrbm93bGVk Z21lbnRzIG1heSBpbmRlZWQNCnRha2UgbXVjaCBsb25nZXIgdG8gJ3RyYWZmaWMnIHRoYW4gdGhl IG91dGJvdW5kIG11bHRpY2FzdCBtZXNzYWdlLiBPYnZpb3VzbHkNCnRoZSBzY2FsZSBpcyB0aGUg c2FtZSBib3RoIHdheXMsIGJ1dCB3aGlsZSB0aGUgbGF0ZW5jeSBpcyBjcml0aWNhbCBnb2luZw0K Zm9yd2FyZCwgdGhlIHJldmVyc2UgcGF0aCBpcyBub3QgaW4gdGhlIGxlYXN0IGJpdCB0aW1lIGNy aXRpY2FsLCBzbw0KcmVsYXRpdmVseSBzbG93ZXIgJ2Jlc3QgZWZmb3J0JyAgYmVhcmVycyB3b3Vs ZCBiZSBmaW5lLiBUaGUgc2VydmVyIHdoaWNoIGlzDQp3aXNoaW5nIHRvIGtub3cgaXRzIHN1YnNj cmliZXJzIGdvdCBhIG1lc3NhZ2UgbWF5IHNlbmQgdGhlIG1lc3NhZ2UgYm90aCBieQ0KdW5pY2Fz dCBhbmQgbXVsdGljYXN0IChhcyBtaW5lIGRvKSwgYnV0IGluZXZpdGFibHkgdGhlIGFja25vd2xl ZGdlbWVudCB3aWxsDQpoYXZlIHRvIGJlIHVuaWNhc3QuIFRoZXJlIGlzIG5vIHNwZWNpZmljIHBy b2JsZW0gaW4gYWxsb3dpbmcgdGhlDQphY2tub3dsZWRnZW1lbnQgb2YgYSBtdWx0aWNhc3QgbWVz c2FnZSBieSB1bmljYXN0IG1lYW5zIGFzIGxvbmcgYXMgd2UNCnVuZGVyc3RhbmQgdGhhdCB0aGUg bGF0ZW5jeSBpcyBpbmRldGVybWluYXRlLiAoSG93ZXZlciBzaW5jZSBpdCdzIG5vdCBjbGVhcg0K d2hlbiB0aGUgYWNrIG1heSBjb21lLCBJIHNlbmQgdGhlIG1lc3NhZ2UgYnkgYm90aCBtZWFucyBz aW11bHRhbmVvdXNseQ0Kd2l0aG91dCB3YWl0aW5nIGZvciBhY2tzLikgDQoNCk15IGNvbmNlcm4g aXMgcmVhbGx5IGZvciB0aGUgTW9iaWxlIE5ldHdvcmssIGF0IGxheWVyIDIuIA0KRm9yIGV4YW1w bGUgaWYgYSBsYXJnZSBudW1iZXIgb2YgdGVybWluYWxzIGFsbCByZWNlaXZlIGEgbXVsdGljYXN0 IGF0IHRoZQ0Kc2FtZSB0aW1lLCB0aGVuIHRoZXkgd2lsbCBhbGwgd2FudCB0byBhY2tub3dsZWRn ZSBhdCB0aGUgc2FtZSB0aW1lLiBUaGlzDQp3aWxsIHJlc3VsdCBpcyBhIHRzdW5hbWkgd2F2ZSBv ZiByYW5kb20gYWNjZXNzIGJ1cnN0cyB0byB0aGUgY2VsbHMgdXBsaW5rDQp0aW1lc2xvdCwgTVND IGNhbGwgc2V0IHVwIGxvYWQsICdjaGFubmVsIGFsbG9jYXRpb24gYWxnb3JpdGhtJyB0aHJlYWRz IGFuZA0KU0RDQ0ggYWxsb2NhdGlvbiBhdHRlbXB0cy4gVGhlbiB0aGVyZSB3aWxsIGJlIGh1Z2Ug bG9hZCBvbiB0aGUgU01TIGdhdGV3YXlzLg0KTW9iaWxlcyB0aGF0IGRvbid0IGdldCBhbiBhY2Nl c3MgZ3JhbnQgbWVzc2FnZSB3aWxsIG9idmlvdXNseSB0cnkgYWdhaW4gYnV0DQpmb3IgYSB3aGls ZSB0aGUgd2hvbGUgbW9iaWxpdHkgbWFuYWdlbWVudCBzeXN0ZW0gd2lsbCBiZSBzaWduaWZpY2Fu dGx5DQpsb2FkZWQuIFRoaXMgYWZmZWN0cyBjaXJjdWl0IHN3aXRjaGVkIHZvaWNlIGp1c3QgYXMg bXVjaCBiZWNhdXNlIHRoZQ0KbW9iaWxpdHkgbWFuYWdlbWVudCBzeXN0ZW0gaXMgY29tbW9uIGZv ciB2b2ljZSBhbmQgU01TLCAoYnV0IG1heWJlIG5vdA0KR1BSUz8pLiBSZWNhbGwgdGhhdCBpbiBj ZWxsdWxhciBuZXR3b3JrIGRlc2lnbiwgZXJsYW5nIGNhbGN1bGF0aW9ucyBhcmUgZG9uZQ0Kc3Vj aCB0aGF0IGl0J3MgdGhlIGFzc3VtcHRpb24gdGhhdCBvbmx5IGEgc21hbGwgZnJhY3Rpb24gb2Yg dGVybWluYWxzIHdpbGwNCm1ha2UgcmFuZG9tIGFjY2VzcyBidXJzdCBhdHRlbXB0cyBhdCBhbnkg b25lIHRpbWUsIHNvIHRoZSBtb2JpbGl0eQ0KbWFuYWdlbWVudCBzeXN0ZW0gaXMgZGVzaWduZWQg Zm9yIHRoaXMgbG9hZCBvbmx5Lg0KDQpJbiBvdGhlciB3b3JkcywgY29uc2lkZXIgdGhhdCBhIHB1 YmxpYyB3YXJuaW5nIG1lc3NhZ2UgKHN1Y2ggYXMgYSBVU0EgIENNQVMNCnByZXNpZGVudGlhbCBt ZXNzYWdlKSB3aWxsIHJlYWNoIDEwMCUgb2YgdGVybWluYWxzIHNpbXVsdGFuZW91c2x5LCByYXRo ZXINCnRoYW4gdGhlIHNtYWxsIHBlcmNlbnRhZ2UgdGhhdCB0aGUgc2lnbmFsaW5nIHN5c3RlbSBj YW4gY29wZSB3aXRoLiBUaGlzIGlzDQp3aHkgYm90aCB0aGUgQ01BUyBhbmQgRVRTSSBzdGFuZGFy ZHMgaW50ZW50aW9uYWxseSBkaXNhbGxvdyBlbWJlZGRlZCBudW1iZXJzDQpvciBVUkxzIGZvciBs YXJnZSBzY2FsZSAoUHVibGljKSB3YXJuaW5ncy4NCg0KU28gaW4gZmFjdCB0aGUgInNjYWxlIiBv ZiB0aGUgcHJvYmxlbSBtYXkgbm90IGJlIGFzIHNpZ25pZmljYW50IGFzIHRoZQ0KaW1wYWN0IG9u IHRoZSBsb2NhbCBpbmZyYXN0cnVjdHVyZSAoc3VjaCBhcyBhIGNlbGwpLiBNYXliZSAic2NhbGUi IGlzIGEgbGVzcw0KaW1wb3J0YW50IGZhY3RvciB0aGFuLCBsZXQncyBzYXksIHBlbmV0cmF0aW9u PyAgDQoNCk9uIHRoZSBvdGhlciBoYW5kIGEgc21hbGxlciBzY2FsZSAob2YgcGVuZXRyYXRpb24p ICBtZXNzYWdlIHdvdWxkIG5vdCBoYXZlDQpzdWNoIGEgcHJvZm91bmQgaW1wYWN0LiBTbyBpbiBz b21lIGNhc2VzIGl0IG1heSBiZSByZWFzb25hYmxlIHRvIGV4cGVjdA0KYWNrbm93bGVkZ2VtZW50 cyBpbiAnYmVzdCBlZmZvcnQnICB0aW1lLiBOb3J3YXksIGZvciBleGFtcGxlLCAgbGlrZXMgdGhp cw0KYXBwcm9hY2guDQoNCkkgYW0gdW5jbGVhciBhcyB0byBpZiBJUCBzeXN0ZW1zIGhhdmUgc3Vj aCBwcm9ibGVtcyBiZWNhdXNlIHRoZXJlIGlzIG5vdCBhDQonc3RhdGVmdWwnICBtb2JpbGl0eSBt YW5hZ2VtZW50IHN5c3RlbSBpbiB0aGUgY29yZSBhbmQgdGhvdWdoIGFja3MgYXJlIG9uIGENCmxh cmdlIHNjYWxlLCB0aGV5IHJlcHJlc2VudCB2ZXJ5IHNtYWxsIHBhY2tldHMgb2YgbGVzcyB0aGFu IDFLIGVhY2guIE1heWJlDQp0aGUgcHJvYmxlbSB3aWxsIGdvIGF3YXkgaW4gdGhlIGZ1dHVyZT8g QW55IGNvbW1lbnRzIG9uIHRoYXQ/DQoNCldhcm0gcmVnYXJkcyBNYXJrIFdvb2QgRFJDRi4NCg0K DQoNCg0KIA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBSb3Nl biBbbWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0XSANClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxNywg MjAxMSAyOjQ0IFBNDQpUbzogPG1hcmsud29vZEBlbmdpbmVlci5jb20+DQpDYzogZWFybHl3YXJu aW5nQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0F0b2NhXSBSZXF1aXJlbWVudCBEMjogIkxhcmdl IEF1ZGllbmNlIg0KDQpJdCBtYXkgYmUsIGJ1dCBJJ2QgbGlrZSB0byBleHBsb3JlIHRoaXMgYSBi aXQgYW55d2F5Lg0KDQpNaWxsaW9ucyBvZiBtZXNzYWdlcyAoYWNrbm93bGVkZ2VtZW50cykgaXMg YSBzY2FsZSB3ZSBjYW4gZGVhbCB3aXRoIHRvZGF5Lg0KSHVuZHJlZHMgb2YgbWlsbGlvbnMgaXMg cHJvYmFibHkgYmV5b25kIHdoYXQgd2UgY2FuIGRlYWwgd2l0aCBpbiBhIHJlc3BvbnNlDQp0byBh IHZlcnkgbGFyZ2UgYWxlcnQuDQoNCk1vc3Qgc3lzdGVtcyBjb25zaXN0IG9mIHNldmVyYWwgc21h bGxlciBzdWJzeXN0ZW1zLiAgVGhlIHB1cnBvc2Ugb2YgYW4NCmFja25vd2xlZGdlbWVudCBpcyB0 byBtYWtlIHN1cmUgZXZlcnlvbmUgZ290IHRoZSBtZXNzYWdlLiAgSWYgdGhlIHN1YnN5c3RlbQ0K Y2FuIGRldGVybWluZSB0aGF0IGV2ZXJ5IG9uZSBvZiBpdHMgY2xpZW50cyBnb3QgaXQsIGl0IGNh biByZXBvcnQgdGhhdCB1cA0KdGhlIGxpbmUuICBJdCBjYW4gc2F2ZSBtaXNzZWQgYWNrcyBmb3Ig bGF0ZXIgYW5hbHlzaXMsIG9yIGlmIHRoZXJlIGFyZSBmZXcNCmVub3VnaCBvZiB0aGVtLCByZXBv cnQgdGhlbSB1cC4NCg0KVGhpcyBtZWFucyBtZXNzYWdlcyBuYXRpb25hbCBzY2FsZSB3aGljaCBo YXZlIHNtYWxsIGVmZmVjdGl2aXR5IHRpbWVzIGNhbid0DQpyZWFzb25hYmx5IGFzayBmb3IgbWVz c2FnZSBhY2tub3dsZWRnZW1lbnQuICBBbnl0aGluZyBzbWFsbGVyIHRoYW4gdGhhdA0KcHJvYmFi bHkgY2FuLg0KDQpTaW5jZSBtb3N0IGFsZXJ0cyByZWFsbHkgZG9uJ3QgaW52b2x2ZSBodW5kcmVk cyBvZiBtaWxsaW9ucyBvZg0Kbm90aWZpY2F0aW9ucywgbW9zdCBhbGVydHMgcHJvYmFibHkgY2Fu IGFzayBmb3IgdGhlbS4NCg0KSWYgeW91ciBkZWxpdmVyeSBtZWNoYW5pc20gaXMgbXVsdGljYXN0 LCB0aGUgbXVsdGljYXN0IG1lY2hhbmlzbSBpdHNlbGYNCmRvZXNuJ3QgdHJhY2sgd2hvIGdldHMg dGhlIGFsZXJ0IGluIGFueSB3YXkgd2UgY2FuIHVzZS4gIFRoYXQgaW1wbGllcw0Kc29tZXRoaW5n IGVsc2UgaXMgdHJhY2tpbmcgd2hvIGdldHMgdGhlIGFsZXJ0LCBhIGNvbXBsaWNhdGlvbiB0aGF0 IGNvdWxkDQpsb29tIGxhcmdlLiAgU29tZSBzeXN0ZW1zIGRvIGtub3cgd2hvIGdldHMgdGhlIGFs ZXJ0IChzb21ldGltZXMgYmVjYXVzZSBpdA0Ka25vd3Mgd2hvIGl0IGlzIGNvbm5lY3RlZCB0bywg YW5kIGFsbCBvZiB0aGVtIGdldCB0aGUgYWxlcnQpLiAgQ2VydGFpbmx5LA0KYW55dGhpbmcgd2l0 aCBhIHN1YnNjcmlwdGlvbiBoYXMgdGhlIGNoYXJhY3RlcmlzdGljIHRoYXQgdGhlIHNlbmRlciBr bm93cw0Kd2hvIGFsbCB0aGUgcmVjaXBpZW50cyBhcmUuICANCg0KSXQncyBWRVJZIHZhbHVhYmxl IHRvIGtub3cgdGhhdCBldmVyeSBlbnRpdHkgdGhhdCBzaG91bGQgZ2V0IHRoZSBhbGVydCBnb3QN Cml0LiAgVGhlIG9ubHkgb3RoZXIgbWVjaGFuaXNtIHdlIGhhdmUgaXMgc29tZSByZXBlYXRpbmcg b2YgdGhlIHNlbmRpbmcgaW4NCnRoZSBob3BlcyB0aGF0IGV2ZXJ5b25lIGdvdCBpdC4gIEluIHNv bWUgY2FzZXMgeW91IG1heSBoYXZlIG1vcmUgdGhhbiBvbmUNCiJwYXRoIiB0byB0aGUgc2FtZSBy ZWNpcGllbnQuICBUaGF0IG1pZ2h0IGJlIG11bHRpcGxlIGRldmljZXMsIG11bHRpcGxlDQpzZXJ2 aWNlcywgb3IgbXVsdGlwbGUgbG9naWNhbCBvciBwaHlzaWNhbCBjb25uZWN0aW9ucy4gIFlvdSBt YXkgdHJ5IG9uZQ0KZmlyc3QsIGFuZCBpZiB0aGF0IGRvZXNuJ3QgZ2V0IGFuIGFjaywgdHJ5IGFu b3RoZXIuICBBbHRob3VnaCB3ZSBvZnRlbiB0aGluaw0Kb2YgdGhpcyBtZWNoYW5pc20gYXMgbmVl ZGluZyBubyBtb3JlIHRoYW4gc2Vjb25kcyB0byBkZXBsb3ksIGluIGZhY3QgbWFueQ0KYWxlcnRz IHdvdWxkIGJlIGZpbmUgd2l0aCBhIGZldyBtaW51dGVzLCBhbmQgdHJ5aW5nIHNvbWUgdGhpbmdz IHNlcXVlbnRpYWxseQ0KbWF5IG1ha2Ugc2Vuc2UuDQoNClNvLCB5ZXMsIHByb2JhYmx5IGEgVHN1 bmFtaSBhbGVydCB0byBhbGwgb2YgRWFzdCBBc2lhIGNhbid0IGFzayBmb3INCmFja25vd2xlZGdl bWVudHMuICBBbiAiQW1iZXIgQWxlcnQiIChwb3NzaWJsZSBhYmR1Y3RlZCBjaGlsZCkgdG8gYSBj b3VudHkNCm1pZ2h0IHZlcnkgd2VsbC4gIENlcnRhaW5seSwgYSBzbm93IGVtZXJnZW5jeSBjbG9z aW5nIHRvIHRoZSBwYXJlbnRzIG9mIGFuDQplbGVtZW50YXJ5IHNjaG9vbCBjb3VsZC4NCg0KQnJp YW4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ZWFybHl3YXJuaW5nIG1haWxpbmcgbGlzdA0KZWFybHl3YXJuaW5nQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vhcmx5d2FybmluZw0K From br@brianrosen.net Tue Jan 18 07:58:20 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74D63A702B for ; Tue, 18 Jan 2011 07:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAyvFnMpTV6L for ; Tue, 18 Jan 2011 07:58:19 -0800 (PST) Received: from barmail2.idig.net (barmail2.idig.net [64.34.111.252]) by core3.amsl.com (Postfix) with ESMTP id 7A6FD3A702A for ; Tue, 18 Jan 2011 07:58:19 -0800 (PST) X-ASG-Debug-ID: 1295366419-23c536c10001-3cgWCS Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail2.idig.net with ESMTP id td6bkEQ8jt11aXTL; Tue, 18 Jan 2011 08:00:19 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=dstr-ltx301.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PfDyf-0000j1-4f; Tue, 18 Jan 2011 08:00:19 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Atoca] Requirement D2: "Large Audience" Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Tue, 18 Jan 2011 11:00:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <31F7811B-FE8D-468B-9A71-A62161AC4ADD@brianrosen.net> References: To: "DALY, BRIAN K (ATTCINW)" X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1295366419 X-Barracuda-URL: http://64.34.111.252:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.52739 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: earlywarning@ietf.org Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:58:21 -0000 I certainly agree that ATOCA would not make use of SMS in any form of = acknowledgement. Similarly, I don't think we would use mobility = management systems. We would specify IP based mechanisms - exchanges of packets on the IP = network. Brian On Jan 18, 2011, at 10:45 AM, DALY, BRIAN K (ATTCINW) wrote: > Mark - you have described the logic behind the development of CMAS and = what that is the alerting mechanism that will be used in the US on CMRS = networks as defined under FCC rules. I was the Chair of the = Communication Technology Group under the FCCs CMSAAC which developed = CMASM Globally this is the Public Warning System as defined in 3GPP = standards. >=20 > SMS for any type of acknowledgment in a mass notification network will = not work and will do more harm than good. This is wehy the FCC rules do = not require acknowledgments.=20 > Brian K. Daly > Sent to you by AT&T...=20 > America's Fastest Mobile Broadband > Network. Rethink Possible. > +1.425.580.6873 > ------- > Sent from my Blackberry >=20 > ----- Original Message ----- > From: earlywarning-bounces@ietf.org > To: earlywarning@ietf.org > Sent: Tue Jan 18 03:49:39 2011 > Subject: Re: [Atoca] Requirement D2: "Large Audience" >=20 >=20 > Thanks Brian, >=20 > Brian's point is well made and correct, thanks Brian, but there are = some > special issues that need to be borne in mind with some bearers. >=20 > I first came into this project with the brief from the UN to "protect = the > (Mobile) mobile networks from catastrophic overload situations during > disasters".=20 > When I "did the numbers" I discovered that the real problem is not = what many > think. The bottleneck is in the mobility management system > (HLR/VLR/Paging/Access grant). EU sponsored Studies by Prof Sophocles > Kiriazakos for the Greek government after the Athens earthquake and > subsequent crash of the Greek networks, confirmed this. This is what = lead > me to work on cell broadcast (which does not use the mobility = management > system at all). >=20 > I agree that it is reasonable to allow that the acknowledgments may = indeed > take much longer to 'traffic' than the outbound multicast message. = Obviously > the scale is the same both ways, but while the latency is critical = going > forward, the reverse path is not in the least bit time critical, so > relatively slower 'best effort' bearers would be fine. The server = which is > wishing to know its subscribers got a message may send the message = both by > unicast and multicast (as mine do), but inevitably the acknowledgement = will > have to be unicast. There is no specific problem in allowing the > acknowledgement of a multicast message by unicast means as long as we > understand that the latency is indeterminate. (However since it's not = clear > when the ack may come, I send the message by both means simultaneously > without waiting for acks.)=20 >=20 > My concern is really for the Mobile Network, at layer 2.=20 > For example if a large number of terminals all receive a multicast at = the > same time, then they will all want to acknowledge at the same time. = This > will result is a tsunami wave of random access bursts to the cells = uplink > timeslot, MSC call set up load, 'channel allocation algorithm' threads = and > SDCCH allocation attempts. Then there will be huge load on the SMS = gateways. > Mobiles that don't get an access grant message will obviously try = again but > for a while the whole mobility management system will be significantly > loaded. This affects circuit switched voice just as much because the > mobility management system is common for voice and SMS, (but maybe not > GPRS?). Recall that in cellular network design, erlang calculations = are done > such that it's the assumption that only a small fraction of terminals = will > make random access burst attempts at any one time, so the mobility > management system is designed for this load only. >=20 > In other words, consider that a public warning message (such as a USA = CMAS > presidential message) will reach 100% of terminals simultaneously, = rather > than the small percentage that the signaling system can cope with. = This is > why both the CMAS and ETSI standards intentionally disallow embedded = numbers > or URLs for large scale (Public) warnings. >=20 > So in fact the "scale" of the problem may not be as significant as the > impact on the local infrastructure (such as a cell). Maybe "scale" is = a less > important factor than, let's say, penetration? =20 >=20 > On the other hand a smaller scale (of penetration) message would not = have > such a profound impact. So in some cases it may be reasonable to = expect > acknowledgements in 'best effort' time. Norway, for example, likes = this > approach. >=20 > I am unclear as to if IP systems have such problems because there is = not a > 'stateful' mobility management system in the core and though acks are = on a > large scale, they represent very small packets of less than 1K each. = Maybe > the problem will go away in the future? Any comments on that? >=20 > Warm regards Mark Wood DRCF. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Monday, January 17, 2011 2:44 PM > To: > Cc: earlywarning@ietf.org > Subject: Re: [Atoca] Requirement D2: "Large Audience" >=20 > It may be, but I'd like to explore this a bit anyway. >=20 > Millions of messages (acknowledgements) is a scale we can deal with = today. > Hundreds of millions is probably beyond what we can deal with in a = response > to a very large alert. >=20 > Most systems consist of several smaller subsystems. The purpose of an > acknowledgement is to make sure everyone got the message. If the = subsystem > can determine that every one of its clients got it, it can report that = up > the line. It can save missed acks for later analysis, or if there are = few > enough of them, report them up. >=20 > This means messages national scale which have small effectivity times = can't > reasonably ask for message acknowledgement. Anything smaller than = that > probably can. >=20 > Since most alerts really don't involve hundreds of millions of > notifications, most alerts probably can ask for them. >=20 > If your delivery mechanism is multicast, the multicast mechanism = itself > doesn't track who gets the alert in any way we can use. That implies > something else is tracking who gets the alert, a complication that = could > loom large. Some systems do know who gets the alert (sometimes = because it > knows who it is connected to, and all of them get the alert). = Certainly, > anything with a subscription has the characteristic that the sender = knows > who all the recipients are. =20 >=20 > It's VERY valuable to know that every entity that should get the alert = got > it. The only other mechanism we have is some repeating of the sending = in > the hopes that everyone got it. In some cases you may have more than = one > "path" to the same recipient. That might be multiple devices, = multiple > services, or multiple logical or physical connections. You may try = one > first, and if that doesn't get an ack, try another. Although we often = think > of this mechanism as needing no more than seconds to deploy, in fact = many > alerts would be fine with a few minutes, and trying some things = sequentially > may make sense. >=20 > So, yes, probably a Tsunami alert to all of East Asia can't ask for > acknowledgements. An "Amber Alert" (possible abducted child) to a = county > might very well. Certainly, a snow emergency closing to the parents = of an > elementary school could. >=20 > Brian >=20 >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From hannes.tschofenig@gmx.net Tue Jan 18 09:45:56 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B7A28C103 for ; Tue, 18 Jan 2011 09:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.864 X-Spam-Level: X-Spam-Status: No, score=-101.864 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eu7PPsoiwkrb for ; Tue, 18 Jan 2011 09:45:54 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 549FD3A6FE2 for ; Tue, 18 Jan 2011 09:45:54 -0800 (PST) Received: (qmail invoked by alias); 18 Jan 2011 17:48:31 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp053) with SMTP; 18 Jan 2011 18:48:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/OEC9uWnTOBOSQGDtIO8Z4bUbleCpvs1jZ6D4sxv noQuRt2GebT5Aq Message-ID: <4D35D26E.5070809@gmx.net> Date: Tue, 18 Jan 2011 19:48:30 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <20110115190001.18610.17937.idtracker@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "earlywarning@ietf.org" Subject: Re: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 17:45:56 -0000 Hey Keith, thanks for your comments! Please find my comments below: On 1/17/2011 7:50 PM, DRAGE, Keith (Keith) wrote: > I was scanning the charter to see if we had requirements for all items mentioned in the charter. > > For the following text: > > "Which devices should get alerts is primarily driven by location. > The first set of recipients that must be catered for are those > within the area identified by the alert originator to be affected > by the emergency event. " > > I could see the requiremnet for recipient control of this: > > Req-S2: > > The protocol solution MUST allow a potential Recipient to express > the geographical area it wants to receive alerts about. > > But I could see no corresponding require for the sender to be able to indicate which geographic locations it wants its alerts to go to. Good catch. A question I have in return is whether this isn't implicitly covered by the fact that the alert message itself may contain location information about the relevant area. For example, take a look at the following alert message: --------------------- KSTO1055887203 KSTO@NWS.NOAA.GOV 2003-06-17T14:57:00-07:00 Actual Alert Public Met SEVERE THUNDERSTORM Severe Likely NATIONAL WEATHER SERVICE SACRAMENTO SEVERE THUNDERSTORM WARNING AT 254 PM PDT... NATIONAL WEATHER SERVICE DOPPLER RADAR INDICATED A SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY... OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL... INTENSE RAIN AND STRONG DAMAGING WINDS ARE LIKELY WITH THIS STORM TAKE COVER IN A SUBSTANTIAL SHELTER UNTIL THE STORM PASSES BARUFFALDI/JUSKIE EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA, EXTREME NORTHEASTERN CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN ALPINE COUNTY IN CALIFORNIA 38.47,-120.14 38.34,-119.95 38.52,-119.74 38.62,-119.89 38.47,-120.14 ----------- So, are you asking to have it stated explicitly that this information has to be there or do you want to have the area description additionally available in SIP itself. Both requests would be useful. The latter one is also relevant given the discussions we had in ECRIT on the data-only emergency calls. > > I also looked at the following charter text: > > "The ATOCA effort is differentiated from and is not intended to > replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the > recipients of ATOCA alerts are the wide range of devices connected to > the Internet and various private IP networks, which humans may have > "at hand" to get such events, as well as automatons who may take > action based on the alerts. This implies that the content of the > alert contains some information, which is intended to be consumed > by humans, and some which is intended to be consumed by automatons. > " > > I could see nothing in the i-d that even mentioned this, let alone discussed it. I think that is an important point we need to capture. We added text to the architectural description but we have not captured this in the requirements section and I believe it makes a bit difference from an interoperability and security point of view whether there is a human there that has to interpret the message or not. What about the following text in the requirements document: " Req-D6: The protocol solution MUST consider cases where alerts are processed by Recipients (who are human) as well as cases where there is no human present (i.e. the Recipient role coincides with the Receiver role). An implication of the latter case is that the Receiver, a software component, needs to make a decision about the validity of the message (for example about the alert message Author). Cases where no human is present can, for example, be found with remote controlled vents, sirens or other warning systems in commercial buildings. " Rather the text: > > "This problem has been illustrated by the London underground bombing > on July 7, 2006, as described in a government report [July2005]. The > UK authorities could only use broadcast media and could not, for > example, easily announce to the "walking wounded" where to assemble." > > Could be be taken to imply that they intend to do exactly that, as I understand the UK initiative as a result of that was directed to mobile phone solutions, as identified above. > Maybe Mark or Steve could comment on what the UK is currently planning to do in this area. Ciao Hannes > > regards > > > Keith > >> -----Original Message----- >> From: earlywarning-bounces@ietf.org >> [mailto:earlywarning-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Saturday, January 15, 2011 7:00 PM >> To: i-d-announce@ietf.org >> Cc: earlywarning@ietf.org >> Subject: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the Authority-to-Citizen Alert >> Working Group of the IETF. >> >> >> Title : Requirements, Terminology and >> Framework for Exigent Communications >> Author(s) : H. Schulzrinne, et al. >> Filename : draft-ietf-atoca-requirements-01.txt >> Pages : 14 >> Date : 2011-01-15 >> >> Before, during and after emergency situations various >> agencies need to provide information to a group of persons or >> to the public within a geographical area. While many aspects >> of such systems are specific to national or local >> jurisdictions, emergencies span such boundaries and >> notifications need to reach visitors from other jurisdictions. >> >> This document provides terminology, requirements and an >> architectural description for protocols exchanging alerts >> between IP-based end points. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-atoca-requireme >> nts-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail >> reader implementation to automatically retrieve the ASCII >> version of the Internet-Draft. >> > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning > From jmpolk@cisco.com Tue Jan 18 14:30:52 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047ED3A6F67 for ; Tue, 18 Jan 2011 14:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.362 X-Spam-Level: X-Spam-Status: No, score=-110.362 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwTF3aJQUk9u for ; Tue, 18 Jan 2011 14:30:50 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 131313A6F58 for ; Tue, 18 Jan 2011 14:30:50 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACakNU2rR7Hu/2dsb2JhbACkX3OoLZo0hVAEhG8 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 18 Jan 2011 22:33:28 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0IMXRwm013085; Tue, 18 Jan 2011 22:33:27 GMT Message-Id: <201101182233.p0IMXRwm013085@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Jan 2011 16:33:26 -0600 To: "Peter Sanders" , "'Brian Rosen'" , "'mark.wood@engineer.commark.wood@engineer.com'"@core3.amsl.com From: "James M. Polk" In-Reply-To: <00a301cbb660$37fdd9d0$a7f98d70$@sanders@one2many.eu> References: <002201cbb636$27cdf790$7769e6b0$@engineer.com> <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net> <00a301cbb660$37fdd9d0$a7f98d70$@sanders@one2many.eu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: earlywarning@ietf.org Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:30:52 -0000 At 10:04 AM 1/17/2011, Peter Sanders wrote: >Hi Brian and Mark, > >Brian, you state in your email the following: >"It's VERY valuable to know that every entity that should get the alert got >it" > >The authorities may not know who in particular needs to receive the alert >message. They wish that everyone in a specific area receives it. However, >the authorities may have no idea who is in the target area at that moment, >so they can't ask for confirmation; they can, but they don't know if they >miss a few acks. Peter I believe that is true in push based alerting, but not in subscription based alerting. If SIP is used, and each end-system that wants to receive a certain alert SUBSCRIBEs to the alerting service, then the alerting service will NOTIFY the end-system that wanted to receive the alert, with a 200 OK as the return acknowledgement that the NOTIFY with the CAP message/container (or whatever is ultimately chosen to tell the receiver what's happening) would be the confirmation. This is all predicated on the use of SIP for this discussion. As Brian effectively points out, if there are many alerting servers alerting a subset of the subscribed end-systems, this scales far better, and I bet it doesn't need to be coalesced in real time for any reports. Further, the 200 OKs are far smaller in size than the alert message itself, so the traffic is far less in the upstream direction. James >Finding out who is in a specific area is technically possible, but may >generate far more network traffic than the acks you expect from a few >million people, and it takes time too. > >I just wanted to add these remarks to the discussion. > >Best regards, >Peter > > >-----Original Message----- >From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] >On Behalf Of Brian Rosen >Sent: maandag 17 januari 2011 15:44 >To: mark.wood@engineer.commark.wood@engineer.com >Cc: earlywarning@ietf.org >Subject: Re: [Atoca] Requirement D2: "Large Audience" > >It may be, but I'd like to explore this a bit anyway. > >Millions of messages (acknowledgements) is a scale we can deal with today. >Hundreds of millions is probably beyond what we can deal with in a response >to a very large alert. > >Most systems consist of several smaller subsystems. The purpose of an >acknowledgement is to make sure everyone got the message. If the subsystem >can determine that every one of its clients got it, it can report that up >the line. It can save missed acks for later analysis, or if there are few >enough of them, report them up. > >This means messages national scale which have small effectivity times can't >reasonably ask for message acknowledgement. Anything smaller than that >probably can. > >Since most alerts really don't involve hundreds of millions of >notifications, most alerts probably can ask for them. > >If your delivery mechanism is multicast, the multicast mechanism itself >doesn't track who gets the alert in any way we can use. That implies >something else is tracking who gets the alert, a complication that could >loom large. Some systems do know who gets the alert (sometimes because it >knows who it is connected to, and all of them get the alert). Certainly, >anything with a subscription has the characteristic that the sender knows >who all the recipients are. > >It's VERY valuable to know that every entity that should get the alert got >it. The only other mechanism we have is some repeating of the sending in >the hopes that everyone got it. In some cases you may have more than one >"path" to the same recipient. That might be multiple devices, multiple >services, or multiple logical or physical connections. You may try one >first, and if that doesn't get an ack, try another. Although we often think >of this mechanism as needing no more than seconds to deploy, in fact many >alerts would be fine with a few minutes, and trying some things sequentially >may make sense. > >So, yes, probably a Tsunami alert to all of East Asia can't ask for >acknowledgements. An "Amber Alert" (possible abducted child) to a county >might very well. Certainly, a snow emergency closing to the parents of an >elementary school could. > >Brian > > >On Jan 17, 2011, at 6:03 AM, > wrote: > > > Hello chaps, > > > > Yes, it's only possible to have any kind of delivery reports regarding > > specific terminals on a one-to-one kind of unicast delivery. The >Australians > > were not considering Cell Broadcast or any other kind of multicast > > technology as they have selected a SMS based delivery system, so this is > > probably what they had in mind. I noticed that atoca language about this >is > > reserved mostly for the 'subscription push' kind of distribution. We need > > to take care not to make it look like a mandated requirement for > > broadcast/multicast bearers. > > > > IMHO, the other special problems with multicast, mean that it needs > > different and special requirements and cannot be generalized with other > > 'push' or 'pull' technologies quite so easily, tempting though that is. I > > think this problem happens because most IT professionals are familiar with > > TCP and UDP but rarely use multicast so are unfamiliar with its very > > different attributes. > > > > Many vendors offer systems which do have a positive indication of who got > > what, and this is a good thing for applications of up to about 10,000 > > receivers. Netherlands studies showed that by the time you scale up to > > millions, the mass scale of all this becomes a problem, so large scale > > systems will have to reluctantly abandon the notion of individual > > confirmation. > > > > Besides, the police authority of a large city don't have the time, during >an > > emergency, to check out millions of replies nor take any action if someone > > does not reply (they are too busy). On the other hand a smaller community > > may value such a facility, so it seems that they authority will need to > > choose whatever is appropriate for the circumstances at their discretion. > > There is no 'one size fits all' solution so we will have to blend many > > bearers in any real situation. For example the Norwegians take the >opposite > > view. > > > > However, it is possible to confirm that the multicast was transmitted, as >a > > network of feedback receivers is envisaged in conjunction with an outer >loop > > reporter system, which would report of the message was transmitted on air. > > If it did not, then an alarm would be generated by the originating > > aggregator for the log file. So the positive indication of the fact of the > > transmission over the air is satisfied even though individual delivery is > > not. > > > > In summary, IMHO, Broadcast/multicast bearers will need special treatment > > as they don't neatly conform to the classic notions of 'push' or 'pull'. > > > > Warm regards, Mark Wood. > > > > > > > > > > _______________________________________________ > > earlywarning mailing list > > earlywarning@ietf.org > > https://www.ietf.org/mailman/listinfo/earlywarning > >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning > >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning From jmpolk@cisco.com Tue Jan 18 14:48:26 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC36728C0FC for ; Tue, 18 Jan 2011 14:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.358 X-Spam-Level: X-Spam-Status: No, score=-110.358 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7ompb8LI5ew for ; Tue, 18 Jan 2011 14:48:25 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 05DDA28C0D7 for ; Tue, 18 Jan 2011 14:48:25 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF6oNU2rRN+J/2dsb2JhbACkQnOoJ5o3gwuCRQSEbw Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 18 Jan 2011 22:51:03 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0IMp2OH004221; Tue, 18 Jan 2011 22:51:02 GMT Message-Id: <201101182251.p0IMp2OH004221@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Jan 2011 16:51:01 -0600 To: Brian Rosen , "" From: "James M. Polk" In-Reply-To: <682E8C23-7988-4A4D-A03F-B00AB05CABF4@brianrosen.net> References: <002201cbb636$27cdf790$7769e6b0$@engineer.com> <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net> <002101cbb705$c9f3f900$5ddbeb00$@engineer.com> <682E8C23-7988-4A4D-A03F-B00AB05CABF4@brianrosen.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: earlywarning@ietf.org Subject: Re: [Atoca] Requirement D2: "Large Audience" X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:48:26 -0000 Brian Are you taking into account the difference in the packet size of the NOTIFY vs. the 200 OK? I believe any burst is the worry of the downstream capacity, and not the 200 OKs in the upstream. That said, what events are we taking about accounting for? - Local tornado/flooding alert? (affecting a creek or the eastern half of Australia?) - metro amber alert? (backwoods sheriff's department or US Tri-state area?) - hurricane alert? (Canary Islands or Katrina sized?) - earthquake alert? (California dessert or Japan?) - limited scale tsunami alert? (only Sumatra or the Indian Ocean?) - ocean scale tsunami alert? I think scoping - with examples - could serve some use in these discussions, and not just refer to them in the abstract. Much of these will have vastly different scaling issues and design considerations - or will they? We could go down the path of scaling regardless of the type of event that caused the alert. In other words, for a #1 - alerting <500 end-systems, do X #2 - alerting <10,000 end-systems, do Y #3 - alerting <500,000 end-systems, do Z ...all the way up to at least the ~140M that are in Japan because they have had events that would have alerted that many within the last 30 years. Obviously, as the number of end-systems subscribe for a certain notification, the scale of the delivery system becomes more distributed to handle the load of the alerts and confirmations. Our documents really ought to recommend ways to aggregate large scale confirmations too. just a couple of thoughts James At 08:02 AM 1/18/2011, Brian Rosen wrote: >I understand your concern. As I stated, in really, really large >events, it may not be practical to get confirmation. On the other >hand, when you have burst events that cause overload, we have >developed techniques for dealing with them. This specific problem >is probably best addressed by a random backoff delay. The devices, >upon receiving a broadcast wait a random time before attempting a >reply, and if they encounter busy conditions, increase the range of >the delay and delay another random time. > >Brian > >On Jan 18, 2011, at 6:49 AM, > wrote: > > > > > Thanks Brian, > > > > Brian's point is well made and correct, thanks Brian, but there are some > > special issues that need to be borne in mind with some bearers. > > > > I first came into this project with the brief from the UN to "protect the > > (Mobile) mobile networks from catastrophic overload situations during > > disasters". > > When I "did the numbers" I discovered that the real problem is > not what many > > think. The bottleneck is in the mobility management system > > (HLR/VLR/Paging/Access grant). EU sponsored Studies by Prof Sophocles > > Kiriazakos for the Greek government after the Athens earthquake and > > subsequent crash of the Greek networks, confirmed this. This is what lead > > me to work on cell broadcast (which does not use the mobility management > > system at all). > > > > I agree that it is reasonable to allow that the acknowledgments may indeed > > take much longer to 'traffic' than the outbound multicast > message. Obviously > > the scale is the same both ways, but while the latency is critical going > > forward, the reverse path is not in the least bit time critical, so > > relatively slower 'best effort' bearers would be fine. The server which is > > wishing to know its subscribers got a message may send the message both by > > unicast and multicast (as mine do), but inevitably the acknowledgement will > > have to be unicast. There is no specific problem in allowing the > > acknowledgement of a multicast message by unicast means as long as we > > understand that the latency is indeterminate. (However since it's not clear > > when the ack may come, I send the message by both means simultaneously > > without waiting for acks.) > > > > My concern is really for the Mobile Network, at layer 2. > > For example if a large number of terminals all receive a multicast at the > > same time, then they will all want to acknowledge at the same time. This > > will result is a tsunami wave of random access bursts to the cells uplink > > timeslot, MSC call set up load, 'channel allocation algorithm' threads and > > SDCCH allocation attempts. Then there will be huge load on the > SMS gateways. > > Mobiles that don't get an access grant message will obviously try again but > > for a while the whole mobility management system will be significantly > > loaded. This affects circuit switched voice just as much because the > > mobility management system is common for voice and SMS, (but maybe not > > GPRS?). Recall that in cellular network design, erlang > calculations are done > > such that it's the assumption that only a small fraction of terminals will > > make random access burst attempts at any one time, so the mobility > > management system is designed for this load only. > > > > In other words, consider that a public warning message (such as a USA CMAS > > presidential message) will reach 100% of terminals simultaneously, rather > > than the small percentage that the signaling system can cope with. This is > > why both the CMAS and ETSI standards intentionally disallow > embedded numbers > > or URLs for large scale (Public) warnings. > > > > So in fact the "scale" of the problem may not be as significant as the > > impact on the local infrastructure (such as a cell). Maybe > "scale" is a less > > important factor than, let's say, penetration? > > > > On the other hand a smaller scale (of penetration) message would not have > > such a profound impact. So in some cases it may be reasonable to expect > > acknowledgements in 'best effort' time. Norway, for example, likes this > > approach. > > > > I am unclear as to if IP systems have such problems because there is not a > > 'stateful' mobility management system in the core and though acks are on a > > large scale, they represent very small packets of less than 1K each. Maybe > > the problem will go away in the future? Any comments on that? > > > > Warm regards Mark Wood DRCF. > > > > > > > > > > > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, January 17, 2011 2:44 PM > > To: > > Cc: earlywarning@ietf.org > > Subject: Re: [Atoca] Requirement D2: "Large Audience" > > > > It may be, but I'd like to explore this a bit anyway. > > > > Millions of messages (acknowledgements) is a scale we can deal with today. > > Hundreds of millions is probably beyond what we can deal with in a response > > to a very large alert. > > > > Most systems consist of several smaller subsystems. The purpose of an > > acknowledgement is to make sure everyone got the message. If the subsystem > > can determine that every one of its clients got it, it can report that up > > the line. It can save missed acks for later analysis, or if there are few > > enough of them, report them up. > > > > This means messages national scale which have small effectivity times can't > > reasonably ask for message acknowledgement. Anything smaller than that > > probably can. > > > > Since most alerts really don't involve hundreds of millions of > > notifications, most alerts probably can ask for them. > > > > If your delivery mechanism is multicast, the multicast mechanism itself > > doesn't track who gets the alert in any way we can use. That implies > > something else is tracking who gets the alert, a complication that could > > loom large. Some systems do know who gets the alert (sometimes because it > > knows who it is connected to, and all of them get the alert). Certainly, > > anything with a subscription has the characteristic that the sender knows > > who all the recipients are. > > > > It's VERY valuable to know that every entity that should get the alert got > > it. The only other mechanism we have is some repeating of the sending in > > the hopes that everyone got it. In some cases you may have more than one > > "path" to the same recipient. That might be multiple devices, multiple > > services, or multiple logical or physical connections. You may try one > > first, and if that doesn't get an ack, try another. Although we > often think > > of this mechanism as needing no more than seconds to deploy, in fact many > > alerts would be fine with a few minutes, and trying some things > sequentially > > may make sense. > > > > So, yes, probably a Tsunami alert to all of East Asia can't ask for > > acknowledgements. An "Amber Alert" (possible abducted child) to a county > > might very well. Certainly, a snow emergency closing to the parents of an > > elementary school could. > > > > Brian > > > > > > _______________________________________________ > > earlywarning mailing list > > earlywarning@ietf.org > > https://www.ietf.org/mailman/listinfo/earlywarning > >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning From jmpolk@cisco.com Tue Jan 18 14:52:48 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5095328C15B for ; Tue, 18 Jan 2011 14:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.517 X-Spam-Level: X-Spam-Status: No, score=-110.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH4HSXSu-by0 for ; Tue, 18 Jan 2011 14:52:45 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ABB3428C163 for ; Tue, 18 Jan 2011 14:52:44 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABKpNU2rR7Ht/2dsb2JhbACkQnOoJ5o3hVAEhG8 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 18 Jan 2011 22:55:23 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0IMtMO5006819; Tue, 18 Jan 2011 22:55:22 GMT Message-Id: <201101182255.p0IMtMO5006819@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Jan 2011 16:55:21 -0600 To: Hannes Tschofenig , "DRAGE, Keith (Keith)" From: "James M. Polk" In-Reply-To: <4D35D26E.5070809@gmx.net> References: <20110115190001.18610.17937.idtracker@localhost> <4D35D26E.5070809@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "earlywarning@ietf.org" Subject: Re: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:52:48 -0000 At 11:48 AM 1/18/2011, Hannes Tschofenig wrote: >Hey Keith, > >thanks for your comments! Please find my comments below: > >On 1/17/2011 7:50 PM, DRAGE, Keith (Keith) wrote: >>I was scanning the charter to see if we had requirements for all >>items mentioned in the charter. >> >>For the following text: >> >>"Which devices should get alerts is primarily driven by location. >>The first set of recipients that must be catered for are those >>within the area identified by the alert originator to be affected >>by the emergency event. " >> >>I could see the requiremnet for recipient control of this: >> >> Req-S2: >> >> The protocol solution MUST allow a potential Recipient to express >> the geographical area it wants to receive alerts about. >> >>But I could see no corresponding require for the sender to be able >>to indicate which geographic locations it wants its alerts to go to. > >Good catch. > >A question I have in return is whether this isn't implicitly covered >by the fact that the alert message itself may contain location >information about the relevant area. I agree with Hannes here, as this may be a case of slight oversight of those of us a little too familiar with what CAP provides to not articular each requirement that we may have seen as implicit within CAP itself. James >For example, take a look at the following alert message: > >--------------------- > > > > > > KSTO1055887203 > KSTO@NWS.NOAA.GOV > 2003-06-17T14:57:00-07:00 > Actual > Alert > Public > > Met > SEVERE THUNDERSTORM > Severe > Likely > NATIONAL WEATHER SERVICE SACRAMENTO > SEVERE THUNDERSTORM WARNING > AT 254 PM PDT... > NATIONAL WEATHER SERVICE > DOPPLER RADAR INDICATED A SEVERE > THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY... > OR ABOUT 18 MILES SOUTHEAST OF > KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL... > INTENSE RAIN AND STRONG DAMAGING WINDS > ARE LIKELY WITH THIS STORM > TAKE COVER IN A SUBSTANTIAL SHELTER > UNTIL THE STORM PASSES > BARUFFALDI/JUSKIE > > EXTREME NORTH CENTRAL TUOLUMNE COUNTY > IN CALIFORNIA, EXTREME NORTHEASTERN > CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN > ALPINE COUNTY IN CALIFORNIA > 38.47,-120.14 38.34,-119.95 38.52,-119.74 > 38.62,-119.89 38.47,-120.14 > > > > >----------- > >So, are you asking to have it stated explicitly that this >information has to be there or do you want to have the area >description additionally available in SIP itself. > >Both requests would be useful. The latter one is also relevant given >the discussions we had in ECRIT on the data-only emergency calls. > >> >>I also looked at the following charter text: >> >>"The ATOCA effort is differentiated from and is not intended to >>replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the >>recipients of ATOCA alerts are the wide range of devices connected to >>the Internet and various private IP networks, which humans may have >>"at hand" to get such events, as well as automatons who may take >>action based on the alerts. This implies that the content of the >>alert contains some information, which is intended to be consumed >>by humans, and some which is intended to be consumed by automatons. >>" >> >>I could see nothing in the i-d that even mentioned this, let alone >>discussed it. > >I think that is an important point we need to capture. We added text >to the architectural description but we have not captured this in >the requirements section and I believe it makes a bit difference >from an interoperability and security point of view whether there is >a human there that has to interpret the message or not. > >What about the following text in the requirements document: > >" > Req-D6: > > The protocol solution MUST consider cases where alerts are > processed by Recipients (who are human) as well as cases where > there is no human present (i.e. the Recipient role coincides with > the Receiver role). An implication of the latter case is that the > Receiver, a software component, needs to make a decision about the > validity of the message (for example about the alert message > Author). Cases where no human is present can, for example, be found > with remote controlled vents, sirens or other warning systems in > commercial buildings. >" > > > > Rather the text: >> >> "This problem has been illustrated by the London underground bombing >> on July 7, 2006, as described in a government report [July2005]. The >> UK authorities could only use broadcast media and could not, for >> example, easily announce to the "walking wounded" where to assemble." >> >>Could be be taken to imply that they intend to do exactly that, as >>I understand the UK initiative as a result of that was directed to >>mobile phone solutions, as identified above. >Maybe Mark or Steve could comment on what the UK is currently >planning to do in this area. > >Ciao >Hannes > >> >>regards >> >> >>Keith >> >>>-----Original Message----- >>>From: earlywarning-bounces@ietf.org >>>[mailto:earlywarning-bounces@ietf.org] On Behalf Of >>>Internet-Drafts@ietf.org >>>Sent: Saturday, January 15, 2011 7:00 PM >>>To: i-d-announce@ietf.org >>>Cc: earlywarning@ietf.org >>>Subject: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt >>> >>>A New Internet-Draft is available from the on-line >>>Internet-Drafts directories. >>>This draft is a work item of the Authority-to-Citizen Alert >>>Working Group of the IETF. >>> >>> >>> Title : Requirements, Terminology and >>>Framework for Exigent Communications >>> Author(s) : H. Schulzrinne, et al. >>> Filename : draft-ietf-atoca-requirements-01.txt >>> Pages : 14 >>> Date : 2011-01-15 >>> >>>Before, during and after emergency situations various >>>agencies need to provide information to a group of persons or >>>to the public within a geographical area. While many aspects >>>of such systems are specific to national or local >>>jurisdictions, emergencies span such boundaries and >>>notifications need to reach visitors from other jurisdictions. >>> >>>This document provides terminology, requirements and an >>>architectural description for protocols exchanging alerts >>>between IP-based end points. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-ietf-atoca-requireme >>>nts-01.txt >>> >>>Internet-Drafts are also available by anonymous FTP at: >>>ftp://ftp.ietf.org/internet-drafts/ >>> >>>Below is the data which will enable a MIME compliant mail >>>reader implementation to automatically retrieve the ASCII >>>version of the Internet-Draft. >>_______________________________________________ >>earlywarning mailing list >>earlywarning@ietf.org >>https://www.ietf.org/mailman/listinfo/earlywarning > >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning From likepeng@huawei.com Thu Jan 20 17:52:26 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D083A67D1 for ; Thu, 20 Jan 2011 17:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.48 X-Spam-Level: X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCiu2PEW4xsr for ; Thu, 20 Jan 2011 17:52:25 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 6E85F3A68A8 for ; Thu, 20 Jan 2011 17:52:24 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFC00HI1NYI6N@szxga05-in.huawei.com> for earlywarning@ietf.org; Fri, 21 Jan 2011 09:54:18 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFC009F1NYI09@szxga05-in.huawei.com> for earlywarning@ietf.org; Fri, 21 Jan 2011 09:54:18 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Jan 2011 09:54:07 +0800 Received: from SZXEML506-MBX.china.huawei.com ([169.254.4.161]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Fri, 21 Jan 2011 09:54:17 +0800 Date: Fri, 21 Jan 2011 01:54:16 +0000 From: Likepeng In-reply-to: X-Originating-IP: [10.70.109.72] To: Hannes Tschofenig , "earlywarning@ietf.org" Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F221A4FC@szxeml506-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [Atoca] Language and Media Type Thread-index: AQHLtOrt3M9Qshs+1k2c1y0R+Z6P5ZPasAVw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [Atoca] Language and Media Type X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 01:52:26 -0000 > ... > Keeping Li (if the meeting minutes reflect his name correctly) noticed that we had a language requirement > in the requirements draft but provided no corresponding solution in the SIP-CAP document. It should be Kepeng Li. ^_^ In my opinion, the indication of language preference is quite useful, especially for some areas with different languages. Kind Regards Kepeng Li