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

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 20 Jul 2017 04:45:02 -0400

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)
<[email-masked]> wrote:
> Thanks for resending Ben!  Some comments and responses below:
>
> On 6/26/17, 8:37 AM, "Ben Campbell" <[email-masked]> 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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Jul 2017 13:53:37 +0200

I will take a look,

Thanks!

Ben.

> On Jul 20, 2017, at 10:45 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Ben,
>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Jul 2017 09:59:41 +0200

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) <[email-masked]> wrote:
> 

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?

[…]

>    ———————————————————————————————————
> 

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

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

[…]

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

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

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

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 24 Jul 2017 21:53:05 +0000

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" <[email-masked]> wrote:

    Ben.

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

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

    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.

    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.”
    
    […]
    
    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.
[NCW] Fair point!  I can renumber the sequence to add this one as ARCH-001

---

From: Ben Campbell <[email-masked]>
Date: Mon, 24 Jul 2017 17:50:41 -0500

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) <[email-masked]> wrote:
> 
> Hi Ben,

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.

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

> [NCW] Perhaps we can make it lowercase given that it should be a requirement just hard to enforce/determine.

That would work for me.

>              required to be used in all cases.

That works for me.

> [NCW] That’s fine, I can change the first MUST to lowercase.

Okay.

> [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 invisi…

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

[…]

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 27 Jul 2017 20:41:18 +0000

Hi Ben,

Apologies for the delays, catching up on emails again.  Reciprocating and cutting to relevant points to discuss below:

On 7/24/17, 3:50 PM, "Ben Campbell" <[email-masked]> wrote:

    
    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.
[NCW] Ah, got it.  While I am not sure how it can be a MUST requirement, I can try to add a SHOULD. How about we add a requirement that reads:
  “T-006 Transfer Protocol adoption: SACM SHOULD where possible, leverage and use existing IETF transfer protocols versus defining new ones.  For example,  where YANG [RFC6020] is used as a data model and a REST interface is desired, RESTCONF [RFC8040] MUST be used.”

    Would it capture the idea to say that SACM must allow for both standardized and proprietary extensions? (leaving out any mention of non-compliance).
[NCW] Yes, that works as well….I can make that adjustment.

    
    "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."
[NCW] That works as well….I can make that adjustment.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 31 Jul 2017 16:06:26 -0500

Hi, comments inline, etc.

Thanks!

Ben.

> On Jul 27, 2017, at 3:41 PM, Nancy Cam-Winget (ncamwing) <[email-masked]> wrote:

[…]

>  “T-006 Transfer Protocol adoption: SACM SHOULD where possible, leverage and use existing IETF transfer protocols versus defining new ones.  For example,  where YANG [RFC6020] is used as a data mod…

That language is in the right track.   I don’t think the example in the second adds much information, and may cause confusion. If you want to keep it, I don’t think it should use a 2119 keyword (MUST or otherwise), since it’s an example to help clarify the requirement, not a requirement in itself.  I’d also suggest weakening the “where possible” to “where reasonably possible”.

So, here’s an alternative suggestion:

"SACM SHOULD, where reasonably possible, leverage and use existing IETF transfer protocols versus defining new ones.”

[…]

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 31 Jul 2017 21:36:45 +0000

Hi Ben,
I’m good with that….I think that resolves our last banter, so I will go ahead and rev the draft.
Many thanks!  
   Nancy

On 7/31/17, 2:06 PM, "Ben Campbell" <[email-masked]> wrote:

    Thanks!
    
    Ben.

    […]

    

    […]