Re: [Insipid] last call for draft-ietf-insipid-logme-marking-11

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Fri, 13 July 2018 07:21 UTC

Return-Path: <Peter.Dawes@vodafone.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306FC130E92; Fri, 13 Jul 2018 00:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 xwqwpOeMgUzV; Fri, 13 Jul 2018 00:21:38 -0700 (PDT)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.66]) (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 7BA6C130DCC; Fri, 13 Jul 2018 00:21:38 -0700 (PDT)
Received: from [46.226.52.199] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-b.eu-west-1.aws.symcld.net id 8D/C0-19217-003584B5; Fri, 13 Jul 2018 07:21:36 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRWlGSWpSXmKPExsWi75nTrcsQ7BF tsO0pu0Vr3yYmi/n3nzFZvDxR5sDsMXn/V2aPJUt+MgUwRbFm5iXlVySwZiy7w17wW6Zi34a9 jA2Mt8W7GLk4hAS2M0ocbtjN3sXICeQcZpRYNjUHIgFkz3jzkR3C2cwosfLCHiCHg4NNwF5ix p4YkLiIwBZGia9/r7KBdAsL2EmsP7eVEcQWAaq5sG43C4RtJPH6wkKwGhYBVYl329+zgti8Aq ES9+c8Y4LYbCTxZv8zsBpOAWOJaS0XmEFsRgFZiS+Nq8FsZgFxiVtP5oPVSwgISCzZc54Zwha VePn4HytEjY7Egt2f2CBsbYllC18zQ+wSlDg58wkLxC5ViX8rFzFNYBSdhWTsLCTts5C0z0LS voCRZRWjRVJRZnpGSW5iZo6uoYGBrqGhka6hpbmuoYWRXmKVbpJeaqlueWpxia6hXmJ5sV5xZ W5yTopeXmrJJkZgtDEAwQ7GpReSDzFKcjApifKyOHpEC/El5adUZiQWZ8QXleakFh9ilOHgUJ LgdQsCygkWpaanVqRl5gDjHiYtwcGjJMLbFgiU5i0uSMwtzkyHSJ1iNOb4837qJGaOfd3TJjE LseTl56VKifOKgUwSACnNKM2DGwRLR5cYZaWEeRmBThPiKUgtys0sQZV/xSjOwagkzJsOspAn M68Ebt8roFOYgE6JS3EDOaUkESEl1cB45bLfhrj0jITcbZxNRzdnvrM+7O/7s6/FcrU+z7IPv Rn/RGe46fs/nK1vYyU2f8LZN5MY3kkfiz1q3p57pbKxk2GBo90choL+tTYy9fZ2QXqBhpo2Cw 8b3Ex9x59i9ngB+73vhq2/b79OnbFv1oTAWO61PV0vVkUW8Ty7LhrcVrY6/o4I2xElluKMREM t5qLiRACByHPeQgMAAA==
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-14.tower-287.messagelabs.com!1531466492!4690757!6
X-Originating-IP: [47.73.108.139]
X-SYMC-ESS-Client-Auth: outbound-route-from=pass
X-StarScan-Received:
X-StarScan-Version: 9.9.15; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10805 invoked from network); 13 Jul 2018 07:21:36 -0000
Received: from vgdpm13vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (47.73.108.139) by server-14.tower-287.messagelabs.com with AES256-SHA256 encrypted SMTP; 13 Jul 2018 07:21:36 -0000
Received: from VOEXH08W.internal.vodafone.com (47.73.211.206) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 13 Jul 2018 09:21:34 +0200
Received: from VOEXC01W.internal.vodafone.com (145.230.101.21) by VOEXH08W.internal.vodafone.com (47.73.211.206) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 13 Jul 2018 09:21:23 +0200
Received: from VOEXC08W.internal.vodafone.com (145.230.101.28) by VOEXC01W.internal.vodafone.com (145.230.101.21) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 13 Jul 2018 09:21:23 +0200
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.229]) by voexc08w.internal.vodafone.com ([145.230.101.28]) with mapi id 14.03.0361.001; Fri, 13 Jul 2018 09:21:22 +0200
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: "Dale R. Worley" <worley@ariadne.com>, "draft-ietf-insipid-logme-marking.all@ietf.org" <draft-ietf-insipid-logme-marking.all@ietf.org>, "insipid@ietf.org" <insipid@ietf.org>
Thread-Topic: last call for draft-ietf-insipid-logme-marking-11
Thread-Index: AQHUGlD7/8l5nMSiw0+cCFpNd//8aqSMufmw
Date: Fri, 13 Jul 2018 07:21:21 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E321EE9B@VOEXM31W.internal.vodafone.com>
References: <87k1pzuaz6.fsf@hobgoblin.ariadne.com>
In-Reply-To: <87k1pzuaz6.fsf@hobgoblin.ariadne.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/Y24GrJ_XN-OJEiklKa_PGF2qnBU>
Subject: Re: [Insipid] last call for draft-ietf-insipid-logme-marking-11
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2018 07:21:41 -0000

