Security Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-18

I too don't see the particular value of having this published as an RFC, but understand that the WG may view it differently. I offer the comments below for what they're worth.

I think the document sows confusion in its use of the terms "transport protocol" and "transfer protocol." They appear to be used interchangeably (maybe? I'm not actually entirely sure), there seem to be claims that HTTP is a L4 transport protocol, and although the terms "SACM transport protocol" and "SACM transfer protocol" are used and vaguely defined in the draft, they are not defined in the terminology document. If this document goes forward it seems like an edit pass to clarify what is meant with these terms each time they are used, and their relationship to what we typically think of as a "transport protocol," is warranted.

I would have thought target location information would be specifically called out in Section 5.2.

I have not seen a response to the Gen-ART review.

I am ABSTAINing because I don't see publication value for this document given that the architecture and the information model are already done (or at least in an advanced state).  I understand the interest of the WG to document the requirements as an RFC, so I won't stand in the way of publication.

Having said that, if the original intent was for this document to be used as input for the development of the architecture, consider updating some of the text so that there's no mix of "timing": the text should probably read as if the architecture/information model don't exist yet; there are no references to them (which is good), but the text makes some mention of them... For example:

Section 2 (Requirements) says that it "describes the requirements used by SACM to assess and compare candidate data models, interfaces, and protocols, to suit the SACM architecture."  I'm guessing that "will be used", and that "by SACM" refers to the WG (SACM by itself is used extensively throughout).  Note that the end says "to suit the architecture", which sounds like the architecture is a foregone conclusion and the requirements are just for the rest.

Also in Section 2: "SACM defines an architecture and information model focused on addressing the needs for determining, sharing, and using posture information via Posture Information Providers and Posture Information Consumers mediated by a Controller."  I didn't check, but this sounds like a quick description of the architecture and information model -- both of which would be developed based on this document.

Hi Nancy,
> Hi Benoit,
> Thanks for the review and feedback.  Please see further comments below:
>
> On 6/21/17, 4:00 AM, "Benoit Claise (bclaise)" <bclaise@cisco.com> wrote:    
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     
>     -     3.  The information model MUST accommodate the interoperable
>             addition of new data types and/or schemas.
>     
>     I guess that you want to say: The data model MUST ...
>     See RFC 3444
> [NCW] The group actually debated “information model” vs “data model” extensively and
> decided on this language.
>     
>     -
>     Reading G-003, G-004, G-012, it seems like you want to be able to select your
>     "transport", with your own requirements.
>
>     However, I guess that, practically, you'll select a data model and the
>     transport will be obvious. MIB module => UDP IFPIX information elemeents =>
>     UDP/DTLS. Yeah, the specs say SCTP/TCP, but in practice ... YANG module, either
>     NETCONF => TCP/SSH or RESTCONF => HTTPS Not sure I believe into a single
>     transport to rules them all, where "them" is all the different data model
>     source of information. This was already my feedback during your previous
>     interim meeting (where I presented yangcatalog.org): your information model
>     draft is basically of a mix of elements already specified in IPFIX, YANG
>     module, MIB module. How do you consolidate all this?
> [NCW] There will be data models that are only suitable for specific transfer models
> and specific transport layers (ROLIE for example as a discovery lends itself better at
> an HTTP and not so much in MIB).  The Information model is meant to be a “raw”
> definition of elements/attributes that can them be mapped into specific data models
> (the group for instance is looking at SWID, others are looking at netconf) etc….
>     
>     Same remark with "2.5 requirements for data model operations".
>     You select your data model and the data model operations are given/specified
>     already Let's say: IPFIX. From there you have a push mechanism only (as opposed
>     to pull). Let's say: YANG module. From there you select NETCONF or NETCONF, and
>     the operations are already specified.
> [NCW] In essence, that is correct.
>     
>     -
>      The SACM information model MUST include the
>         ability to discover and negotiate the use of a particular data model
>         or any data model.
>     
>     What does it mean "negotiate"?
>     Either an end point supports a data model or it doesn't, no?
>
>     Same remark for:
>        DM-007  Data Model Negotiation: The interfaces and actions in the
>         data model MUST include capability negotiation to enable discovery
>         of supported and available data types and schemas.
> [NCW] In this context, “Negotiate” is the means by which two parties can agree on the data model to be used.
> The “means” could be data model and/or transfer protocol specific….but the intent is to enable that thru
> The abstraction to allow for that should be in the Information model definition.

>
>
>     
>     - Read the following one multiple times, and I still don't understand it:
>        IM-005  Data Lifetime Management: The information model MUST provide
>         a means to allow data models to include data lifetime management.
> [NCW] It is really meant to be a means by which the consumer of the information can know when that data may be obsoleted (updated, changed or removed).
What about trying to make the text clear(er)?
>
>     
>     -
>     The SACM information model represents an abstraction for "what"
>        information can be communicated and "how" it is to be represented and
>        shared.
>     
>     Not sure it's aligned with RFC3444:
>                   IM                --> conceptual/abstract model
>                   |                    for designers and operators
>        +----------+---------+
>        |          |         |
>        DM        DM         DM     --> concrete/detailed model
>                                        for implementors
>
> [NCW] We really have tried….if it isn’t clear, I am open to making it more so but
> the resulting draft and definitions come from much debate and final agreement from the WG.

What I considered to be an easy COMMENT turned out more complicated that I thought. I guess that we'll agree to disagree.
I don't feel that this data model/information model discussion will be resolved to my OPS-view satisfaction.
I can't support this document publication and I don't want to spend energy to try to convince people for this COMMENT
Since I don't want to be in the way, I'll ABSTAIN.

Regards, Benoit

I abstain because I don’t think there is a achievable value in publishing this document in the RFC series (for consumption outside the wg). However, I also don’t understand why there is a requirement to support multiple transport protocols, including potentially UDP. I don’t think this is worth a discuss on this document but if SACM plans to invent a new transport (over UDP) instead of just using TCP which seems more than appropriate, it needs a real justification for that (which is at least in this document not at all given)!

I do see the value of writing up the requirements to guide further work in the WG, but I do not see that value of publishing them in a standalone RFC. I would have much preferred the requirements to be included in the other WG deliverables (as Alvaro and Terry have noted). I do respect the WG's intent to publish and I am abstaining to move out of the way.

I am balloting ABSTAIN on this document as I don't see strong value in a set of requirements as a standalone document added to the RFC series. I appreciate it's an extension of the use-cases document and a WG milestone but it reads like the architecture and info model is already done (and indeed WG revisions of that work look mature). In which case I STRONGLY urge that the 10 pages of requirements be placed (as required) in appendices of the milestone documents (information-model, data-model, protocol/Interface, architecture etc). This maintains the rationale for the designs in question and aids the reader in comprehension of the work.

That said, with ABSTAIN positions, I am not blocking publication of this document and I shall leave it to the responsible AD to adjudicate.