[sacm] ROLIE Software Descriptor Review
Jessica Fitzgerald-McKay <jmfmckay@gmail.com> Wed, 27 March 2019 15:13 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 6B67F1200EF for <sacm@ietfa.amsl.com>; Wed, 27 Mar 2019 08:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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] 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 FUHogxhSJUFH for <sacm@ietfa.amsl.com>; Wed, 27 Mar 2019 08:13:01 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 EF104120073 for <sacm@ietf.org>; Wed, 27 Mar 2019 08:13:00 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id v4so14369069ioj.5 for <sacm@ietf.org>; Wed, 27 Mar 2019 08:13:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Svglldc+U1kmjP7q93/ZvKd2dFvAQGIdvE3RXM87P5s=; b=OyQR+aggflTNwyJLaAxkH7eB9WcF0LqUu0O3hCMA87nsuO2+tPPcOzEOycTnRB9lvU wUdrwl9ebT/kkdObMMCBi2sPUamyeWOHmTgSw1DLgIKe3Mwu6bw18PjNWLK8QK1TKtzl NgrsZCcbRPw4vqOZyAcljQTAbiQ2zCG6uSQFNr0rLAr/U9rKlerVq/nGAwJTILWATa9T /l/NUaCEgSXaO4m4onGTzW8FFVLFl2/ICS17TSbF4lVCAKMop2HJy6SY5A98mkjrc154 qZV4LplSENDZBaIELWJX1Qq+88060+XaZ4HjRPsg+2b0B3Zl7omFcEpvjxRXauKrxLcn h8tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Svglldc+U1kmjP7q93/ZvKd2dFvAQGIdvE3RXM87P5s=; b=KyCLPkcq4jzrZlX/jiIiFDeVFUKRUf317l6khyoCDBgqBKjpQTjKVuKIa1Ff9Eie58 aCRibsrj13FJbc40gYbjTe1tdjEuFPaWfQtSX2jAdMhWYzHpMy5bhFOmx9WlF+l9NafN 6KBF8tTGLRbZ0zCrIm2XcjjxXyVKwoLEZnvldiSAPYSDnA+wyEXxnGvbu09qP4qUEUPj Iq5QycygkDpMXyF05wTrQ4nMEWFNmqaDE16BAcmvwnopcjou+C8ykBMW36gX01K6UqiD seHjiTUek5AwN/BsafXdJkTqRKD2BRDwF3s5gfZ78K6DJnH2rsQjQtlnNsZ/vcDkCU0c EXqQ==
X-Gm-Message-State: APjAAAXEQF5TDpmiZCRHKyNvH5NS6sPJLqufdlmGQ9DZ5OPNJSxS6WfU CNFmxPC95wJ+VkRc5UUeuToxOVcsb6XyopUzy/wsQpl0
X-Google-Smtp-Source: APXvYqwhIg4/rqd1DuUlSGlJyORNQ+q2ZkaZssdgUg1yYEwqxO/YI7uNABaWkmGvdgK1OAbTuFPhz5hE1r7kyr275zY=
X-Received: by 2002:a5e:c60d:: with SMTP id f13mr27020972iok.23.1553699579731; Wed, 27 Mar 2019 08:12:59 -0700 (PDT)
MIME-Version: 1.0
From: Jessica Fitzgerald-McKay <jmfmckay@gmail.com>
Date: Wed, 27 Mar 2019 11:12:48 -0400
Message-ID: <CAM+R6NVBRZzm27kervMnmASyYayPyGx_qW0DSzxqW6y_FyUD-w@mail.gmail.com>
To: sacm@ietf.org
Content-Type: multipart/alternative; boundary="00000000000089a3fb058514dfde"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/a2ZuXybBZhcdTPw7U8aKOTi-E7g>
Subject: [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: Wed, 27 Mar 2019 15:13:04 -0000
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 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 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." - What does "smaller state space" mean? - "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. - "Value added information" sounds like a marketing term. Maybe you can just say checklists or assessment requirements? - 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. - The bulleted section that begins "Organizations can use" has an unnecessary comma, "thru" should be "through", and expand RIM. Section 2 - I think it is worth pointing to definitions of words like "Entry" or "Feed" in whichever RFC they are defined. Section 3 - Drop "This" at the beginning of the second sentence - While I agree with your second sentence, I wonder if we can back it up. Is there a source for this information? - 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. - 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" 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 - 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. Section 5.1 - I can't be sure, but I think there's an extra space between "As such" and the following comma 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" - 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" - 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" 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? - 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". - 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) - 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?
- [sacm] ROLIE Software Descriptor Review Jessica Fitzgerald-McKay
- Re: [sacm] ROLIE Software Descriptor Review Banghart, Stephen A. (Fed)
- Re: [sacm] ROLIE Software Descriptor Review Jessica Fitzgerald-McKay
- Re: [sacm] ROLIE Software Descriptor Review Waltermire, David A. (Fed)