Re: [sacm] Benoit Claise's No Objection on draft-ietf-sacm-requirements-16: (with COMMENT)

[Benoit Claise <[e-mail]>]

Hi Nancy,
> Hi Benoit,
> Thanks for the review and feedback.  Please see further comments below:
>
> On 6/21/17, 4:00 AM, "Benoit Claise (bclaise)" <[e-mail]> wrote:
>      ----------------------------------------------------------------------
>      COMMENT:
>      ----------------------------------------------------------------------
>      
>      -     3.  The information model MUST accommodate the interoperable
>              addition of new data types and/or schemas.
>      
>      I guess that you want to say: The data model MUST ...
>      See RFC 3444
> [NCW] The group actually debated “information model” vs “data model” extensively and
> decided on this language.
>      
>      -
>      Reading G-003, G-004, G-012, it seems like you want to be able to select your
>      "transport", with your own requirements.
>
>      However, I guess that, practically, you'll select a data model and the
>      transport will be obvious. MIB module => UDP IFPIX information elemeents =>
>      UDP/DTLS. Yeah, the specs say SCTP/TCP, but in practice ... YANG module, either
>      NETCONF => TCP/SSH or RESTCONF => HTTPS Not sure I believe into a single
>      transport to rules them all, where "them" is all the different data model
>      source of information. This was already my feedback during your previous
>      interim meeting (where I presented yangcatalog.org): your information model
>      draft is basically of a mix of elements already specified in IPFIX, YANG
>      module, MIB module. How do you consolidate all this?
> [NCW] There will be data models that are only suitable for specific transfer models
> and specific transport layers (ROLIE for example as a discovery lends itself better at
> an HTTP and not so much in MIB).  The Information model is meant to be a “raw”
> definition of elements/attributes that can them be mapped into specific data models
> (the group for instance is looking at SWID, others are looking at netconf) etc….
>      
>      Same remark with "2.5 requirements for data model operations".
>      You select your data model and the data model operations are given/specified
>      already Let's say: IPFIX. From there you have a push mechanism only (as opposed
>      to pull). Let's say: YANG module. From there you select NETCONF or NETCONF, and
>      the operations are already specified.
> [NCW] In essence, that is correct.
>      
>      -
>       The SACM information model MUST include the
>          ability to discover and negotiate the use of a particular data model
>          or any data model.
>      
>      What does it mean "negotiate"?
>      Either an end point supports a data model or it doesn't, no?
>
>      Same remark for:
>         DM-007  Data Model Negotiation: The interfaces and actions in the
>          data model MUST include capability negotiation to enable discovery
>          of supported and available data types and schemas.
> [NCW] In this context, “Negotiate” is the means by which two parties can agree on the data model to be used.
> The “means” could be data model and/or transfer protocol specific….but the intent is to enable that thru
> The abstraction to allow for that should be in the Information model definition.

>
>      
>      - Read the following one multiple times, and I still don't understand it:
>         IM-005  Data Lifetime Management: The information model MUST provide
>          a means to allow data models to include data lifetime management.
> [NCW] It is really meant to be a means by which the consumer of the information can know when that data may be obsoleted (updated, changed or removed).
What about trying to make the text clear(er)?
>      
>      -
>      The SACM information model represents an abstraction for "what"
>         information can be communicated and "how" it is to be represented and
>         shared.
>      
>      Not sure it's aligned with RFC3444:
>                    IM                --> conceptual/abstract model
>                    |                    for designers and operators
>         +----------+---------+
>         |          |         |
>         DM        DM         DM     --> concrete/detailed model
>                                         for implementors
>
> [NCW] We really have tried….if it isn’t clear, I am open to making it more so but
> the resulting draft and definitions come from much debate and final agreement from the WG.

What I considered to be an easy COMMENT turned out more complicated that 
I thought. I guess that we'll agree to disagree.
I don't feel that this data model/information model discussion will be 
resolved to my OPS-view satisfaction.
I can't support this document publication and I don't want to spend 
energy to try to convince people for this COMMENT
Since I don't want to be in the way, I'll ABSTAIN.

Regards, Benoit