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

From: Roger Marshall <[email-masked]>
Date: Fri, 4 Oct 2013 18:18:01 +0000

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.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 7 Oct 2013 13:45:47 -0700

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,

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

[email-masked]

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 13 Oct 2013 18:59:56 +0300

Hi Roger,

thanks for working on the updated charter text.

The text is fine for me; I only have a few minor suggestions.

On 04.10.2013 21:18, Roger Marshall wrote:
> The ECRIT working group agreed that the chairs would propose updated
> language to the wg charter, along with milestone data changes.
>

I would omit this last sentence. I also believe that the term "document" 
isn't appropriate here.

> and use, augmented information that could assist emergency call takers or

s/"authentication of location"/"trustworthy location"

> such as NENA and ETSI EMTEL, any solution presented must be useful

You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL 
with "ETSI" since we are now dealing also with other groups in ETSI in 
addition to EMTEL.

> dealing with Unauthenticated and Unauthorized Devices' to the IESG for

I thought that this document has been sent to the IESG already.

> to the IESG for consideration as a Standards Track RFC

I believe you should also list all other concluded documents as well 
(and mark them as done).

Ciao
Hannes

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

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sun, 13 Oct 2013 12:37:33 -0400

Hi,
Policy based routing was once said to enable routing based on for 
example media requirements and capabilities to specific PSAPs equipped 
or educated for such calls.
In latest NENA spec for policy based routing, only PSAP availability is 
mentioned as reason to route.

I do not remember that we have anything sufficiently explicit from IETF 
on this topic, and suggest to include it in the goals.

Thanks,
Gunnar

------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46708204288
On 2013-10-13 11:59, Hannes Tschofenig wrote:
> I would omit this last sentence. I also believe that the term 
> "document" isn't appropriate here.
>
>
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 13 Oct 2013 19:50:41 +0300

Hi Gunnar,

that's fine with me but where do you want to add this remark in the 
charter text Roger proposed?

Also, do we have any specific document in progress that is impacted by 
policy based routing?

Ciao
Hannes

---

From: "Gellens, Randall" <[email-masked]>
Date: Sun, 13 Oct 2013 23:22:05 +0000

The current NENA document on policy-based routing only deals with legacy capabilities (that is, call diversion/exception handling).  The NENA group intends to produce a version two that covers NG9-1-1 (NENA i3) capabilities with the enhancements for call processing including media and other needs.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Hannes Tschofenig [[email-masked]]
Sent: Sunday, October 13, 2013 9:50 AM
To: Gunnar Hellstrom
Cc: [email-masked]
Subject: Re: [Ecrit] Charter & Milestones update - Comments sought

Hi Gunnar,

Ciao
Hannes

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sun, 13 Oct 2013 19:52:56 -0400

An addition could be made to this sentence:

"Further, it must be possible for multiple delegations within a 
jurisdiction to be handled independently, as callrouting for specific 
emergency types may be handled independently."

To

"Further, it must be possible for multiple delegations within a 
jurisdiction to be handled independently, as callrouting for specific 
emergency types, media types, language contents etc.  may be routed 
differently depending on established policies and availability."

And in the goals list include:

xxx 2014 - Submit a draft 'Policy based routing in Emergency Services'

Regards

Gunnar

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Oct 2013 10:54:50 +0300

Hi Randy,

My question is whether we need to go to that level of detail in the 
ECRIT charter text.

Unless we have a document we want to pick up as a WG item that deals 
with these issues I don't think we have to talk too much about these 
details.

If you look at other aspects there are reasons why the text mentions 
things like 'trustworthy location', and 'sensor initiated requests'.

Ciao
Hannes

On 14.10.2013 02:22, Gellens, Randall wrote:
> Subject: Re: [Ecrit] Charter&  Milestones update - Comments sought
>
> Hi Gunnar,
>

---

From: "Gellens, Randall" <[email-masked]>
Date: Mon, 14 Oct 2013 15:26:03 +0000

