Subject: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure

From: "Mehmet Ersue" <[email-masked]>
Date: Wed, 18 Jan 2017 00:06:14 +0100

Dear NETCONF WG,

looking at the feedback on the three options Eric Voit summarized in his
mail below but also related discussion on this topic, NETCONF co-chairs came
to the conclusion that option (iii) for updating/enhancing RFC5277 did not
get any proponents. On the other hand we see a huge support and attraction
for the new notification/subscription capabilities and extensions discussed
and provided by the Subscriptions and Events team.

We think that the addition of new notification capabilities in concert with
the drafts from the Subscriptions and Events team provide rich features that
implementations will want to support in the future. The key features in
preparation are transport independence, multiple dynamic and/or configured
subscriptions in a transport session.      

The documents the Subscriptions and Events team are currently working on
are:

- A document which defines the protocol-neutral notification framework,
i.e., explains the concepts of subscriptions, filters, control plane
notifications, replay, etc.  And also defines the associated YANG data
model, RPCs, etc. This is currently covered in 5277bis document which would
need to be renamed.

- A document which defines how notifications are sent over NETCONF
(generalizing section 3.7 of RFC 5277) and how YANG notifications are
encoded in XML and JSON (draft-ietf-netconf-netconf-event-notifications),

- A document which defines how notifications are sent over RESTCONF
(generalizing section 6 of RESTCONF RFC) and HTTP2.  Also defines how YANG
notifications are encoded in XML and JSON
(draft-ietf-netconf-restconf-notif),

- A document which defines the subscription and push mechanism for YANG
datastores allowing subscriber applications to request updates from a YANG
datastore (draft-ietf-netconf-yang-push).

A) NETCONF co-chairs think that the Subscriptions and Events team should
continue its valuable work and propose to change our current charter to add
the development of notifications and subscription capabilities with the
listed documents and focus above as a starting point. WG members are asked
to state their opinion on the proposed plan. 

Please let us know on NETCONF maillist by January 27, 2017 EOB PT, if you
have a strong objection to this plan and explain your concern with valid
arguments. Please also state clearly if you support this plan.

B) NETCONF co-chairs further propose that NETCONF WG should use its energy
in the future to complete and improve the new notification and subscription
RFCs and stop maintaining RFC 5277 for issues other than errata.  Note that
it is required that RFC 5277 and all new work needs to gracefully co-exist
in any deployment.  

Please state your opinion on the maillist by January 27, 2017 EOB PT,
whether you think RFC 5277 should be obsoleted during the publication of the
new draft set or not.

Many Thanks in advance for your valuable comments.  

Mehmet & Mahesh

From: Eric Voit (evoit) [mailto:[email-masked]] 
Sent: Tuesday, December 20, 2016 4:33 PM
To: [email-masked]; [email-masked]
Subject: 3 Options for Subscription & Event Notification draft structure

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.

*	Implementations can still choose 5277 or 5277bis, even though IETF
recommends 5277bis.
*	Implementations provide backwards compatibility through concurrent,
parallel support of both specifications.
*	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.  

*	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:

*	Cannot support (1) or (8)
*	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: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Jan 2017 08:53:14 +0100

> model, RPCs, etc. This is currently covered in 5277bis document which would

I think 'control plane notification' is a really bad term for what it
does and the sooner we find a better term the better it is. I actually
think that no term is needed.
 
> encoded in XML and JSON (draft-ietf-netconf-netconf-event-notifications),

The encoding of YANG defined notifications into XML and JSON is defined
in RFC 7950 and RFC 7951. NETCONF does not support JSON.

> (draft-ietf-netconf-restconf-notif),

The encoding of	YANG defined notifications into	XML and	JSON is	defined
in RFC 7950 and	RFC 7951.

> datastore (draft-ietf-netconf-yang-push).

Perhaps you mean the right thing but from the writing this is not
clear. Perhaps you actually mean the following four documents:

a) protocol-neutral extended notification framework

b) using extended notifications with NETCONF

c) using extended notifications with RESTCONF

d) a YANG data model for extended notifications

Such a set of documents makes sense to me.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 18 Jan 2017 19:34:27 +0000

With respect to Mehmet’s original email:

