Re: [sacm] Warren Kumari's Yes on draft-ietf-sacm-requirements-16: (with COMMENT)

Warren Kumari <warren@kumari.net> Mon, 26 June 2017 06:02 UTC

Return-Path: <warren@kumari.net>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED43E126B7E for <sacm@ietfa.amsl.com>; Sun, 25 Jun 2017 23:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 2caODak3bG7a for <sacm@ietfa.amsl.com>; Sun, 25 Jun 2017 23:02:21 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 F195A127058 for <sacm@ietf.org>; Sun, 25 Jun 2017 23:02:17 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id 191so34958757vko.2 for <sacm@ietf.org>; Sun, 25 Jun 2017 23:02:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RNWoyJeaSwjDst7B/dXrky7oBseH3F4tK4FAbkHNPu0=; b=ZUHxGwiw6tsZEK6QfwBo3IDp3LFXN/ZxBxyPke1Q/ZJ9z6cWmSpEXO1R0TCJ4lKT+r 6NR96PA+ZnrZlwYcKJCycTHjwECQ454PkD2RtuMm7uH6b4LV6nAcZH6LaMBWtyas0SYZ 7cov6sJ6noPstQi+J4EcIh45xOLnbz+94ya87tf1OICzI9nZ4mwtgDyLvMsP6ZB821+6 A3jPofYP9x45uNkyQCsiVVKero04EkQrVuupk9fllBvdX9NMBDib1RkTMUl/AAI/opmo MxFZX9PjUBkf6Lt51m2ZroRFQqc7QMXjSL59FR6WKgcaLOxLhr5XXLzdb0sbIZL+Q/2P WnCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RNWoyJeaSwjDst7B/dXrky7oBseH3F4tK4FAbkHNPu0=; b=ep2ceErWrZ50wljOEwjpJMg/uB03sZCiCNUUwl2TpMSMLNo2oiAwZNz6yL1XRGAplU Hlg/pob7/vMbL62H4TJjyKahWTSA3E07C9IkbvRGqepsG0Sw4kG1qPTej5EK3qaDwXrR Vyl1oodwzQOL5wTTkV15BPpVsfgZi/0+sAmsf7ZxmuvW0IE3jAH0VQ9r+BjXGzzwCbXR iETdwga7yhbW1r/QfDmgbwHodJyIIvDwzTutX2tqDdVC0PApu5XktohmMvPD+UQNP/fj 1aAimuWgY9+oCtfaPVKbwuAs8i2EYow9u0l28HL5k8+5MakxRRDRJpRPaFv1HRDj8jlh mjVw==
X-Gm-Message-State: AKS2vOzbNoT/U9rvCTPGEWADVRoDjcpwL3ugZMJbrBKfmDk1G8uqPMzH SAwYmUe0z1w0D+Coo1q8wdMCC6BU1Nv3
X-Received: by 10.31.65.87 with SMTP id o84mr8059404vka.7.1498456936979; Sun, 25 Jun 2017 23:02:16 -0700 (PDT)
MIME-Version: 1.0
References: <149806277017.15559.6264125955174335967.idtracker@ietfa.amsl.com> <BF4A9E2A-3A46-49EC-8AEA-1A31AF9D381B@cisco.com>
In-Reply-To: <BF4A9E2A-3A46-49EC-8AEA-1A31AF9D381B@cisco.com>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 26 Jun 2017 06:02:06 +0000
Message-ID: <CAHw9_iLiqwncrTvZvQ8SQ+9SHwZWHcrM2gzNeA6r+-TNDTZhYA@mail.gmail.com>
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, The IESG <iesg@ietf.org>
Cc: Karen O'Donoghue <odonoghue@isoc.org>, "draft-ietf-sacm-requirements@ietf.org" <draft-ietf-sacm-requirements@ietf.org>, "sacm-chairs@ietf.org" <sacm-chairs@ietf.org>, "sacm@ietf.org" <sacm@ietf.org>
Content-Type: multipart/alternative; boundary="001a114db3d270d2d50552d6b118"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/_njTSB-DoWxfqbaFJ99vvtbxK04>
Subject: Re: [sacm] Warren Kumari's Yes on draft-ietf-sacm-requirements-16: (with COMMENT)
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Mon, 26 Jun 2017 06:02:24 -0000

Excellent, thank you.


W

On Mon, Jun 26, 2017 at 1:45 AM Nancy Cam-Winget (ncamwing) <
ncamwing@cisco.com> wrote:

