[sacm] Early AD review of draft-ietf-sacm-arch-07

[Roman Danyliw <[e-mail]>]

Hi!

I performed on an early AD review on draft-ietf-sacm-arch-07.  As this is an early review, my feedback and questions are primarily about what is current written in -07, and likely doesn't capture the ongoing WG discussions (and open issues, etc).  I caught a few editorial nits along the way, and documented them here because I happen to notice.

==[ Top level feedback
** It seems very late in the WG lifecycle for an architecture to be published.  What work and who will implement this architecture?  Who is the audience of this document?

** How is the architecture described here related to the one described in draft-ietf-sacm-epcp?

** It wasn't clear if this document is intended to specify architecture/requirements, or also get into protocol details.  I followed the specifics of the high-level architecture in Section 3.  I found parts of Section 4 and 5; and the hints in Section 8 containing getting into the details of what I'd consider the protocol without providing enough details to actually implement the behavior in an interoperable way.  

For a proposed standard, the current text seems underspecified.  As an architecture/requirements document, it would fit better as an informational document.  It might be helpful to be clearer on what is in vs. out of scope.

==[ More detailed feedback
** Section 3.1.  Why aren't there "orchestrator sub-architectures" and "repository sub-architectures" just like the Collection and Evaluation sub-architectures?

** Section 3.1.  How is a "sub-architecture" component different from a component which isn't labeled as a "sub-architecture" (i.e., is "sub-architecture" a special designation)?

** Section 3.2.2.  Why is the notion of repositories abstracted when this architecture seems to only use three - Posture Attribute, Evaluation Results and Policy Repos

** Section 3.3.  Per "Each notional SACM component represents distinct sub-architectures which will exchange information via the integration services, using interactions described in this draft", this sentence didn't make sense to me in the content of explaining "Downstream uses".

** Section 4.*.  Several sections make explicit references to topics (e.g., /orchestrator/registration) where is that topic syntax defined?

** Section 4.2.1.  Per "The Orchestrator MUST have ... unique identifiers", unique to what scope?

** Section 4.2.1.  Per "The Orchestrator MUST support making directed requests to registered components over the component's administrative interface ...", is that interface connected to the integration service?

** Section 4.* Several sections make reference to registering and reading topics.  Where are the properties of this "topic queue" specified?

** Section 5.*.  There appear to be snippet of what looks like machine readable code (i.e., "component-registration-request: ..."), what formal language is that?

** Section 7.
-- What are the expected security properties of the interactions/integration services?

-- Are there any requirements on the authentication/authorization model?

** Scope clarification
-- Is the expectation that the WG would define a data model + protocol for all interactions between all components listed in this architecture?

--  How much of the interface(s) into to the repositories is in scope?

-- Is the "policy feed" in scope?  What is the relationship between the policy feed and orchestrator?

-- How do elements of the architecture discovery themselves?

-- The exact properties and requirements for the integration service aren't clear

==[ Nits
** Abstract.  The abstract contains references, it should not.

** Section 2.  ietf-sacm-terminology is a unpublished, and expired I-D.  This will be a DOWNREF.

** Section 3.2.1.  The discussion of "topic authorization policies" seems abrupt as the notion of subscribing to topics wasn't established yet.

** Section 3.4.1.1.1.  Typo. s/colletion/collection/

** Section 3.4.1.1.  YANG Push needs a reference.

** Section 4.2.  Typo.  s/mangement/Management/

** Section 5.* Typo. s/hearbeat/heartbeat/

** Section 5.4.1.1.  There is inline XML in the value column of the topic row.

** Section 5.4.2.1.1.  There is inline XML markup in the Value column of the topic row.

** Section 9.  Please address the following feedback from idnits:

== Missing Reference: 'TBD' is mentioned on line 1414, but not defined

  == Unused Reference: 'I-D.ietf-sacm-ecp' is defined on line 1435, but no
     explicit reference was found in the text

  == Unused Reference: 'RFC8412' is defined on line 1447, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC8600' is defined on line 1453, but no explicit
     reference was found in the text

  == Unused Reference: 'HACK100' is defined on line 1471, but no explicit
     reference was found in the text

  == Unused Reference: 'HACK101' is defined on line 1475, but no explicit
     reference was found in the text

  == Unused Reference: 'HACK102' is defined on line 1478, but no explicit
     reference was found in the text

  == Unused Reference: 'HACK103' is defined on line 1482, but no explicit
     reference was found in the text

  == Unused Reference: 'HACK104' is defined on line 1485, but no explicit
     reference was found in the text

  == Unused Reference: 'HACK105' is defined on line 1488, but no explicit
     reference was found in the text

  == Unused Reference: 'HACK99' is defined on line 1492, but no explicit
     reference was found in the text

  == Unused Reference: 'NIST800126' is defined on line 1504, but no explicit
     reference was found in the text

  == Unused Reference: 'NISTIR7694' is defined on line 1512, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5023' is defined on line 1518, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC8322' is defined on line 1532, but no explicit
     reference was found in the text

  == Unused Reference: 'XMPPEXT' is defined on line 1537, but no explicit
     reference was found in the text

** Section A.3.1.3.  Typo. s/neeeded/needed/

Regards,
Roman