Subject: [Netconf] 3 Options for Subscription & Event Notification draft structure

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 20 Dec 2016 15:32:36 +0000

To summarize previous threads, key benefits of 5277bis over RFC 5277 include:

  (1) transport independence

  (2) configured subscriptions

  (3) many subscriptions per transport session

  (4) modify and delete subscription RPCs

  (5) control plane notifications

  (6) data plane notification including subscription-id

  (7) negotiation (see Yves' thread from yesterday)

  (8) control plane reuse with draft-ietf-netconf-yang-push.

Those of us working 5277bis had been planning on supporting existing 5277 implementations via a separate backwards compatibility section.  But as we have gone forward, we see no meaningful technical overlaps.  I.e., there are no RPC or notifications shared between the 5277 and 5277bis solutions.  Any compatibility mode section would be fully standalone.  Considering that people can just refer to 5277 if they need it, and considering 5277 & 5277bis could easily run in parallel on different transport sessions, building a standalone backwards compatibility section seems both confusing and redundant.

This leaves three options:

  (i.) OBSOLETE 5277 by replacing it with 5277bis

  (ii.) Support 5277bis without Obsoleting 5277

  (iii.) Write a new UPDATE draft for 5277 NETCONF only transport

The benefits and issues of each are as follows:

(i.) OBSOLETE 5277 by replacing it with 5277bis

*       Supports all requirements (1) through (8).

*       IETF does not continue protocol maintenance of 5277.

o   Implementations can still choose 5277 or 5277bis, even though IETF recommends 5277bis.

o   Implementations provide backwards compatibility through concurrent, parallel support of both specifications.

o   Although obsoleted, the IETF does not deprecate 5277 so that current implementations may stay with existing 5277.

*       Need to change the NETCONF WG charter to show that 5277 is being replaced rather than enhanced.

(ii.) Support 5277bis without Obsoleting 5277

*       Technically identical to (i).

*       Implementations free to choose 5277 or 5277bis, with no guidance on which the WG recommends.

o   This could be confusing to customers as NETCONF WG will be advocating competing technologies for the place of overlap.  -- i.e., NETCONF over XML with a single subscription.

*       Establishes competing technology futures where one direction would suffice.

(iii.) Write a new UPDATE draft for 5277 NETCONF only transport

*       Supports a subset of requirements:

o   Cannot support (1) or (8)

o   Supporting (2), (3), (4), (5), (6), & (7) possible, but would require the creation of replicated/competing mechanisms with (8).

*       Doubles the development effort if the yang-push control plane is also required.

*       WG would need to build guidelines on when to use 5277bis or this new UPDATE draft (assuming the WG wanted to proceed with the transport independent 5277bis.)

*       No identified author / champion for this path.  (Because business drivers being driven by other than NETCONF/XML.)

*       Update draft itself wouldn't require a NETCONF charter update.

Based on this list, the people working in on the Subscription & Event Notification weekly calls have a preference for (i.) followed by (ii.).  Do you have a preference or additional questions not addressed here or in the earlier threads?

Thanks,

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 21 Dec 2016 11:06:52 +0100 (CET)

>   (8) control plane reuse with draft-ietf-netconf-yang-push.

I will have to assume that when you say "5277bis" you mean
draft-ietf-netconf-rfc5277bis-00.  If this is true, I don't think that
your statement above is correct.  Maybe this is your *plan*, but it is
difficult to comment on...

Also note that RFC 5277 defines how notifications are sent over
NETCONF.  This is by nature protocol-specific, and it must be done.
So the fact that draft-ietf-netconf-rfc5277bis-00 does (1) is a bug,
not a feature, if you want to obsolete RFC 5277.

> Those of us working 5277bis had been planning on supporting existing
> 5277 implementations via a separate backwards compatibility section.
> But as we have gone forward, we see no meaningful technical overlaps.
> I.e., there are no RPC or notifications shared between the 5277 and
> 5277bis solutions.  Any compatibility mode section would be fully
> standalone.  Considering that people can just refer to 5277 if they
> need it, and considering 5277 & 5277bis could easily run in parallel
> on different transport sessions, building a standalone backwards
> compatibility section seems both confusing and redundant.
> 
> 
> 

Maybe, but note that (1) through (8) is not a *complete* list of
requirements.  (And not all items are real requirements, e.g., (6)).
For example, the requirement that we must have a definition for how
notifications are sent over NETCONF is not addressed by
draft-ietf-netconf-rfc5277bis-00.

> o Although obsoleted, the IETF does not deprecate 5277 so that current
> implementations may stay with existing 5277.

I don't get this.  If the spec is obsolete then it is obsolete.

> *       Need to change the NETCONF WG charter to show that 5277 is being
> *       replaced rather than enhanced.
> 
> 
> 
> *       Implementations free to choose 5277 or 5277bis, with no guidance on
> *       which the WG recommends.
> 
> o This could be confusing to customers as NETCONF WG will be
> advocating competing technologies for the place of overlap.  -- i.e.,
> NETCONF over XML with a single subscription.
> 
> *       Establishes competing technology futures where one direction would
> *       suffice.
> 
> 
> 

I'm not sure what you have in mind?  What exactly would this new draft
contain?

> o Supporting (2), (3), (4), (5), (6), & (7) possible, but would
> require the creation of replicated/competing mechanisms with (8).
> 
> *       Doubles the development effort if the yang-push control plane is also
> *       required.
> 
> *       WG would need to build guidelines on when to use 5277bis or this new
> *       UPDATE draft (assuming the WG wanted to proceed with the transport
> *       independent 5277bis.)
> 
> *       No identified author / champion for this path.  (Because business
> *       drivers being driven by other than NETCONF/XML.)
> 
> Based on this list, the people working in on the Subscription & Event
> Notification weekly calls have a preference for (i.) followed by
> (ii.).  Do you have a preference or additional questions not addressed
> here or in the earlier threads?

I think the reasoning goes something like this:

  We need to support multiple subscriptions in a single NETCONF
  session.  This implies that we need a 'subscription-id' field in the
  payload.  The current payload does not contain a 'subscription-id',
  and it is inflexible in the sense that it does not allow us to add
  header fields.

  Thus, we need a new notification payload, which means that we cannot
  simply update RFC 5277 and be backwards compatible.

If this is correct, I think it is fine to obsolete RFC 5277, but not
with the current draft-ietf-netconf-rfc5277bis-00.  Instead, I
propose:

  A. one document that defines, in a protocol-neutral manner, the
     notification architecture, i.e., explains the concepts of
     streams, replay, filters, and subscriptions etc.

  B. one document that defines, in a protocol-neutral manner, how YANG
     notifications are encoded in XML and JSON.  This covers NETCONF
     and RESTCONF (future protocols might reuse this, or they might
     need something else).

  C1. one document that defines how notifications are sent over
     NETCONF.  Specifially, it needs to generalize section 3.7 of RFC
     5277, since it changes the message flow defined in RFC 6241.
     (In the best of worlds, this would be a section in the NETCONF
     protocol spec).

  C2. one document that defines how notifications are sent over
     RESTCONF (this is currently section 6 in
     draft-ietf-netconf-restconf-18, and it needs to be updated)

  D. one document that defines the YANG data model for stream
     detection, subscription mgmt etc.  This is mostly the current
     draft-ietf-netconf-rfc5277bis-00.

Note that RFC 5277 contains A+B+C1+D.

Maybe some of these could be collapsed into one document, e.g. A+B, or
maybe A+B+D.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 21 Dec 2016 17:13:04 +0000

Hi Martin,

Thanks for the thoughts...  

> From: Martin Bjorklund, December 21, 2016 5:07 AM
> I will have to assume that when you say "5277bis" you mean draft-ietf-netconf-
> rfc5277bis-00.  If this is true, I don't think that your statement above is correct.
> Maybe this is your *plan*, but it is difficult to comment on...

current WG draft is -01.  

A working version of -02 is at
https://github.com/netconf-wg/rfc5277bis/blob/master/rfc5277bis-02-v20Dec2016.txt 
But it hasn't been posted yet.
 
> Also note that RFC 5277 defines how notifications are sent over NETCONF.  This
> is by nature protocol-specific, and it must be done.
> So the fact that draft-ietf-netconf-rfc5277bis-00 does (1) is a bug, not a
> feature, if you want to obsolete RFC 5277.

the obsoleting of 5277 is intended to come from a combination of 
draft-ietf-netconf-rfc5277bis & draft-ietf-netconf-netconf-event-notifications

I agree work is needed to get the full coverage across them.

> Maybe, but note that (1) through (8) is not a *complete* list of requirements.

Yes.  (1)-(8) is a summary.

> (And not all items are real requirements, e.g., (6)).

Below you note that we need a 'subscription-id' field in the payload'.  That is what is intended in (6) 

> notifications are sent over NETCONF is not addressed by draft-ietf-netconf-
> rfc5277bis-00.

Payload headers are coming in the next 5277bis version.  Per the last minutes, Andy is thinking about using some TailF stuff as a starting point.   The transport encapsulation for NETCONF will be in draft-ietf-netconf-netconf-event-notifications.  Alberto is awaiting the new notification payload before writing that up.
 
> I don't get this.  If the spec is obsolete then it is obsolete.

Old protocols live in deployments after a doc is obsoleted.  My assumption is that deprecated means we actively provide reasons why people shouldn't use an old spec tp make people convert faster.  Does Obsolete require Deprecate?  I don't know.   I am happy to go with whatever the IETF process uses here.

> I'm not sure what you have in mind?  What exactly would this new draft

I don't find this path interesting, nor do I plan any authorship on this option.  So I am not thinking about it much.  I am not sure if anyone wants (iii.).

> If this is correct,

It is.

> I think it is fine to obsolete RFC 5277, but not with the current
> draft-ietf-netconf-rfc5277bis-00.  Instead, I
> propose:
> 

This is in 5277bis. 

>      and RESTCONF (future protocols might reuse this, or they might

Currently encoding examples are in draft-ietf-netconf-netconf-event-notifications and draft-ietf-netconf-restconf-notif.  Incomplete notification definitions are in 5277bis (as noted above).  But if the WG wishes, we could rearrange things and have a protocol independent encoding document for notifications.  

I believe we should revisit the proper placement of this now as part of our discussion on the structure of the notifications.  
 
>      (In the best of worlds, this would be a section in the NETCONF

draft-ietf-netconf-netconf-event-notifications
 
>      draft-ietf-netconf-restconf-18, and it needs to be updated)

draft-ietf-netconf-restconf-notif, although we recommend HTTP2 for the notifications, and RESTCONF for the dynamic subscription establishment.

>      draft-ietf-netconf-rfc5277bis-00.

Yes
 
> Maybe some of these could be collapsed into one document, e.g. A+B, or

The current document breakdown covers the intents above.  But we could move B to an independent draft if the WG prefers.

Eric

---

From: <[email-masked]>
Date: Wed, 21 Dec 2016 12:33:56 -0800

(resending, not sure my earlier message got through)

Couple of additional thoughts:  
Re: relationship with 5277 to 5277bis version and obsoleting RFC 5277:
- Yes, clearly 5277 defines how notifications are sent over Netconf.  This
aspect is actually covered in
draft-ietf-netconf-netconf-event-notifications.  The scope of RFC 5277 has
been split, in order to distinguish the transport independent and transport
dependent aspects.  So, it is the combination of
draft-ietf-netconf-netconf-event-notifications and RFC 5277bis which covers
the original scope of bis.  
- Clearly, implementations can choose to continue to support 5277.  I don't
see how marking 5277 as obsolete would change that.  De-facto I would think
that the new sets of draft provide richer capabilities that implementations
will want to support so I think de-facto 5277 is being deprecated, how this
should best be reflected in status I don't know but seems somewhat secondary
to me.  

Re: breaking out the aspect of encoding of notifications from the current
into a separate draft, it's possible although I don't think necessary.  It
leads to further proliferation of number of drafts; I think it can just as
well stay in 5277bis (whatever will be its name).  That said, I can think of
instances where it will make sense to refer to such encoding, such as when
it comes to persisting event notifications in logs.  

--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Eric Voit
(evoit)
Sent: Wednesday, December 21, 2016 9:13 AM
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Netconf] 3 Options for Subscription & Event Notification draft
structure

Hi Martin,

> From: Martin Bjorklund, December 21, 2016 5:07 AM "Eric Voit (evoit)" 
> <[email-masked]> wrote:
> draft-ietf-netconf- rfc5277bis-00.  If this is true, I don't think that
your statement above is correct.

current WG draft is -01.  

A working version of -02 is at
https://github.com/netconf-wg/rfc5277bis/blob/master/rfc5277bis-02-v20Dec201
6.txt
But it hasn't been posted yet.

the obsoleting of 5277 is intended to come from a combination of
draft-ietf-netconf-rfc5277bis &
draft-ietf-netconf-netconf-event-notifications

> Maybe, but note that (1) through (8) is not a *complete* list of
requirements.

> (And not all items are real requirements, e.g., (6)).

Below you note that we need a 'subscription-id' field in the payload'.  That
is what is intended in (6) 

> draft-ietf-netconf- rfc5277bis-00.

Payload headers are coming in the next 5277bis version.  Per the last
minutes, Andy is thinking about using some TailF stuff as a starting point.
The transport encapsulation for NETCONF will be in
draft-ietf-netconf-netconf-event-notifications.  Alberto is awaiting the new
notification payload before writing that up.
 
> > o Implementations provide backwards compatibility through 
> > concurrent, parallel support of both specifications.
> >
> > o Although obsoleted, the IETF does not deprecate 5277 so that 
> > current implementations may stay with existing 5277.
> 

Old protocols live in deployments after a doc is obsoleted.  My assumption
is that deprecated means we actively provide reasons why people shouldn't
use an old spec tp make people convert faster.  Does Obsolete require
Deprecate?  I don't know.   I am happy to go with whatever the IETF process
uses here.

> > advocating competing technologies for the place of overlap.  -- 
> > i.e., NETCONF over XML with a single subscription.
> >

I don't find this path interesting, nor do I plan any authorship on this
option.  So I am not thinking about it much.  I am not sure if anyone wants
(iii.).

> > Based on this list, the people working in on the Subscription & 
> > Event Notification weekly calls have a preference for (i.) followed 
> > by (ii.).  Do you have a preference or additional questions not 
> > addressed here or in the earlier threads?
> 

It is.

This is in 5277bis. 

>      and RESTCONF (future protocols might reuse this, or they might

Currently encoding examples are in
draft-ietf-netconf-netconf-event-notifications and
draft-ietf-netconf-restconf-notif.  Incomplete notification definitions are
in 5277bis (as noted above).  But if the WG wishes, we could rearrange
things and have a protocol independent encoding document for notifications.

I believe we should revisit the proper placement of this now as part of our
discussion on the structure of the notifications.  

 
>      draft-ietf-netconf-restconf-18, and it needs to be updated)

draft-ietf-netconf-restconf-notif, although we recommend HTTP2 for the
notifications, and RESTCONF for the dynamic subscription establishment.

Yes
 
> Maybe some of these could be collapsed into one document, e.g. A+B, or 

The current document breakdown covers the intents above.  But we could move
B to an independent draft if the WG prefers.

Eric

> /martin

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 22 Dec 2016 08:08:25 +0100 (CET)

"Eric Voit (evoit)" <[email-masked]> wrote:
> Below you note that we need a 'subscription-id' field in the
> payload'.

Yes, but this is a solution that follows from the requirements; it is
not a requirement in itself.

[...]

> >      streams, replay, filters, and subscriptions etc.

Ok.  I think we already agree that some things are currently missing,
like replay, but that's fine.

> I believe we should revisit the proper placement of this now as part of our discussion on the structure of the notifications.  

See below; (a chapter in 5277bis for this topic is fine)

> draft-ietf-netconf-netconf-event-notifications

Ok, good.

But as I wrote in my most recent review, I think
draft-ietf-netconf-netconf-event-notifications needs to be rewritten.
It should be a pretty short document that focuses on the message flow
for notifications over NETCONF.  The current document doesn't have any
new normative text.

> The current document breakdown covers the intents above.  But we could move B to an independent draft if the WG prefers.

The name of the drafts are confusing, esp. 5277bis.  But I don't
propose a change of the draft names.  Maybe we should adjust the
titles a bit, when we have agreement on what goes into the different
drafts.

As I wrote earlier, it is fine if there is one document that covers
A+B+D, and if that is 5277bis, that's fine with me.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 22 Dec 2016 14:24:19 +0000

Thanks Martin, I think we are in the same place then.

Eric

> From: Martin Bjorklund, December 22, 2016 2:08 AM
> 
> > > From: Martin Bjorklund, December 21, 2016 5:07 AM "Eric Voit
> > > (evoit)" <[email-masked]> wrote:
> > > > To summarize previous threads, key benefits of 5277bis over RFC
> > > > 5277
> > > > include:
> > > >
> > > draft-ietf-netconf- rfc5277bis-00.  If this is true, I don't think that your
> statement above is correct.
> > > > I.e., there are no RPC or notifications shared between the 5277
> > > > and 5277bis solutions.  Any compatibility mode section would be
> > > > fully standalone.  Considering that people can just refer to 5277
> > > > if they need it, and considering 5277 & 5277bis could easily run
> > > > in parallel on different transport sessions, building a standalone
> > > > backwards compatibility section seems both confusing and redundant.
> > > >
> > > >
> > > >
> > Below you note that we need a 'subscription-id' field in the payload'.
> 
> Yes, but this is a solution that follows from the requirements; it is not a
> requirement in itself.
> 
> [...]
> 
> Ok.  I think we already agree that some things are currently missing, like replay,
> but that's fine.
> 
> > Currently encoding examples are in draft-ietf-netconf-netconf-event-
> notifications and draft-ietf-netconf-restconf-notif.  Incomplete notification
> definitions are in 5277bis (as noted above).  But if the WG wishes, we could
> rearrange things and have a protocol independent encoding document for
> notifications.
> >
> But as I wrote in my most recent review, I think draft-ietf-netconf-netconf-
> event-notifications needs to be rewritten.
> It should be a pretty short document that focuses on the message flow for
> notifications over NETCONF.  The current document doesn't have any new
> normative text.
> 
> > > Maybe some of these could be collapsed into one document, e.g. A+B,
> > > or maybe A+B+D.
> >
> > The current document breakdown covers the intents above.  But we could
> move B to an independent draft if the WG prefers.
> 
> The name of the drafts are confusing, esp. 5277bis.  But I don't propose a
> change of the draft names.  Maybe we should adjust the titles a bit, when we
> have agreement on what goes into the different drafts.
>