> Thanks for the review and comments.  Please see further comments below:
>
> On 6/21/17, 9:32 AM, "Warren Kumari" <warren@kumari.net> wrote:
>
>     Warren Kumari has entered the following ballot position for
>     draft-ietf-sacm-requirements-16: Yes
>
>     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-requirements/
>
>
>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>
>     I spent a while trying to figure out how to ballot on this - I
> personally see
>     value in requirements, use-cases and similar (informational) documents
> - they
>     help newcomers to the technology understand how and why it is shaped
> as it is.
>     This document is also (kind of) mentioned in the charter ("A document
> or
>     documents describing the SACM Architecture. This will include protocol
>     requirements and their associated use cases as well as a description
> ..." , and
>     so I've decided on Yes
>
>     However, there are still some comments / nits which should be
> addressed,
>     including:
>
>     Abstract:
>     "The requirements and scope are based on the agreed upon use cases."
> -- what
>     use cases / agreed upon by whom? (Missing ref).
> [NCW] The use cases are now in RFC 7632 and its reference has been added.
>
>     1. Introduction
>     "Today’s environment of rapidly-evolving security threats highlights
> the need
>     to automate the sharing of security information (such as posture
> information)
>     while protecting user information as well as the systems that store,
> process,
>     and transmit this information." - "... user information as well as the
> systems"
>     -> "user information and the systems" ? Not sure if this is better....
> [NCW] Yes, it helps and I’ve made the change in the next revision.
>
>     2.  Requirements
>     I got somewhat lost in "A SACM transport protocol is one that runs on
> top of L3
>     protocols such as TCP/IP or L4 protocols such as HTTP, carries
> operations
>     (requests / responses), and moves data." - perhaps "A SACM transport
> protocol
>     is one that runs on top of L3 protocols (such as TCP/IP) or L4
> protocols (such
>     as HTTP), carries operations (requests / responses), and moves data."
> [NCW] I’ve change L3 and L4 to be “transport layer” and “Internet layer”
> as suggested by Carsten.
>
>     3: "With the information model defining assets and attributes to
> facilitate the
>     guidance, collection, and assessment of posture, these are some of the
> tasks
>     that should be considered:" - the "With" and "these" feel unrelated.
> I'm not
>     really sure how they are supposed to tie together, so I cannot suggest
> text.
> [NCW] I’ve changed “these are some of the tasks that should be considered”
> to read
> “tasks that should be considered include”.  Hopefully it ties them as
> tasks to facilitate the
> workflow for “collection”, “guidance” etc…
>
>
>     G-001
>     "2.  The query language MUST allow for general inquiries, as well as
> expression
>     of specific attributes or relationships between attributes to follow;
> the
>     retrieval of specific information ..." -- I don't really understand
> the "to
>     follow"; can it be struck?
> [NCW] Yes, thanks for catching it….
>
>     G-002
>     "Interoperability: The data models, protocols, and transports  must be
>     specified with enough details to ensure interoperability." -- I really
> don't
>     understand the point of saying this - are you expecting that if you
> *didn't*
>     say this that people would intentionally create models without enough
> detail?
>     Is this just a "motherhood and apple pie" statement?
> [NCW] Yes!  There were a couple of proposals that didn’t provide enough
> specificity
> so the WG asked for this requirement to be included.
>
>      G-006
>     "Mechanisms for this protection are unspecified but should include
> industry
>     best practices such as encrypted storage, encrypted transports, data
> checksums,
>     etc. " -- the list of best practices seems harmful;  if you provide a
> list
>     people will implicitly assume it is exhaustive, and industry best
> practices
>     change over time. Also, what is a "data checksum"? I'm assuming you
> mean
>     something "cryptographic checksums" or "secure hash" - a data checksum
> implies
>     something like a simple CRC. I'd suggest just dropping the "such
> as..." list.
> [NCW] Done.
>
>     IM-004
>     "Data Model Identification: The information model MUST provide a means
> to
>     uniquely identify each data model uniquely." - you really really want
> this to
>     be unique, don't you :-P
> [NCW] LoL….2nd uniquely is removed
>
>     5.2.  Privacy Considerations
>     "In addition to identity and SACM capabilities information disclosure,
> the use
>     of time stamps or other attributes that can be used as identifiers
> especially
>     as they are coupled with an identity can be further used to determine
> a target
>     endpoint or user’s behavioral patterns." -- this sentence could use
> some work.
>     I agree with what it is trying to say, but it is long and confusing.
> Perhaps:
>     "In addition to identity and SACM capabilities information disclosure,
> the use
>     of time stamps (or other attributes that can be used as identifiers)
> could be
>     further used to determine a target endpoint or user’s behavioral
> patterns." --
>     I *think* that that maintains the meaning, but is clearer.
> [NCW] Yes, thanks for the improvement.
>
>     "Data confidentiality can provide some level of privacy but may fall
> short
>     where unecessary data is still transmitted." - "unnecessary" (typo)
> [NCW] Fixed.
>
>
>
>
> --
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf