Subject: [sacm] Alexey Melnikov's No Objection on draft-ietf-sacm-requirements-16: (with COMMENT)

From: Alexey Melnikov <[email-masked]>
Date: Thu, 22 Jun 2017 03:40:18 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-sacm-requirements-16: No Objection

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/

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

I generally dislike "requirements" documents, as most WG are not going to check
final protocol against requirements. However I can see that such documents can
be sometimes useful.

I have some specific comments on Section 2.6. It generally looks very confused
on transport protocol versa transfer protocol, which I don't think are synonyms:

2.6.  Requirements for SACM Transport Protocols

I think you meant "Transfer Protocol" in the section title, as my understanding
that "SACM transfer protocol" != "SACM transport protocol"?

   The term SACM transfer protocol is intended to be distinguished from
   underlying layer 3 and 4 protocols such as TCP/IP, operating at an
   equivalent level as the hyperText transfer protocol (HTTP).  The SACM
   transfer protocol is focused on moving data and performing necessary
   access control operations; it is agnostic to the data model
   operations.

   The requirements for SACM transport protocols include:

Again, do you mean "transfer protocol" here?

(snip)

   T-003  Data Confidentiality: SACM transfer protocols MUST be able to
    support data confidentiality.  SACM transport protocols MUST ensure

Do you really mean "transport protocol" above? This will rule out both TCP and
UDP.

    data protection for data in transit (e.g. by encryption) to provide
    confidentiality, integrity, and robustness against protocol-based
    attacks.  Note that while the transport MUST be able to support data
    confidentiality, implementations MAY provide a configuration option
    that enables and disables confidentiality in deployments.
    Protection for data at rest is not in scope for transport protocols.

Again, "transfer protocols"?

    Data protection MAY be used for both privacy and non-privacy
    scenarios.