Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs

Alberto Llamas <albertollamaso@gmail.com> Tue, 11 October 2016 08:00 UTC

Return-Path: <albertollamaso@gmail.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 03B491297DF for <insipid@ietfa.amsl.com>; Tue, 11 Oct 2016 01:00:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 E1NrAphUpfW6 for <insipid@ietfa.amsl.com>; Tue, 11 Oct 2016 01:00:41 -0700 (PDT)
Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AFC1294A3 for <insipid@ietf.org>; Tue, 11 Oct 2016 01:00:38 -0700 (PDT)
Received: by mail-yb0-x22e.google.com with SMTP id 184so4424223yby.2 for <insipid@ietf.org>; Tue, 11 Oct 2016 01:00:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ksSbhKJ7RVOQ7Wt0d/TFAupLqpb66KXFlgOeijDE8rc=; b=0sBPiZc0BcFjnjNl2a5ubLXJ9dks6lEli6G2cWfvqcHpfI6a5Y3uD/BzbEJ4jPyH/p 0K7NUIqE9oFicB0fAMW6hzt+yzE3c/mPDhz/lR9URGUrOTXTTLPKMh9Xihmb/og/x7pC lXyU/3u7g26Z4ZPeryXMdtRxMQ+6JzBzjXHMHaYcrGyh8r+1g4SfxzTGJncXQce1Ksfz j1LK/6FRVPKDybKnmZzPVXN/YkTNIcd+lIRIDz4N46Fsp/Q+uY8xNQKc8udefFy8bQRN DR/Ch5AmM0g4wg4Jh9RfyQ02iWT3U65Yj5JFuM23BprwEO470fZ2PrPVvMbrWy7k2bEK Je8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ksSbhKJ7RVOQ7Wt0d/TFAupLqpb66KXFlgOeijDE8rc=; b=Q04hKsp4pSjPoLCbMhJ0bvpXSVWAL4mDixzzWBF1iU0bZBCqgvNEG4VcYJTcQqOPZN s8JeinZSjjWWGkSPWOiua6Q+jjeomaFfrvqwcIihfo8XVBeKLL1Fy2VeZVG2GNClrPh8 hiWUlohpJ4Z19o3ETnxKjYRi0UIyfhsrsuJUJNP7x1UaiBlBbNjf2QKIIN5BnSLH7JcD eYi4/HJBGNZ4oAFkGsM4gO1JV5lD6dVi7eZY2NMbOgPJCr5oKzfQZbgqj9BFXzuJ+RL5 /zYsOsPTvUcL4EblfnDtxc//uQr8Z2BkGPijVnSVGEwzyp9F9jrHJvGTA91EWofqGukc K1FA==
X-Gm-Message-State: AA6/9RlxX3afOXRlGv7vXHXxxMLLcICSZWJbGheqrCt/s0xsA0eKBb10/+MBf5w9BXTtsw2YokrcMq4RJRMTiA==
X-Received: by 10.37.5.4 with SMTP id 4mr2003344ybf.162.1476172838084; Tue, 11 Oct 2016 01:00:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.172.150 with HTTP; Tue, 11 Oct 2016 01:00:37 -0700 (PDT)
In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8B8E102@VOEXM31W.internal.vodafone.com>
References: <4C52DDE4-07CF-4F5F-8DB7-8CEB51119A6A@cisco.com> <7FA11A21-D8BC-4829-B6D5-EE2B44200D8E@cisco.com> <984E4584-C850-4198-8F78-1839A027C36A@cisco.com> <79D6B8EF-4C53-40B1-A7B9-C8C8479E153B@cisco.com> <38281C26-6FDD-4755-AFBB-F6AC93D2EC48@cisco.com> <F5241F4A-B1FE-41D9-BD20-6C31B67B80A5@cisco.com> <6EE9E419-BCE8-4E5A-B0F1-2E0AE53C8BF0@cisco.com> <C0EB6615-9318-453E-B784-ECACAAC4856C@cisco.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8B72473@VOEXM31W.internal.vodafone.com> <CAHH1jkMVARqfAOaABHhtOgzCE0k26reWP4f-XgaenaxbheLMCw@mail.gmail.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8B8E102@VOEXM31W.internal.vodafone.com>
From: Alberto Llamas <albertollamaso@gmail.com>
Date: Tue, 11 Oct 2016 10:00:37 +0200
Message-ID: <CAHH1jkP1=jcaooqv+E8taxRZz66j5C7scUrZE4bwcoUs8BNenw@mail.gmail.com>
To: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
Content-Type: multipart/alternative; boundary=001a11c03196a4268d053e9245b2
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/xIvNiBVXHgt3EXeNmMdsozU1484>
Cc: "ben@nostrum.com" <ben@nostrum.com>, "Arun Arunachalam \(carunach\)" <carunach@cisco.com>, "brett@broadsoft.com" <brett@broadsoft.com>, "Gonzalo Salgueiro \(gsalguei\)" <gsalguei@cisco.com>, "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>, "insipid@ietf.org" <insipid@ietf.org>, "Paul Giralt \(pgiralt\)" <pgiralt@cisco.com>
Subject: Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 11 Oct 2016 08:00:46 -0000

