[sacm] Ben Campbell's Discuss on draft-ietf-sacm-requirements-16: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-sacm-requirements-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(Resending because I forgot to hit the "send email" button this first time. No
other change.)

The SACM charter requires the group to " whenever reasonable and possible,
reuse existing protocols, mechanisms, information and data models. " If that is
reflected anywhere in the requirements, I missed it. (which is possible.) In
particular, I think section 2.6 needs to include requirements to favor use of
existing "transfer protocols".  (As written, T-001 seems almost tailored to
counter arguments to "just use HTTP".)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

General:

- I agree with the other abstain positions that the content in this draft
doesn't seem to warrant publication as an RFC. I'm not going to abstain over
it, since I think that sort of discussion should occur at charter or milestone
adoption time.

- I don't think the contents of this draft warrant the use of 2119 keywords.
While I think it reasonable to sometimes use 2119 keywords to add precision and
clarity to requirements on standards work, many of the requirements in this
draft seem vague and hand-wavy. All-caps MUSTs and SHOULDs only serve to give
the appearance of precision and verifiability. I mention a few more glaring
instances in my detailed comments, but those are not exhaustive.

Specifics:

- 1.1, 2nd paragraph: If you stick with using normative keywords, but want to
disclaim lower case versions, please consider switching to the boilerplate from
RFC 8174.

- 2.1 (and rest of document): I assume the requirements numbering scheme means
something. It would be helpful to describe that scheme prior to use.

- g-001: "SACM MUST allow
    implementations to use their own extensions; either proprietary data
    models, protocols or extensions to SACM data models or protocols
    could be used though they are not considered to be SACM compliant."

That seems to say that SACM must allow extensions, but those extensions would
not be considered compliant. That seems like a contradiction. As worded with
the MUST, it seems like it says SACM cannot prevent implementations from doing
non-interoperable things.

- G-002: This is the whole point of IETF processes. It seems odd to state it as
a requirement.

- g-003: It seems like you are using "datagram" in an unconventional way. A
definition would help.

- g-004: "...MUST be suitably specified..." is vague and unverifiable.

- G-005: "For interoperability and
    scope boundary,"
I don't understand what "scope boundary" means in that clause.

- G-006: Is this a requirement for e2e protection? It seems like it is, but the
description is vague. In particular, I cannot tell if the mention of
middleboxes is to say that middleboxes should not be able to read or modify
traffic, or if it is to say that middleboxes may be part of the architecture
and actually need that sort of access. (Also, the requirement title says
"integrity", but the text seems to be about both integrity and confidentiality.)

- G-015: "... accommodate considerations such as geographic,
    regulatory, operational and federations..." seems vague for use with a MUST.

- ARCH-004: "The fact that a centralized or
    decentralized deployment is used SHOULD be invisible to a consumer."
Can you elaborate on why? Might not a consumer want to consider the nature of a
data source?

- 2.6: The section switches between saying "transport protocols" and "transfer
protocols" Please be consistent.

- T-001: I think this needs some elaboration, or a citation to elaboration
somewhere else. Otherwise, it seems like this assertion opens the door for a
lot of complexity and lack of interoperability.