Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Fri, 16 June 2017 14:30 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 3673812EB8B for <insipid@ietfa.amsl.com>; Fri, 16 Jun 2017 07:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level:
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, 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 w5m35qigTeGn for <insipid@ietfa.amsl.com>; Fri, 16 Jun 2017 07:30:20 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) by ietfa.amsl.com (Postfix) with ESMTP id E27ED12E04D for <insipid@ietf.org>; Fri, 16 Jun 2017 07:30:19 -0700 (PDT)
Received: from [85.158.136.83] by server-1.bemta-5.messagelabs.com id 24/FD-01992-A7BE3495; Fri, 16 Jun 2017 14:30:18 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRWlGSWpSXmKPExsWi75nTqVv12jn S4McDJYvGB9PYLebff8Zk8eBHL5vFrekT2R1YPKb83sjqMfnxHEaPJUt+Mnk0fVvEFsASxZqZ l5RfkcCasXzHH8aCTZ4Vr2/8ZGtg3OHRxcjFISSwnVHiy/MbzBDOYUaJKdea2OCcq+v+M0I4m xglZi16ztTFyMHBJmAvMWNPTBcjJ4eIQIpEw65eNhCbWaBYYv+3z4wgtrCAi8SBS5PAykUEXC Xe3qiGKHeT2DH/LwuIzSKgKrH1cR9YK69AqMTauXuYIFY1MklcXXiVHSTBKeAu8WTDebAGRgF ZiS+Nq5khdolL3HoynwnElhAQkFiy5zwzhC0q8fLxP1aQvcwCmhLrd+lDlCtKTOl+yA6xS1Di 5MwnYCOFgG74t3IR0wRGsVlIps5C6J6FpHsWku4FjCyrGDWKU4vKUot0jSz0kooy0zNKchMzc 3QNDUz1clOLixPTU3MSk4r1kvNzNzECY7CegYFxB2PfKr9DjJIcTEqivO+fOEcK8SXlp1RmJB ZnxBeV5qQWH2KU4eBQkuBlfQWUEyxKTU+tSMvMASYDmLQEB4+SCK/NS6A0b3FBYm5xZjpE6hS jLse5yVu/MAmx5OXnpUqJ8/KDzBAAKcoozYMbAUtMlxhlpYR5GRkYGIR4ClKLcjNLUOVfMYpz MCoJ80aBrOLJzCuB2/QK6AgmoCOCLjiAHFGSiJCSamB00tPp0Z7V9+Ss+gLVUM++/T2/dgcKB ns/tOLJ/fiWv2NDsIb09v+vehLMZ3JHuiw+yfhjf9k32wdBL7g/BFu+c1xw81sbn5DJukjpyz NZdysVsbfl/Lt9OOSG4qQQBoaAQ5XiEQLygY+ZxfJd/sfUZe19klckccjZJcFD68oT7QutN1r 22yuxFGckGmoxFxUnAgAEtZ3BRwMAAA==
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-14.tower-36.messagelabs.com!1497623418!109046425!1
X-Originating-IP: [47.73.108.137]
X-StarScan-Received:
X-StarScan-Version: 9.4.19; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29450 invoked from network); 16 Jun 2017 14:30:18 -0000
Received: from vgdpm11vr.vodafone.com (HELO voxe06hw.internal.vodafone.com) (47.73.108.137) by server-14.tower-36.messagelabs.com with SMTP; 16 Jun 2017 14:30:18 -0000
Received: from VOEXH09W.internal.vodafone.com (47.73.211.207) by edge1.vodafone.com (195.232.244.51) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 16 Jun 2017 16:30:12 +0200
Received: from VOEXC01W.internal.vodafone.com (145.230.101.21) by VOEXH09W.internal.vodafone.com (47.73.211.207) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 16 Jun 2017 16:30:12 +0200
Received: from VOEXC16W.internal.vodafone.com (145.230.101.18) by VOEXC01W.internal.vodafone.com (145.230.101.21) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 16 Jun 2017 16:30:11 +0200
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.50]) by voexc16w.internal.vodafone.com ([145.230.101.18]) with mapi id 14.03.0352.000; Fri, 16 Jun 2017 16:30:11 +0200
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: "Vijay K. Gurbani" <vijay.gurbani@nokia-bell-labs.com>, Paul Kyzivat <paul.kyzivat@comcast.net>
CC: "insipid@ietf.org" <insipid@ietf.org>, "Arun Arunachalam (carunach) (carunach@cisco.com)" <carunach@cisco.com>
Thread-Topic: [Insipid] Review of draft-ietf-insipid-logme-marking-07
Thread-Index: AQHS5UMMAPKNYGXfF0SXCMdcYfdsIKIkux6AgAD5WQCAAA3ngIAByRLg
Date: Fri, 16 Jun 2017 14:30:09 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E15B988D@VOEXM31W.internal.vodafone.com>
References: <077dae6c-8d9f-fb26-c18f-749e529b395d@nokia-bell-labs.com> <ca5a378b-8a91-ce98-66fc-53ebf4304715@comcast.net> <4A4F136CBD0E0D44AE1EDE36C4CD9D99E15B75F3@VOEXM31W.internal.vodafone.com> <d4a97070-f7df-e318-2b3c-3c68cee5a989@nokia-bell-labs.com>
In-Reply-To: <d4a97070-f7df-e318-2b3c-3c68cee5a989@nokia-bell-labs.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/yRkCsfhsLMqABHw1Xll_wLuAly0>
Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.22
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, 16 Jun 2017 14:30:24 -0000