> A) NETCONF co-chairs think that the Subscriptions and Events team should continue its valuable work and propose to change our current charter to add the development of notifications and subscription capabilities with the listed documents and focus above as a starting point. WG members are asked to state their opinion on the proposed plan. 
> Please let us know on NETCONF maillist by January 27, 2017 EOB PT, if you have a strong objection to this plan and explain your concern with valid arguments. Please also state clearly if you support this plan.

I support this plan.

> B) NETCONF co-chairs further propose that NETCONF WG should use its energy in the future to complete and improve the new notification and subscription RFCs and stop maintaining RFC 5277 for issues other than errata.  Note that it is required that RFC 5277 and all new work needs to gracefully co-exist in any deployment.  
> Please state your opinion on the maillist by January 27, 2017 EOB PT, whether you think RFC 5277 should be obsoleted during the publication of the new draft set or not.

I think it makes sense to stop maintaining 5277 for issues other than errata, and that once the new work is complete, moving forward should be encouraged, with eventual obsoletion of 5277. Completely agreed on graceful co-existence.

A couple of comments below as well.

> On 18 Jan 2017, at 07:53, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I agree that “control plane” should be taken out from the text and no replacement made.

> in RFC 7950 and RFC 7951. NETCONF does not support JSON.

Agreed that there are existing definitions that should be leveraged. However, there may be some additions to how notifications are generated the require elaboration.

> in RFC 7950 and	RFC 7951.

Same comment as above.

>> datastore (draft-ietf-netconf-yang-push).

This document is required also. If (d) below is intended to encompass this as well, then fine.

> Such a set of documents makes sense to me.

Agreed with caveat as noted above on what (d) encompasses.

Cheers,

Einar

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Jan 2017 11:08:51 +0100 (CET)

> Such a set of documents makes sense to me.

Hmm, this is not what I understood from Mehmet's description.
Specifically, in Mehmet's description, the YANG data model is part of
the first document.

Also, it is not clear to me what is included in the "extended notification
framework".  Is "push" included there?

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 19 Jan 2017 14:08:52 +0000

> From: Mehmet Ersue, January 17, 2017 6:06 PM
> 
> Dear NETCONF WG,
> 
> looking at the feedback on the three options Eric Voit summarized in his mail
> below but also related discussion on this topic, NETCONF co-chairs came to the
> conclusion that option (iii) for updating/enhancing RFC5277 did not get any
> proponents. On the other hand we see a huge support and attraction for the
> new notification/subscription capabilities and extensions discussed and
> provided by the Subscriptions and Events team.
> 
> We think that the addition of new notification capabilities in concert with the
> drafts from the Subscriptions and Events team provide rich features that
> - A document which defines the protocol-neutral notification framework, i.e.,
> explains the concepts of subscriptions, filters, control plane notifications,
> replay, etc.  And also defines the associated YANG data model, RPCs, etc. This is
> currently covered in 5277bis document which would need to be renamed.
> (generalizing section 3.7 of RFC 5277) and how YANG notifications are encoded
> in XML and JSON (draft-ietf-netconf-netconf-event-notifications),
> notifications are encoded in XML and JSON (draft-ietf-netconf-restconf-notif),
> the development of notifications and subscription capabilities with the listed
> documents and focus above as a starting point. WG members are asked to state
> their opinion on the proposed plan.

I support the charter change proposal described in (A)
 
> RFCs and stop maintaining RFC 5277 for issues other than errata.  Note that it
> is required that RFC 5277 and all new work needs to gracefully co-exist in any
> deployment. Please state your opinion on the maillist by January 27, 2017 EOB
> PT, whether you think RFC 5277 should be obsoleted during the publication of
> the new draft set or not.

I believe it easier to obsolete RFC-5277 simply so that NETCONF is seen as advocating a single more comprehensive solution/approach for new deployments.  

Eric 
 