Hi Hannes,

Sorry for not being more explicit.  I'm not suggesting that the charter go into the details of NENA's work on policy-based routing, far from it.  I'm pointing out that NENA is actively engaged in the topic, and hence, I don't see a current need for the IETF to develop a document in this area.

________________________________________
From: Hannes Tschofenig [[email-masked]]
Sent: Monday, October 14, 2013 12:54 AM
To: Gellens, Randall
Cc: Hannes Tschofenig; Gunnar Hellstrom; [email-masked]
Subject: Re: [Ecrit] Charter & Milestones update - Comments sought

Hi Randy,

Ciao
Hannes

---

From: Roger Marshall <[email-masked]>
Date: Mon, 21 Oct 2013 17:10:40 +0000

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:[email-masked]]
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.

Content-Language: en-US

Regards,

_______________________________________________
Ecrit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ecrit

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only

---

From: Randall Gellens <[email-masked]>
Date: Mon, 21 Oct 2013 10:24:50 -0700

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:[email-masked]]

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

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,

ECRIT Chairs

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

Done - Submit 'Public Safety Answering Point (PSAP)
Callbacks' to the IESG

Nov 2013 - Submit 'Trustworthy Location Information' to
the IESG for

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

Mar 2014 - Submit 'Using Imprecise Location for Emergency
Call Routing'

Dec 2013 - Submit a draft 'URN For Country Specific
Emergency Services'

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

[email-masked]

--

Randall Gellens

-------------- Randomly selected tag: ---------------

--Judge
Sotomayor

--

Randall Gellens

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

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Oct 2013 20:29:55 +0300

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 <[email-masked]>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.
>
> **        **
>
>
> 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:[email-masked]]
> *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,
> jurisdictions will migrate to next-generation at the same time.  A
> SIP-based emergency call won't work in a legacy emergency call jurisdiction.
>
>
>
> requiring a
> 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
> received this message in error, please notify the sender immediately, and
> delete it and all attachments from your computer and network.
>
>
> **
> **

---

From: Roger Marshall <[email-masked]>
Date: Mon, 21 Oct 2013 17:40:28 +0000

I think these suggested changes in the text are reasonable, since they reach beyond NENA's span (North America only).

I'll plan to make this change to the Charter & add to the Milestones.

-roger.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gunnar Hellstrom
Sent: Sunday, October 13, 2013 4:53 PM
To: Gellens, Randall
Cc: [email-masked]
Subject: Re: [Ecrit] Charter & Milestones update - Comments sought

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

To

"Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types, media types, language contents etc.  may be routed differently depending on established policies and availability."

Regards

Gunnar

________________________________
Gunnar Hellström
Omnitor
[email-masked]<mailto:[email-masked]>
+46708204288
On 2013-10-13 19:22, Gellens, Randall wrote:

From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Hannes Tschofenig [[email-masked]<mailto:[email-masked]>]

To: Gunnar Hellstrom

Cc: [email-masked]<mailto:[email-masked]>

Hi Gunnar,

policy based routing?

Ciao

Hannes

Hi,

Thanks,

Gunnar

Gunnar Hellström

Omnitor

[email-masked]<mailto:[email-masked]>

+46708204288

Hi Roger,

Please send your comments to the list, whether in favor, or with

alternative wording and/or dates.

Regards,

ECRIT Chairs

response center. Though the term "call routing" is used in this

document,

services.

Beyond human initiated emergency call request mechanisms, this group

will

address topics such as authentication of location, service URN

definition

and use, augmented information that could assist emergency call

takers or

responders.

requirements.

addition to EMTEL.

requiring a

Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the

IESG

Emergency Alerts using the Session Initiation Protocol (SIP)' to the

IESG for consideration as an

Experimental RFC

dealing with Unauthenticated and Unauthorized Devices' to the IESG for

consideration

as a Standards Track RFC

