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

[Kathleen Moriarty <[e-mail]>]

Thank you, both!

On Tue, Aug 1, 2017 at 10:52 AM, Ben Campbell <[e-mail]> wrote:
> Thanks! I will clear my DISCUSS.
>
> Ben.
>
>> On Jul 31, 2017, at 4:36 PM, Nancy Cam-Winget (ncamwing) <[e-mail]> wrote:
>>
>> 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" <[e-mail]> wrote:
>>
>>    Hi, comments inline, etc.
>>
>>    Thanks!
>>
>>    Ben.
>>
>>> On Jul 27, 2017, at 3:41 PM, Nancy Cam-Winget (ncamwing) <[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.”
>>
>>    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.”
>>
>>    […]
>>
>>
>>
>



-- 

Best regards,
Kathleen