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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 07 September 2016 14:48 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 5D55112B1B8 for <insipid@ietfa.amsl.com>; Wed, 7 Sep 2016 07:48:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 HZpEY6kLdDgK for <insipid@ietfa.amsl.com>; Wed, 7 Sep 2016 07:48:45 -0700 (PDT)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 6BA2D12B103 for <insipid@ietf.org>; Wed, 7 Sep 2016 07:48:45 -0700 (PDT)
Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-03v.sys.comcast.net with SMTP id he8sb674v8GkChe9cbQqQY; Wed, 07 Sep 2016 14:48:44 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-14v.sys.comcast.net with SMTP id he9bbaiCegRKYhe9bbokRj; Wed, 07 Sep 2016 14:48:44 +0000
To: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>, "insipid@ietf.org" <insipid@ietf.org>
References: <4C52DDE4-07CF-4F5F-8DB7-8CEB51119A6A@cisco.com> <A0B5C7D9-0C0B-4072-8782-8AABFAD1FF2E@cisco.com> <9fc02fda-7b26-5bc5-7a2f-ff10e5b43880@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8B3FD9D@VOEXM31W.internal.vodafone.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <479354a7-31ff-3d91-17da-4359f5dda492@alum.mit.edu>
Date: Wed, 7 Sep 2016 10:48:42 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8B3FD9D@VOEXM31W.internal.vodafone.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfKGP8R131tFsZNH2lJ14Bq+HOD7aMe3x7v/99wG96K90ixI0UASwerErIUkSc76DDlsN0pYiBp4taQhSry03eFfo6WFYcj+z6uWAxZkOMOHMojYOnHrK hm3CT0HPwPgNviTiwx8BIAD3LVUs7aFn82dMy4Hn90yFpxclS2Qmy/8SVBF/PS5Oj7BhGkIQB12h+r+SFep2JdlPfqc/Cx2BhCS7uhv0bMg24jzXGydZGBF8 jza1kU4klx74jXuKO8AmKA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/imLzS9p833sxc2q2RWGLAOb20eQ>
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:48:47 -0000

On 9/7/16 10:39 AM, Dawes, Peter, Vodafone Group wrote:
> 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.

Sounds good. I'll keep an eye out for the next version.

	Thanks,
	Paul

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