[Insipid] Review of draft-ietf-insipid-logme-reqs-11
Sean Turner <sean@sn3rd.com> Sat, 07 January 2017 02:56 UTC
Return-Path: <sean@sn3rd.com>
X-Original-To: insipid@ietf.org
Delivered-To: insipid@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF2B1270B4; Fri, 6 Jan 2017 18:56:33 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Sean Turner <sean@sn3rd.com>
To: secdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148375779374.17442.8516164323586796119.idtracker@ietfa.amsl.com>
Date: Fri, 06 Jan 2017 18:56:33 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/fKlVJ7ENN3aWs-ILrvCfwXF_oU0>
Cc: insipid@ietf.org, ietf@ietf.org, draft-ietf-insipid-logme-reqs.all@ietf.org
Subject: [Insipid] Review of draft-ietf-insipid-logme-reqs-11
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 07 Jan 2017 02:56:34 -0000
Reviewer: Sean Turner Review result: Has Nits After getting over my initial reaction that was something like "srsly!? we're going to standardize the exact opposite of 'do not track'", I realized that this is a requirements draft for an IETF approved WG and a chartered work item of that WG :) 0) s3.2: Is the intent to define a protocol mechanism to determine if the two or domains are part of the same trust domain? This requirement could be achieved by saying out-of-band bilateral agreements are the mechanism to establish the domain. 1) s5.1: REQ1 - Did you mean to say "using SIP standard logging format"? Is there another logging format other than SIP CLF? 2) s5.1: Should the must be MUST in the following: All log retrieval mechanisms must adhere to authorization and privacy protection policies set forth by the network administrator. 3) s5.2: REQ3 seems odd to me - Isn't this kind of like a SIP thing? I mean if SIP doesn't allow adding new headers then didn't somebody sink your battleship? But SIP does allow you to add arbitrary headers so I think I'm missing something as to why this is needed? 4) s5.2: REQ3 - Reads a bit awkward to me how about: It MUST be possible to mark a SIP request or response for logging by inserting a "log me" marker. i.e., remove "of interest" 5) s5.2: REQ4 - Again this seems like a basic SIP thing - I mean are there fields that SIP requires be stripped? 6) Is there a missing requirement based on the security considerations that requires the this marker MUST be removed at the earliest opportunity if it has been incorrectly inserted?
- [Insipid] Review of draft-ietf-insipid-logme-reqs… Sean Turner
- Re: [Insipid] Review of draft-ietf-insipid-logme-… Dawes, Peter, Vodafone Group
- Re: [Insipid] Review of draft-ietf-insipid-logme-… Paul Kyzivat
- Re: [Insipid] Review of draft-ietf-insipid-logme-… Dawes, Peter, Vodafone Group
- Re: [Insipid] Review of draft-ietf-insipid-logme-… Paul Kyzivat
- Re: [Insipid] Review of draft-ietf-insipid-logme-… Dawes, Peter, Vodafone Group
- Re: [Insipid] Review of draft-ietf-insipid-logme-… Paul Kyzivat
- Re: [Insipid] Review of draft-ietf-insipid-logme-… Dawes, Peter, Vodafone Group