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

Ivo Sedlacek <ivo.sedlacek@ericsson.com> Thu, 01 December 2016 10:39 UTC

Return-Path: <ivo.sedlacek@ericsson.com>
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 82808129C26 for <ecrit@ietfa.amsl.com>; Thu, 1 Dec 2016 02:39:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com
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 nHUfjSWr8CPV for <ecrit@ietfa.amsl.com>; Thu, 1 Dec 2016 02:39:18 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58DD0129660 for <ecrit@ietf.org>; Thu, 1 Dec 2016 02:39:17 -0800 (PST)
X-AuditID: c1b4fb30-851fe70000000c18-be-583ffdd1e15c
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 48.0D.03096.1DDFF385; Thu, 1 Dec 2016 11:39:15 +0100 (CET)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.84) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 1 Dec 2016 11:39:13 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XIyzunkty2btRC2KEHOhEHaxYtUbJX/AHcOVYAFAVfQ=; b=afRIIHjKGenB5xbG0ZpcbUB9UWYW4Vhld9ETwDwN5+otbJq5uQKAKDdUhlEJk/4oOB+msyKknuN7ZJISkJrKZ3iXxP3lBnZx5KAq7GGvH8v44m6YalAMUf96uo8TSzHk9JFVp3c3OZd7Z1zuJjcQKzT8J7M2Ym3073ay6tBPvNE=
Received: from DB6PR0701MB2469.eurprd07.prod.outlook.com (10.168.75.150) by DB6PR0701MB2469.eurprd07.prod.outlook.com (10.168.75.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.5; Thu, 1 Dec 2016 10:39:07 +0000
Received: from DB6PR0701MB2469.eurprd07.prod.outlook.com ([10.168.75.150]) by DB6PR0701MB2469.eurprd07.prod.outlook.com ([10.168.75.150]) with mapi id 15.01.0761.009; Thu, 1 Dec 2016 10:39:07 +0000
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: Alissa Cooper <alissa@cooperw.in>
Thread-Topic: [Ecrit] Objection to draft-ietf-ecrit-ecall progressing to state "Submitted to IESG for Publication"
Thread-Index: AdJFbsXsFLqBou5eRfmZkKIHQi68XQD77loQAEcH03AAASC2gAAZtXwwABmzOIAAHC6a4A==
Date: Thu, 01 Dec 2016 10:39:07 +0000
Message-ID: <DB6PR0701MB2469A80EF7687838546760CAE58F0@DB6PR0701MB2469.eurprd07.prod.outlook.com>
References: <AM5PR0701MB2468062E91B51B26AC2396DBE5B70@AM5PR0701MB2468.eurprd07.prod.outlook.com> <AM5PR0701MB246818833BDFCDA9E5AB9876E58A0@AM5PR0701MB2468.eurprd07.prod.outlook.com> <7594FB04B1934943A5C02806D1A2204B4BEB11F2@ESESSMB209.ericsson.se> <205FED72-32AA-494B-A2B0-3BD579BE9FD3@salsgiver.com> <AM5PR0701MB24680C4B1DEBC06EA6A224B7E58C0@AM5PR0701MB2468.eurprd07.prod.outlook.com> <5B603E8A-BB04-435E-A721-9D8FF4FBB394@cooperw.in>
In-Reply-To: <5B603E8A-BB04-435E-A721-9D8FF4FBB394@cooperw.in>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ivo.sedlacek@ericsson.com;
x-originating-ip: [88.208.76.170]
x-ld-processed: 92e84ceb-fbfd-47ab-be52-080c6b87953f,ExtAddr
x-ms-office365-filtering-correlation-id: bb9039ea-bac4-48a3-2be3-08d419d6475f
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:DB6PR0701MB2469;
x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2469; 7:N/baz4cOh2eCaIoCbrt1mMxmJ7VimOQ5HKWtHVzlk6CFQ1TQVHUTdysjrisjNjFPVdq/a9oes8LqzXLZGlpfhG15Ed39iHna4fnHQX32tze0nrXPOxEmDk2Y0LJfW1aubX18bhADWeiZUfbqOuXNkzfr5MEjKQtbgzZu7XwjMO31tmlOA5Yj1rx7KBsRXjXc7Gj+vBmIuz+yGkUbQbv7JLjaGBw5SelF2SWnZLBtKKSF9rmqQjjZrorrCpVRl7cNYi9ocgnxFR6JwuDPaJddIy2qBUWHai8ZM5A02NUYseqW+WA67qGgvjoK3cnjfJOmJ4JgTBmtTNrYIBywIHTgUnj1mSYM23hazY2WzzG2tb+WqKRr5L2C3lcs59NfkCtdYLIXcyhgCkZ41sQlI2O2gNad8rkK1kINFV5z+SiqGsihsems3dza0bU5lCuQqivwoL9KEONcrCyxW1DFnIPcpQ==
x-microsoft-antispam-prvs: <DB6PR0701MB24690371CCAB6A93958BDE97E58F0@DB6PR0701MB2469.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(788757137089)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:DB6PR0701MB2469; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2469;
x-forefront-prvs: 014304E855
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(50986999)(110136003)(76176999)(229853002)(106356001)(3660700001)(105586002)(2950100002)(7696004)(7736002)(6506003)(92566002)(6916009)(54356999)(66066001)(93886004)(189998001)(74316002)(7846002)(101416001)(33656002)(97736004)(5660300001)(3280700002)(230783001)(2906002)(39450400002)(3846002)(2900100001)(122556002)(86362001)(102836003)(5890100001)(8936002)(76576001)(81156014)(81166006)(9686002)(790700001)(8676002)(39410400001)(4326007)(68736007)(38730400001)(77096006)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2469; H:DB6PR0701MB2469.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB6PR0701MB2469A80EF7687838546760CAE58F0DB6PR0701MB2469_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2016 10:39:07.5156 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2469
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUhUURiGOXPvzFyHBk6Ty4dL5JSUgksSJmQu/8yIJloULXLK65ZbcydL /ZGpEzGiY2JumIZriVs2plYiWo5atqhFmGFkZo0QmqNpiJp3joH/nvO+L+f7zsthKFmr0JaJ SVCzqgRlnFwkoUtC2k+5jq76hXgYepy9i4ZWkXehoUXsfaPyu9CfClyYMgoCq6v/CgIre5eF CipU4hPBxsUksyp333BJdGbWR0HSzDt0ra1+AKWj+6+QFlkwgA+AqWB2gyWMDDchmB7W07wh w/0IWjJ28gaNcygYeK8Vk1SxAFo0z2lyGETwK3PAfJcIu8Ft/Qshz5bYCT4YlkVaxDAUToO6 yZM87sAclI2zJKGGijediPAZ6BpKNw+m8R6Y1BWIeZbicLhVWyMio7ooaBsZFfGGBfaFuZpV 8yiErWHpZYOAZwrbwKepCgF5GobqZ28pwlZg/La2mT8L69kmIdEdQafRiQn7QHF2EcXvCfgY PH6kIPJxuJk/tHlNLg3Tv0MJJ4LmT+2mHghLowvmfjYyApjuM9DEsIeJxQyKGN1CWFwvR6Re FuoaNSgPuZRu2ZtwIjTPj9Cl5gK2w2DJ1AbzNTpD8xN3EnGEguyvYsL7QFN2V7xVv4fE9ciK Y7kL8VGenm6sKuYixyUmuCWw6la08ZN69CseHcj4I6AXYQbJt0mTjL4hMqEymUuJ70XAUHJL KVrxC5FJI5Qpqawq8bzqShzL9SI7hpbbSL0efAmW4Silmr3Eskms6r8rYCxs05Fur1/kCSo2 rF06pph1KCwvbb8e1KCI3WVKe9hDTTqk94VVlYyNDx+1rNL5L4vyZvQd9k8bg13th3LnJkaC tal3jlRyrxVz8wH+eT79wsO1+adb/UU1a16XsyTOVyt3RzbF//zsERS6nONgsNMePGfqtE7u rre6pTfGOMXXHjLZyGkuWrnfhVJxyn8H4mYLRQMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/DF24aIIHIK5s2wsIGziL3mxXA4Q>
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: Thu, 01 Dec 2016 10:39:21 -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