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

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

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