Re: [Ecrit] Charter & Milestones update - Comments sought

[Richard Barnes <[e-mail]>]

On Mon, Oct 21, 2013 at 8:47 PM, Randall Gellens <[e-mail]>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"



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

--Richard




>
> 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 <[e-mail]>
> 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:[e-mail]]
> *Sent:* Monday, October 07, 2013 1:46 PM
> *To:* Roger Marshall; 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_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1tel
> ecomsy_"
>
> 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
> [e-mail]
> 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
> [e-mail]
> 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
>