> To: mailto:[email-masked]; mailto:[email-masked]
> To summarize previous threads, key benefits of 5277bis over RFC 5277 include:
> 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.
> 
> (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,
> o Although obsoleted, the IETF does not deprecate 5277 so that current
> . Need to change the NETCONF WG charter to show that 5277 is being
> (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.,
> . 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
> 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.
> 
> 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: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 19 Jan 2017 15:12:43 +0000

> From: Martin Bjorklund, January 19, 2017 5:09 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3
> Options for Subscription & Event Notification draft structure
> 
(1)>>> - A document which defines the protocol-neutral notification
> > > framework, i.e., explains the concepts of subscriptions, filters,
> > > control plane notifications, replay, etc.  And also defines the
> > > associated YANG data model, RPCs, etc. This is currently covered in
> > > 5277bis document which would need to be renamed.
> >
> > does and the sooner we find a better term the better it is. 

A better term would be great, maybe "Subscription State Notification"?   

> > I actually think that no term is needed.

I do think some term is helpful.  These are the notifications which match 1:1 with the set of Subscription State model state changes on a Publisher.  See 5277bis, section 2.4.  

(2)>>> - A document which defines how notifications are sent over NETCONF
> > > (generalizing section 3.7 of RFC 5277) and how YANG notifications
> > > are encoded in XML and JSON
> > > (draft-ietf-netconf-netconf-event-notifications),
> >
> > The encoding of YANG defined notifications into XML and JSON is
> > defined in RFC 7950 and RFC 7951. NETCONF does not support JSON.
> >
(3)>>> - A document which defines how notifications are sent over RESTCONF
> > > (generalizing section 6 of RESTCONF RFC) and HTTP2.  Also defines
> > > how YANG notifications are encoded in XML and JSON
> > in RFC 7950 and	RFC 7951
(4)>>> - A document which defines the subscription and push mechanism for
> > > YANG datastores allowing subscriber applications to request updates
> > > from a YANG datastore (draft-ietf-netconf-yang-push).
> >
> Specifically, in Mehmet's description, the YANG data model is part of the first
> document.

The breakdown in Mehmet's email aimed to match contents of the WG drafts.  So yes, the base subscription model is in Mehmet's first document (1).  Augmentations to the base model for yang-push specifics in Mehmet's fourth document (4).  

What we have found missing is a protocol-neutral data plane notification message.  While that could be bundled into Juergen's (a) or Mehmet's (1), it likely is better to have stand-alone so it isn't exclusively coupled to Subscriptions.

> framework".  Is "push" included there?

My reading is the (d) includes the YANG models currently within (1) and (4).

Eric

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Jan 2017 16:40:02 +0100

> A better term would be great, maybe "Subscription State Notification"?   

This proposed term is much much better.

> I do think some term is helpful.  These are the notifications which match 1:1 with the set of Subscription State model state changes on a Publisher.  See 5277bis, section 2.4.  

Fine with me - as long as the term is specific.

/js

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 19 Jan 2017 18:29:33 +0000

Hi,

The specific notifications under discussions are notifications that inform a receiver of notifications of changes to subscription state that will impact what notifications the receiver can expect to receive.  What sets those particular notifications apart from other notifications is that you do not have to explicitly subscribe to them in order to receive them, and that the notifications are confined to that particular context and not subscribable to others.  Instead, use of a particular feature (in this case, subscribing to a set of notifications) makes a user automatically "subscribed" to notifications in this context.  

While "subscription state notification" is in one sense an accurate description of what this does, I think a more general term may be more appropriate, for several reasons:
- To capture the different nature of this type of notification vs other notifications, e.g. an "interface state notification", which would behave genuinely differently in terms of how to subscribe to it.  
- To allow for a generalization of this concept to other areas as well.  The question is whether this is intended to be in charter, but it is certainly conceivable to use a similar type of notifications for other use cases.  Think, for example, of an ongoing test in which intermediate updates about test progress would be sent using notifications - but those notifications should go only to the initiator of the test, and the initiator of the test should not have to separately subscribe to test update notifications.  

What about the term "OAM notifications"?  or, to leave out "plane" from "control plane notifications" and simply call it "control notifications"?  

--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, January 19, 2017 7:40 AM
To: Eric Voit (evoit) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure

On Thu, Jan 19, 2017 at 03:12:43PM +0000, Eric Voit (evoit) wrote:
> > >
> > > I think 'control plane notification' is a really bad term for what 
> > > it does and the sooner we find a better term the better it is.
> 

/js

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 19 Jan 2017 18:39:36 +0000

I support item (A) for the charter change.

I also support item (B).  Whether RFC 5277 is  obsoleted or not, it is clearly recognized that 5277 and new work will gracefully coexist in deployments.  Obsoleting RFC 5277 seems preferable over other alternatives as to not be ambiguous about which solution approach is advocated as basis for going forward.

--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Mehmet Ersue
Sent: Tuesday, January 17, 2017 3:06 PM
To: 'Netconf' <[email-masked]>
Subject: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure

Dear NETCONF WG,

looking at the feedback on the three options Eric Voit summarized in his mail below but also related discussion on this topic, NETCONF co-chairs came to the conclusion that option (iii) for updating/enhancing RFC5277 did not get any proponents. On the other hand we see a huge support and attraction for the new notification/subscription capabilities and extensions discussed and provided by the Subscriptions and Events team.

We think that the addition of new notification capabilities in concert with the drafts from the Subscriptions and Events team provide rich features that implementations will want to support in the future. The key features in preparation are transport independence, multiple dynamic and/or configured subscriptions in a transport session.

The documents the Subscriptions and Events team are currently working on are:
- A document which defines the protocol-neutral notification framework, i.e., explains the concepts of subscriptions, filters, control plane notifications, replay, etc.  And also defines the associated YANG data model, RPCs, etc. This is currently covered in 5277bis document which would need to be renamed.
- A document which defines how notifications are sent over NETCONF (generalizing section 3.7 of RFC 5277) and how YANG notifications are encoded in XML and JSON (draft-ietf-netconf-netconf-event-notifications),
- A document which defines how notifications are sent over RESTCONF (generalizing section 6 of RESTCONF RFC) and HTTP2.  Also defines how YANG notifications are encoded in XML and JSON (draft-ietf-netconf-restconf-notif),
- A document which defines the subscription and push mechanism for YANG datastores allowing subscriber applications to request updates from a YANG datastore (draft-ietf-netconf-yang-push).

Mehmet & Mahesh

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Tuesday, December 20, 2016 4:33 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: 3 Options for Subscription & Event Notification draft structure

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.

  *   Supports all requirements (1) through (8).
  *   IETF does not continue protocol maintenance of 5277.
     *   Implementations can still choose 5277 or 5277bis, even though IETF recommends 5277bis.
     *   Implementations provide backwards compatibility through concurrent, parallel support of both specifications.
     *   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.

  *   Technically identical to (i).
  *   Implementations free to choose 5277 or 5277bis, with no guidance on which the WG recommends.
     *   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.

  *   Supports a subset of requirements:
     *   Cannot support (1) or (8)
     *   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: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Jan 2017 19:48:42 +0100

I think we should clearly separate _what_ kind of information
notifications carry (and "subscription state notification" seems right
on target here) from _how_ subscriptions to notificiations are created
/ deleted (explicit, implicit, ...) and we should I think avoid trying
to find an opaque term like 'OAM notifications' that folds two
separate concepts into a single and by itself confusing term.

/js

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 19 Jan 2017 19:55:52 +0000

OK, so for the purposes here I am fine with subscription state notifications.  

The question remains, however, whether we want to allow for generation of this concept and have this in charter.  I.e., support the use cases of notifications intended for a specific receiver / tied to a specific object or long-lived operation that has a clear ownership.  However, I am thinking of the example of the long-running test operation with continuous updates.  Applying something called subscription state notifications in that scenario appears like a stretch, although the same concept would be applicable there.  To keep things simple, perhaps we should just keep ourselves to subscription state notifications; at the same time it might a good opportunity to capture this also while we are discussing the charter change.  Anyway, it was just a thought.   

--- Alex  

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, January 19, 2017 10:49 AM
To: Alexander Clemm <[email-masked]>
Cc: Eric Voit (evoit) <[email-masked]>; [email-masked]
Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure

I think we should clearly separate _what_ kind of information notifications carry (and "subscription state notification" seems right on target here) from _how_ subscriptions to notificiations are created / deleted (explicit, implicit, ...) and we should I think avoid trying to find an opaque term like 'OAM notifications' that folds two separate concepts into a single and by itself confusing term.

/js

On Thu, Jan 19, 2017 at 06:29:33PM +0000, Alexander Clemm wrote:
> Subject: Re: [Netconf] New Notification and Subscription Features 
> WASFW: 3 Options for Subscription & Event Notification draft structure
> 
> > > > I think 'control plane notification' is a really bad term for 
> > > > what it does and the sooner we find a better term the better it is.
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Jan 2017 21:17:42 +0100

Alex,

I do not think the current charter covers work on long running
operations and intermediate updates. There were discussions some
months / years ago about this and there are different possible
solutions. I do not think the WG is chartered to work on any of
these solutions right now.

/js

---

From: "Alberto Gonzalez Prieto (albertgo)" <[email-masked]>
Date: Wed, 25 Jan 2017 06:54:05 +0000

Hello,

I support the proposed charter change (A)
I also support (B). I think it is important to provide clear guidance with respect to what solution should be preferred in new implementations. I think that obsoleting 5277 achieves this.

Thanks,

Alberto

On 1/17/17, 3:06 PM, "Netconf on behalf of Mehmet Ersue" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Dear NETCONF WG,

Mehmet & Mahesh

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

  *   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.

Thanks,

Eric

---

From: "Alberto Gonzalez Prieto (albertgo)" <[email-masked]>
Date: Wed, 25 Jan 2017 06:58:52 +0000

Hello,

I am OK with “subscription state notifications”. 
I think it is important to have a term that differentiates these notifications for conceptually, they are different from “event notifications”.

Thanks,

Alberto

-----Original Message-----
From: Netconf <[email-masked]> on behalf of Alexander Clemm <[email-masked]>
Date: Thursday, January 19, 2017 at 11:55 AM
To: Juergen Schoenwaelder <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure

    
    --- Alex  
    
    -----Original Message-----
    From: Juergen Schoenwaelder [mailto:[email-masked]] 
    Sent: Thursday, January 19, 2017 10:49 AM
    To: Alexander Clemm <[email-masked]>
    Cc: Eric Voit (evoit) <[email-masked]>; [email-masked]
    Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure

    /js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 26 Jan 2017 09:02:10 +0100 (CET)

> to state their opinion on the proposed plan. 

I think this is fine, but *if* this happens to coincide with a
rfc6241bis document, I would be nice to move the contents of the
second of these documents (i.e., how notifications are sent over
NETCONF) into rfc6241bis.  As has been stated before, bumping the
protocol version to 1.2 would allow us to change the "notification"
element contents.

I also agree w/ Jurgen that the second and third documents should not
contain the XML and JSON encoding of YANG-defined notifications.
Thus, I assume that these two documents will be very short.

> whether you think RFC 5277 should be obsoleted during the publication of the

I think 5277 should be obsoleted by these new drafts.

/martin

---

From: "Mehmet Ersue" <[email-masked]>
Date: Tue, 31 Jan 2017 22:01:02 +0100

Dear NETCONF WG,

the WG seems to agree that we should continue the work the Subscriptions and
Events team is doing and change the current charter to add the development
of notifications and subscription capabilities. There is also support for
obsoleting RFC 5277 during the publication of the new draft set. The
co-chairs will provide a draft charter text for WG's review soon.

That said, we need some discussion and a conclusion on the required document
set.

The original document set proposed was:

a) A document which defines the protocol-neutral notification framework,
i.e., explains the concepts of subscriptions, filters, control plane
notifications, replay, etc.  And also defines the associated YANG data
model, RPCs, etc. This is currently covered in 5277bis document which would
need to be renamed.

b) A document which defines how notifications are sent over NETCONF
(generalizing section 3.7 of RFC 5277) and how YANG notifications are
encoded in XML and JSON (draft-ietf-netconf-netconf-event-notifications),

