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

[Ben Campbell <[e-mail]>]

Thank; see inline. As before, I’ve deleted sections that do not seem to need further discussion.

> On Jul 24, 2017, at 4:53 PM, Nancy Cam-Winget (ncamwing) <[e-mail]> wrote:
> 
> Hi Ben,
> See my hopefully more clear responses below…also, please let me know if you are amenable to the suggested updates so that I can do another revision (would rather wait in case you suggest more changes….) -Thanks	
> 
> On 7/21/17, 12:59 AM, "Ben Campbell" <[e-mail]> wrote:
> 
>    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?
> [NCW] My response was to suggest that no change was needed as the group could not agree to a “preferred list” but rather, not cite any in the requirements so as not to preclude other standards.  Also, to your last point, the analysis has not really been completed.  SACM is also in the process of updating its charter and in the new charter, the work defined is going to be more prescriptive to the technologies that will be sought.
> At this point, I don’t think it makes sense to call out preferred mechanisms in the requirements draft as the group is already evaluating applicability of existing ones to consider (some of which were not mentioned at the time the requirements document was evolving and other new ones being developed in other groups @IETF can be candidates).

I think we are talking past each other. I am not asking for this document to call out specific technologies. I am asking for it to contain a requirement to prefer existing IETF technologies over creating new mechanisms from scratch. It doesn’t need to enumerate “preferred” technologies to do that, and such a requirement should still allow the working group to create new mechanisms if no existing mechanism can fulfill the requirements.

> 
>    […]
> 
>>   ----------------------------------------------------------------------
>>   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.
> [NCW] I am open to suggestions to lessen confusion!  Would it improve readability and intent if the sentence were to be removed?

Would it capture the idea to say that SACM must allow for both standardized and proprietary extensions? (leaving out any mention of non-compliance).

> 
>    […]
>>   - 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.
> [NCW] Perhaps we can make it lowercase given that it should be a requirement just hard to enforce/determine.

That would work for me.


> 
>    […]
> 
> 
>>   - 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?
> [NCW] The intent is for the protection to be end to end.  How about an update to read:
>          G-006  Data Protection: To protect the information being shared, SACM
>              components MUST protect the integrity and confidentiality of data in
>              transit (end to end) and data at rest (as information is stored in repositories).  
>              Mechanisms for this protection are unspecified but 
>              should include industry best practices.  These mechanisms are required to be 
>              available (i.e. all data-handling components must support them), but are not 
>              required to be used in all cases.

That works for me.

> 
> 
>> 
>>   - 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.)
> [NCW] That’s fine, I can change the first MUST to lowercase.

Okay.

> 
>> 
>>   - 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.
> [NCW] Suggested change to the last sentence to read: “As a consumer may or may not desire to explicitly know the data source, knowledge of a centralized or decentralized deployment SHOULD be invisible to a consumer.”

I don’t think that helps, as it seems to say suggest that the consumer might want this but you shouldn’t give it to them. How about something like the following:

"The fact that a centralized or decentralized deployment is used SHOULD be invisible to a consumer. However, there may be cases where the producer chooses
  to include that information due to consumer preference."


[…]