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

[Ben Campbell <[e-mail]>]

I will take a look,

Thanks!

Ben.

> On Jul 20, 2017, at 10:45 AM, Kathleen Moriarty <[e-mail]> wrote:
> 
> 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