Subject: Re: [Ecrit] Objection to draft-ietf-ecrit-ecall progressing to state "Submitted to IESG for Publication"

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 1 Dec 2016 10:39:07 +0000

Hello,

thank you Alissa.

I proposed changes resolving my concerns in a mail sent in 3rd Nov 2016 to ECRIT list. In that mail, I included an updated draft with proposed changes and explained why I did them.

Let me summarize those proposed changes again:

i)

Proposed change: replace "[RFC7852] establishes a general mechanism for attaching blocks of data to a SIP emergency call." with "[RFC7852] establishes a general mechanism for conveying blocks of data in a SIP emergency call.".

Reason: rfc7852 does not define "attaching" data, rfc7852 defines "conveying" of data.

ii)

Proposed change: remove "This mechanism permits certain emergency call MIME types to be attached to SIP messages."

Reason:

- rfc7852 does not define "attaching" data, rfc7852 defines "conveying" of data.

- the preceding sentence "[RFC7852] establishes a general mechanism for conveying blocks of data in a SIP emergency call." says the same thing.

- we never include a MIME type in a message, we can only include a message-body of a given MIME type or a MIME body part of a given MIME type.

- this sentence attempts to formulate what rfc7852 contains and that's not needed - the reader should read rfc7852 instead.

iii)

Proposed change: replace "An In-Vehicle System (IVS) transmits an MSD (see Section 5) by encoding it per Annex A of EN 15722 [msd] and attaching it to a SIP message as a MIME body part per [RFC7852]." with "An In-Vehicle System (IVS) transmits an MSD (see Section 5) by encoding it per Annex A of EN 15722 [msd] in a MIME body part and by including the MIME body part in a SIP message as a block transmitted by value per [RFC7852]. "

Reason: rfc7852 does not define "attaching" data but rfc7852 defines what to do when blocks are transmitted by value.

iv)

Proposed change: replace "A PSAP or IVS transmits a metadata/control object (see Section 9) by encoding it per the description in this document and attaching it to a SIP message as a MIME body part per [RFC7852]." with "A PSAP or IVS transmits a metadata/control object (see Section 9) by encoding it per the description in this document in a MIME body part and including the MIME body part in a SIP message as a block transmitted by value per [RFC7852]."

Reason: same reason as for the previous proposed change.

v)

Proposed change: replace "An In-Vehicle System (IVS) initiating an NG-eCall attaches an MSD to the initial INVITE and optionally attaches a metadata/control object informing the PSAP of its capabilities." with "An In-Vehicle System (IVS) initiating an NG-eCall

   - includes a MIME body part containing an MSD as a block transmitted by value per [RFC7852]; and

  - optionally includes another MIME body part containing a metadata/control object informing the PSAP of its capabilities as a block transmitted by value per [RFC7852];

  in the initial INVITE request."

Reason: same reason as for the previous proposed change.

vi)

Proposed change: replace "The PSAP creates a metadata/control object acknowledging receipt of the MSD and attaches it to the SIP final response to the INVITE." with "The PSAP creates a metadata/control object acknowledging receipt of the MSD and includes it in the SIP final response to the INVITE request as a block transmitted by value per [RFC7852]."

Reason: same reason as for the previous proposed change.

vii)

Proposed change: extend "A PSAP is able to reject a call while indicating that it is aware of the situation by including a metadata/control object acknowledging the MSD and containing "received=true" in a final response using SIP response code 600 (Busy Everywhere), 486 (Busy Here), or 603 (Decline)." with additional text "as a block transmitted by value per [RFC7852]".

Reason: RFC7852 is to be used both when call is accepted and when it is rejected.

viii)

Proposed change: replace "To do so, the PSAP creates a metadata/control object requesting an MSD and attaches it to a SIP INFO request and sends it within the dialog." with "To do so, the PSAP creates a metadata/control object requesting an MSD, includes it to a SIP  INFO request as per [RFC6086] and sends it within the dialog.".

Reason: There has been discussion in past on whether rfc7852 is needed in SIP INFO request or not as sematic of the bodies associated with info package is defined in the info package itself. IIRC, the conclusion was:

- rfc7852 is not needed; and

- to align with how body parts are sent in an INFO request and in messages other than INFO requests, a Call-Info header field inclusion is added in SIP INFO request - see 2nd paragraph of section 10.6.

ix)

Proposed change: replace "The IVS then attaches an updated MSD to a SIP INFO request and sends it within the dialog." with "The IVS then includes an updated MSD to a SIP INFO request as per [RFC6086] and sends it within the dialog.".

