Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt

From: [email-masked]
Date: Mon, 15 Dec 2014 21:14:36 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF.

        Title           : Additional Data Related to an Emergency Call
        Authors         : Randall Gellens
                          Brian Rosen
                          Hannes Tschofenig
                          Roger Marshall
                          James Winterbottom
	Filename        : draft-ietf-ecrit-additional-data-27.txt
	Pages           : 105
	Date            : 2014-12-15

Abstract:
   When an emergency call is sent to a Public Safety Answering Point
   (PSAP), the device that sends it, as well as any application service
   provider in the path of the call, or access network provider through
   which the call originated may have information about the call, the
   caller or the location which the PSAP may be able to use.  This
   document describes data structures and a mechanism to convey such
   data to the PSAP.  The mechanism uses a Uniform Resource Identifier
   (URI), which may point to either an external resource or an object in
   the body of the SIP message.  The mechanism thus allows the data to
   be passed by reference (when the URI points to an external resource)
   or by value (when it points into the body of the message).  This
   follows the tradition of prior emergency services standardization
   work where data can be conveyed by value within the call signaling
   (i.e., in body of the SIP message) and also by reference.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-27

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-27

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Marc Linsner (mlinsner)" <[email-masked]>
Date: Tue, 16 Dec 2014 14:00:29 +0000

All,

I asked Randy to submit the new version to correct one error that showed up the idnits process.  Idnits was claiming that RFC3325 should be an informative reference vs. normative.

I'll proceed sending to the IESG.

-Marc-

Begin forwarded message:

> From: <[email-masked]>
> Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt
> Date: December 16, 2014 at 12:14:36 AM EST
> To: <[email-masked]>
> Cc: <[email-masked]>
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Dec 2014 16:27:04 +0100

Thanks for pushing the document through the process, Marc!

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 16 Dec 2014 15:32:54 +0000

One concern I have about the discussion that has just occurred is that it is assuming the application within an environment where this usage has not yet been specified.

The assumed enviroment is within a car using the cellular network, and this expectation exists when we get to 

https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/
https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/

It has to be assumed that the cellular network will normally be a 3GPP network. However no work has yet started in 3GPP on how this would be supported in such a network. Therefore assumptions (from both sides of the previous discussion) are being made that this will be compatible with whatever 3GPP will decide when it eventually opens the work. 

Given that all the participants in the dialog are 3GPP members, would it not be an idea to get the required 3GPP work started and hold this work until that occurs.

Regards

Keith

> -----Original Message-----
> From: Ecrit [mailto:[email-masked]] On Behalf Of Marc 
> Linsner (mlinsner)
> Sent: 16 December 2014 14:00
> To: [email-masked]
> Subject: [Ecrit] Fwd: I-D Action: 
> draft-ietf-ecrit-additional-data-27.txt
> 
> All,
> 
> I asked Randy to submit the new version to correct one error 
> that showed up the idnits process.  Idnits was claiming that 
> RFC3325 should be an informative reference vs. normative.
> 
> > This draft is a work item of the Emergency Context 
> Resolution with Internet Technologies Working Group of the IETF.
> > 
> > Please note that it may take a couple of minutes from the time of 
> > submission until the htmlized version and diff are 
> available at tools.ietf.org.
> >

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 16 Dec 2014 16:11:14 +0000

-car-crash does not need any 3GPP support.  A 3rd party telematics company such as OnStar can do it by themselves.

There could be some support for it in 3GPP, but we don’t need it.

Brian

> On Dec 16, 2014, at 10:32 AM, DRAGE, Keith (Keith) <[email-masked]> wrote:
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 16 Dec 2014 16:19:06 +0000

As far as 3GPP is concerned - there would be no unauthenticated usage, because in 3GPP it would not be an emergency call.

Nor would there be any roaming support, in terms of reaching an emergency service provider in the country in which you are, unless of course you use lost first.

But in any case, I see no restriction in the document that says it can only be used OTT, and therefore not using the IMS SIP stack.

Keith 

> From: Rosen, Brian [mailto:[email-masked]] 
> Sent: 16 December 2014 16:11
> To: DRAGE, Keith (Keith)
> Cc: Marc Linsner; [email-masked]
> Subject: Re: [Ecrit] I-D Action: 
> -car-crash does not need any 3GPP support.  A 3rd party 
> telematics company such as OnStar can do it by themselves.
> 
> There could be some support for it in 3GPP, but we don't need it.
> 
> Brian
> 
> > One concern I have about the discussion that has just 
> occurred is that it is assuming the application within an 
> environment where this usage has not yet been specified.
> > 
> > The assumed enviroment is within a car using the cellular 
> network, and 
> > this expectation exists when we get to
> > 
> > It has to be assumed that the cellular network will 
> normally be a 3GPP network. However no work has yet started 
> in 3GPP on how this would be supported in such a network. 
> Therefore assumptions (from both sides of the previous 
> discussion) are being made that this will be compatible with 
> whatever 3GPP will decide when it eventually opens the work. 
> > 
> > Given that all the participants in the dialog are 3GPP 
> members, would it not be an idea to get the required 3GPP 
> work started and hold this work until that occurs.
> > 
> > Regards
> > 
> > Keith
> > 
> >> From: Ecrit [mailto:[email-masked]] On Behalf Of 
> Marc Linsner 
> >> (mlinsner)
> >> I asked Randy to submit the new version to correct one error that 
> >> showed up the idnits process.  Idnits was claiming that

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Dec 2014 10:34:52 +0000

Hi,

I agree with Keith. If we see 3GPP as the main intended customer of some/all of these drafts, we really need to get input from 3GPP before publishing them as RFCs.

Regards,

Christer

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: 16 December 2014 18:19
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt

Keith 

> -car-crash does not need any 3GPP support.  A 3rd party telematics 
> company such as OnStar can do it by themselves.
> 
> occurred is that it is assuming the application within an environment 
> where this usage has not yet been specified.
> > 
> normally be a 3GPP network. However no work has yet started in 3GPP on 
> how this would be supported in such a network.
> discussion) are being made that this will be compatible with whatever 
> 3GPP will decide when it eventually opens the work.
> > 
> members, would it not be an idea to get the required 3GPP work started 
> and hold this work until that occurs.
> > 
> > Regards
> > 
> > Keith
> >