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

Alberto Llamas <> Thu, 06 October 2016 12:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA1B1129637 for <>; Thu, 6 Oct 2016 05:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FzsyH0fJYJW4 for <>; Thu, 6 Oct 2016 05:46:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 41F1A127A90 for <>; Thu, 6 Oct 2016 05:46:17 -0700 (PDT)
Received: by with SMTP id g192so12070605ywh.1 for <>; Thu, 06 Oct 2016 05:46:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tp7Ve4UXI311iyMHirQgHptPSqrOzEd3zwMUKGlROdM=; b=BT6+PWvh+nOdl2uYJQ1la0PG1F7rLCqiotE0HFqQO8nN+DMO+6tWD5q2TZyRoqKqKp rEHAwQZA54vi2uGubZbEFuTQEshARPDb4fj+uu5PPqb+WzEdyJZhuD9mS12jnI/qynp+ //irkIbSn0Ywq19iqDdvqrO5W50hICzUzkIG5OmbyT0aGGuD1HMAx9MTQKTqjwdhDb// yH5iToNAtirSYRhpbSRzxSEPkqBKpZ/zDBzejhYgDEYKXeDufuv4cy5byZJ439cwrSwb jYTbxbn7+VmkruFjnoPjKS8ZRcFHN2tkPOzxNDo8Gs9OdoYhV9xw/cLZboSp47A+GavL ymRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tp7Ve4UXI311iyMHirQgHptPSqrOzEd3zwMUKGlROdM=; b=DvSh8sfs8/QHgcKa+Y1eJw9drjHB73ktxYgvlN2Wgq5a+K/Nh7Z51yCbolCmg8/lEw IqkBQo1GRL3gVPZHBgYuje7QAbPAXeySWsp/yGqPEvb9VQpyquQAUlbbVlA8X4JnczcS PJzA/vVtsvKhx/lrYZpLTRSzz9EeocXIwIy/emPbhKIBBPEyvX+ASo2nwRx8iWSu5UbW sbPu3TIyx0m6qTqVhea+WL7lsiiXJMzmPuHouZJ94+Ns/kVgpp8O43ee/D530PWvMzIP uKxs8aLE/eSPN/DDtLa9k2Io1oqWk938zZR7Sgyk7X9OQNZXy9OyqLMC3//nUyd0BlrJ Rk9g==
X-Gm-Message-State: AA6/9RnvWmyWanwf1e+FJ3coPTz7/rUNwfXwh97aC8GMVjpU4x0SmWqO7bSRBJxc4LiF8Sb77i/U0KCqrAgKcg==
X-Received: by with SMTP id t71mr10947426ywc.51.1475757976437; Thu, 06 Oct 2016 05:46:16 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 6 Oct 2016 05:46:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Alberto Llamas <>
Date: Thu, 6 Oct 2016 14:46:15 +0200
Message-ID: <>
To: "Dawes, Peter, Vodafone Group" <>
Content-Type: multipart/alternative; boundary=94eb2c0b9808f5c9e3053e31adf9
Archived-At: <>
Cc: "" <>, "Arun Arunachalam \(carunach\)" <>, "" <>, "Gonzalo Salgueiro \(gsalguei\)" <>, "" <>, "" <>, "Paul Giralt \(pgiralt\)" <>
Subject: Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Oct 2016 12:46:22 -0000

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.


On Mon, Oct 3, 2016 at 4:09 PM, Dawes, Peter, Vodafone Group <> wrote:

> Hello All,
> Thanks to everyone who reviewed and commented on the logme requirements
> draft, we have uploaded revision -08 (
> 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) []
> Sent: 29 September 2016 19:15
> To: Arun Arunachalam (carunach)
> Cc: Gonzalo Salgueiro (gsalguei);;;
> 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) <
>> 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) <>
> wrote:
> Hi Arun,
> Sorry for not replying earlier. Inline…
> On Sep 22, 2016, at 10:13 AM, Arun Arunachalam (carunach) <
>> wrote:
> Hi Paul,
> Please see inline.
> On Sep 14, 2016, at 7:30 PM, Paul Giralt (pgiralt) <>
> wrote:
> Thanks Arun. See below…
> On Sep 14, 2016, at 6:36 PM, Arun Arunachalam (carunach) <
>> 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)