Reason: same reason as for the previous proposed change.

x)

Proposed change: extend "If the IVS is unable to send an MSD, it instead sends a metadata/control object acknowledging the request with the 'success' parameter set to 'false' and a 'reason' parameter (and optionally a 'details' parameter) indicating why the request could not be accomplished." with additional text "as per [RFC6086]".

Reason: RFC6086 is to be used both when request to send MSD is accepted and when it is rejected.

xi)

Proposed change: replace "See Section 6 for more information on attaching a metadata/control block to a SIP message." with "See Section 6 for more information on including a metadata/control block to a SIP message.".

Reason: "attaching X to SIP message" is not defined.

It would be also nice to fix the following minor issues:

- "INVITE" is used in some places where "INVITE request" should be.

- "method" is missing is some places.

However, those are nice-to-have and not critical.

Kind regards

Ivo Sedlacek

---

From: Randall Gellens <[email-masked]>
Date: Thu, 1 Dec 2016 11:57:28 -0800

At 3:40 AM +0000 11/30/16, Christer Holmberg wrote:

>  Hi,
>
>  So, exactly what wording do you intend to add?
>
>  Regards,
>
>  Christer

Hi Christer,

I propose to add to Section 1 ("Terminology") the following:

----------
In this document, the term "attach" means to include a specified set 
of data as a body part within a SIP message. Section 7 ("Data 
Transport") describes how an MSD or metadata/control block is 
included in a SIP message.
----------

>
>  Sent from my iPhone
>
>>  On 30 Nov 2016, at 1.00, Randall Gellens <[email-masked]> wrote:
>>
>>  At 3:28 PM -0500 11/29/16, Brian Rosen wrote:
>>
>>>  Despite your characterization, there is no technical issue here. 
>>> Everyone agrees on how the mechanism works.  There is an 
>>> editorial issue on interpreting the word "attached".  I don't 
>>> object to wordsmithing to make it more clear, but it's not a 
>>> technical problem and it can be dealt with any time before 
>>> publication.
>>
>>  I agree and plan to add clarifying wording as part of IETF Last Call.
>>
>>  --
>>  Randall Gellens
>>  Opinions are personal;    facts are suspect;    I speak for myself only
>>  -------------- Randomly selected tag: ---------------
>>  As far as the laws of mathematics refer to reality, they are not
>>  certain; and as far as they are certain, they do not refer to reality.
>>                                                    --Albert Einstein

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Every man thinks God is on his side.
The rich and powerful know he is.
                     --Jean Anouilh

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Dec 2016 20:00:34 +0000

Hi,

> In this document, the term "attach" means to include a specified set of data as a body 
> part within a SIP message. Section 7 ("Data Transport") describes how an MSD or 
> metadata/control block is included in a SIP message.
>----------

I think we should properly fix the text throughout the document, as suggested by Ivo. It's not that much work to do.

Regards,

Christer

>>> Everyone agrees on how the mechanism works.  There is an editorial 
>>> issue on interpreting the word "attached".  I don't object to 
>>> wordsmithing to make it more clear, but it's not a technical problem 
>>> and it can be dealt with any time before publication.
>>
>>  -------------- Randomly selected tag: ---------------  As far as the 
>> laws of mathematics refer to reality, they are not  certain; and as 
>> far as they are certain, they do not refer to reality.
>>                                                    --Albert Einstein

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- Every man thinks God is on his side.
The rich and powerful know he is.
                     --Jean Anouilh

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 2 Dec 2016 14:11:14 +0000

+1 to Christer and Ivo

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 01 December 2016 20:01
To: Randall Gellens <[email-masked]>
Cc: [email-masked]; Brian Rosen <[email-masked]>
Subject: Re: [Ecrit] Objection to draft-ietf-ecrit-ecall progressing to state "Submitted to IESG for Publication"

Hi,

>Transport") describes how an MSD or  metadata/control block is included in a SIP message.
>----------

Regards,

Christer

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

---

From: Randall Gellens <[email-masked]>
Date: Mon, 5 Dec 2016 15:14:02 -0800

At 10:39 AM +0000 12/1/16, Ivo Sedlacek wrote:

>  I proposed changes resolving my concerns in a mail sent in 3rd Nov 
> 2016 to ECRIT list. In that mail, I included an updated draft with 
> proposed changes and explained why I did them.
>
>  Proposed change: replace "[RFC7852] establishes a general mechanism 
> for attaching blocks of data to a SIP emergency call." with 
> "[RFC7852] establishes a general mechanism for conveying blocks of 
> data in a SIP emergency call.".

Ok, done.

>
>  ii)
>  Proposed change: remove "This mechanism permits certain emergency 
> call MIME types to be attached to SIP messages."
>  Reason:
>  - the preceding sentence "[RFC7852] establishes a general mechanism 
> for conveying blocks of data in a SIP emergency call." says the 
> same thing.
>  - we never include a MIME type in a message, we can only include a 
> message-body of a given MIME type or a MIME body part of a given 
> MIME type.
>  - this sentence attempts to formulate what rfc7852 contains and 
> that's not needed - the reader should read rfc7852 instead.