Hello Vijay,
Thanks for the suggested text, this seems a good approach. Also thanks for all of your other review comments which I agree need to be resolved in the next revision of the draft. I have one response regarding the following comment on S3.4.1:

>- S3.4.1: I don't see the relationship between the two sentences.
>  Perhaps simpler to say:
>
>     When a user device inserts the "log me" marker, the marker MUST be
>     be passed unchanged in the To and From headers across an edge proxy
>     or a B2BUA adjacent to the user device. 
>

The current S3.4.1 mixes two ideas, firstly that only authorized and authenticated user agents are allowed to mark signalling ("Edge proxy or B2BUA checks whether the user device is allowed to make/receive e.g. calls, based on authentication and on authorization.") and secondly that marking must be passed unchanged. As you say, the current draft is confusing so in the next revision we will try to better explain these two aspects.

Regards,
Peter

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vijay.gurbani@nokia-bell-labs.com]
> Sent: 15 June 2017 13:59
> To: Dawes, Peter, Vodafone Group <Peter.Dawes@vodafone.com>om>; Paul
> Kyzivat <paul.kyzivat@comcast.net>
> Cc: insipid@ietf.org; Arun Arunachalam (carunach) (carunach@cisco.com)
> <carunach@cisco.com>
> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07
> 
> Paul, Peter: Thank you for the feedback.
> 
> Peter, since Paul's recollection is on the spot, it appears to be reasonable to
> use his text as a starting point.  S3.2 can be clarified by replacing the existing
> paragraph to something like the following (please feel free to discard, edit, or
> adopt):
> 
>   A user agent or proxy adds a "log me" marker in a request or response
>   for two reasons: either it is configured to do so or it has detected
>   that a dialog is being "log me" marked, causing it to maintain state
>   to ensure that all requests and responses in the dialog are "log me"
>   marked.
> 
>   When a user agent or proxy is configured to add a "log me" marker in
>   messages, the duration that the user agent or proxy will be so
>   configured is out of the scope of this document.  For instance, the
>   user agent client or proxy could be configured to add a "log me"
>   marker for a certain number of requests, or it could be configured to
>   mark messages with a temporal scope (i.e., 9:00am - 10:00am every
>   day), or it could be configured to mark messages when it encounters a
>   specific "User-Agent" header.
> 
>   On the other hand, when a user agent or proxy detects that a dialog-
>   initiating request is being "log me" marked, the scope of such marking
>   extends to the lifetime of the dialog.  In addition, as discussed in
>   Section 3.7, "log me" marked dialogues that create related dialogues
>   (REFER) may transfer the marking to the related dialogues.  In such
>   cases, the entire "session", identified by the Session-ID header, is
>   "log me" marked.
> 
> Thanks,
> 
> On 06/15/2017 05:30 AM, Dawes, Peter, Vodafone Group wrote:
> > Hello Vijay, Paul,
> > Paul's summary is correct and the review comment from Vijay indicates
> that section 3.2 needs to be clearer on configuration vs. per-dialog scope of
> "log me" marking.
> >
> > An example of configuration is that a service provider might have a test
> terminal programmed to run through a set of SIP sessions (call, call re-
> directed at set up, call transfer) and this terminal would be configured to "log
> me" mark all of them. An example of per-dialog scope is a SIP terminating
> user agent, which needs to be aware that a dialog is being "log me" marked
> (i.e. it needs to be stateful) in order to mark any in-dialog requests that it
> sends (e.g. BYE). Such a terminating UA knows that when the dialog ends it
> can close its signalling log for that dialog and stop marking requests that it
> sends. Such a user agent does not use configuration to perform "log me"
> marking.
> >
> > We will clarify S3.2 in the next revision.
> >
> > Regards,
> > Peter
> >
> >> -----Original Message-----
> >> From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul
> >> Kyzivat
> >> Sent: 14 June 2017 22:17
> >> To: insipid@ietf.org
> >> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07
> >>
> >> On 6/14/17 3:18 PM, Vijay K. Gurbani wrote:
> >>> Hello,
> >>>
> >>> I was asked by the authors to review
> >>> draft-ietf-insipid-logme-marking-07.  My review is below.
> >>>
> >>> Summary: good stuff, but some issues need to be addressed as
> >>> documented next.
> >>>
> >>> MAJOR:
> >>>
> >>> - S3.2: So, it appears from the last sentence that "log me" is scoped by
> >>>    the dialogue.  If through some configuration, a SIP UA is configured
> >>>    to insert the "logme" parameter, then the UA will continue inserting
> >>>    the parameter for all dialogues created by the UA until configured to
> >>>    stop inserting the parameter, right?
> >>>
> >>>    If so, then the scope of the "logme" parameter is driven by
> >>>    configuration more than a dialogue.  This should be made clear in the
> >>>    text, as there are many places that state that "logme" is scoped to a
> >>>    dialogue (S6.4.5, for instance).
> >>>
> >>>    I believe this is an important aspect to clarify: Is the "logme"
> >>>    scoped by a dialogue or through configuration, as time limited as that
> >>>    configuration may be?  My reading of the draft suggests that the
> >>>    scoping is through configuration, and S6.4.5 appears to support this
> >>>   (in my reading, at least).
> >>
> >> I'm not an author, so this can be a test of how clear they have been.
> >>
> >> IIUC, a given logme "session" is dialog scoped. (Though not exactly,
> >> since in the presence of B2BUAs it becomes a set of related dialogs.)
> >> This is identified by the SessionID. Those entities that did not
> >> initiate the logging need to keep state for that duration. And of course this
> then is tied to the resulting logs.
> >>
> >> Some entities may also have some other state that causes them to
> >> initiate logging "sessions". The duration of that state is undefined.
> >>
> >> Now the authors can say if I got it right.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >> _______________________________________________
> >> insipid mailing list
> >> insipid@ietf.org
> >> https://www.ietf.org/mailman/listinfo/insipid
> >
> > _______________________________________________
> > insipid mailing list
> > insipid@ietf.org
> > https://www.ietf.org/mailman/listinfo/insipid
> >
> 
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Nokia Networks
> Email: vijay.gurbani@nokia-bell-labs.com / vkg@bell-labs.com
> Web: https://www.bell-labs.com/usr/vijay.gurbani
> Calendar: http://goo.gl/x3Ogq