Subject: [Netconf] yang push drafts

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Apr 2016 21:16:18 +0200 (CEST)

Hi,

I am a bit confused about the discussion on four drafts for yang
push.

In my view, RFC 6241 + 5277 (or 5277bis) defines how the NETCONF
transport works.  There is nothing in the *-push-* suite of drafts
that changes this, right?

Also, draft-ietf-netconf-restconf defines how to transport any YANG
object (data, rpc, notification) over RESTCONF.  Again, nothing in
*-push-* changes this, right?

For HTTP and HTTP2 we need something new, if they are in scope.

The new things that YANG push brings is (1) a new YANG module to
control both dynamic and static subscriptions, in a
transport-independent way, and (2) a way to define trigger expressions
on datastores (and related parameters) for the subscriptions in (1).

Would it make sense to instead split the YANG push document into the
two pieces identified above?

Also, currently there seems to be overlap between YANG push and
5277bis; both define ways to control dynamic and static
subscriptions.  However, 5277bis is NETCONF-specifc but
content-generic, whereas YANG push is transport-generic but
content-specific (can only be used for the data store push
mechanism).

/martin

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 8 Apr 2016 00:00:16 +0000

Hi Martin,

I am not sure what you are proposing - are you proposing one more draft - splitting YANG-Push?

I think we are all in agreement on the "guiding principles" - separation of subscription model from the transports, and separation of the definition of update triggers and what to include in update records from subscriptions to an event stream.  

>From there, I would see one logical way to structure it as follows:

(a) Subscription model for event notifications - create-subscription to an event stream etc.  The subscription model can be defined as a YANG model
(b) Netconf transport for event notifications.  

(a) and (b) are subject to RFC 5277bis, but separable into an RFC 5277bis (a) and (b), if you will, for a clear transport and subscription model separation.  

On top, we have 
(c) YANG-Push - in essence providing a way to define triggers (and a few other things) for a stream of updates that users can subscribe to.  This is in essence again a YANG Model.  The way the updates are streamed/communicated is defined separately, as different transports can be configured.  

Finally, (d) defines another tranport (e.g. HTTP2) in addition to Netconf transport (b). 

On your other comment, you are correct that YANG-Push and RFC 5277bis currently have overlap.  Basically, portions of YANG-Push are being pulled into RFC 5277bis.  We haven't updated YANG-Push since we published RFC5277bis.  The next revision will address that.  

--- Alex 

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Thursday, April 07, 2016 12:16 PM
To: [email-masked]
Subject: [Netconf] yang push drafts

Hi,

I am a bit confused about the discussion on four drafts for yang push.

In my view, RFC 6241 + 5277 (or 5277bis) defines how the NETCONF transport works.  There is nothing in the *-push-* suite of drafts that changes this, right?

Also, draft-ietf-netconf-restconf defines how to transport any YANG object (data, rpc, notification) over RESTCONF.  Again, nothing in
*-push-* changes this, right?

The new things that YANG push brings is (1) a new YANG module to control both dynamic and static subscriptions, in a transport-independent way, and (2) a way to define trigger expressions on datastores (and related parameters) for the subscriptions in (1).

Would it make sense to instead split the YANG push document into the two pieces identified above?

Also, currently there seems to be overlap between YANG push and 5277bis; both define ways to control dynamic and static subscriptions.  However, 5277bis is NETCONF-specifc but content-generic, whereas YANG push is transport-generic but content-specific (can only be used for the data store push mechanism).

/martin

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Apr 2016 08:36:56 +0200 (CEST)

"Alexander Clemm (alex)" <[email-masked]> wrote:
> I think we are all in agreement on the "guiding principles" -
> separation of subscription model from the transports, and separation
> of the definition of update triggers and what to include in update
> records from subscriptions to an event stream.
> 
> (a) Subscription model for event notifications - create-subscription
> to an event stream etc.  The subscription model can be defined as a
> YANG model
> (a) and (b) are subject to RFC 5277bis, but separable into an RFC
> 5277bis (a) and (b), if you will, for a clear transport and
> subscription model separation.

I was thinking that esp. static subscriptions would benfit from having
one single transport-independent model to control them.  Of course,
there would have to be transport-specific stuff there as well,
possibly as augmentations.

Dynamic subscriptions are a bit different; in NETCONF you send an rpc,
in RESTCONF you GET a stream resource.  However, it might be useful to
define the create-subscription / establish-subscription rpcs in such a
way that they _can_ be used by other transports.

> On top, we have 
> (c) YANG-Push - in essence providing a way to define triggers (and a
> few other things) for a stream of updates that users can subscribe to.
> This is in essence again a YANG Model.  The way the updates are
> streamed/communicated is defined separately, as different transports
> can be configured.

For static subscriptions, this results in a nice, layered model.  The
YANG push would augment the generic static susbcription data model,
and everything would "just work" for all transports.

This is nice, b/c if we in the future come up with yet another generic
feature to configure the generation of certain notifications, we can
just do one more augmentation.

But for dynamic subscriptions, it is more difficult, due to the fact
that we have transport-specific ways to start them.  For NETCONF, we
would augemnt create-subscription / establish-subscription, but for
RESTCONF, we'd have to define query paramters in plain text.  This is
not a great model...

/martin

> On your other comment, you are correct that YANG-Push and RFC 5277bis
> currently have overlap.  Basically, portions of YANG-Push are being
> pulled into RFC 5277bis.  We haven't updated YANG-Push since we
> published RFC5277bis.  The next revision will address that.
> 
> --- Alex 
> 
> 
> 5277bis; both define ways to control dynamic and static subscriptions.
> However, 5277bis is NETCONF-specifc but content-generic, whereas YANG
> push is transport-generic but content-specific (can only be used for
> the data store push mechanism).
> 
> 
> 
> /martin
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 11 Apr 2016 16:59:22 +0000

> Martin Bjorklund, April 08, 2016 2:37 AM
> 
> I was thinking that esp. static subscriptions would benfit from having one single
> transport-independent model to control them.  Of course, there would have to
> be transport-specific stuff there as well, possibly as augmentations.
> 
> Dynamic subscriptions are a bit different; in NETCONF you send an rpc, in
> RESTCONF you GET a stream resource.  However, it might be useful to define
> the create-subscription / establish-subscription rpcs in such a way that they
> _can_ be used by other transports.

Agree.  This should be made easier via the separation of the YANG Push and Notification drafts from the transport drafts.

> For static subscriptions, this results in a nice, layered model.  The YANG push
> would augment the generic static susbcription data model, and everything
> would "just work" for all transports.
> 
> This is nice, b/c if we in the future come up with yet another generic feature to
> configure the generation of certain notifications, we can just do one more
> augmentation.
> 
> But for dynamic subscriptions, it is more difficult, due to the fact that we have
> transport-specific ways to start them.  For NETCONF, we would augemnt
> create-subscription / establish-subscription, but for RESTCONF, we'd have to
> define query paramters in plain text.  This is not a great model...

This variation is one of the reasons we believe transport specific drafts are the way to go.   

As RESTCONF is over TLS, the query parameters here at least will be secure.   Beyond that, it would seem to me that parameter passing is a general RESTCONF consideration rather than something specific to Push subscription establishment.  Am I missing something?

Eric