OK, done.

>
>  iii)
>  Proposed change: replace "An In-Vehicle System (IVS) transmits an 
> MSD (see Section 5) by encoding it per Annex A of EN 15722 [msd] 
> and attaching it to a SIP message as a MIME body part per 
> [RFC7852]." with "An In-Vehicle System (IVS) transmits an MSD (see 
> Section 5) by encoding it per Annex A of EN 15722 [msd] in a MIME 
> body part and by including the MIME body part in a SIP message as a 
> block transmitted by value per [RFC7852]. "
>  Reason: rfc7852 does not define "attaching" data but rfc7852 
> defines what to do when blocks are transmitted by value.

OK, done.

>
>  iv)
>  Proposed change: replace "A PSAP or IVS transmits a 
> metadata/control object (see Section 9) by encoding it per the 
> description in this document and attaching it to a SIP message as a 
> MIME body part per [RFC7852]." with "A PSAP or IVS transmits a 
> metadata/control object (see Section 9) by encoding it per the 
> description in this document in a MIME body part and including the 
> MIME body part in a SIP message as a block transmitted by value per 
> [RFC7852]."

OK.

>
>  v)
>  Proposed change: replace "An In-Vehicle System (IVS) initiating an 
> NG-eCall attaches an MSD to the initial INVITE and optionally 
> attaches a metadata/control object informing the PSAP of its 
> capabilities." with "An In-Vehicle System (IVS) initiating an 
> NG-eCall
>    - optionally includes another MIME body part containing a 
> metadata/control object informing the PSAP of its capabilities as a 
> block transmitted by value per [RFC7852];

OK.

>
>  vi)
>  Proposed change: replace "The PSAP creates a metadata/control 
> object acknowledging receipt of the MSD and attaches it to the SIP 
> final response to the INVITE." with "The PSAP creates a 
> metadata/control object acknowledging receipt of the MSD and 
> includes it in the SIP final response to the INVITE request as a 
> block transmitted by value per [RFC7852]."

OK.

>
>  vii)
>  Proposed change: extend "A PSAP is able to reject a call while 
> indicating that it is aware of the situation by including a 
> metadata/control object acknowledging the MSD and containing 
> "received=true" in a final response using SIP response code 600 
> (Busy Everywhere), 486 (Busy Here), or 603 (Decline)." with 
> additional text "as a block transmitted by value per [RFC7852]".

OK.

>
>  viii)
>  Proposed change: replace "To do so, the PSAP creates a 
> metadata/control object requesting an MSD and attaches it to a SIP 
> INFO request and sends it within the dialog." with "To do so, the 
> PSAP creates a metadata/control object requesting an MSD, includes 
> it to a SIP  INFO request as per [RFC6086] and sends it within the 
> dialog.".
>  Reason: There has been discussion in past on whether rfc7852 is 
> needed in SIP INFO request or not as sematic of the bodies 
> associated with info package is defined in the info package itself. 
> IIRC, the conclusion was:
>  - to align with how body parts are sent in an INFO request and in 
> messages other than INFO requests, a Call-Info header field 
> inclusion is added in SIP INFO request - see 2nd paragraph of 
> section 10.6.

I changed "attach" to "include".  Note that the paragraph already says:
    Per
    [RFC6086], metadata/control objects and MSDs are sent using the INFO
    package defined in Section 10.  In addition, to align with how an MSD
    or metadata/control block is transmitted in a SIP message other than
    an INFO request, a Call-Info header field is included in the SIP INFO
    request to reference the MSD or metadata/control block per [RFC7852].

I believe this makes it very clear that (a) everything sent within 
INFO is done per RFC6086, and (b) the use of Call-Info is done for 
consistency with non-INFO messages.

>
>  ix)
>  Proposed change: replace "The IVS then attaches an updated MSD to a 
> SIP INFO request and sends it within the dialog." with "The IVS 
> then includes an updated MSD to a SIP INFO request as per [RFC6086] 
> and sends it within the dialog.".

