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

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

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" <[e-mail]> wrote:

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