(and mark them as done).

Ciao

Hannes

Ecrit mailing list

Ecrit mailing list

Ecrit mailing list

Ecrit mailing list

---

From: Roger Marshall <[email-masked]>
Date: Mon, 21 Oct 2013 17:42:56 +0000

Hannes:
Thanks for your review and suggestions.  See inline.

-roger.

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Sunday, October 13, 2013 9:00 AM
To: Roger Marshall
Cc: ecrit_ietf.org; [email-masked]
Subject: Re: [Ecrit] Charter & Milestones update - Comments sought

Hi Roger,

[rsm] suggested changes accepted.

[rsm] okay.

> such as NENA and ETSI EMTEL, any solution presented must be useful

You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL with "ETSI" since we are now dealing also with other groups in ETSI in addition to EMTEL.

[rsm] changes will be made.

[rsm] true.  Status will be changed to Done.

> to the IESG for consideration as a Standards Track RFC

I believe you should also list all other concluded documents as well (and mark them as done).

[rsm] Yes, okay.

Ciao
Hannes

---

From: Randall Gellens <[email-masked]>
Date: Mon, 21 Oct 2013 10:47:47 -0700

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.

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.

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 <[email-masked]>
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.

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.

Content-Language: en-US

Regards,

ECRIT Chairs

along with appropriate call routing to
an emergency service center.

overlay networks and tunnels (either as
VPNs or for mobility) makes

routing.  This working group will
describe where and how these mechanisms

may be used. The group will show how
the availability of location data

it should be understood that some of
the mechanisms which will be

services.

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

requirements.

Experimental RFC

as a Standards Track RFC

Ecrit mailing list

[email-masked]

--

Randall Gellens

-------------- Randomly selected tag: ---------------

--Judge Sotomayor

--

Randall Gellens

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

[email-masked]

--

Randall Gellens

-------------- Randomly selected tag: ---------------

I have learned

To spell hors d'oeuvres

Which still grates on

Some people's n'oeuvres.

-- Warren Knox

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Oct 2013 21:05:55 +0300

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

> 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
>
>
>
>         "any solution presented must be useful regardless of jurisdiction,
> and it must be possible to use without requiring a single, central
> authority"
>
>

---

From: Randall Gellens <[email-masked]>
Date: Mon, 21 Oct 2013 11:29:24 -0700

Hi Richard,

At 9:05 PM +0300 10/21/13, Richard Barnes wrote:

On Mon, Oct 21, 2013 at 8:47 PM, Randall
Gellens <[email-masked]>
wrote:

Hi Richard,

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.

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:

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 <[email-masked]>
wrote:

Hi Roger,

I suggest deleting:

"any

Randy:

-roger.

Content-Language: en-US

Regards,

ECRIT Chairs

services.

responders.

requirements.

Experimental RFC

as a Standards Track RFC

Ecrit mailing list

[email-masked]

--

Randall Gellens

-------------- Randomly selected tag: ---------------

--Judge Sotomayor

--

Randall Gellens

-------------- Randomly selected tag: ---------------

should be controlled.
--Marcus Tullius Cicero
(106-43 B.C.)

Ecrit mailing list

[email-masked]

--

Randall Gellens

-------------- Randomly selected tag: ---------------

I have learned

To spell hors d'oeuvres

Which still grates on

Some people's n'oeuvres.

-- Warren
Knox

--

Randall Gellens

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

---

From: Roger Marshall <[email-masked]>
Date: Mon, 21 Oct 2013 19:59:35 +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:[email-masked]]
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,

On Mon, Oct 21, 2013 at 8:47 PM, Randall Gellens <[email-masked]<mailto:[email-masked]>> 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.

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 <[email-masked]<mailto:[email-masked]>> 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.

Randy:

-roger.

From: Randall Gellens [mailto:[email-masked]<mailto:[email-masked]>]
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

Content-Language: en-US

Regards,

    services.

