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

From: Benoit Claise <[email-masked]>
Date: Wed, 21 Jun 2017 04:00:54 -0700

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

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

-     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

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

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.

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

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

-
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

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 26 Jun 2017 00:20:13 +0000

Hi Benoit,
Thanks for the review and feedback.  Please see further comments below:

On 6/21/17, 4:00 AM, "Benoit Claise (bclaise)" <[email-masked]> wrote:    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

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

    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….
    
[NCW] In essence, that is correct.
    
    -

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

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

---

From: Benoit Claise <[email-masked]>
Date: Tue, 27 Jun 2017 10:57:56 +0200

Hi Nancy,

> [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)?
>                    |                    for designers and operators

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