Completely agree.

Albert

On Fri, Oct 7, 2016 at 3:56 PM, Dawes, Peter, Vodafone Group <
Peter.Dawes@vodafone.com> wrote:

> Hello Alberto,
>
> Thanks for checking the latest draft. For 4.3, 5.1, I agree with your
> point and we can change the text from “logging on to the SIP entity that
> contains the logs” to “logging on to the SIP entity or entities that
> contain the logs”.
>
>
>
> For stop events, as you suggest, a dialog end is required to be the end of
> logging (REQ11):
>
>
>
> REQ11: "log me" marking of requests and responses MUST be applied
>
>       on a per-dialog granularity.  If applied, "log me" marking MUST
>
>       begin with the dialog-creating request and SHOULD continue to the
>
>       dialog end. "log me" marking SHOULD be applied to in-dialog
>
>       requests and responses in either direction. "log me" marking MUST
>
>       NOT be stopped and re-started on a given dialog.
>
>
>
> ‘stop events’ other than dialog end could be almost anything. Perhaps
> logging stops after 5 minutes, or when video media is removed from a
> session, or as soon as a call is answered. I think all of these things
> could be configured without new functionality so the requirements draft can
> give a hint at such possibilities but should not try to formalize them.
>
>
>
> Regards,
>
> Peter
>
>
>
>
>
> *From:* Alberto Llamas [mailto:albertollamaso@gmail.com]
> *Sent:* 06 October 2016 13:46
> *To:* Dawes, Peter, Vodafone Group
> *Cc:* insipid@ietf.org; Gonzalo Salgueiro (gsalguei); ben@nostrum.com;
> pkyzivat@alum.mit.edu; brett@broadsoft.com; Arun Arunachalam (carunach);
> Paul Giralt (pgiralt)
>
> *Subject:* Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
>
>
>
> Hi Peter, it looks very good. I just have couple of comments you would
> take in consideration:
>
>    - *In points 4.3 and 5.1 the sentence:*
>
>
>
> logging on to the SIP entity that contains the logs
>
> Maybe could be change for something like:
>
> logging on to any or all SIP entity that contains the logs
>
>
>    - *In points 4.3 and 5.3:*
>
> You are referring to the 'stop event' that cause logging to stop. In this
> draft and also in '*draft-ietf-insipid-logme-marking-05*' I don't find
> any explanation about what a stop event is and/or how to detect it. There
> is a short example that a stop event could be *"**typically expiry of a
> certain amount of time*". From my point of view stop events should be
> defined somewhere or at least define a single stop event as an end of the
> dialog.
>
>
>
> Regards,
>
>
>
>
>
> On Mon, Oct 3, 2016 at 4:09 PM, Dawes, Peter, Vodafone Group <
> Peter.Dawes@vodafone.com> wrote:
>
> Hello All,
> Thanks to everyone who reviewed and commented on the logme requirements
> draft, we have uploaded revision -08 (https://www.ietf.org/id/
> draft-ietf-insipid-logme-reqs-08.txt) with the changes summarized below
> that aim to resolve the issues raised. Some of the changes are taken from
> e-mail exchanges here on the insipid list but some of the text (and
> structure) is new so it would be good to hear whether the revised draft is
> now OK.
>
> (a)  Expanded REQ8 (was REQ5 in revision -07) to explicitly mention
> gateways and B2BUAs. (commented by Alberto Llamas and Paul Giralt)
> (b)  Example debugging procedure given its own subclause and simplified to
> make it clear that it is only an example and does not contain any
> requirements. (commented by Paul Kyzivat)
> (c)  Requirements split into 3 groups depending on whether they apply to
> SIP entities, the logging procedure, or the logme marker itself. (commented
> by Paul Kyzivat)
> (d)  New subclause added that defines a network boundary. (commented by
> Paul Kyzivat)
> (e)  New subclause added that defines a trust domain as it applies to
> logme (commented by Paul Kyzivat)
> (f)  All requirements in the descriptive clause moved to the requirements
> clause (commented by Paul Kyzivat)
> (g)  Changed "proxy" to "intermediary" in requirements related to whether
> SIP entities are stateful or stateless in terms of their logging behaviour.
> (commented by Paul Kyzivat and Paul Giralt)
> (h)  Reworded requirement on form of logged message to say that messages
> should be logged in the form that they appear in the signaling. (commented
> by Brett Tate)
> (i)   References to draft-insipid-session-id updated to the latest
> version. (commented by Brett Tate)
> (j)  Added the sentence: ""log me" marking SHOULD be applied to in-dialog
> requests and responses in either direction. " to the requirement about
> per-dialog granularity. (commented by Paul Giralt)
> (k)  Changed wording in introduction to use a more general description
> than "service providers" to include enterprises and other operators of SIP
> networks. (commented by Paul Giralt)
> (l)  Wording changed to "Header fields SHOULD be logged in the form in
> which they appear in the message, they SHOULD NOT be converted between long
> and compact forms..." (commented by Paul Giralt)
> (m)  Added the sentence ""log me" marking SHOULD be applied to in-dialog
> requests and responses in either direction." (commented by Paul Giralt)
> (n)  Section 6.2.1 revised to capitalize normative words (MUST etc.). Also
> text related to sending logged information to a server removed. (commented
> by Paul Giralt)
> (o)  Changed text in "Trust Domain" subclause of the "Security" clause to
> say SHOULD NOT rather than "might not": "If a prior agreement to log
> sessions exists with the next hop network then the "log me" marker SHOULD
> NOT be removed". (authors change)
> (p)  Revised the 6.2.2 "Sending Logged Information" to "Logged
> Information" and changed the description to state that unauthorized parties
> should not have access to the logged information. (Related to comment by
> Paul Giralt on solutions draft)
> (q)  Changed the format of cross references so that the reference name is
> not repeated. (Related to comment by Paul Giralt on solutions draft)
> (r)  REQ5 (was REQ8 in revision -07) updated to have test identifier as a
> random value instead of human readable name due to Session-ID privacy
> requirements defined in REQ 4 of RFC7206. (commented by Paul Giralt)
> (s)  REQ9 (was REQ6 in revision -07) updated with an additional use case
> in which intermediaries continue to mark logme for related sessions.
> (commented by Paul Giralt)
> (t)  Acknowledgments updated to include reviewers who provided comments
> during last call.
>
>
> Thanks and regards,
> Peter (on behalf of the co-authors)
>
>
>
> From: Paul Giralt (pgiralt) [mailto:pgiralt@cisco.com]
> Sent: 29 September 2016 19:15
> To: Arun Arunachalam (carunach)
> Cc: Gonzalo Salgueiro (gsalguei); insipid@ietf.org; ben@nostrum.com;
> Dawes, Peter, Vodafone Group
> Subject: Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
>
> Looks good to me.
>
> -Paul
>
> On Sep 29, 2016, at 2:13 PM, Arun Arunachalam (carunach) <
> carunach@cisco.com> wrote:
>
> Thanks Paul !
>
> (1) Agree, let’s have a random test id given REQ 4 of RFC 7206.
>
> (2) We can update REQ 6 as shown below to incorporate your comment:
>
>  REQ6: A SIP intermediary MAY insert a "log me" marker into requests and
>       responses.  The typical case for which a intermediary needs to
> insert a
>       "log me" marker is for compatibility with UAs that have not
>       implemented "logme" marking, i.e. when a UA has not marked a
>       request or when responses received on a dialog of interest for
>       logging do not contain an echoed "log me" marker.  Another use
>       case is when the session origination UA that inserted log me marker
>       is no longer participating in the session (e.g: call transfer
> scenarios)
>       and the intermediary adds "log me" marker in related sessions to
> enable
>       end-to-end signaling analysis. In these cases, the entity that
> inserts a
>       "log me" marker is stateful inasmuch as it must remember when a
> dialog is
>       of interest for logging.  An entity that inserts a "log me" marker
>       SHOULD also log the SIP request or response as per REQ4.
>
>
> Arun
>
>
>
>
> On Sep 29, 2016, at 11:57 AM, Paul Giralt (pgiralt) <pgiralt@cisco.com>
> wrote:
>
> Hi Arun,
>
> Sorry for not replying earlier. Inline…
>
>
> On Sep 22, 2016, at 10:13 AM, Arun Arunachalam (carunach) <
> carunach@cisco.com> wrote:
>
> Hi Paul,
>
> Please see inline.
>
> On Sep 14, 2016, at 7:30 PM, Paul Giralt (pgiralt) <pgiralt@cisco.com>
> wrote:
>
> Thanks Arun. See below…
>
> On Sep 14, 2016, at 6:36 PM, Arun Arunachalam (carunach) <
> carunach@cisco.com> wrote:
>
> REQ8: Should update to latest session-id draft. Also, I have some concerns
> about using Session-ID as the test case identifier. The Session-ID can
> change (in fact will change for every session because the initial INVITE
> will have a null remote UUID).
>
> How about using the local UUID of the Session-ID generated by the
> originating UA / proxy as a test identifier (if the admin wants the system
> to auto-generate a test ID)?
>
>
> I think using just the local UUID makes more sense because this will be
> consistent throughout the life of the session as long as the originating
> endpoint is still in the call. It’s possible that some B2BUA could remove
> the originator from the session (e.g. call gets transferred) but at that
> point, the device that requested the session be logged is no longer in an
> active session anyway.
>
> That said, what if the admin doesn’t want the system to auto-generate a
> test ID? Where would that go? The local UUID must be in a very specific
> format to comply with drafy-ietf-insipid-session-id, so you can’t put any
> arbitrary text in for the local UUID. I think either you need to stipulate
> that the test ID will always be automatically generated or find some other
> place to put it.
>
> I think there is value in giving the admin the ability to specify their
> own identifier.
>
> One option would be to have a user defined test identifier as shown below:
>
>    test-identifier = (alphanum / "_") *(alphanum "_")
>
> If the user defined test identifier is not present, the log analysis
> server would use the local UUID of the originator’s Session-ID as the test
> identifier.
>
>
>
> I like this in concept. The concern I have is whether it meets the privacy
> requirements stipulated for additional parameters in the Session-ID header.
> If someone puts a value of the person’s name or perhaps a ticket number,
> that could be considered personally identifiable information which is not
> allowed to be present in the Session-ID header. I’m not sure how we’d
> reconcile these requirements. We may have to just live with the test ID
> being something random.
>
>
>
>
> Also, should intermediaries be required to or at least allowed to continue
> indicating log me markings on other messages related to the session even if
> the originating device is no longer participating in the session?
>
> This will be useful to perform an end-to-end call flow analysis.
>
> The good thing about originator based log me marking is the “ability /
> control” to disable logging simply by disconnecting the call at the
> originator (the device requesting to enable logging).
>
> This control no longer exists if we allow the intermediaries to continue
> marking even after the originator is no longer in the session.
>
> I guess this could be left up to the implementation of the intermediary.
> It is free to add a logme marker to whatever it wants to, so even if the
> originator drops off, there is no reason why it can’t add the identifier to
> related sessions. This is probably something worth mentioning in the draft,
> but might not be necessary in the requirements doc.
>
> -Paul
>
>
>
>
>
>
> --
>
> Alberto Llamas
>
> Phone: +1-786-805-6003
>
> Telecommunications Engineer
>
> Digium Certified Asterisk Professional (dCap)
>
>
>



-- 
Alberto Llamas
Phone: +1-786-805-6003
Telecommunications Engineer
Digium Certified Asterisk Professional (dCap)