Re: [sacm] ROLIE Software Descriptor Review

Jessica Fitzgerald-McKay <jmfmckay@gmail.com> Fri, 29 March 2019 08:30 UTC

Return-Path: <jmfmckay@gmail.com>
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 B5637120257 for <sacm@ietfa.amsl.com>; Fri, 29 Mar 2019 01:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CAeCI-_kyCam for <sacm@ietfa.amsl.com>; Fri, 29 Mar 2019 01:30:00 -0700 (PDT)
Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 13D591203BD for <sacm@ietf.org>; Fri, 29 Mar 2019 01:30:00 -0700 (PDT)
Received: by mail-it1-x135.google.com with SMTP id u65so2557504itc.2 for <sacm@ietf.org>; Fri, 29 Mar 2019 01:30:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FYOTcOd8j+2Jk4PDV4srSYlQ2j3nGWY2idfoMEpXoRc=; b=uQQu+Z2bk5+jJdSaIe0mxaBytZSWQeev61PgB8DyzDcb93FPb26FwuK/UvnaOjQ8tk UviFVvhFZn70qyKKeqgkCKrcMYunXDnwnyWON8+KWVT8LUQz2dvsBbzV3wwrvngIAEOE TqJnW9qhP7znPIbeJ/1BX3QW+DKgSLQB2pH/Pl0V/K1Ad35QiBNx5VPG+Hubt6aMJ7BI jeuC1Ab1QmZe4XumMoj7Aln1Id+vShNPBCZE33vaI+JU8XVNwXe85cHtoCwM02byrY9K h9NG87i1JEz5ojRm2mb0ziwhp/7V8rl+lhC6RFE0C+46iH348OMub2JXc16zww5kdNPH JIug==
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=FYOTcOd8j+2Jk4PDV4srSYlQ2j3nGWY2idfoMEpXoRc=; b=FkiM+8BGJsHST/QrWdUh41RVHxfmNY+qqUnNtl+smECp6/BxzQhLyhHEQtUPDAUcG0 7vBip3DVVItrOMoCRK5gyWNgvIMfqNS1Nt/N7QXKJ02G6lLK4UMayjfIylWmLSEhUpsQ iEuMPP1gAnnMfJEE3hhTiafNzk7J7KablGw/LNWM4eTlo+HRxC3hCnEpO3gHZYibwxr3 5twz5jv8n5WrpZetQdxfjEgFKJY97CzyI1m/qF/rR0aHwuG5b6m2xUZYxoVgbiHPs75/ ZVNNJAx70yfAHSJC09cqaSNnPeYDk9bsF2c+4N5nR+b5sGFY8U6yyRO7NAsg3txsTpgm eveg==
X-Gm-Message-State: APjAAAVsDCzY/f68GlY09a9ANx2r40ZUQAFDQtE5C6/u0sGR9LmlKcZc 27N9TEoNt3FuMwJLUghbMFe39ZsJ5HduDk5T8Mw=
X-Google-Smtp-Source: APXvYqz1NgAxODGeQZWp+u42MtHIqkENP1xRzMgkqWsF/QrFcCKOoUn9d60LtSWRZSo+892mGVJvYO8z5wr5KzWtHdw=
X-Received: by 2002:a24:c8d6:: with SMTP id w205mr3153874itf.29.1553848199067; Fri, 29 Mar 2019 01:29:59 -0700 (PDT)
MIME-Version: 1.0
References: <CAM+R6NVBRZzm27kervMnmASyYayPyGx_qW0DSzxqW6y_FyUD-w@mail.gmail.com> <BN3PR09MB060981E61E71DA4DF1FEB402F0590@BN3PR09MB0609.namprd09.prod.outlook.com>
In-Reply-To: <BN3PR09MB060981E61E71DA4DF1FEB402F0590@BN3PR09MB0609.namprd09.prod.outlook.com>
From: Jessica Fitzgerald-McKay <jmfmckay@gmail.com>
Date: Fri, 29 Mar 2019 04:29:47 -0400
Message-ID: <CAM+R6NUri6BL6h8QNyWtdobu3hG5vrnYw4BfovUH4p0Sp_EE0A@mail.gmail.com>
To: "Banghart, Stephen A. (Fed)" <stephen.banghart@nist.gov>
Cc: "sacm@ietf.org" <sacm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f0bed90585377976"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/Vntl6GYDoflArILN4XuJ6uErG1s>
Subject: Re: [sacm] ROLIE Software Descriptor Review
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 29 Mar 2019 08:30:11 -0000

