[sacm] Ben Campbell's Discuss on draft-ietf-sacm-nea-swima-patnc-02: (with DISCUSS and COMMENT)
Ben Campbell <ben@nostrum.com> Thu, 22 February 2018 03:09 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: sacm@ietf.org
Delivered-To: sacm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F6312008A; Wed, 21 Feb 2018 19:09:31 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sacm-nea-swima-patnc@ietf.org, sacm@ietf.org, Karen O'Donoghue <odonoghue@isoc.org>, sacm-chairs@ietf.org, odonoghue@isoc.org, sacm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151926897179.21101.1205735756502467820.idtracker@ietfa.amsl.com>
Date: Wed, 21 Feb 2018 19:09:31 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/UAmIwclKDOdX7p0lvJI5CT65Cis>
Subject: [sacm] Ben Campbell's Discuss on draft-ietf-sacm-nea-swima-patnc-02: (with DISCUSS and COMMENT)
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.22
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Feb 2018 03:09:32 -0000
Ben Campbell has entered the following ballot position for draft-ietf-sacm-nea-swima-patnc-02: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (This is related to one of Ekr's comments, but I don't think it's quite the same.) In the first paragraph of §7.2, the conclusions seem to be based on the following sentence: "This is generally not considered to be problematic, as those with access to the endpoint can usually learn of everything disclosed by that endpoint’s records simply by inspecting other parts of the endpoint." This doesn’t seem like a reasonable assumption. Multiuser endpoints may well have access controls that prevent a given user from seeing all software packages installed on the system. This leads to the conclusion that the records on the endpoint are not sensitive. I do not think this document should draw that conclusion. Even if this were provably true for all existing systems, such an assumption could be problematic for future systems. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive Comments: §2.4: This seems to assume there is never a need to hide information from intermediaries. Is that the intent? (Or maybe there aren't any intermediaries?) §3.4.3, -- first paragraph: What is the expected scope of uniqueness for record identifiers? -- In the sentence "The Record Identifier SHOULD remain unchanged if that record is modified.", why is the SHOULD not a MUST? What would happen if the identifier did change? §3.4.4: -- "However, if that directory is shared by other software products, the "location" SHOULD be the location of the primary executable associated with the software product." I'm confused by the the condition, since sharing a directory with other products doesn't seem to introduce the ambiguity that the rest of the sentence assumes. Perhaps this was meant to be about situations where a software package is installed across multiple directories? -- "Even a probable location for a software product is preferable to using a zero-length locator." This could use elaboration; do you expect the collector to guess? §7.1: " Some tools might not be designed to update records in the Software Inventory Evidence Collection in real time,..." Wasn't there a normative requirement that they be capable of this? §8, -- 2nd paragraph: It’s worth mentioning that in some contexts this sort of information could expose the user to severe personal risk, including the risk of death. -- Last paragraph: "For this reason, privacy safeguards might be necessary for collected inventory information." Can this be stated more strongly than "might be necessary"? Editorial Comments and Nits: §3.8.5, first paragraph: "As noted in Section 3.6 SWIMA-PCs MUST ..." Please reserve 2119 keywords for the authoritative statement of a requirement; that is, please do not use them to refer to requirements defined elsewhere. (Note that this pattern occurs multiple times in the draft.) §9: Nit: is there are reasons to violate the convention that IANA, security, and privacy considerations are the last substantive sections in in the body of an RFC?
- [sacm] Ben Campbell's Discuss on draft-ietf-sacm-… Ben Campbell
- Re: [sacm] Ben Campbell's Discuss on draft-ietf-s… Schmidt, Charles M.
- Re: [sacm] Ben Campbell's Discuss on draft-ietf-s… Ben Campbell
- Re: [sacm] Ben Campbell's Discuss on draft-ietf-s… Schmidt, Charles M.
- Re: [sacm] Ben Campbell's Discuss on draft-ietf-s… Kathleen Moriarty
- Re: [sacm] Ben Campbell's Discuss on draft-ietf-s… Ben Campbell
- Re: [sacm] Ben Campbell's Discuss on draft-ietf-s… Schmidt, Charles M.
- Re: [sacm] Ben Campbell's Discuss on draft-ietf-s… Ben Campbell