c) A document which defines how notifications are sent over RESTCONF
(generalizing section 6 of RESTCONF RFC) and HTTP2.  Also defines how YANG
notifications are encoded in XML and JSON
(draft-ietf-netconf-restconf-notif),

d) A document which defines the subscription and push mechanism for YANG
datastores allowing subscriber applications to request updates from a YANG
datastore (draft-ietf-netconf-yang-push).

This proposal was aiming to address the requirements Mahesh and I have read
on NETCONF and NETMOD maillists and discussed with Eric:

- Provide the protocol-neutral notification framework in a separate
document.

- Improve YANG specification RFC 7950 to be (as good as possible and
required) protocol-independent and remove XML and JSON notification encoding
sections for NETCONF. This was also the discussion result between NETCONF
and NETMOD co-chairs.

- Provide protocol-specific details e.g. how notifications are sent and the
notification encodings in separate documents. This part could be for sure
put into 6241bis and RESTCONF-bis. Though Eric and the co-chairs were
favoring to have separate documents.

That said I see Martin's comments below as valid.

> > I think this is fine, but *if* this happens to coincide with a
rfc6241bis document, I would be nice to move the contents of the second of
these documents (i.e., 

> > how notifications are sent over NETCONF) into rfc6241bis.  As has been
stated before, bumping the protocol version to 1.2 would allow us to change
the 

