Subject: Re: [Ecrit] Usage of INFO by draft-ietf-ecrit-ecall

From: Randall Gellens <[email-masked]>
Date: Tue, 7 Jun 2016 18:06:46 -0700

Hi Keith,

At 12:17 PM +0000 5/19/16, Keith (Nokia - GB) Drage wrote:

>  I did a reread of the INFO RFC last night in respect of the above 
> draft, and came to the following conclusions.
>
>  1)	Any usage of the INFO method requires a full Info package 
> definition. While there are various mentions of legacy usage, the 
> draft is not trying to follow that direction, and in any case I am 
> not convinced new registrations of relevant usage would be allowed 
> down that route. So if the draft is to attempt to use the INFO 
> method, it should formally define that method.

I am not sure what you are saying is the problem with the draft.  The 
draft does not try to use INFO in a legacy (non-package) manner.  It 
does register an INFO package.  Could you clarify the problem that 
you see?

>
>  2)	The INFO RFC lays down clear instructions for the reviewer of 
> the INFO package definition before it can be registered. In my view 
> the current ecrit-ecall document would not pass that review.

What is the problem?

>
>  3)	The INFO RFC makes no reference to transfer of data outside 
> of the INFO method itself. My understanding is that the negotiation 
> of the Info package within the Info-Package header field set to 
> 'emergencyCallData.eCall' relates only to the data transferred in 
> the INFO method using a conformant Info package definition. There 
> therefore needs to be a discussion about what forms the negotiation 
> mechanism for other information transferred, for example in the 
> INVITE request, or other methods of the dialog, if such transfer is 
> needed, and for it to be clearly documented.

The INFO RFC is limited to the INFO method, so wouldn't be expected 
to discuss transfer of data outside of INFO.

The draft references additional-data for data transfer in INVITE.

>
>  4)	As indicated in 3), the INFO RFC does not expect data outside 
> the Info package itself, and therefore nothing is stated there 
> about the correlation of data between an application tagging things 
> onto the methods of the dialog, and the application using the Info 
> package.

The draft has limited scope: it is for emergency calls where the 
endpoints support the draft (and additional-data, which is a 
normative reference).  So, confirming endpoints would understand data 
transferred in accordance with the draft and additional-data.

>
>  5)	The INFO RFC allows for multiple Info packages to be used on 
> the same dialog. There needs to be careful review to ensure that 
> this capability is not compromised either in regard to the existing 
> Info packages, or to new ones, particularly in regard to the 
> assumed correlation between data in the Info package, and data 
> transferred elsewhere in the dialog. I'd note that the draft would 
> appear to sanction the inclusion of data in INFO methods belonging 
> to entirely unrelated Info packages.

The draft is not trying to authorize or discuss any other INFO 
packages or their data.  I'll see if I can improve the wording to 
make this more clear.

>  I would note that I am beginning to question whether there needs to 
> be any transfer of data in the INVITE request. Transfer only within 
> the INFO package after the response to the INVITE request is 
> exchanged would still meet the 3GPP stage 1 requirements (see 
> 22.101 release 14), and the whole document would be significantly 
> simpler. None of the contents of the MSD is used for routeing the 
> emergency call. This is without going into discussion about whether 
> transfer using the signalling bearer, or some bearer negotiated 
> using the SDP, is more appropriate.

The draft makes use of additional-data, which carries various data 
types in the initial INVITE.  3GPP has now agreed to use this for the 
MSD, in accordance with the draft.  However, 3GPP wants the ASN.1 
encoding rather than the XML encoding of the MSD used, so this change 
is being made.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The most likely way for the world to be destroyed, most experts agree,
is by accident.  That's where we come in; we're computer professionals.
We cause accidents.                              --Nathaniel Borenstein

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 10 Jun 2016 06:48:22 +0000

Hello,

> > draft is not trying to follow that direction, and in any case I am not

> > convinced new registrations of relevant usage would be allowed down

> > that route. So if the draft is to attempt to use the INFO method, it

> > should formally define that method.

> does register  an INFO package.  Could you clarify the problem that you see?

In order to define and register an info package in IANA, a filled-in template for info package definition described in RFC6086 section 10 needs to be provided.

According to RFC6086 section 10, the template consisting of:

