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

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Wed, 07 September 2016 14:40 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 18A1512B1BE for <insipid@ietfa.amsl.com>; Wed, 7 Sep 2016 07:40:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 lsziOYZIOLWT for <insipid@ietfa.amsl.com>; Wed, 7 Sep 2016 07:40:03 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C7C12B1BA for <insipid@ietf.org>; Wed, 7 Sep 2016 07:40:02 -0700 (PDT)
Received: from [195.245.230.51] by server-12.bemta-3.messagelabs.com id 5F/07-09160-1C620D75; Wed, 07 Sep 2016 14:40:01 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRWlGSWpSXmKPExsVy+MWXNt2Dahf CDaZ1MVk0PpjGbjH//jMmixUbDrA6MHv8ff+ByWPK742sHkuW/GQKYI5izcxLyq9IYM1Y0f+D seCEXMX2BadZGhgXSnYxcnIICexhlFi437yLkQvIXskoMe9oLyuEs5xJYu3cRSwQzmFGiatv3 7NDOJsYJdbMOAWU4eBgE7CXmLEnBsQUEQiQOLmCA2Qqs4C3xNJtS5lBbGEBJ4lH2z8xQZQ4S9 zuCgcJi4CEv6xhAbFZBFQkFjT0s4OU8AqESkw8xAuxaDGjxL4tE9hAajgFHCTW3DjBCGIzCsh KfGlczQyxSlzi1pP5TCC2hICAxJI955khbFGJl4//sULU6Egs2P2JDcLWlli28DVYDa+AoMTJ mU9YJjCKzUIyahaSlllIWmYhaVnAyLKKUb04tagstUjXRC+pKDM9oyQ3MTNH19DAWC83tbg4M T01JzGpWC85P3cTIzDaGIBgB2PjF6dDjJIcTEqivNtYL4QL8SXlp1RmJBZnxBeV5qQWH2KU4e BQkuD9owKUEyxKTU+tSMvMAcY9TFqCg0dJhDdRFSjNW1yQmFucmQ6ROsWoKCXO6wqSEABJZJT mwbXBUs0lRlkpYV5GoEOEeApSi3IzS1DlXzGKczAqCfN+B9nOk5lXAjf9FdBiJqDFQqfOgywu SURISTUwap1ZLXQ9fOofrwAH6ydcCfaLNUrOnH695owT6yeJI1+Sn7f+zdVUP7WR8fXBE/8sG 5fnhs8UsW3P+fQ11tm2Y1rAzGwdx4wpf2Mc4r7yWJ0xaXzyt0Pn/o1vEyeuK7nA87yp9u/P5X KiE2ekzunvXaYQmnJR12nW9wulD2ZfFbp0KvTYbNvMbCWW4oxEQy3mouJEAKGuJN0wAwAA
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-8.tower-33.messagelabs.com!1473259200!43724259!1
X-Originating-IP: [195.232.244.134]
X-StarScan-Received:
X-StarScan-Version: 8.84; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9091 invoked from network); 7 Sep 2016 14:40:00 -0000
Received: from mailout02.vodafone.com (HELO mailout02.vodafone.com) (195.232.244.134) by server-8.tower-33.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 7 Sep 2016 14:40:00 -0000
Received: from mailint02.vodafone.com (mailint02.vodafone.com [195.232.244.199]) by mailout02.vodafone.com (Postfix) with ESMTP id 3sTmMh4TRvzbdMX; Wed, 7 Sep 2016 16:40:00 +0200 (CEST)
Received: from mailint02.vodafone.com (localhost [127.0.0.1]) by mailint02.vodafone.com (Postfix) with ESMTP id 3sTmMh3HlSzR5DJ; Wed, 7 Sep 2016 16:40:00 +0200 (CEST)
Received: from VOEXC04W.internal.vodafone.com (voexc04w.dc-ratingen.de [145.230.101.24]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint02.vodafone.com (Postfix) with ESMTPS id 3sTmMh3BzDzR0Jc; Wed, 7 Sep 2016 16:40:00 +0200 (CEST)
Received: from AVOEXC03W.internal.vodafone.com (145.230.15.132) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 7 Sep 2016 16:40:00 +0200
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.18]) by AVOEXC03W.internal.vodafone.com ([145.230.15.132]) with mapi id 14.03.0224.002; Wed, 7 Sep 2016 16:39:59 +0200
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "insipid@ietf.org" <insipid@ietf.org>
Thread-Topic: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
Thread-Index: AQHR+qJKQYTiWYnxYkiT+e2GsVMuOqBk2NKAgAAS14CACQlycA==
Date: Wed, 7 Sep 2016 14:39:58 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8B3FD9D@VOEXM31W.internal.vodafone.com>
References: <4C52DDE4-07CF-4F5F-8DB7-8CEB51119A6A@cisco.com> <A0B5C7D9-0C0B-4072-8782-8AABFAD1FF2E@cisco.com> <9fc02fda-7b26-5bc5-7a2f-ff10e5b43880@alum.mit.edu>
In-Reply-To: <9fc02fda-7b26-5bc5-7a2f-ff10e5b43880@alum.mit.edu>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/FX2LhwobB-FHNAsrFwpy3e8lzZc>
Cc: "Arun Arunachalam \(carunach\) \(carunach@cisco.com\)" <carunach@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: Wed, 07 Sep 2016 14:40:06 -0000