> > "notification" element contents.

@All: Please comment on the documents a)-d) above. Especially on the
questions:

- whether the XML and JSON notification encoding sections should be removed
from 7950 and put into NETCONF WG documents as well as

- whether the documents b) and c) are good to separate or they should be put
into 6241bis and RESTCONF-bis documents. 

Thanks.

Best Regards,

Mehmet

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Thursday, January 26, 2017 9:02 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3

> looking at the feedback on the three options Eric Voit summarized in 

> his mail below but also related discussion on this topic, NETCONF 

> co-chairs came to the conclusion that option (iii) for 

> updating/enhancing RFC5277 did not get any proponents. On the other 

> hand we see a huge support and attraction for the new 

> notification/subscription capabilities and extensions discussed and

> We think that the addition of new notification capabilities in concert 

> with the drafts from the Subscriptions and Events team provide rich 

> features that implementations will want to support in the future. The 

> key features in preparation are transport independence, multiple dynamic
and/or configured

> The documents the Subscriptions and Events team are currently working 

> on

> - A document which defines the protocol-neutral notification 

> encoded in XML and JSON 

> (generalizing section 6 of RESTCONF RFC) and HTTP2.  Also defines how 

> YANG notifications are encoded in XML and JSON 

> - A document which defines the subscription and push mechanism for 