-------------- Randomly selected tag: ---------------

--

Randall Gellens
-------------- Randomly selected tag: ---------------

--

Randall Gellens
-------------- Randomly selected tag: ---------------
I have learned
To spell hors d'oeuvres
Which still grates on
Some people's n'oeuvres.
       -- Warren Knox

---

From: Randall Gellens <[email-masked]>
Date: Mon, 21 Oct 2013 14:51:55 -0700

At 7:59 PM +0000 10/21/13, Roger Marshall wrote:

>  You suggested text: "any solution presented 
> must not rely on assumptions specific to a 
>  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).
>
>  I believe means that we should build "general 
> purpose solutions" that could be applied 
> anywhere (though assuming only with Internet 
> technologies).

My concern is that it could be interpreted to 
prohibit work needed for NENA or eCall, that is 
intended for use within a specific continent. 
Let's address your specific concern (general 
purpose solutions).  How about:

	"any solution presented must be general 
enough to be potentially useful in or across 
multiple regions or jurisdictions"

-------------- Randomly selected tag: ---------------
Arguments are to be avoided; they are always vulgar and often convincing.                                     --Oscar Wilde

---

From: Roger Marshall <[email-masked]>
Date: Mon, 21 Oct 2013 22:31:39 +0000

Based on text feedback from the list, I've updated the Charter text and Milestones.  See below.

(I've also included an attached file for redlined changes)

ECRIT charter (as revised):

    response center. Though the term "call routing" is used,
    described might be used to enable other types of media streams.

    While this group anticipates a close working relationship with groups
    such as NENA, EENA, 3GPP, and ETSI , any solution presented must be
    general enough to be potentially useful in or across multiple regions
    or jurisdictions, 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, things
    such as call routing for specific emergency types, media types, language
    contents, etc.,  may be routed differently depending on established
    policies and availability.

Also, dependent on the above text, Gunnar has suggested the addition of the
following milestone:

The complete Milestone list (as revised):

Done  Informational RFC containing terminology definitions and the requirements
Done  An Informational document describing the threats and security considerations
Done  A Standards Track RFC describing how to identify a session set-up request is to an emergency response center
Done  A Standards Track RFC describing how to route an emergency call based on location information
Done  An Informational document describing the Mapping Protocol Architecture
Done  Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC.
Done  Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC.
Done  Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document
Done  Submit 'LoST Extension for returning Boundary Information for Services' to the IESG for consideration as an Experimental RFC
Done  Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC
Done    Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG  for consideration as an Informational RFC
Done    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 2014 - Submit a draft 'Policy based routing in Emergency Services'
to the IESG for consideration as a Standards Track RFC

To

Regards

Gunnar

To: Gunnar Hellstrom

Hi Gunnar,

policy based routing?

Ciao

Hannes

Hi,

Thanks,

Gunnar

Gunnar Hellström

Omnitor

+46708204288

Hi Roger,

Regards,

ECRIT Chairs

document,

services.

will

definition

takers or

responders.

requirements.

addition to EMTEL.

requiring a

IESG

Experimental RFC

consideration

as a Standards Track RFC

(and mark them as done).

Ciao

Hannes

Ecrit mailing list

Ecrit mailing list

Ecrit mailing list

Ecrit mailing list

---

From: Randall Gellens <[email-masked]>
Date: Tue, 22 Oct 2013 21:30:30 -0700

At 10:31 PM +0000 10/21/13, Roger Marshall wrote:

Also, dependent on the above text, Gunnar
has suggested the addition of the

following milestone:

xxx 2014 - Submit a draft 'Policy
based routing in Emergency Services'

I'd suggest we not include this milestone at this time.
Let's wait until we see a need for such a draft.  Given that NENA
is addressing this, I'm not clear on what the IETF's role needs to
be.

--

Randall Gellens

-------------- Randomly selected tag: ---------------

Those who can make you believe absurdities

can make you commit atrocities.

--Voltaire