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

Paul Kyzivat <> Wed, 14 June 2017 21:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2F53129549 for <>; Wed, 14 Jun 2017 14:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 DZeK3ZBzadDX for <>; Wed, 14 Jun 2017 14:17:13 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56D5412940C for <>; Wed, 14 Jun 2017 14:17:13 -0700 (PDT)
Received: from ([]) by with SMTP id LFdSdVtiHzz3dLFf6d8okV; Wed, 14 Jun 2017 21:17:12 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20161114; t=1497475032; bh=j0p4+vTVPntMa1FWrWyxLTH7JNtYO8fkY5Sa2L0p1FE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=TN6PB2CVlMhCtAMV4VI4tiV2DcIrIkSdTXy9wlUtjGyIldIjrCHMBCtOW7PNXUce0 KPdhzNKkPO242+vL8IrqB1NWqFXCA3EQSKOz+frbx8t1KGEqzOYI13QB6Hy8TIhCSO 5OGvnwNtWlglOmJl1xK6uRtGO8GV/5hkNX0F+VjDY2AAKXgsffUR1bXo4z9ND2Xioa joUvz8KkO7jrKRlzqqyl6rAiVP5SDKUnj10M7HC01slev6i6oAPLBlSTDqwf9gHHeP /kjO15ArLTqByWbjKFhyUE+Y8Dt0P1Hf69pwlghV8yLne6lfC1Tx/GG9ZxRXBZ2pfI w2qP8mxCnsluQ==
Received: from [] ([]) by with SMTP id LFf5dNN3QtZO6LFf5dfaNw; Wed, 14 Jun 2017 21:17:12 +0000
References: <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Wed, 14 Jun 2017 17:17:11 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfL/LQWnE05TxmDef9jLD1Opf21u9Gk2SMVkByGtR/NXwniC9FOpDm+s72/w7s3XajWq7Hov3aaxzfIwr8PG8pdl0f9jOCXnlPn869wOGlKMxUjuTb+M9 /ou1d2qgGCNyV2NKw3/bJpWZLK4H3nrdrs9EKEOYMSUPh6CsnSYVVuQkeaq52/ZAYBuKIAz7M2HI4w==
Archived-At: <>
Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Jun 2017 21:17:15 -0000

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.
> - 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.