Hi Dale,
Thanks for checking draft -11 and for your comments. Regarding related dialogs, the draft has section 3.7 (opening paragraph copied below). Section 3.7 also includes a signalling example with REFER and points out how UUIDs can be used to link sessions together ("dialog3 is not logged by Alice's terminal, however the test case identifier ab30317f1a784dc48ff824d0d3715d86 is also the test case identifier local-uuid) in INVITE F5.  Also, the test case identifier of dialog2, which is logged by Alice's terminal, can be linked to dialog1 and dialog3 because the remote-uuid component of dialog2 is the test case identifier ab30317f1a784dc48ff824d0d3715d86"). 

Session-ID must be supported for logme, so implementers will need to understand RFC 7989 and its concept of related sessions. 

Regards,
Peter

3.7.  Marking Related Dialogs


   "Log me" marking is done per-dialog and typically begins at dialog
   creation and ends when the dialog ends.  However, dialogs related to
   a "log me" marked dialog MAY also be "log me" marked.  An example is
   call transfer described in section 6.1 of [RFC5589] and the logged
   signaling for related dialogs can be correlated using Session-ID
   values as described in section 10.9 of [RFC7989].

> -----Original Message-----
> From: Dale R. Worley <worley@ariadne.com>;
> Sent: 13 July 2018 04:27
> To: draft-ietf-insipid-logme-marking.all@ietf.org; insipid@ietf.org
> Subject: last call for draft-ietf-insipid-logme-marking-11
> 
> I happened to see the Gen-Art last call review of draft-ietf-insipid-logme-
> marking-11.  It looks like a useful tool if we can get people to use it.  But it
> seems to me that the draft could use some work in the following way:
> 
> The draft seems to be deeply oriented toward making logging working well in
> situations that span multiple networks, and in particular, where the UAs may
> not actually support "logme", but rather intermediaries provide logme
> support on behalf of the UAs.  This requires a lot of discussion of course.
> 
> But the draft doesn't pay enough attention to the numerous situations where
> one dialog is replaced by, or otherwise related to, another.  A lot of services,
> when implemented in SIP, result in generating new dialogs, often replacing
> old ones.  For example, suppose a dialog is operating with "logme", and an
> INVITE-with-Replaces arrives at one of the UAs, *without* "logme".  What
> should happen?  Naively, you would think that the new dialog should be
> logged, but there's no way for the UAS of INVITE-with-Replaces to initiate
> "logme" in that dialog.
> 
> Seemingly related to this lack of attention is:
> 
>    3.3.  Identifying Test Cases
> 
>    The local Universally Unique Identifier (UUID) portion of Session-ID
>    [RFC7989] in the initial SIP request of a dialog is used as a random
>    test case identifier.  This provides the ability to collate all
>    logged SIP requests and responses to the initial SIP request in a
>    dialog or standalone transaction.
> 
> This overlooks that requests generated by one UA have one local UUID in
> Session-ID, while requests generated by the other UA have a different local
> UUID.  And the various dialogs in a call transfer will have various
> combinations of UUIDs; there will be no single UUID that all of the requests
> involved will share.  This isn't insurmountable -- all practical SIP debugging
> tools have ways of accumulating the identifiers of a related set of dialogs --
> but the fact that the draft doesn't recognize that complexity suggests that the
> consequences of that for "logme" haven't been thought through.
> 
> Dale