Re: [Dots] use of restconf for the data channel?

["Teague, Nik" <[e-mail]>]

Sue hi,

Are you detailing this still in the context of the DOTS data channel?  You mention DOTS signaling

Thanks,

-Nik

On 22/02/2017, 14:50, "Dots on behalf of Susan Hares" <[e-mail] on behalf of [e-mail]> wrote:

    Gilbert and Tirumaleswar: 
    
    Here are a few advanced on NETCONF/RESTCONF stack related to upcoming
    changes. 
    
    ----------------------------------------------------------------------------
    ------------
    Content (data models) ---> data stores (config, control plane, dynamic
    configuration) 
    ----------------------------------------------------------------------------
    --------------
    Operations: NETCONF, RESTCONF 
       config + events + pub/sub 
      Upcoming  operations:  control plane state +  dynamic config (dhcp)  
    ----------------------------------------------------------------------------
    ---------------
    CoAP (proposed for light-weight config/events, or streams) 
    ---------------
    |TLS| DLTS |
    --------------
    |TCP|UDP |
    --------------
    | IP            |
    ---------------
    
    The NETCONF/RESTCONF events are NETCONF and NETMOD Working Documents.  The
    signaling of events or publication streams may range from light weight (I'm
    here, I'm attacked) to large streams.  The  events +
    publication/subscription streams requirements come from I2RS work which
    desires these to be used for configuration and for control plane protocols
    such as I2RS protocol.  DOTS signaling could be another control plane
    protocol.  CoAPs does not yet support these events, but it could be added.
    
    
    Why use this?  The event notification and publication/subscription stream
    have many of the same base mechanisms. ID, lifetime, policy-id, sequencing
    numbers, and timeouts plus additional features to tune the level of data
    transmission.  Mitigation request/signaling requires status updates at
    period intervals which could use the publication/subscription channel that
    sends this information to multiple clients.    A binary encoding of the
    event/signal mechanism via CoAP would this efficient. 
    
    One other thing to consider is the mixture of configuration/control plane
    protocols.   The NETMOD revised data stores
    (https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/)
    describes the NETMOD architecture for the mixture of configuration and
    control plane.   The  control plane protocol does not need to follow the
    netconf/restconf operational rules -  but can set their own rules for
    validation of data.   NETMOD plans to support Yang modification for this
    point.
    
    I hope this helps.   We'll talk in a few minutes. 
    
    Sue Hares 
    
    -----Original Message-----
    From: Dots [mailto:[e-mail]] On Behalf Of Susan Hares
    Sent: Wednesday, February 22, 2017 8:55 AM
    To: 'Clark, Gilbert J. (GRC-LCA0)'; 'Tirumaleswar Reddy (tireddy)'; 'Roman
    D. Danyliw'; 'Mortensen, Andrew'; [e-mail]
    Subject: Re: [Dots] use of restconf for the data channel?
    
    Gilbert: 
    
    Can you provide a bit more unpacking of the message here?    NETCONF or
    RESTCONF + Yang data models was the initial suggestion to allow stable
    protocol plus the ability to rapidly change data models that form the
    content of the bulk data channel. I sent a longish message to the list
    around IETF 97 since you have questions, I will reformat this message as an
    internet-draft and send it to the list this week. 
    
    The Data channel requirements are:  reliable transport, data privacy and
    integrity, resource configuration (described in OP-07), data-004 black-white
    list management.  These are the basic design requirements for
    NETCONF/RESTCONF functionality.   The specific resources, black-list, or
    white-list management can be data models.   
    
    There are four parts to NETCONF/RESTCONF protocol: 
    
    Content  --   data models 
    Messaging method  (NETCONF: edit-config, get-config, RESTCONF/ PUT, GET)  
                                    + new Event and publication/subscription
    streams information  
    Messaging protocol (rpc/rpc-reply / secure http)   
    =============
    Secure transport (TLS with X.509 certifications, DTLS + add ons)   
    Transport (TCP or UDP) 
    
    Since all of the requirements for the secure transport are the same (peer
    mutual authentication, message confidentiality, integrity and authenticity,
    and message replay protection are the same as the DOTS requirements.   You
    may wish to change the messaging protocol (rpc/rpc-reply or RESTCONF http)
    to protobufs.  If so, I suggest you make that suggestion to the I2NSF WG
    that will include it in its general changes suggested to NETCONF WG and I2RS
    WG .   The WGs would consider protobufs if there is a real use case.  
    
    If you want to change the message method to edit configuration, what your
    alternative would be?  If you are read, write, or updating you configuration
    or white lists, this is what these protocols are built for.   The yang data
    models are tailored for user-readability.   If you want to change the new
    event publication and subscription,  exactly what do you want to change.
    As I will rapidly turn around a draft to answer your questions, please let
    me know exactly what your concerns are. 
    
    If you are looking for the a secure shim layer, 
    
    Content  --   data models 
    Messaging method  (NETCONF: edit-config, get-config, RESTCONF/ PUT, GET)  
                                    + new Event and publication/subscription
    streams information  
    Messaging protocol (rpc/rpc-reply / secure http) (proposed: protobufs)   
    =============
    Secure session layer (for attack scenarios) 
    Secure transport (TLS with X.509 certifications, DTLS + add ons)   
    Transport (TCP or UDP
    
    Bob Moskowitz and I have proposed one.  If you use this, you may be able to
    utilize a lighter weight upper layer. 
    
    
    Thanks for your comments, 
    
    Sue Hares 
    
    -----Original Message-----
    From: Dots [mailto:[e-mail]] On Behalf Of Clark, Gilbert J.
    (GRC-LCA0)
    Sent: Wednesday, February 22, 2017 8:16 AM
    To: Tirumaleswar Reddy (tireddy); Roman D. Danyliw; Mortensen, Andrew;
    [e-mail]
    Subject: Re: [Dots] use of restconf for the data channel?
    
    Oh, neat: didn't realize RESTCONF graduated to an RFC.  Looks like it was
    pretty recent, but that is still a good thing and does alleviate one of my
    concerns to an extent :)
    
    "But for DOTS data channel RESTCONF is suitable"
    
    Why is RESTCONF suitable for the data channel?  Why was RESTCONF,
    specifically, chosen?  What does it offer that might justify the
    implementation burden that it brings, and would therefore make it a
    compelling choice when compared to just building and documenting a REST
    interface?  If there are reasons to use it that justify the complexity, then
    okay.  I haven't seen these elements documented on the mailing list, though
    (apologies if I missed them?), and I also didn't see them documented
    anywhere in the current draft.  
    
    With this in mind, including text to explain what benefits RESTCONF offers
    and explains *why* its adoption is important to the data channel would go a
    long way to alleviate the concerns I have in this instance :)
    
    I would also point out that the data-channel-04 draft still references the
    restconf draft instead of the RFC [1] - that's something that should
    probably be corrected for a future revision of the draft, if it hasn't
    already.
    
    Cheers,
    Gilbert
    
    [1]    [I-D.ietf-netconf-restconf]
                  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
                  Protocol", draft-ietf-netconf-restconf-18 (work in
                  progress), October 2016.
    ________________________________________
    From: Tirumaleswar Reddy (tireddy) [[e-mail]]
    Sent: Wednesday, February 22, 2017 2:17 AM
    To: Clark, Gilbert J. (GRC-LCA0); Roman D. Danyliw; Mortensen, Andrew;
    [e-mail]
    Subject: RE: use of restconf for the data channel?
    
    NETCONF and RESTCONF are not both suitable for DOTS signal channel.
    But for DOTS data channel RESTCONF is suitable and RESTCONF is already an
    RFC https://tools.ietf.org/html/rfc8040.
    Various products in the market already use RESTCONF (e.g. confd 6.3
    http://www.tail-f.com/management-agent/)
    
    -Tiru
    
    > -----Original Message-----
    > From: Dots [mailto:[e-mail]] On Behalf Of Clark, Gilbert 
    > J. (GRC-
    > LCA0)
    > Sent: Wednesday, February 22, 2017 11:26 AM
    > To: Roman D. Danyliw <[e-mail]>; Mortensen, Andrew 
    > <[e-mail]>; [e-mail]
    > Subject: Re: [Dots] use of restconf for the data channel?
    >
    > Hi:
    >
    > My strongest objection to both NETCONF and RESTCONF were in the 
    > context of their consideration for use in the signal channel.
    >
    > I wouldn't personally vote to see NETCONF, specifically, used in 
    > either
    channel.
    > NETCONF can involve substantial implementation complexity to support 
    > capabilities that, in the case of DOTS, seem to me to be of marginal 
    > utility at best.
    >
    > The use of RESTCONF seems a little more reasonable to me here since 
    > many of those implementation requirements are relaxed.
    >
    > I will note that adoption of RESTCONF will inflict a 100+ page 
    > not-yet-RFC as
    > (additional) required reading for anyone who wishes to implement a 
    > DOTS data channel from scratch.  Also, note that the use of RESTCONF 
    > would introduce a dependency on something that is still in 
    > development, and that therefore most likely hasn't yet been very well 
    > tested and / or may be subject to change.
    >
    > Just offering some clarification on my original opinion(s), for what 
    > that's worth.
    >
    > -Gilbert
    > _________________________________
    > From: Dots [[e-mail]] on behalf of Roman D. Danyliw 
    > [[e-mail]]
    > Sent: Wednesday, February 15, 2017 9:51 AM
    > To: Mortensen, Andrew; [e-mail]
    > Subject: Re: [Dots] use of restconf for the data channel?
    >
    > > Subject: [Dots] use of restconf for the data channel?
    > > [snip]
    > >
    > > Since RESTCONF is now a concrete proposal, it seems worthwhile 
    > > continuing the debate ahead of the interim meeting.  Are there 
    > > specific concerns in the WG regarding the use ...
    >
    > This discussion topic is one we need to resolve.  We can start here on 
    > the list but I'll also add a slot to the interim meeting to continue 
    > the
    conversation.
    >
    > Roman
    >
    > _______________________________________________
    > Dots mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/dots
    >
    > _______________________________________________
    > Dots mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/dots
    
    _______________________________________________
    Dots mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/dots
    
    _______________________________________________
    Dots mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/dots
    
    _______________________________________________
    Dots mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/dots