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

[Benoit Claise <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-sacm-requirements-16: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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