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

[Kathleen Moriarty <[e-mail]>]

Hi Ben,

Could you take a look through the response and updated draft to help
guide the editors/WG toward resolving your concerns?

Thank you,
Kathleen

On Tue, Jun 27, 2017 at 2:06 PM, Nancy Cam-Winget (ncamwing)
<[e-mail]> wrote:
> Thanks for resending Ben!  Some comments and responses below:
>
> On 6/26/17, 8:37 AM, "Ben Campbell" <[e-mail]> wrote:
>     ----------------------------------------------------------------------
>     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".)
> [NCW] “Whenever reasonable and possible” imho is subjective, while we discussed
> existing data models and protocols such as OVAL, IF-MAP, IODEF, YANG,
> etc.  The group concluded that it was best to include the phrase rather than call
> out the ones raised in the group as new ones have arisen (e.g. leveraging SWID
> and I think there is one to potentially use ROLIE).
>
> There was also inconsistancies and ambiguities to the use of “transfer” vs “transport”
> In the requirements draft, for which the intent is to define “transfer protocols”
> Potentially reusing existing ones.
>
>
>     ----------------------------------------------------------------------
>     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.
> [NCW] Noted.  As a requirements draft, 2119 is not applicable and I’ve made updates
> to address that (e.g. the intent behind the use of MUST as a requirement vs. SHOULD
> as a recommended feature/capability).
>
>     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.
> [NCW] Clarifying language usage that is not 2119 should help.
>
>     - 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.
> [NCW] Good suggestions. Yes, the numbering is meant to be used by the upcoming proposals to use
> as describing how each of the proposals meet (or not) the specific requirements enumerated
> in the draft.  I will add such a note in the draft.
>
>     - 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.
> [NCW] I would expect proprietary extensions to not be interoperable, but
> the SACM elements to be compliant (I think this is true, for example of RADIUS
> and the RADIUS defined AVPs enabling interop between implementations vs proprietary ones).
>
>
>     - G-002: This is the whole point of IETF processes. It seems odd to state it as
>     a requirement.
> [NCW] The WG agreed to its inclusions…
>
>     - g-003: It seems like you are using "datagram" in an unconventional way. A
>     definition would help.
> [NCW] I’ve changed “datagram” to “message” per Eric’s suggestion.
>
>     - g-004: "...MUST be suitably specified..." is vague and unverifiable.
> [NCW] Can you provide an alternate suggestion?  It is meant to leave room
> to allow for different implementations to describe their flexibility or suitability
> in different deployments so I can see the conclusion that it is vague.
>
>     - G-005: "For interoperability and
>         scope boundary,"
>     I don't understand what "scope boundary" means in that clause.
> [NCW] It is meant “within the SACM scope”.
>
>     - 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.)
> [NCW] It is somewhat open as some mechanisms would rely on the underlying
> transport (or transfer) security….and you are right, as it is both integrity and
> confidentiality, I will change the requirement to be “Data Protection:.
>
>     - G-015: "... accommodate considerations such as geographic,
>         regulatory, operational and federations..." seems vague for use with a MUST.
> [NCW]  The MUST goes to enabling different attributes to drive access control,
> the exemplar list is only meant to be a short list and not hard requirements but
> rather that the access control consider multiple attributes.
>
>     - 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?
> [NCW] Yes, which is why it is a SHOULD….that is a consumer may not care or, to your
> point, want to know the nature of the data source (and provenance).
>
>     - 2.6: The section switches between saying "transport protocols" and "transfer
>     protocols" Please be consistent.
> [NCW] Thanks, yes….I’ve made the global update to “transfer” vs “transport”
>
>     - 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.
> [NCW] I’ve added an example with citations of where multiple transports may be applicable
>  when using NEA.
>
>
>
>



-- 

Best regards,
Kathleen