Re: [Ecrit] Charter & Milestones update - Comments sought
Roger Marshall <RMarshall@telecomsys.com> Mon, 21 October 2013 20:01 UTC
Return-Path: <RMarshall@telecomsys.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDB511E86D8 for <ecrit@ietfa.amsl.com>; Mon, 21 Oct 2013 13:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvlBwGdOwPPt for <ecrit@ietfa.amsl.com>; Mon, 21 Oct 2013 13:00:59 -0700 (PDT)
Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1C911E8282 for <ecrit@ietf.org>; Mon, 21 Oct 2013 12:59:43 -0700 (PDT)
Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id r9LJxaf1005768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 21 Oct 2013 12:59:36 -0700
Received: from SEA-EXCAS-3.telecomsys.com (10.32.12.6) by SEA-EXCAS-2.telecomsys.com (10.32.12.187) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 21 Oct 2013 12:59:36 -0700
Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.31]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.01.0218.012; Mon, 21 Oct 2013 12:59:35 -0700
From: Roger Marshall <RMarshall@telecomsys.com>
To: Randall Gellens <randy@qti.qualcomm.com>, Richard Barnes <rlb@ipv.sx>
Thread-Topic: [Ecrit] Charter & Milestones update - Comments sought
Thread-Index: AQHOzogvgOHANmOzQNGU4fpZSblfKZn/7zcA//+bIxA=
Date: Mon, 21 Oct 2013 19:59:35 +0000
Message-ID: <FBD5AAFFD0978846BF6D3FAB4C892ACC4864C2@SEA-EXMB-1.telecomsys.com>
References: <FBD5AAFFD0978846BF6D3FAB4C892ACC45811B@SEA-EXMB-1.telecomsys.com> <p06240602ce78cc3a5e0a@10.184.126.229> <FBD5AAFFD0978846BF6D3FAB4C892ACC484ED7@SEA-EXMB-1.telecomsys.com> <p06240601ce8b1354f008@99.111.97.136> <CAL02cgRyXMNxe-UPPFBkJtDM2UeZjgardeTeXAy9TbbU2SuWWg@mail.gmail.com> <p06240604ce8b16239896@99.111.97.136> <CAL02cgSeKxrJv2B85Mjaw2SOTWNUMXfHhPnpLhCDwGZmh9xM0w@mail.gmail.com> <p06240606ce8b20c31647@[99.111.97.136]>
In-Reply-To: <p06240606ce8b20c31647@[99.111.97.136]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.32.12.134]
Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC4864C2SEAEXMB1telecomsy_"
MIME-Version: 1.0
Cc: "ecrit_ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] Charter & Milestones update - Comments sought
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Oct 2013 20:01:09 -0000
Richard: You suggested text: "any solution presented must not rely on assumptions specific to a given jurisdiction or region" I think your text mod takes us too far, since some of our ECRIT solutions do rely on assumptions specific to a given jurisdiction... (but not only that jurisdiction). What's wrong with the original text, when it says, "any solution presented must be useful regardless of jurisdiction" I believe means that we should build "general purpose solutions" that could be applied anywhere (though assuming only with Internet technologies). Randy: Your objection to the text, "...and it must be possible to use without requiring a single, central authority. " yes, this has applied to routing, but I don't think it is/was limited to just routing (It doesn't even preclude having a single, central authority). I think this could be taken to mean any distributed service, including rich data sources and the like. No solutions that _require_ a central authority to own it all. -roger. -roger. From: Randall Gellens [mailto:randy@qti.qualcomm.com] Sent: Monday, October 21, 2013 11:29 AM To: Richard Barnes Cc: Roger Marshall; ecrit_ietf.org Subject: Re: [Ecrit] Charter & Milestones update - Comments sought Hi Richard, At 9:05 PM +0300 10/21/13, Richard Barnes wrote: On Mon, Oct 21, 2013 at 8:47 PM, Randall Gellens <randy@qti.qualcomm.com<mailto:randy@qti.qualcomm.com>> wrote: Hi Richard, I don't what what the phrase "useful regardless of jurisdiction" is supposed to mean in this context, and I'm concerned that it might be interpreted to mean that work needed for, e.g., eCall that is intended for use within the E.U. is out of scope. Likewise for work intended for NENA's needs. I agree that we don't want to do work that *can't* be used broadly on the Internet, but that's different than prohibiting work *intended* (at least initially) for use within a particular continent. I suppose we could say "potentially useful" instead of just "useful" to make it clear that the prohibition is only on what the work *could* be used for, and not what it is initially intended for use for. I still think we could just delete the sentence, since I don't see the group in danger of doing work that can't be broadly used. Ok, I think we're more or less on the same page w.r.t. the intent of the "jurisdiction" text. How about this? OLD: "any solution presented must be useful regardless of jurisdiction" NEW: "any solution presented must not rely on assumptions specific to a given jurisdiction or region" I'm not sure what this will mean in practice, and I'm concerned that it could limit work that NENA or eCall needs (someone could say that all of NENA i3 is based on assumptions specific to North America). Let's take a step back and see first if we feel that the group is likely to venture into something that we want to prohibit. If so, let's agree precisely what it is that the group is likely to do and then agree on text to stop it. On the other hand, if we think the group and its chairs are sufficiently mature at this stage, maybe we don't need this text in the charter. Groups certainly do need more restrictive charter text early on. To me, the phrase "it must be possible to use without requiring a single, central authority" seems intended to limit the work that became LosT, to try and avoid creating an LDAP-type situation that required a global root. However, it seems like that's still a desirable goal for other systems, right? Just to make something up, suppose an ACN system depended on a single, standardized clearing house for ACN notifications. That would be bad, right? But it could also be tempting in a particular jurisdiction to assume that such a clearing-house is set in the standard. So ISTM this text is valuable for reminding people that things like that need to be discoverable. I'd rather not have charter language based on such made up examples, especially for a group that is fairly mature and that doesn't seem to be in danger of heading off into dangerous areas. If someone proposed an ACN or even an authority-to-citizen alert protocol that required a single authority to clear all transactions, would the group be in danger of accepting the proposal? If not, then we don't need the charter to prohibit it. At 8:29 PM +0300 10/21/13, Richard Barnes wrote: Could you explain more why that sentence is problematic? After all, our job here is to design things for the whole Internet; work that is only useful to a given jurisdiction should be done there. That's not to say that the general work can't be based on locality-specific work, and done at the same time -- RFC 6881 is arguably a generalization of a part of the NENA system. But what's done in the IETF needs to remain general. --Richard On Mon, Oct 21, 2013 at 8:24 PM, Randall Gellens <randy@qti.qualcomm.com<mailto:randy@qti.qualcomm.com>> wrote: Hi Roger, I suggest deleting: "any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single, central authority" The text seems to me to be more applicable to the solution that became LoST. As such, I don't think it serves any purpose now. At 5:10 PM +0000 10/21/13, Roger Marshall wrote: Randy: I'm not sure what you're proposing as a change to the text. I agree that the present text has some history in pre-LoST, but I don't think its inclusion limits what you are suggesting, (ACN or pan-EU emergency calling). -roger. From: Randall Gellens [mailto:randy@qti.qualcomm.com<mailto:randy@qti.qualcomm.com>] Sent: Monday, October 07, 2013 1:46 PM To: Roger Marshall; ecrit_ietf.org<http://ecrit_ietf.org> Subject: Re: [Ecrit] Charter & Milestones update - Comments sought I realize some of this language is a holdover from our very early days when we weren't sure which way we could go for things which became LoST, for example. Still, I'm not sure exactly what "any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single, central authority" mean today. In one sense, everything we do has dependency on jurisdiction, because not all jurisdictions will migrate to next-generation at the same time. A SIP-based emergency call won't work in a legacy emergency call jurisdiction. We want to be sure that we can work on generic ACN and pan-Europen eCall. At 6:18 PM +0000 10/4/13, Roger Marshall wrote: Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1telecomsy_" The ECRIT working group agreed that the chairs would propose updated language to the wg charter, along with milestone data changes. Compare this to the original charter found at: http://tools.ietf.org/wg/ecrit/charters. Please send your comments to the list, whether in favor, or with alternative wording and/or dates. Regards, Roger Marshall/Marc Linsner ECRIT Chairs ECRIT charter (w/proposed revisions): Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (usually one that is short and easily memorized) as a request for emergency services. These numbers (e.g., 911, 112) are related to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained approach for service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires an association of both the physical location of the originating device along with appropriate call routing to an emergency service center. Calls placed using Internet technologies do not use the same systems Mentioned above to achieve those same goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting these goals even more challenging. There are, however, Internet technologies available to manage location and to perform call routing. This working group will describe where and how these mechanisms may be used. The group will show how the availability of location data and call routing information at different steps in the call session setup would enable communication between a user and a relevant emergency response center. Though the term "call routing" is used in this document, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services. Beyond human initiated emergency call request mechanisms, this group will develop new methods to request emergency assistance, such as sensor initiated emergency requests, and additional processes specified that address topics such as authentication of location, service URN definition and use, augmented information that could assist emergency call takers or responders. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. While this group anticipates a close working relationship with groups such as NENA and ETSI EMTEL, any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be handled independently. This working group cares about privacy and security concerns, and will address them within its documents. Milestones w/revised status/dates, as proposed Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an Experimental RFC Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration as a Standards Track RFC Dec 2013 - Submit a draft 'Policy for defining new service-identifying labels' to the IESG for consideration as BCP Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' to the IESG for consideration as a Standards Track RFC CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org<mailto:Ecrit@ietf.org> https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Personal experiences affect the facts that judges choose to see. --Judge Sotomayor -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The budget should be balanced. The treasury should be refilled. Public debt should be reduced. The arrogance of public officials should be controlled. --Marcus Tullius Cicero (106-43 B.C.) _______________________________________________ Ecrit mailing list Ecrit@ietf.org<mailto:Ecrit@ietf.org> https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I have learned To spell hors d'oeuvres Which still grates on Some people's n'oeuvres. -- Warren Knox -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- "SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of San Francisco Police Jacket, as reported by Herb Caen in SF Chronicle
- [Ecrit] Charter & Milestones update - Comments so… Roger Marshall
- Re: [Ecrit] Charter & Milestones update - Comment… Randall Gellens
- Re: [Ecrit] Charter & Milestones update - Comment… Hannes Tschofenig
- Re: [Ecrit] Charter & Milestones update - Comment… Gunnar Hellstrom
- Re: [Ecrit] Charter & Milestones update - Comment… Hannes Tschofenig
- Re: [Ecrit] Charter & Milestones update - Comment… Gellens, Randall
- Re: [Ecrit] Charter & Milestones update - Comment… Gunnar Hellstrom
- Re: [Ecrit] Charter & Milestones update - Comment… Hannes Tschofenig
- Re: [Ecrit] Charter & Milestones update - Comment… Gellens, Randall
- Re: [Ecrit] Charter & Milestones update - Comment… Roger Marshall
- Re: [Ecrit] Charter & Milestones update - Comment… Randall Gellens
- Re: [Ecrit] Charter & Milestones update - Comment… Richard Barnes
- Re: [Ecrit] Charter & Milestones update - Comment… Roger Marshall
- Re: [Ecrit] Charter & Milestones update - Comment… Roger Marshall
- Re: [Ecrit] Charter & Milestones update - Comment… Randall Gellens
- Re: [Ecrit] Charter & Milestones update - Comment… Richard Barnes
- Re: [Ecrit] Charter & Milestones update - Comment… Randall Gellens
- Re: [Ecrit] Charter & Milestones update - Comment… Roger Marshall
- Re: [Ecrit] Charter & Milestones update - Comment… Randall Gellens
- Re: [Ecrit] Charter & Milestones update - Comment… Roger Marshall
- Re: [Ecrit] Charter & Milestones update - Comment… Randall Gellens