Review of draft-ietf-insipid-logme-reqs-11

Sean Turner <> Sat, 07 January 2017 02:56 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (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 <>
To: <>
Subject: Review of draft-ietf-insipid-logme-reqs-11
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Fri, 06 Jan 2017 18:56:33 -0800
Archived-At: <>
X-Mailman-Version: 2.1.17
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?