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

Ivo Sedlacek <ivo.sedlacek@ericsson.com> Thu, 08 December 2016 14:34 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 251D712A0A8 for <ecrit@ietfa.amsl.com>; Thu, 8 Dec 2016 06:34:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 2B6Z2JEyvBZv for <ecrit@ietfa.amsl.com>; Thu, 8 Dec 2016 06:34:16 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 8DD6512A0B4 for <ecrit@ietf.org>; Thu, 8 Dec 2016 06:34:14 -0800 (PST)
X-AuditID: c1b4fb2d-26a859800000561e-9c-58496f64f595
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id 88.94.22046.46F69485; Thu, 8 Dec 2016 15:34:12 +0100 (CET)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 8 Dec 2016 15:34:01 +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=o/u1CiwjUmVXIRWuZjI3i6UzlngJDcOb62YmVC5h1SM=; b=PKruL2O+Nq5bubeK8MrRYUh5gIYgRLeQEeA8qOFq/0CD5LHUqYeOgZPQvvRPkS6in/WZe7i1cAztIHvc0OFOPNVer4DmusHbHQRXFbO6eNskpBWxfIvAWVAjo4gbp4Q3oOODGBVCwGk5CHTaQXNHFGktP2sW8jz0rxt12lWA0QQ=
Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2465.eurprd07.prod.outlook.com (10.169.153.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Thu, 8 Dec 2016 14:34:00 +0000
Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) by AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) with mapi id 15.01.0771.009; Thu, 8 Dec 2016 14:34:00 +0000
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: Randall Gellens <rg+ietf@randy.pensive.org>, Alissa Cooper <alissa@cooperw.in>
Thread-Topic: [Ecrit] Objection to draft-ietf-ecrit-ecall progressing to state "Submitted to IESG for Publication"
Thread-Index: AQHST02Iv6jG2lDMHk+OFtLh4YL6KKD+EMCA
Date: Thu, 8 Dec 2016 14:34:00 +0000
Message-ID: <AM5PR0701MB2468EDF7EEA81C8F137441D2E5840@AM5PR0701MB2468.eurprd07.prod.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> <p06240603d46b9dccdd89@[99.111.97.136]>
In-Reply-To: <p06240603d46b9dccdd89@[99.111.97.136]>
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: [193.179.210.162]
x-ms-office365-filtering-correlation-id: 309645bf-3b60-466d-059a-08d41f774049
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2465;
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2465; 7:SbA7j9/IcqZ+yu4VUMtWOFbQKQKgQGYM4ctxOdQnUszRC6S2DBGOlrQ19R9z2pKky1ngvTJwLsMUL3K47gGIsK6o7z1B0sCEOXSZOUcfMz6jkRDk2bij4CGG7qBQE3KWLvrV1xkp6mXVg59IcylY02+N1poUVlkbTNAqJqkOzMEIumsZXqQzr0rQxzQiGbAnqzOnOJ+0+nR3gCxvpxAbf03vaQ8hCpogozUR8vKATmz79wetUtDEHIOGidxau33fqrgPmuC96Uf1g8bNS0FjtB208szVLKZ19UTLzIChmM42mLDlBz4H8VHhxv1nSRxnz0ILFM/PfxMc8y0jiqS48MP+6dQ9cFkmKAgcDGtsxJybgcyVzh7vs88B7h1fUljCmbBK1GQnlH5GFX8wGzwdP4m+4hrS8Hn/paIhpBKrEXHmEWkuyJxcAFAtPv7MeJqiUVQMXua3EjiRdiruj2AslQ==
x-microsoft-antispam-prvs: <AM5PR0701MB2465F0FF4F39E303E399D58CE5840@AM5PR0701MB2465.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(788757137089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:AM5PR0701MB2465; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2465;
x-forefront-prvs: 0150F3F97D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39850400002)(39840400002)(39450400003)(39860400002)(39410400002)(199003)(189002)(51914003)(33656002)(8936002)(81166006)(229853002)(81156014)(3660700001)(2906002)(230783001)(3280700002)(68736007)(7846002)(6506006)(77096006)(76576001)(97736004)(5890100001)(5001770100001)(38730400001)(2900100001)(189998001)(105586002)(92566002)(3846002)(102836003)(6116002)(106116001)(106356001)(86362001)(7696004)(74316002)(54356999)(93886004)(5660300001)(9686002)(122556002)(66066001)(7736002)(4326007)(8676002)(305945005)(101416001)(50986999)(76176999)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2465; H:AM5PR0701MB2468.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2016 14:34:00.5088 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2465
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUyM2K7jW5KvmeEwfpT1hbTz/xltJh2bAO7 ReOip6wW3593MTqweHx58pLJY8mSn0weW+88ZvFYdOgHawBLFJdNSmpOZllqkb5dAlfGvClb WQpualf8WLmbsYFxvlIXIyeHhICJxKumHcwgtpDAOkaJ7reZXYxcQPZxRolvT96wgzgsAr3M En9mX2eGyMxkkrh9az4jhHOaUaK15RoLSD+bgJ7ExC1HWEFsEYEQiaeT/zCC2MwCrhLXtv9i A7GFBUokjhyezAZRUyoxbeM6dgjbSOLBrwawOSwCKhJfvhwFi/MKJEi0Xd4Idd8xFomHr01B bE6guzf9eQ22i1FATOL7qTVMELvEJW49mc8E8ZuAxJI955khbFGJl4//QdXHSPzv/swKEVeW 2DLpPVSNr8SkBaeg4v4S107NYwN5UkKgD2jv1btAz3AAOfkSixodIGosJN4/uM8MVcMk8eLe NahBMhLnX81lh0h8Y5U4u/43C8QHqRLL17YyQkJCSuLulU7GCYxas5AcDmHrSCzY/YkNwtaW WLbwNfMscGAISpyc+YRlASPLKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzABHNwy2/dHYyr XzseYhTgYFTi4f2g7BEhxJpYVlyZe4hRgoNZSYT3TJZnhBBvSmJlVWpRfnxRaU5q8SFGaQ4W JXFes5X3w4UE0hNLUrNTUwtSi2CyTBycUg2MUYXel3cF1n7omMOrkt5rGZ3Ca/c8zjbZQ6su a8Keq42JXmuDH3CzXvta8PQ2/+OuGXPVFapZv//N+VoyyXV38sOOsF0/1/i9kXmvGJ5W7i07 VfbFn/W/j7/83375697Im+t1c2utzTbVvp6xe+HhhGdCszVK7z65cnDXh/K50aleP9kj2I34 lFiKMxINtZiLihMB/XPwHywDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/oH1PK9wKiq29P8j7pDcwy-RbgOM>
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, 08 Dec 2016 14:34:23 -0000

Hello Randall,

thanks for the updates.

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

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.

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

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.

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

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.

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