As above, I changed "attach" to "include" but the reference to RFC 
6086 is within the same paragraph and covers this sentence so doesn't 
need to be repeated.

>
>  x)
>  Proposed change: extend "If the IVS is unable to send an MSD, it 
> instead sends a metadata/control object acknowledging the request 
> with the 'success' parameter set to 'false' and a 'reason' 
> parameter (and optionally a 'details' parameter) indicating why the 
> request could not be accomplished." with additional text "as per 
> [RFC6086]".

As above.

>
>  xi)
>  Proposed change: replace "See Section 6 for more information on 
> attaching a metadata/control block to a SIP message." with "See 
> Section 6 for more information on including a metadata/control 
> block to a SIP message.".

OK.

>  However, those are nice-to-have and not critical.

I fixed cases where "request" was missing.  If you point out cases 
where "method" is missing I can fix them as part of IETF LC.

-------------- Randomly selected tag: ---------------
[C]reativity [requires] the discomfort of confusion, uncertainty,
anxiety and ambiguity.
        --Jeff Mauzy and Richard Harriman, in 'Creativity Inc.'

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 8 Dec 2016 14:34:00 +0000

Hello Randall,

thanks for the updates.

> > INFO request and sends it within the dialog." with "To do so, the PSAP 
> > creates a metadata/control object requesting an MSD, includes it to a 
> > SIP  INFO request as per [RFC6086] and sends it within the dialog.".
> > needed in SIP INFO request or not as sematic of the bodies associated 
> > with info package is defined in the info package itself.
> > messages other than INFO requests, a Call-Info header field inclusion 
> > is added in SIP INFO request - see 2nd paragraph of section 10.6.
> 
> I believe this makes it very clear that (a) everything sent within INFO is 
> done per RFC6086, and (b) the use of Call-Info is done for consistency with 
> non-INFO messages.

If I understood it correctly, the text will be: "To do so, the PSAP creates a metadata/control object requesting an MSD and includes it to a SIP INFO request and sends it within the dialog."
if so, that's OK with me.
Thanks.

> > SIP INFO request and sends it within the dialog." with "The IVS then 
> > includes an updated MSD to a SIP INFO request as per [RFC6086] and 
> > sends it within the dialog.".
> 6086 is within the same paragraph and covers this sentence so doesn't need to 
> be repeated.

If I understood it correctly, the text will be: "The IVS then includes an updated MSD to a SIP INFO request and sends it within the dialog."
if so, that's OK with me.
Thanks.

OK.

> where "method" is missing I can fix them as part of IETF LC.

IMO, "method" should be used in section 10.2 as follows:
----------------------
10.2.  Applicability

   This section describes "why the Info Package mechanism, rather than
   some other mechanism, has been chosen for the specific use-case...."

   The use of INFO >>method<< is based on an analysis of the requirements against
   the intent and effects of INFO >>method<< versus other approaches (which
   included SIP MESSAGE >>method<<, SIP OPTIONS >>method<<, SIP re-INVITE >>method<<, media plane
   transport, and non-SIP protocols).  In particular, the transport of
   emergency call data blocks occurs within a SIP emergency dialog, per
   Section 6, and is normally carried in the initial INVITE  >>request<<and its
   response; the use of INFO >>method<< only occurs when emergency-call-related
   data needs to be sent mid-call.  While MESSAGE >>method (or request?)<< could be used, it is
   not tied to a SIP dialog as is INFO >>method (or request?)<< and thus might not be associated
   with the dialog.  SIP OPTIONS >>method (or request?)<< or re-INVITE  >>method (or request?)<< could also be used, but is
   seen as less clean than INFO >>method (or request?)<<.  SUBSCRIBE/NOTIFY  >>methods (or requests?)<< could be coerced into
   service, but the semantics are not a good fit, e.g., the subscribe/
   notify mechanism provides one-way communication consisting of (often
   multiple) notifications from notifier to subscriber indicating that
   certain events in notifier have occurred, whereas what's needed here
   is two-way communication of data related to the emergency dialog.
   Use of the media plane mechanisms was discounted because the number
   of messages needing to be exchanged in a dialog is normally zero or
   very few, and the size of the data is likewise very small.  The
   overhead caused by user plane setup (e.g., to use MSRP as transport)
   would be disproportionately large.

   Based on the the analyses, the SIP INFO method was chosen to provide
   for mid-call data transport.
----------------------

Kind regards

Ivo Sedlacek