> A) NETCONF co-chairs think that the Subscriptions and Events team 

> should continue its valuable work and propose to change our current 

> charter to add the development of notifications and subscription 

> capabilities with the listed documents and focus above as a starting 

> point. WG members are asked to state their opinion on the proposed plan.

I think this is fine, but *if* this happens to coincide with a rfc6241bis
document, I would be nice to move the contents of the second of these
documents (i.e., how notifications are sent over

NETCONF) into rfc6241bis.  As has been stated before, bumping the protocol
version to 1.2 would allow us to change the "notification"

element contents.

> Please let us know on NETCONF maillist by January 27, 2017 EOB PT, if 

> you have a strong objection to this plan and explain your concern with 

> valid arguments. Please also state clearly if you support this plan.

> B) NETCONF co-chairs further propose that NETCONF WG should use its 

> energy in the future to complete and improve the new notification and 

> subscription RFCs and stop maintaining RFC 5277 for issues other than 

> errata.  Note that it is required that RFC 5277 and all new work needs 

> to gracefully co-exist in any deployment.

> whether you think RFC 5277 should be obsoleted during the publication 

> of the new draft set or not.

 

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 Jan 2017 22:16:19 +0100

> into 6241bis and RESTCONF-bis documents. 

Since when has RFC 7950 JSON notification encoding sections? This
email is confusing on multiple ends.

/js

---

From: "Mehmet Ersue" <[email-masked]>
Date: Tue, 31 Jan 2017 23:18:07 +0100

Thanks. It should read:

@All: Please comment on the documents a)-d) below. Especially on the
questions:
- whether the XML notification encoding section should be removed from 7950
and put into NETCONF WG documents as well as
- whether the documents b) and c) are good to separate or the
protocol-specific content should be put into 6241bis and RESTCONF-bis
documents. 

