[Insipid] AD Evaluation of draft-ietf-insipid-logme-reqs-10

"Ben Campbell" <ben@nostrum.com> Mon, 31 October 2016 21:32 UTC

Return-Path: <ben@nostrum.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 690EA129B36; Mon, 31 Oct 2016 14:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 h8SOVr_KPJma; Mon, 31 Oct 2016 14:32:16 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E14129B12; Mon, 31 Oct 2016 14:32:13 -0700 (PDT)
Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9VLWBnS076367 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 31 Oct 2016 16:32:12 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21]
From: "Ben Campbell" <ben@nostrum.com>
To: draft-ietf-insipid-logme-reqs.all@ietf.org, insipid@ietf.org
Date: Mon, 31 Oct 2016 16:31:32 -0500
Message-ID: <36BFA904-FB78-4D63-BA62-B559BA5D700B@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/At-bkeCSIq2wbfHtJVN-Z2SH8D8>
Subject: [Insipid] AD Evaluation of draft-ietf-insipid-logme-reqs-10
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: Mon, 31 Oct 2016 21:32:18 -0000

Hi, this is my initial AD evaluation of 
draft-ietf-insipid-logme-reqs-10.

I have some significant concerns about this document, as noted below. 
I'd like to discuss the major concerns before progressing the document.

Major Concerns:

- What is the archival value for this draft after the mechanism is 
complete? Is there really a reason to publish it as an RFC? Could the 
info here be stored in the working group wiki, included in the solution 
draft, or even allowed to expire once the mechanism is complete? I 
contrast this to the session-id requirements document, since that 
explored the details of some tricky concepts (such as "session".) It's 
not clear to me that this draft does the same. I also note that 
logme-marking already seems to replicate a good deal of this draft, and 
seems to dive even deeper into use cases, and in some areas seems to 
have moved beyond the requirements in this draft.

I ask because the question is likely to come up in IESG review, and also 
because the publication process creates a lot of effort for the working 
group, RFC editor, reviewers, etc.

- The purpose of the draft is not clear to me. I understand it to be 
requirements for the creation of a protocol mechanism; that is, that it 
would describe the features of the mechanism, but not the details of how 
the mechanism works. But many of the requirements seem like requirements 
on the behavior of network elements (that is, mechanism details). If 
this draft is to be published as an RFC, I think quite a number of them 
will need to be rethought. Details in the minor concerns section.

Minor Concerns:

-2: The usage in this draft does not exactly match RFC2119.  That RFC is 
about interoperability, not compliance or requirements on a mechanism. 
(That could be more clear in the definitions of the terms in 2119, but 
it's pretty clear in section 6.). That doesn't mean this draft cannot 
use 2119 terms, but please edit the boilerplate to describe how you 
really intend to use them. (I note that this draft does use some 2119 
language as described in 2119, but that's what triggered my other 
comments about describing mechanism rather than requirements.

- 3.1, 2nd paragraph: Is this still part of the definition of network 
boundary?

- 3.2: I assume the "trust domain" is specific to trust for logging 
purposes. I suggest "Logging trust domain" or "logging domain".

- 4.3, third bullet: Is "dialog" the correct term here? Is this really 
limited to a dialog, or do you expect it to apply to the concept of a 
"session" as described in the session-ID doc?

- 5.1, REQ1: This seems more like mechanism than a requirement against 
the mechanism, in that it states a requirement for specific network 
element behavior. Isn't the real requirement something along the lines 
of "The mechanism must allow the endpoint to indicate that it wishes the 
entire message to be logged"?

Also the MUST seems misplaced as stated; do elements have the option not 
to log? That seems to be in conflict with typical privacy requirements 
that suggest log minimization.

- 5.1, third paragraph: Making policies about log retrieval out of scope 
seems unfortunate. This draft should have something to say about such 
policies in the form of privacy requirements on the mechanism. That 
doesn't mean this draft has to state the policies, but it can require 
the mechanism to discuss them. (Or can something be referenced from the 
CLF work?)

- 5.3: Req6 is confusing as worded. It starts off saying things work 
best if the marker goes end to end, then says not to send it end to end. 
Please explain why the "responsible" behavior goes against the first 
sentence. (I think we can all infer the reasoning, but it's better to be 
explicit.)

-- Req7: This seems like mechanism, not requirements for a mechanism. It 
stated normative requirements on the behavior of a network element. It 
seems like that belongs in the mechanism document.

-- Req8: Same as last comment.

-- Req9 seems to have privacy implications that need discussion 
somewhere. How would a user know logging was requested? Can a user 
override that?

-- Req10: Again, this seems like mechanism. I would expect a requirement 
to say something like "The mechanism must allow for stateless 
operation."

-- Req11: Mechanism again. I would expect a requirement to be of the 
form of " a log me indication applies for the duration of a dialog (or a 
session?).

- 6.2.1: Would it make sense to say the marker must not contain 
information can be used to identify the uer or endpoint device, and that 
it must not be possible to correlate markers across multiple sessions? 
If not, why not?

-- Does the requirement that the marker must not be modified in transit 
imply that it must not be possible for it to be modified, or just that 
participating endpoints must not modify it?

-- The requirement that logs not be readable by an unauthorized party 
seems to contradict the earlier statement that how and when logs are 
read is out of scope.

- 6.2.2: The previous section stated this more strongly, so this section 
seems entirely redundant.

Editorial Comments:

- Abstact: "... if network or client software is upgraded.":
s/if/when

- abstract, paragraph 2:
I assume this document intends to create requirements on the 
capabilities of a logme indication mechanism, not define how the 
indicator works. (The latter would be solution, not requirements)

- introduction: " if SIP client software/hardware"

I suggest "... when SIP client software or hardware"

-3.1, 2nd paragraph : "prevent the
    sending network passing on sensitive information"
s/network passing/network from passing/

- figure 1: there are lines that don't seem to line up. (e.g. diagonal 
line from top of country Y and from the side of country X, Operator A, 
SIP phones.

- 5.3, Req 9: Should the "dialog" be "session"?