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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Gilbert,

RESTCONF provides a simplified interface and only supports a subset of the capabilities provided by NETCONF. 
DOTS data channel does not need all the functionality of RESTCONF only a subset of it, please
see https://tools.ietf.org/html/draft-reddy-dots-data-channel-04 for more details.

As you may already know, the REST-like API provided by RESTCONF is not intended to replace NETCONF, but rather provide a 
simplified interface, thereby meeting a need of application developers.

I will add more details to the draft to discuss the reasons behind using RESTCONF.

-Tiru


> -----Original Message-----
> From: Clark, Gilbert J. (GRC-LCA0) [mailto:[e-mail]]
> Sent: Wednesday, February 22, 2017 9:40 PM
> To: Teague, Nik <[e-mail]>; Susan Hares <[e-mail]>;
> Tirumaleswar Reddy (tireddy) <[e-mail]>; 'Roman D. Danyliw'
> <[e-mail]>; 'Mortensen, Andrew' <[e-mail]>;
> [e-mail]
> Subject: RE: [Dots] use of restconf for the data channel?
> 
> Hi:
> 
> Just as an addendum, I unfortunately can't make the meeting.
> 
> I don't notice a notable distinction between RESTCONF and NETCONF in this
> discussion thus far, which I find to be concerning to an extent.  The two are
> not the same, and should therefore be considered separately based on the
> merits and suitability of each.  I also think that upcoming features in NETCONF
> is really orthogonal to the conversation here: I'm sure NETCONF has a number
> of features that could possibly be useful.  Instead, my question is whether
> NETCONF's implementation, configuration, and runtime complexity justify its
> use.
> 
> Also: revisiting the idea of using RESTCONF and / or NETCONF in the signaling
> channel should really be a separate conversation, in my opinion.
> 
> I would also point out that the WG in general isn't going to be the primary
> audience for a generalized DDoS solution.  Instead, the challenge will be
> twofold:
> 
> * Convincing vendors that it's worth their while to implement what's
> developed here as part of a generalized DDoS mitigation strategy.  If people
> don't like it, they'll go standardize their own ... and while two generalized
> DDoS mitigation protocols would still probably be an improvement to what
> exists today, I also doubt that such would be the ideal outcome in the case of
> DOTS.
> 
> * Convincing operators that it's worth their while to use what the vendors
> have developed.  NETCONF has a unique set of connotations for the operators
> I know (which are not necessarily always entirely positive), which means that
> including it as a requirement for DOTS could immediately alienate anyone who
> doesn't like NETCONF.  RESTCONF sounds close enough to NETCONF that it
> would, in all likelihood, have a similar effect.  The way these things are named
> might also beg the question of why a configuration protocol is a good choice
> for something billed as a data channel, which seems like it could be a point of
> confusion to those reading through the specification.
> 
> With this in mind, minimizing both implementation / configuration complexity
> and runtime requirements strike me as essential, especially for the signaling
> aspects of the protocol.  I'd be concerned with NETCONF, in particular,
> because it has a few elements that can make it tricky to implement
> (configuration locking, transaction support, an ability to parse XML, stuff like
> that) and can lead to relatively high runtime requirements (for some definition
> of relatively high).  To my understanding, RESTCONF relaxes many of these
> requirements, and operates in a manner that is widely understood, so it seems
> like a better choice to me than NETCONF does.    It does, however, still require
> the folks implementing the draft to first understand RESTCONF before they
> can implement DOTS, which will add additional implementation cost to the
> vendor writing the implementation, and could *possibly* make things more
> difficult for the operators to both initially configure the system and
> troubleshoot issues when they come up.
> 
> Really though, all I'm suggesting here is a little text to the data channel draft in
> order to make the RESTCONF decision appear to be a little less arbitrary than I
> perceive it to be at the moment.  Whether or not the authors agree and
> choose to add said text is, of course, entirely up to them :)
> 
> Cheers,
> Gilbert
> ________________________________________
> From: Teague, Nik [[e-mail]]
> Sent: Wednesday, February 22, 2017 10:06 AM
> To: Susan Hares; 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?
> 
> 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" <dots-
> [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
>