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

From: Roger Marshall <[email-masked]>
Date: Thu, 29 Jan 2015 18:44:52 +0000

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

The subject line is -additional-data, but I assume that you have asked the 3GPP-related question based on -ecall and -car-crash only, and not -additional-data.  Please confirm and change the subject line.

As to main intended customers, I see NENA (i3) as the biggest user of the -additional-data mechanism over the next few years.

-roger. 

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

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

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 

> -----Original Message-----
> 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: 
> draft-ietf-ecrit-additional-data-27.txt
> 
> -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:
> > 
> > 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.
> >> 
> >> 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]>
> >>> 
> >>> 
> >>> 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/
> >>> 
> >>> _______________________________________________
> >>> Ecrit mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >> 
> >> _______________________________________________
> >> Ecrit mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> 
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ecrit
> 
> 
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

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