-------------

      10.2. Overall Description

      10.3. Applicability

      10.4. Info Package Name

      10.5. Info Package Parameters

      10.6. SIP Option-Tags

      10.7. INFO Message Body Parts

      10.8. Info Package Usage Restrictions

      10.9. Rate of INFO Requests

      10.10. Info Package Security Considerations

      10.11. Implementation Details

      10.12. Examples

-------------

The draft can say e.g. the following. I am not expert on ecrit eCall draft so text might need updates - feel free to update it according to the draft.

-------------

1. Overall Description

The [I-D.ietf-ecrit-eCall] defines an NG-eCall protocol enabling a PSAP to obtain a minimal set of data (MSD) from a UA located in a vehicle. The protocol makes use of SIP INFO requests associated with the emergencyCallData.eCall info package to transport NG-eCall messages.

NG-eCall messages are:

- request for MSD

- acknowledgement of reception of request for MSD

- MSD

- acknowledgement of reception of MSD

- ...

2. Applicability

A number of solutions were discussed for the transportation of NG-eCall messages between the UA and the PSAP. The solutions were:

1)            use of subscription to an event package;

2)            use of the session related methods (e.g. SIP 200 (OK) response to the SIP INVITE request);

3)            use of the SIP MESSAGE method;

4)            use of media plane mechanisms; and

5)            use of the SIP INFO method as described in IETF RFC 6086, by defining a new info package.

Furthermore, each of the solutions 1), 2), 3), 4) and 5) were evaluated.

The use of an event package was discounted as the usage of subscribe/notify mechanism for two-way communication is not appropriate since subscribe/notify mechanism is to provide one-way communication consisting of notifications from notifier to subscriber indicating that certain events in notifier have occurred.

The use of session related methods for messages other than the initial MSD was discounted as it was concluded that usage of UPDATE method for transport of USSD message would have side effect of impacting dialog configuration (e.g. possibly changing the remote contact URI).

Use of the SIP MESSAGE method was discounted since NG-eCall protocol is dialog based and all NG-eCall messages has to be part of the related session.

Use of the media plane mechanisms was discounted because the amount of NG-eCall messages in a dialog is normally very small (normally only ????) and overhead caused by user plane setup (e.g. if MSRP is used as transport) would be disproportionately big in comparion to the actual NG-eCall message size.

Based on the above analyses, the SIP INFO method was chosen to transport the NG-eCall message between the UA and the PSAP.

3. Info Package Name

The info package name is emergencyCallData.eCall.

4. Info Package Parameters

None defined.

5. SIP Option-Tags

None defined.

6. INFO Message Body Parts

The INFO request carries:

1) an application/EmergencyCallData:eCall-control+xml MIME body; or

2) an application/EmergencyCallData:eCall-control+xml MIME body part and an application/emergencyCallData.eCall.MSD MIME body part.

7. Info Package Usage Restrictions

None defined.

8. Rate of INFO Requests

Maximum rate of SIP INFO requests associated with emergencyCallData.eCall info package is ......

9. Info Package Security Considerations

The security is based on the generic security mechanism provided for the underlying SIP signalling. No additional security mechanism is defined.

10. Implementation Details

The [I-D.ietf-ecrit-eCall] describes the NG-eCall protocol details.

11. Examples

The [I-D.ietf-ecrit-eCall] gives the NG-eCall protocol examples.

-------------

Kind regards

Ivo Sedlacek

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 15 Jun 2016 14:58:20 +0000

I got some offline comments on text below of section 6 of the template so please see below updated text.

Kind regards

Ivo Sedlacek

