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

[Ben Campbell <[e-mail]>]

Hi, thanks for the response. Comments inline. I removed text that doesn’t seem to need further discussion.

Ben.

> On Jun 27, 2017, at 8: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).
> 

I’m not sure I understand your response, and I see that version 17 did not add anything to the requirement language. Do you argue that there are no need for requirements to prefer existing mechanisms? I don’t expect a requirement to reuse any particular mechanism by name, but I think these requirements are incomplete without some explicit bias towards existing technologies.

Or you do you mean to argue that the analysis of potential existing technologies has already been completed?

[…]

>    ----------------------------------------------------------------------
>    COMMENT:
>    ———————————————————————————————————
> 

[…]
> 
>    - 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).
> 

So this is probably pedantic, but I’m still confused when you say that something is must be allowed but is not compliant. That seems like a contradiction.

[…]
>    - 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.

I suggest dropping the MUST, since there’s really no real way of determining the requirement has been met.

[…]


>    - 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:.

That doesn’t address my question. Specifically, this requirement says that data must be protected “ … through middleboxes…”. Are those middleboxes expected to be able to read or modify the data, or is the protection intended to ensure that they cannot?


> 
>    - 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.


I have trouble understanding the meaning of the first MUST, since nothing really defines the “considerations” except for the example list. I suggest dropping that MUST and treating the first sentence as explanatory. (I have no objection to the 2nd 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?
> [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).

I suggest a sentence or two to that effect.

[…]

New (non-blocking) Comment: You’ve added a MUST in the first paragraph of 2.2. That seems more like a statement of fact than a requirement. If you intend it as a requirement, it might make sense to add a numbered requirement for it.