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

From: "Mortensen, Andrew" <[email-masked]>
Date: Sun, 12 Feb 2017 16:20:05 +0000

The data channel proposed in draft-reddy-dots-data-channel (and previously in draft-reddy-dots-transport) has evolved over the past year from using HTTP and a limited REST API, to a CoAP form of the same, to using RESTCONF in the current revision. That evolution seems in part driven by this thread from November:

<https://mailarchive.ietf.org/arch/search/?email_list=dots&index=cvB-XEkY-gjEWPRBKmIm0bu_6iw&gbt=1>

 It seems to me in particular this exchange seems to be the catalyst for the current choice of RESTCONF:

“So, if your CBOR was derived from a YANG model, you’d be doing exactly NETCONF, btw.

<https://mailarchive.ietf.org/arch/msg/dots/AfhhDdhAPvkGyUumx6SB4Tbyi4g>

A number of contributors to the thread raised objections to using NETCONF/RESTCONF. The concerns, as I read them, are mostly about using NETCONF/RESTCONF as the protocol for the signal channel, but that may be because I’ve also proposed using RESTCONF for the data channel in the past. [1]

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 of RESTCONF for the data channel? One concern apparent in the discussion coinciding with the meeting in Seoul was added complexity, but I’m having a hard time discerning whether that concern applies to the signal channel, data channel, or both.

andrew

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 13 Feb 2017 23:05:00 -0500

On 2/12/17 11:20 AM, Mortensen, Andrew wrote:
> The data channel proposed in draft-reddy-dots-data-channel (and 
> previously in draft-reddy-dots-transport) has evolved over the past 
> year from using HTTP and a limited REST API, to a CoAP form of the 
> same, to using RESTCONF in the current revision. That evolution seems 
> in part driven by this thread from November:
>
> A number of contributors to the thread raised objections to using 
> NETCONF/RESTCONF. The concerns, as I read them, are mostly about using 
> NETCONF/RESTCONF as the protocol for the signal channel, but that may 
> be because I’ve also proposed using RESTCONF for the data channel in 
> the past. [1]
>
> 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 of RESTCONF for the data channel? 
> One concern apparent in the discussion coinciding with the meeting in 
> Seoul was added complexity, but I’m having a hard time discerning 
> whether that concern applies to the signal channel, data channel, or both.
>
Me too, however I suggest we focus the RESTCONF discussion on the data 
channel for now.

Thanks

-- Flemming

> andrew
>
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Wed, 15 Feb 2017 14:51:25 +0000

> 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

---

From: "Clark, Gilbert J. (GRC-LCA0)" <[email-masked]>
Date: Wed, 22 Feb 2017 05:56:11 +0000

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 [[email-masked]] on behalf of Roman D. Danyliw [[email-masked]]
Sent: Wednesday, February 15, 2017 9:51 AM
To: Mortensen, Andrew; [email-masked]
Subject: Re: [Dots] use of restconf for the data channel?

Roman

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 22 Feb 2017 07:17:50 +0000

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:[email-masked]] On Behalf Of Clark, Gilbert J. (GRC-
> LCA0)
> Sent: Wednesday, February 22, 2017 11:26 AM
> To: Roman D. Danyliw <[email-masked]>; Mortensen, Andrew
> <[email-masked]>; [email-masked]
> 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.
> 
> > 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
>

---

From: "Clark, Gilbert J. (GRC-LCA0)" <[email-masked]>
Date: Wed, 22 Feb 2017 13:16:21 +0000

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) [[email-masked]]
Sent: Wednesday, February 22, 2017 2:17 AM
To: Clark, Gilbert J. (GRC-LCA0); Roman D. Danyliw; Mortensen, Andrew; [email-masked]
Subject: RE: use of restconf for the data channel?

-Tiru

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 22 Feb 2017 08:54:34 -0500

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:[email-masked]] 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;
[email-masked]
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 :)

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

To: Clark, Gilbert J. (GRC-LCA0); Roman D. Danyliw; Mortensen, Andrew;
[email-masked]

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

> My strongest objection to both NETCONF and RESTCONF were in the 
> context of their consideration for use in the signal channel.
>
> 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.
>
> (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.
>
> 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.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 22 Feb 2017 09:50:24 -0500

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:[email-masked]] 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'; [email-masked]
Subject: Re: [Dots] use of restconf for the data channel?

Gilbert: 

Content  --   data models 

Content  --   data models 

Sue Hares 

-----Original Message-----

Cheers,
Gilbert

-Tiru

> I wouldn't personally vote to see NETCONF, specifically, used in 
> either
channel.
conversation.

---

From: "Teague, Nik" <[email-masked]>
Date: Wed, 22 Feb 2017 15:06:07 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    Sue Hares 
    
    -----Original Message-----
    From: Dots [mailto:[email-masked]] 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'; [email-masked]
    Subject: Re: [Dots] use of restconf for the data channel?
    
    Gilbert: 

    
    
    Content  --   data models 

    
    
    Content  --   data models 

    
    Sue Hares 
    
    -----Original Message-----
    From: Dots [mailto:[email-masked]] 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;
    [email-masked]
    Subject: Re: [Dots] use of restconf for the data channel?

    

    
    Cheers,
    Gilbert

    
    -Tiru
    
    channel.
    conversation.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 22 Feb 2017 10:53:06 -0500

