Re: [mile] [sacm] Fwd: New Version Notification for draft-mandm-sacm-rolie-configuration-checklist-00.txt

[Adam Montville <[e-mail]>]

Thanks, Stephen.

With respect to producing a standard template for ROLIE extensions, I think
that could be useful, either as a separate draft or, perhaps, as an
appendix in ROLIE proper.

We'll get to your other comments as soon as possible.

Kind regards,

Adam

On Wed, Jun 28, 2017 at 11:00 AM Banghart, Stephen A. (Fed) <
[e-mail]> wrote:

> All,
>
>
>
> I finished my review of this document and had some personal feedback/would
> like to start some discussion. I’d also like to pose a question to the
> group/authors: would it be valuable to produce a standard template for
> ROLIE Extensions? We could create a template that would enumerate the
> required and optional sections, and discuss the intended content of each
> section. If this would provide value to anyone I’d be willing to put it
> together.
>
>
>
> *Introduction:*
>
>
>
> How would ROLIE fit into the checklist ecosystem you describe here? I
> understood your explanation of how these checklists may be used in general,
> but not how they may be used/published/downloaded from a ROLIE repository.
>
>
>
> *New information-types*
>
>
>
> I had a hard time trying to pin down what exactly would fall under the
> “configuration-checklist” information type given the description here. I
> think the list of configuration checklist components threw me off. For
> example: ‘ A “Value” ’. What is the definition of value here? Is a
> standalone “Value” a valid configuration-checklist information type? Some
> of these things seem like valid checklist content, like rules and profiles,
> but I didn’t see where the rest fit the definition given at the head of the
> section.
>
>
>
> In ROLIE SWD and ROLIE CSIRT, we provide a list of example information
> that could be, if placed into <content> by themselves, classified as the
> information type in question, rather than the components that make up that
> information type. That approach may make it easier for me to understand the
> configuration checklist information type at a higher level.
>
>
>
> *Usage of Configuration Checklist Information in the Atom Publishing*
>
> *    Protocol*
>
>
>
> The first paragraph talks about “these requirements” but no requirements
> are listed in this section. I may have misunderstood the XML snippet at the
> bottom of this section, however.
>
>
>
> *The 'atom:content' Element*
>
>
>
> The serialization type is provided as a MIME type in the content element,
> so it doesn’t need to be declared in the specification. If a serialization
> has some bearing on other requirements, the MIME type should probably be
> referenced so that your requirement is machine enforceable.
>
>
>
> *The 'rolie:format' Element’*
>
>
>
> The format element describes the data model in use, not the serialization.
> If I understand correctly (I may not), at it stands today the relevant data
> model for this information-type is XCCDF and maybe OVAL, which could be
> serialized in XML, JSON, and if you’re really creative, even Excel, Word,
> and PDF. Discussing these data models would probably help me pin down what
> the configuration checklist information type entails as well.
>
>
>
> *Configuration checklist metadata included in the 'rolie:property'*
>
> *      Element*
>
>
>
> So after looking through these we’ve realized that some of them would be
> valuable to include in the ROLIE core specification. I’ve sent an email to
> the MILE list to request the addition of “content-version”, “content-id”,
> and “content-published-date”. These would replace your “checklist version”,
> ”title”, and “publication date” properties, respectively. We also already
> have a “content-author” property, so you needn’t register “author”.
>
>
>
> For the rest of the properties, I would note that property names can’t
> have spaces in them, as they form a URN (e.g.
> urn:ietf:params:rolie:property:content-author-name).
>
>
>
> Is the product category property intended for human or machine
> consumption? A non-standardized open world plain text description seems
> dangerously vague for machine consumption. If this is something that is
> important to this extension, a new IANA table where each of these
> categories are enumerated and described would be a good solution.
>
>
>
> Depending on how these product categories are used, also consider
> registering them as categories instead of properties. I’m not sure if these
> values are more commonly used as organizing buckets or just as additional
> identifying information.
>
>
>
> *Atom:link Registrations*
>
>
>
> You can have 0..n of any given link element.
>
>
>
> These registrations would take place at
> https://www.iana.org/assignments/link-relations/link-relations.xhtml,
> which is designed to hold general purpose link relations. As described in
> the ROLIE core link extension point section, domain specific link relations
> shouldn’t be registered to this table.
>
>
>
> It would be helpful for me if you explicitly defined what you mean by
> “conformance”. Is this implementation or usage conformance?
>
>
>
> *IANA Considerations*
>
>
>
> I’m unclear on what the “New IANA table for "ROLIE Entry Format"” block of
> text is meant to be. Is this a new table registration? ROLIE core doesn’t
> establish a table for registering formats. CVRF and CVE are probably not
> relevant formats for configuration checklists regardless right? I would
> imagine those are formats used to describe some future “vulnerability”
> information type.
>
>
>
> The reference field of the information type registration should contain a
> reference to “this document”, to satisfy the registration requirement. The
> registrations for links, properties, and categories will have to be listed
> here at some point as well.
>
>
>
> Thanks,
>
> Stephen Banghart
>
>
>
> *From:* sacm [mailto:[e-mail]] *On Behalf Of *Adam Montville
> *Sent:* Friday, June 16, 2017 11:20 AM
> *To:* [e-mail]
> *Subject:* [sacm] Fwd: New Version Notification for
> draft-mandm-sacm-rolie-configuration-checklist-00.txt
>
>
>
> Not necessarily for immediate review, but we've submitted a ROLIE
> extension for configuration checklists. This is intended to get the
> conversation started at some point.
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Fri, Jun 16, 2017 at 10:07 AM
> Subject: New Version Notification for
> draft-mandm-sacm-rolie-configuration-checklist-00.txt
> To: Bill Munyan <[e-mail]>, Adam Montville <
> [e-mail]>
>
>
>
>
> A new version of I-D, draft-mandm-sacm-rolie-configuration-checklist-00.txt
> has been successfully submitted by Adam Montville and posted to the
> IETF repository.
>
> Name:           draft-mandm-sacm-rolie-configuration-checklist
> Revision:       00
> Title:          Definition of the ROLIE configuration checklist Extension
> Document date:  2017-06-16
> Group:          Individual Submission
> Pages:          10
> URL:
> https://www.ietf.org/internet-drafts/draft-mandm-sacm-rolie-configuration-checklist-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-mandm-sacm-rolie-configuration-checklist/
> Htmlized:
> https://tools.ietf.org/html/draft-mandm-sacm-rolie-configuration-checklist-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-mandm-sacm-rolie-configuration-checklist-00
>
>
> Abstract:
>    This document extends the Resource-Oriented Lightweight Information
>    Exchange (ROLIE) core by defining a new information-type to ROLIE's
>    atom:category pertaining to security configuration checklists.
>    Additional supporting requirements are also defined which describe
>    the use of specific formats and link relations pertaining to the new
>    information-type.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>