Re: [sacm] ROLIE Software Descriptor Review

[Jessica Fitzgerald-McKay <[e-mail]>]

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



On Thu, Mar 28, 2019 at 10:33 AM Banghart, Stephen A. (Fed) <
[e-mail]> 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 <[e-mail]> on behalf of Jessica
> Fitzgerald-McKay <[e-mail]>
> *Sent:* Wednesday, March 27, 2019 11:12 AM
> *To:* [e-mail]
> *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]
>