[Insipid] Fwd: Re: draft-ietf-insipid-logme-marking-08

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 28 November 2017 19:43 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F3381128DE7 for <insipid@ietfa.amsl.com>; Tue, 28 Nov 2017 11:43:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2g5V3XnEsuVI for <insipid@ietfa.amsl.com>; Tue, 28 Nov 2017 11:43:32 -0800 (PST)
Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu []) by ietfa.amsl.com (Postfix) with ESMTP id AEF7A128B88 for <insipid@ietf.org>; Tue, 28 Nov 2017 11:43:31 -0800 (PST)
X-AuditID: 1207440f-a43ff70000007960-91-5a1dbc604dd4
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 48.79.31072.16CBD1A5; Tue, 28 Nov 2017 14:43:29 -0500 (EST)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net []) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vASJhRJn007561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <insipid@ietf.org>; Tue, 28 Nov 2017 14:43:28 -0500
References: <5a4ebaa5-4683-ca80-f13b-ecb15e213ccb@alum.mit.edu>
To: "insipid@ietf.org" <insipid@ietf.org>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Forwarded-Message-Id: <5a4ebaa5-4683-ca80-f13b-ecb15e213ccb@alum.mit.edu>
Message-ID: <be7d330a-8352-df27-7bef-73fa45f3040b@alum.mit.edu>
Date: Tue, 28 Nov 2017 14:43:27 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <5a4ebaa5-4683-ca80-f13b-ecb15e213ccb@alum.mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYndR1E3aIxtlsHGikMX8+8+YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8W/7M/aCF0oVi1u2szYwbpXuYuTkkBAwkdh1eBdLFyMXh5DA DiaJNzvvs0I4P5gkvm48xwhSJSxgKjH9+HsWEFtIwF7iROMVVhBbREBT4uONc8wgNpuAlsSc Q/9ZIKZ6SyzZvpwdxOYFql/14xlYnEVAVaLnzy82EFtUIE1iz4UOFogaQYmTM5+A2ZwCDhIt Ny+D9TIL2ErcmbubGcIWl7j1ZD4ThC0vsf3tHOYJjAKzkLTPQtIyC0nLLCQtCxhZVjHKJeaU 5urmJmbmFKcm6xYnJ+blpRbpmujlZpbopaaUbmKEhCv/Dsau9TKHGAU4GJV4eC+skI0SYk0s K67MPcQoycGkJMr7aSFQiC8pP6UyI7E4I76oNCe1+BCjBAezkghv5SSgHG9KYmVValE+TEqa g0VJnFd9ibqfkEB6YklqdmpqQWoRTFaGg0NJgjduN1CjYFFqempFWmZOCUKaiYMTZDgP0PDt IDW8xQWJucWZ6RD5U4zGHD09N/4wcTyb+bqBWYglLz8vVUqc1xmkVACkNKM0D24aLOW8YhQH ek6YdxFIFQ8wXcHNewW0iglo1c390iCrShIRUlINjBN0/sc8VuS2fiLO8u6KndsJbn3pP3E2 kgrPqjbmTy55UyDzyDpbX1qzKdxgSutm4dlhG5lV63orD5uxRZ76vW76bRG21afsbd3tMvZs Mgt6E2mwgLfScHdw/07lv/eFLj3M3vmQ/fau/iVXS/7d0hJK8qlmUyv8989T8tmGrfd+2ZV3 zdU3V2Ipzkg01GIuKk4EAN5TYfAUAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/b5dqCNBeHnTQ94D32GskmgX1Z3U>
Subject: [Insipid] Fwd: Re: draft-ietf-insipid-logme-marking-08
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: Tue, 28 Nov 2017 19:43:34 -0000

I had sent these comments to the authors. Peter asked me to forward them 
to the list. Here they are.


-------- Forwarded Message --------
Subject: Re: draft-ietf-insipid-logme-marking-08
Date: Thu, 26 Oct 2017 17:32:41 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: Dawes, Peter, Vodafone Group <Peter.Dawes@vodafone.com>
CC: Arun Arunachalam (carunach) (carunach@cisco.com) <carunach@cisco.com>


On 10/26/17 5:38 AM, Dawes, Peter, Vodafone Group wrote:
> Hello Paul,
> Just a kind reminder to ask if you are able to review the latest 
> logme-marking draft and post to the insipid list? We authors would very 
> much like to conclude logme J

Oh, sorry. I see -08 has addressed a number of my comments on -07.

Reviewing the recent changes:

In section 3.7:

    In the example shown in Figure 2 below, Alice has reported problems
    making call transfers and her terminal is configured to log
    signalling for a call transfer.  ...

IIUC it isn't really feasible to configure to log just call transfers. 
The logging has to commence at the start of a dialog, before it is known 
whether there  will be a transfer. The signaling is consistent with 
this, but the description above ought to reflect reality.

Also in 3.7:

Some of the message contents aren't right. I didn't check everything, 
but here are a few problems I noted:

- F1 is supposed to be from transferor to transferee, but the From and 
To URIs are backwards from this.

- in F4, IIUC the To URI ought to be the Contact URI from F3, but 
instead has the From-URI from F3.

These all need to be rechecked.

ADAM: can you check the that the REFER stuff is correct according to the 
most recent definitions?

In section 4.2:

The terms "originating SIP intermediary" and "terminating SIP 
intermediary" are used in this section without definition. Since these 
are used in a normative way they ought to be defined. But I have a 
feeling this will not be easy. (I *think* you mean 'first' and 'last' 
here, rather than the IMS notion of simply being on the originating or 
terminating side.) While a device will know if it is acting as an 
intermediary, I don't think it in general has any way to know if it is 
first or last intermediary. Nor do I think it is necessary for it to 
know to make your mechanism work. Rather it simply has to recognize 
whether the request matches its internal state for the dialog. But 
describing it this will will require some rewording.

In section

I have a question on this. IIUC Proxy 2 is logme-aware but by policy is 
removing logme marking coming from outside network B. If that is the 
intent, wouldn't it be better for it to maintain state and insert the 
logme marking on messages headed back to network A?

Or are you assuming the Proxy 2 isn't logme-aware and actively removes 
stuff it doesn't understand? (If so it is really a B2BUA rather than a 

Section 5.1:

I think the text here is not very precise on which cases are error 
cases, and how to distinguish them from cases where a neighbor doesn't 
support logme marking. ISTM the condition described here must be 
evaluated separately for each neighbor. It is an error if the neighbor 
has previously sent logme in the dialog and then stops, regardless of 
what has been happening on the other "side". The examples are pretty 
clear about this, but the text here is not so clear.

Otherwise it looks fine to me and my comments on -07 have been addressed.


> Best regards,
> Peter
> *From:*Dawes, Peter, Vodafone Group
> *Sent:* 19 September 2017 10:18
> *To:* 'pkyzivat@alum.mit.edu' <pkyzivat@alum.mit.edu>
> *Subject:* draft-ietf-insipid-logme-marking-08
> Hello Paul,
> Thanks very much for being one of the people who reviewed the logme 
> solution draft in detail, it took us a while but we co-authors uploaded 
> an update and posted a summary of changes to the insipid exploder 
> https://mailarchive.ietf.org/arch/msg/insipid/6iAK8HspcC7nXNBsQEARYNoC3TA
> It would be very helpful if you could check the changes listed and post 
> any comments to the list (the summary of changes lists the ones that are 
> specific to each review). We are hoping to resolve any remaining 
> comments and then we can request a security review of the draft.
> Best regards,
> Peter