Hello Paul,
Thanks very much for your review comments and suggestions, the authors will discuss and try to resolve them in the next version. I have outlined my thoughts on resolving the comments in-line below.

Regards,
Peter

> -----Original Message-----
> From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: 01 September 2016 19:47
> To: insipid@ietf.org
> Subject: Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
> 
> Here are some comments on the document:
> 
> * Section 4:
> 
> I'm not clear of the intent of this section. It doesn't seem to include
> requirements, yet it has normative statements. It reads more like a
> mechanism.
> 
> I think this section should be rewritten. Perhaps as a set of
> assumptions/prerequisites for the environment where you are seeking a
> solution.
> 
[PD] Section 4 is currently a mixture of describing the motivating scenario, some pre-requisites (such as logging ends when a dialog ends) and requirements that do not apply to the logme marker itself. We can try to better group these aspects.

> * Section 5:
> 
> I think the requirements in this section are a bit mixed up. Some are
> requirements that are to be met by a log-me *mechanism*. Others seem to
> be requirements that should be levied by a log-me mechanism on those who
> are implementing the mechanism. These are both useful things, but they are
> different. Perhaps they should be in two separate lists.
[PD] We can try to group the requirements by who or what they impact.

> 
> * REQ2
> 
> This talks about "network boundaries". I think more definition is needed to
> clarify exactly what constitutes a network boundary and what the
> impediments are for something to cross it. (Perhaps by referencing
> RFC7092.)
[PD] We can revise REQ2 to make the scenarios clear, perhaps by a combination of referring to some of the figures in RFC5853, which has many examples of network boundaries  even though it does not use the term "network boundary", and giving the RFC7092 categories of B2BUA that could manipulate the logme marker in SIP. 
> 
> * REQ3 (and section 6.1)
> 
> Do you have a particular definition of "trust domain" in mind? Again, I think
> some sort of definition is needed.
> 
[PD] We can define trust domain as it applies to these requirements. A trust domain contains all SIP entities under configuration control of the network operator that is performing (e.g.) regression testing plus all SIP entities that are under configuration control of peer network operators who have agreed to participate in that (e.g.) regression testing. The purpose of trust domain requirements is to prevent network operators inadvertantly triggering logging in networks that are not part of any testing or troubleshooting. 
 
> Also, more discussion of motivation for removing at trust domains is needed.
> IMO there is often little motivation for removing the marking on
> *exit* from a trust domain, and in fact good reason for not doing so.
> OTOH, there may indeed be good reason for removing from a request that is
> *entering* a trust domain. (And some might want to remove the indicator
> on exit in order to ensure that neighbors *aren't* aware they are
> debugging.)
[PD] We can clarify the role of trust domains.
> 
> * REQ6/7
> 
> Do you really mean *proxy*? I suspect you really mean *intermediary*,
> including both proxies and B2BUAs?
[PD] "proxies" was used to make it clear that SIP entities that are currently stateless are able to implement logme and still stay stateless. We can consider the B2BUA types in RFC7092 to see whether this wording needs to cover some subtleties of intermediary types.  
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid