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

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

Hi Susan,

Yes, I am aware of the below work. https://tools.ietf.org/html/draft-reddy-dots-signal-channel-08 uses CoAP Observe option to receive unsolicited notifications on the mitigation status from the DOTS server. CoAP is also discussed in CORE WG for managing constrained devices (see https://tools.ietf.org/html/draft-ietf-core-comi-00). 

Just like COMI, reddy-dots-signal-channel-8 uses YANG and maps to CBOR to keep the message size small. But there are differences b/w COMI and DOTS signal channel, the latter uses non-confirmable messages for DOTS mitigation request/response.

-Tiru

> -----Original Message-----
> From: Susan Hares [mailto:[e-mail]]
> Sent: Wednesday, February 22, 2017 8:20 PM
> To: 'Clark, Gilbert J. (GRC-LCA0)' <[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?
> 
> 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