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

"Drage, Keith (Nokia - GB)" <keith.drage@nokia.com> Thu, 19 May 2016 12:17 UTC

Return-Path: <keith.drage@nokia.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 3690C12D63E for <ecrit@ietfa.amsl.com>; Thu, 19 May 2016 05:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 n5yPriBW2FBs for <ecrit@ietfa.amsl.com>; Thu, 19 May 2016 05:17:52 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 7606412D9B7 for <ecrit@ietf.org>; Thu, 19 May 2016 05:17:51 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 25198D3AAA41D for <ecrit@ietf.org>; Thu, 19 May 2016 12:17:47 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4JCHnk7031075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <ecrit@ietf.org>; Thu, 19 May 2016 12:17:49 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4JCHljo008482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <ecrit@ietf.org>; Thu, 19 May 2016 14:17:48 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.13]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 19 May 2016 14:17:48 +0200
From: "Drage, Keith (Nokia - GB)" <keith.drage@nokia.com>
To: "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: Usage of INFO by draft-ietf-ecrit-ecall
Thread-Index: AdGxxaodRUBm1sCZRMealvPb/OtN8w==
Date: Thu, 19 May 2016 12:17:48 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEF7E2B@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ecrit/duDey7srJ7fm2oIdSB1BjHLlAd8>
Subject: [Ecrit] Usage of INFO by draft-ietf-ecrit-ecall
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, 19 May 2016 12:17:54 -0000

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.

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.

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.

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.

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.

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. 

Regards

Keith Drage