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

Randall Gellens <rg+ietf@randy.pensive.org> Mon, 05 December 2016 23:15 UTC

Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4606012960D for <ecrit@ietfa.amsl.com>; Mon, 5 Dec 2016 15:15:36 -0800 (PST)
X-Quarantine-ID: <Z751U0q0wM2S>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Level:
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z751U0q0wM2S for <ecrit@ietfa.amsl.com>; Mon, 5 Dec 2016 15:15:34 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8B6129E8B for <ecrit@ietf.org>; Mon, 5 Dec 2016 15:15:34 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 5 Dec 2016 15:15:33 -0800
Mime-Version: 1.0
Message-Id: <p06240603d46b9dccdd89@[99.111.97.136]>
In-Reply-To: <DB6PR0701MB2469A80EF7687838546760CAE58F0@DB6PR0701MB2469.eurprd07.pro d.outlook.com>
References: <AM5PR0701MB2468062E91B51B26AC2396DBE5B70@AM5PR0701MB2468.eurprd07.pro d.outlook.com> <AM5PR0701MB246818833BDFCDA9E5AB9876E58A0@AM5PR0701MB2468.eurprd07.pro d.outlook.com> <7594FB04B1934943A5C02806D1A2204B4BEB11F2@ESESSMB209.ericsson.se> <205FED72-32AA-494B-A2B0-3BD579BE9FD3@salsgiver.com> <AM5PR0701MB24680C4B1DEBC06EA6A224B7E58C0@AM5PR0701MB2468.eurprd07.pro d.outlook.com> <5B603E8A-BB04-435E-A721-9D8FF4FBB394@cooperw.in> <DB6PR0701MB2469A80EF7687838546760CAE58F0@DB6PR0701MB2469.eurprd07.pro d.outlook.com>
X-Mailer: Eudora for Mac OS X
Date: Mon, 5 Dec 2016 15:14:02 -0800
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, Alissa Cooper <alissa@cooperw.in>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/2pextmWm3v0mduxMQVpds4BkTOs>
Cc: "ecrit@ietf.org" <ecrit@ietf.org>, Brian Rosen <br@salsgiver.com>
Subject: Re: [Ecrit] Objection to draft-ietf-ecrit-ecall progressing to state "Submitted to IESG for Publication"
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Dec 2016 23:15:36 -0000

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

Ok, done.

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

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]."
>  Reason: same reason as for the previous proposed change.

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

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]."
>  Reason: same reason as for the previous proposed change.

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]".
>  Reason: RFC7852 is to be used both when call is accepted and when 
> it is rejected.

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

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.".
>  Reason: same reason as for the previous proposed change.

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]".
>  Reason: RFC6086 is to be used both when request to send MSD is 
> accepted and when it is rejected.

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.".
>  Reason: "attaching X to SIP message" is not defined.

OK.

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

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.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
[C]reativity [requires] the discomfort of confusion, uncertainty,
anxiety and ambiguity.
        --Jeff Mauzy and Richard Harriman, in 'Creativity Inc.'