From: Ecrit [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: Friday, June 10, 2016 8:48 AM
To: Randall Gellens; Drage, Keith (Nokia - GB); [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] Usage of INFO by draft-ietf-ecrit-ecall

Hello,

-------------

      10.3. Applicability

      10.4. Info Package Name

      10.6. SIP Option-Tags

      10.12. Examples

-------------

-------------

1. Overall Description

NG-eCall messages are:

- request for MSD

- MSD

- ...

2. Applicability

3. Info Package Name

None defined.

5. SIP Option-Tags

None defined.

application/EmergencyCallData:eCall-control+xml message body parts and application/emergencyCallData.eCall.MSD message body parts carried in SIP INFO requests are associated with the emergencyCallData.eCall info package.

If both an application/EmergencyCallData:eCall-control+xml message body part and an application/emergencyCallData.eCall.MSD message body part are carried in a SIP INFO request, they are included in a multipart/mixed message body.

The application/EmergencyCallData:eCall-control+xml MIME type and the application/emergencyCallData.eCall.MSD MIME type are defined in [I-D.ietf-ecrit-eCall].

The Content-Disposition value of a message body part associated with the emergencyCallData.eCall info package is "info-package".

None defined.

8. Rate of INFO Requests

11. Examples

-------------

Kind regards

Ivo Sedlacek

---

From: Randall Gellens <[email-masked]>
Date: Mon, 27 Jun 2016 17:08:43 -0700

Hi Ivo,

Thanks for pointing out that the draft hadn't fully complied with 
Section 10 of 6086.  I've fixed it.

--Randy

At 2:58 PM +0000 6/15/16, Ivo Sedlacek wrote:

>  I got some offline comments on text below of section 6 of the 
> template so please see below updated text.
>
>  Kind regards
>
>  Ivo Sedlacek
>
>  From: Ecrit 
> [<mailto:[email-masked]>mailto:[email-masked]] On 
> Behalf Of Ivo Sedlacek
>  To: Randall Gellens; Drage, Keith (Nokia - GB); 
> <mailto:[email-masked]> [email-masked]
>  In order to define and register an info package in IANA, a 
> filled-in template for info package definition described in RFC6086 
> section 10 needs to be provided.
>
>  The draft can say e.g. the following. I am not expert on ecrit 
> eCall draft so text might need updates - feel free to update it 
> according to the draft.
>  -------------
>  1. Overall Description
>
>  The [I-D.ietf-ecrit-eCall] defines an NG-eCall protocol enabling a 
> PSAP to obtain a minimal set of data (MSD) from a UA located in a 
> vehicle. The protocol makes use of SIP INFO requests associated 
> with the emergencyCallData.eCall info package to transport NG-eCall 
> messages.
>
>  NG-eCall messages are:
>  - request for MSD
>  A number of solutions were discussed for the transportation of 
> NG-eCall messages between the UA and the PSAP. The solutions were:
>  The use of an event package was discounted as the usage of 
> subscribe/notify mechanism for two-way communication is not 
> appropriate since subscribe/notify mechanism is to provide one-way 
> communication consisting of notifications from notifier to 
> subscriber indicating that certain events in notifier have occurred.
>
>  The use of session related methods for messages other than the 
> initial MSD was discounted as it was concluded that usage of UPDATE 
> method for transport of USSD message would have side effect of 
> impacting dialog configuration (e.g. possibly changing the remote 
> contact URI).
>
>  Use of the SIP MESSAGE method was discounted since NG-eCall 
> protocol is dialog based and all NG-eCall messages has to be part 
> of the related session.
>
>  Use of the media plane mechanisms was discounted because the amount 
> of NG-eCall messages in a dialog is normally very small (normally 
> only ????) and overhead caused by user plane setup (e.g. if MSRP is 
> used as transport) would be disproportionately big in comparion to 
> the actual NG-eCall message size.
>
>  Based on the above analyses, the SIP INFO method was chosen to 
> transport the NG-eCall message between the UA and the PSAP.
>
>  3. Info Package Name
>
>  application/EmergencyCallData:eCall-control+xml message body parts 
> and application/emergencyCallData.eCall.MSD message body parts 
> carried in SIP INFO requests are associated with the 
> emergencyCallData.eCall info package.
>
>  If both an application/EmergencyCallData:eCall-control+xml message 
> body part and an application/emergencyCallData.eCall.MSD message 
> body part are carried in a SIP INFO request, they are included in a 
> multipart/mixed message body.
>
>  The application/EmergencyCallData:eCall-control+xml MIME type and 
> the application/emergencyCallData.eCall.MSD MIME type are defined 
> in [I-D.ietf-ecrit-eCall].
>
>  The Content-Disposition value of a message body part associated 
> with the emergencyCallData.eCall info package is "info-package".
>
>  Maximum rate of SIP INFO requests associated with 
> emergencyCallData.eCall info package is ......
>
>  The security is based on the generic security mechanism provided 
> for the underlying SIP signalling. No additional security mechanism 
> is defined.
>

-------------- Randomly selected tag: ---------------
Consistency is the last refuge of the unimaginative.
                                       --Oscar Wilde