Definitely confirm with Henk, but I suspect RIM = Reference Integrity
Measurements



On Thu, Mar 28, 2019 at 10:33 AM Banghart, Stephen A. (Fed) <
stephen.banghart@nist.gov>; wrote:

> Jess,
>
> Thanks for the great review, I've gone through and addressed your
> concerns. I'll wait for the rest of the reviews and publish the new version.
>
> I don't think there are any changes in particular you would need to
> respond to, but I've provided a brief description of each below:
>
>
> Header
> -The authors' place of work could be listed as "NIST" (as it is in other
> I-Ds and RFCS) to avoid the current craziness in the header information
>
> > Fixed.
>
> Section 1
> - The sentence " Software descriptor information is information that
> characterizes static software components, packages, and installers;
> including identifying, versioning, software creation and publication, and
> file artifact information." doesn't flow well, in my opinion. I would
> revise to "Software descriptor information is information that
> characterizes static software components, packages, and installers;
> including identification, version, software creation and publication, and
> file artifact iinformation."
>
> > Updated
>
> - What does "smaller state space" mean?
>
> > Fair enough, its pretty vague. I've changed it to "tightly limited
> scope".
>
> - "ROLIE Feeds" is used before it is defines. I wonder if these are use
> cases for ROLIE Software Descriptor Information, and "ROLIE Feeds" is
> unnecessary here.
>
> >ROLIE Feeds are defined in section 6.1 of the ROLIE core. I've added a
> reference out to that.
>
> - "Value added information" sounds like a marketing term. Maybe you can
> just say checklists or assessment requirements?
>
> > I've updated this to  "...and to provide downsteam services
> >            (e.g., software configuration checklist repositories)."
> >I've also removed the rest of that sentence (Past the quoted section
> above), because on a re-read I found it way to long.
>
> - The bulleted section that begins "End user organizations" has a
> misplaced comma. I think you were trying to separate multiple "and"
> statements. Perhaps the first "and" should become "as well as" to make this
> section more clear.
>
> > Agreed. Updated to: "End user organizations can consume software
> >           descriptor information along with related software..."
>
> - The bulleted section that begins "Organizations can use" has an
> unnecessary comma, "thru" should be "through", and expand RIM.
>
> >Fixed. On investigation I can't even find what RIM is supposed to stand
> for. I seem to remember Henk suggesting its addition. I'll ask him to
> define it.
>
> Section 2
>
> - I think it is worth pointing to definitions of words like "Entry" or
> "Feed" in whichever RFC they are defined.
>
> >Entry and Feed are both defined in the ROLIE Core RFC8322, I'll add an
> explicit statement for that.
>
> Section 3
>
> - Drop "This" at the beginning of the second sentence
>
> >Fixed
>
> - While I agree with your second sentence, I wonder if we can back it up.
> Is there a source for this information?
>
> >I'm struggling to find a source. I've changed it to "significant
> portion", which is closer to a truism.
>
> - In the third sentence, I think that a device can have a secure and
> managed OS and still not have good representation of the other software on
> the device.
>
> > I've added "with strict software whitelisting" to the secure and managed
> OS. My idea was to refer to secure OSes where software is infrequently, if
> ever, installed beyond the original deployment.
>
> - Expand SWID on first use (which is actually in the Abstract, I just
> noticed it when I got to Section 3. I think you could make the argument
> that you don't want to make the abstract longer than necessary, and so
> choose to expand it here, though)
>
> - drop comma in first sentence, second paragraph, between "format" and
> "expressed"
>
> > Done
>
> Section 4
>
> - last sentence first paragraph requires no commas
>
> - in the list of things software-descriptor information can do, the first
> two items in the list begin with full sentences. The remaining item, as
> well as all the items in the non-exhaustive list below it, start with a
> sentence fragment. I personally prefer the style that begins with the
> sentence fragments, and suggest editing items one and two to match that
> style
>
>  - bullet that begins "Version and patching information" is incomplete
>
> - bullet that begins "Vendor or source information" -drop the word "from"
>
> - bullet that begins "descriptive information and data"- expand the
> acronym OSs
>
> >Fixed all the above
>
> - The two paragraphs after the non-exhaustive list both start out asking
> the reader to note something. Maybe more appropriate for the first of these
> paragraph than the second.
>
> >I've simply removed the first of the two paragraphs, since we already
> mention that the list is non-exhaustive.
>
> Section 5.1
>
> - I can't be sure, but I think there's an extra space between "As such"
> and the following comma
>
> >At least in my editor there is no space. I'll keep an eye on it.
>
> Section 6.1.1
>
> - spacing is inconsistent within the bulleted list
>
> Section 6.1.2
>
> - second bullet drop "as" in "as per"
>
> - in the SWID Tag Entry requirements list, second bullet, drop "for" in
> "This allows for"
>
> >Fixed the above
>
> - in the SWID Tag Entry requirements third bullet, "this field aids ROLIE
> consumers in search and filtering Entries" doesn't flow well. Maybe "This
> helps ROLIE consumers search and filter entries"
>
> >Yeah that sounds better, updated
>
> - in the SWID Tag Entry requirements fourth bullet, "it's" -> "its"
>
>
> Section 6.2.1
>
> - second sentence, "This provides" -> "CBOR provides"
>
> - third sentence, "It provides" -> "COSWID provides"
>
> Section 6.2.2
>
> - second bullet, "as per" -> "per"
>
> - in the COSWID Tag Entry requirements list, second bullet, drop "for" in
> "This allows for"
>
> - in the COSWID Tag Entry requirements third bullet, edit to "This helps
> ROLIE consumers search and filter entries"
>
> >Fixed all the above
>
> Section 7
>
> - Why are these relationships required if they are only used in edge
> cases? Alternatively, why not create registries for all required elements
> of the format?
>
> >They are niche in the context of the link relation IANA table, which
> covers the entire internet. Additionally "supporting" these link relations
> in your >implementation shoundn't actually take any work at all (barring
> some extremely strict implementation, thus the requirement)
>
> - Maybe I do not fully understand what you mean, but the sentence "These
> relations come in related pairs" seems odd. I think "related" is
> unnecessary, and I cannot tell if "relations" should be "relationships".
>
> >This entire is sentence is actually pretty confusing and I'm not
> convinced it actually says anything that matters. I'm just going to remove
> it.
>
> - the chart would be easier to read with more whitespace between the
> descriptions, as well as an ascii indicator of which pairs go together (I
> know, it is obvious, but readability is a thing)
>
> >I'll take a look at this
>
> - in description of "patches vulnerability", "are describing" ->
> "describes"
>
> Section 9
>
> - second paragraph, "should have been" -> "should be"
>
> - fourth paragraph, "utilized" -> "used"
>
> Section 10
>
> - why no link in SWID tag reference?
>
> >Fixed the above
>
> Thanks,
> Stephen Banghart
>
>
>
> ------------------------------
> *From:* sacm <sacm-bounces@ietf.org>; on behalf of Jessica
> Fitzgerald-McKay <jmfmckay@gmail.com>;
> *Sent:* Wednesday, March 27, 2019 11:12 AM
> *To:* sacm@ietf.org
> *Subject:* [sacm] ROLIE Software Descriptor Review
>
> I reviewed version -06 of this ID. It looked very good to me. What follows
> is mostly a long list of nits, in which I quibble over Stephen's use of
> commas.
> I'm happy to discuss any of these suggestions. Once these revisions are
> made, I think this document is ready for WGLC
>
> [snip, replicated above]
>