Mehmet

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, January 31, 2017 10:16 PM
To: Mehmet Ersue <[email-masked]>
Cc: 'Martin Bjorklund' <[email-masked]>; [email-masked]
Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3

On Tue, Jan 31, 2017 at 10:01:02PM +0100, Mehmet Ersue wrote:
> a) A document which defines the protocol-neutral notification 
> d) A document which defines the subscription and push mechanism for 
> This proposal was aiming to address the requirements Mahesh and I have 
> read on NETCONF and NETMOD maillists and discussed with Eric:
> 
> required) protocol-independent and remove XML and JSON notification 
> encoding sections for NETCONF. This was also the discussion result 
> between NETCONF and NETMOD co-chairs.
> 
> - Provide protocol-specific details e.g. how notifications are sent 
> and the notification encodings in separate documents. This part could 
> be for sure put into 6241bis and RESTCONF-bis. Though Eric and the 
> co-chairs were favoring to have separate documents.
> 
>  
> 
> second of these documents (i.e.,
> 
> stated before, bumping the protocol version to 1.2 would allow us to 
> change the
> 
> - whether the XML and JSON notification encoding sections should be 
> removed from 7950 and put into NETCONF WG documents as well as
> 
> - whether the documents b) and c) are good to separate or they should 
> be put into 6241bis and RESTCONF-bis documents.
>

Since when has RFC 7950 JSON notification encoding sections? This email is
confusing on multiple ends.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 31 Jan 2017 22:20:23 +0000

> email is confusing on multiple ends.

True, RFC 7950 doesn't have any JSON encoding sections, so there is nothing to be done on that front.   Also, while I agree that the XML encoding sections should be move out of RFC 7950, I view this purely as a NETMOD WG activity (not a NETCONF WG activity) and hence doesn't need to be discussed here.

What I think should be discussed here is moving all the NETCONF-isms in RFC 7950 to the NETCONF WG including, but not limited to, all the NETCONF XML Encoding Rules sections.  

RFC 7950 also contains a large number of NETCONF usage examples.  I think the NETMOD WG needs to discuss if these should to be moved to the NETCONF WG also, or if it's the better to convert half the examples to RESTCONF so RFC 7590 shows impartiality.  Though this is a NETMOD issue to discuss, it clearly might impact NETCONF, hence why I'm mentioning it here now.

Separately, in addition to moving material from NETMOD drafts to NETCONF drafts, I think there should be a discussion about moving material the other direction as well.  For instance, I think these terms defined in RFC 6241 might be better placed in the datastores draft:

  o configuration data
  o configuration datastore
  o datastore
  o state data

Thoughts?

Kent // a NETCONF contributor

---

From: Andy Bierman <[email-masked]>
Date: Tue, 31 Jan 2017 14:27:48 -0800

Hi,

I am not in favor of refactoring RFCs just to move content around.
If/when NETCONF 1.2 gets done, then the NETCONF bits in RFC 7950 should
get moved to that document. The NETCONF specific text is unfortunate,
but not causing harm to interoperability.

On Tue, Jan 31, 2017 at 2:20 PM, Kent Watsen <[email-masked]> wrote:

> True, RFC 7950 doesn't have any JSON encoding sections, so there is
> nothing to be done on that front.   Also, while I agree that the XML
> encoding sections should be move out of RFC 7950, I view this purely as a
> NETMOD WG activity (not a NETCONF WG activity) and hence doesn't need to be
> discussed here.
>
> What I think should be discussed here is moving all the NETCONF-isms in
> RFC 7950 to the NETCONF WG including, but not limited to, all the NETCONF
> XML Encoding Rules sections.
>
> RFC 7950 also contains a large number of NETCONF usage examples.  I think
> the NETMOD WG needs to discuss if these should to be moved to the NETCONF
> WG also, or if it's the better to convert half the examples to RESTCONF so
> RFC 7590 shows impartiality.  Though this is a NETMOD issue to discuss, it
> clearly might impact NETCONF, hence why I'm mentioning it here now.
>
> Separately, in addition to moving material from NETMOD drafts to NETCONF
> drafts, I think there should be a discussion about moving material the
> other direction as well.  For instance, I think these terms defined in RFC
> 6241 might be better placed in the datastores draft:
>
>   o configuration data