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

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

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.