Nik: 

This second message was to inform you of upcoming changes in NETCONF and NETMOD work. 

Here's the take away: 

1) NETMOD's revision of data store design allows Yang support for control plane protocols (E.g. DOTS signal), and the traditional configuration (E.g. NETCONF/RESTCONF configuration for the DOTS bulk protocol) 

2) Events and publication/subscription functionality in NETCONF/NETMO is something you should review - ODL has open-source code
3) Other control plane protocols (E.g. I2RS or I2NSF) will want to use CoAP below the event stream with minimal additional layers 
    Perhaps working with them will help you determine what is common and what is unique to DOTS signaling channels. 

Sue 

-----Original Message-----
From: Teague, Nik [mailto:[email-masked]] 
Sent: Wednesday, February 22, 2017 10:06 AM
To: Susan Hares; 'Clark, Gilbert J. (GRC-LCA0)'; 'Tirumaleswar Reddy (tireddy)'; 'Roman D. Danyliw'; 'Mortensen, Andrew'; [email-masked]
Subject: Re: [Dots] use of restconf for the data channel?

Sue hi,

Thanks,

-Nik

    

    

    Sue Hares 
    
    -----Original Message-----
    From: Dots [mailto:[email-masked]] 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'; [email-masked]
    Subject: Re: [Dots] use of restconf for the data channel?
    
    Gilbert: 

    
    
    Content  --   data models 

    
    
    Content  --   data models 

    
    Sue Hares 
    
    -----Original Message-----
    From: Dots [mailto:[email-masked]] 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;
    [email-masked]
    Subject: Re: [Dots] use of restconf for the data channel?

    

    
    Cheers,
    Gilbert

    
    -Tiru
    
    channel.
    conversation.

---

From: "Clark, Gilbert J. (GRC-LCA0)" <[email-masked]>
Date: Wed, 22 Feb 2017 16:10:21 +0000

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 [[email-masked]]
Sent: Wednesday, February 22, 2017 10:06 AM
To: Susan Hares; Clark, Gilbert J. (GRC-LCA0); 'Tirumaleswar Reddy (tireddy)'; 'Roman D. Danyliw'; 'Mortensen, Andrew'; [email-masked]
Subject: Re:  [Dots] use of restconf for the data channel?

Sue hi,

Thanks,

-Nik

    Sue Hares

    -----Original Message-----
    From: Dots [mailto:[email-masked]] 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'; [email-masked]
    Subject: Re: [Dots] use of restconf for the data channel?

    Gilbert:

    Content  --   data models

    Content  --   data models

    Sue Hares

    -----Original Message-----
    From: Dots [mailto:[email-masked]] 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;
    [email-masked]
    Subject: Re: [Dots] use of restconf for the data channel?

    Cheers,
    Gilbert

    -Tiru

    channel.
    conversation.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 23 Feb 2017 03:40:46 +0000

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

> From: Clark, Gilbert J. (GRC-LCA0) [mailto:[email-masked]]
> Sent: Wednesday, February 22, 2017 9:40 PM
> To: Teague, Nik <[email-masked]>; Susan Hares <[email-masked]>;
> Tirumaleswar Reddy (tireddy) <[email-masked]>; 'Roman D. Danyliw'
> <[email-masked]>; 'Mortensen, Andrew' <[email-masked]>;
> [email-masked]
> Subject: RE: [Dots] use of restconf for the data channel?
> 
> Hi:
> 
> 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
> To: Susan Hares; Clark, Gilbert J. (GRC-LCA0); 'Tirumaleswar Reddy (tireddy)';
> 'Roman D. Danyliw'; 'Mortensen, Andrew'; [email-masked]
> On 22/02/2017, 14:50, "Dots on behalf of Susan Hares" <dots-
> [email-masked] on behalf of [email-masked]> wrote:
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 23 Feb 2017 03:58:54 +0000

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

> From: Susan Hares [mailto:[email-masked]]
> Sent: Wednesday, February 22, 2017 8:20 PM
> To: 'Clark, Gilbert J. (GRC-LCA0)' <[email-masked]>; Tirumaleswar
> Reddy (tireddy) <[email-masked]>; 'Roman D. Danyliw' <[email-masked]>;
> 'Mortensen, Andrew' <[email-masked]>; [email-masked]
> 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 +
> 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.
> 
> 
> transmission.  Mitigation request/signaling requires status updates at period
> intervals which could use the publication/subscription channel that
> To: 'Clark, Gilbert J. (GRC-LCA0)'; 'Tirumaleswar Reddy (tireddy)'; 'Roman D.
> Danyliw'; 'Mortensen, Andrew'; [email-masked]
> 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.
> 
>                                 + new Event and publication/subscription streams
> information
> 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
> As I will rapidly turn around a draft to answer your questions, please let me
> know exactly what your concerns are.
> 
>                                 + new Event and publication/subscription streams
> information
> 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 :)
> 
> 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
>