Subject: [Netconf] Agenda Request

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 6 Mar 2016 19:22:13 -0800

It is that time again where we ask if you want to present in the NETCONF session at IETF 95.

Please indicate

Topic:
Length:
Presenter:

in your request for the slot. 

All this assumes that you have published/updated a draft on the mailing list and have garnered some discussion around it. If not, there is still time to do that before the meeting.

Cheers.

Mahesh & Mehmet

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 7 Mar 2016 13:52:11 +0000

Hi Mahesh & Mehmet,

Below are the two topics we were hoping present .

Topics:
(1) Yang Subscriptions
  -  draft-ietf-netconf-yang-push 
       - WG draft revisions
       - IETF hackathon demo results: yang-push interworking with OpenDaylight 
  -  draft-voit-netconf-restconf-yang-push
       - New draft this week: shrunk to cover just Restconf & HTTP transports
  -  Discussion:  do we have the desired WG division for these drafts?

(2) RFC5277bis 
  - Proposal coming into WG before submission cut-off date

Length: 
(1) Yang Subscriptions - 20 min
(2) RFC5277bis - 10 min

Presenter: 
  -  Eric Voit (on behalf of the authors)

Thanks,
Eric, Alex, Alberto, Ambika, Einar

-------------------
From: Netconf [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: Sunday, March 06, 2016 10:22 PM
To: NETCONF
Subject: [Netconf] Agenda Request

Please indicate

Topic:
Length:
Presenter:

Cheers.

Mahesh & Mehmet

---

From: "Alberto Gonzalez Prieto (albertgo)" <[email-masked]>
Date: Mon, 21 Mar 2016 18:49:38 +0000

Hello,

Our proposal for RFC5277-bis has been submitted
(https://datatracker.ietf.org/doc/draft-gonzalez-netconf-5277bis)
You can find an high-level summary of the draft below.
We would like to present it in the NETCONF session at IETF 95.

Length: 10 minutes
Presenter: Eric Voit

Thanks,

Alberto, Alex, Eric, Einar, and Ambika

This draft targets charter item #6 of the NETCONF WG.
It enhances RFC 5277, addressing limitations identified during the design
of draft-ietf-netconf-yang-push-01 and
draft-voit-netconf-restconf-yang-push-02

Goals of charter item #6, (all of them addressed in the draft):
- Ability to delete subscriptions without closing the client session.
- Ability to modify existing subscriptions.
- Ability to have multiple subscriptions on a client session.
- Do not affect older clients.
- Convert data models in RFC 5277 into YANG.

The draft also includes the following features:
- Subscription negotiation.
- Static subscriptions. (i.e., configuration-driven susbcription)
- Subscription suspension and termination by server.
- Support for multiple encodings (e.g., json).

On 3/7/16, 2:52 PM, "Netconf on behalf of Eric Voit (evoit)"
<[email-masked] on behalf of [email-masked]> wrote:

>All this assumes that you have published/updated a draft on the mailing
>list and have garnered some discussion around it. If not, there is still
>time to do that before the meeting.
>
>Cheers.
>
>Mahesh & Mehmet
>
>
>
>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Mar 2016 14:18:46 -0700

Hi,

I don't know how much agreement there is on requirements or solution.

IMO, this draft should not be called RFC5277bis

 - all mechanisms from RFC 5277 have been removed
 - all RFC 5277 authors have been removed

IMO, the new work should not obsolete RFC 5277, as stated in the draft.
The existing notifications work as intended and there are several
independent
implementations.

This new draft is radically different and much more complex to implement on
the client and server than RFC 5277.

Andy

---

From: "Alberto Gonzalez Prieto (albertgo)" <[email-masked]>
Date: Wed, 23 Mar 2016 02:13:05 +0000

Thanks Andy,

The draft targets charter item #6. I include it below for convenience.

One of the goals in the item is to not affect older clients I.e., backwards compatibility.
To achieve this, we have kept the mechanisms in 5277. E.g., the create-subscription RPC.
If a mechanism in 5277 is not in the draft it is an unintended omission.

I agree that the complete set of features in the draft is more complex than those in 5277.
Some features are explicitly stated in the charter item (e.g., multiple subscriptions over a session).
Others, like static subscription, are not mandatory in the yang with the new features.
What is mandatory and what is optional is open to discussion.
A server implementation may only advertise the capabilities corresponding to 5277.

On the point your bring about the authors, I am not familiar with it. Guidance from the chairs would be appreciated.

Thanks,

Alberto

6. Enhance RFC 5277 with the ability to delete subscriptions without
closing the client session, to modify existing subscriptions, and to
have multiple subscriptions on a established client session. These
changes should not affect older clients that do not support these
particular subscription requirements. The RPCs and the data models in
RFC 5277 should be converted to YANG.

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 22, 2016 at 10:18 PM
To: Alberto Gonzalez Prieto <[email-masked]<mailto:[email-masked]>>
Cc: "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>>, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>, NETCONF <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] Agenda Request

Hi,

IMO, the new work should not obsolete RFC 5277, as stated in the draft.
The existing notifications work as intended and there are several independent
implementations.

Andy

On Mon, Mar 21, 2016 at 11:49 AM, Alberto Gonzalez Prieto (albertgo) <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

Length: 10 minutes
Presenter: Eric Voit

Thanks,

On 3/7/16, 2:52 PM, "Netconf on behalf of Eric Voit (evoit)"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

>From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mahesh
>Jethanandani
>[email-masked]<mailto:[email-masked]>

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Mar 2016 19:43:51 -0700

Hi,

    These changes should not affect older clients that do not support these
    particular subscription requirements.

So you are claiming that an RFC 5277 client will work with this draft, even
though the namespaces
are changed?  The :interleave capability has been completely removed.

IMO this new work should be decoupled since it appears to be intended
for platforms with extensive resources.
I don't see protocol definitions for a new type of notification delivery,
just a new "receivers" table.  Is interoperability expected without
a protocol definition?

I don't see any text about replayComplete except you augmented the
notification with a subscription-id. The entire replay buffer has been
removed.
Perhaps your intent is to extend RFC 5277 instead of replacing it?

Andy

On Tue, Mar 22, 2016 at 7:13 PM, Alberto Gonzalez Prieto (albertgo) <
[email-masked]> wrote:

> On the point your bring about the authors, I am not familiar with it.
> Guidance from the chairs would be appreciated.
>
> Thanks,
>
> Alberto
>
>
>
> From: Andy Bierman <[email-masked]>
> To: Alberto Gonzalez Prieto <[email-masked]>
> Cc: "Eric Voit (evoit)" <[email-masked]>, Mahesh Jethanandani <
> [email-masked]>, NETCONF <[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Mar 2016 20:42:01 -0700

Hi,

I do not want to give the impression I am against this work.
We will probably implement it.

IMO the best way not to break 5277 implementations or
confuse people is to just extend 5277 with a new RFC
with new operations and new monitoring data.

Here are examples of modules I wrote about 6 years ago
that provide YANG versions of the XSDs in RFC 5277:

http://www.netconfcentral.org/modulereport/nc-notifications
http://www.netconfcentral.org/modulereport/notifications

I think the correct namespaces have to be used to match the XSDs.

Andy

---

From: "Alberto Gonzalez Prieto (albertgo)" <[email-masked]>
Date: Thu, 24 Mar 2016 00:49:31 +0000

Thanks for your input Andy,

The goal is not to affect older clients. Anything that departs from that will be addressed.
You point at two items. The situation is different in those two cases:
- namespaces. The ones in the examples are the ones in RFC5277. In the yang models, we added a TODO note because to pass the pyang —ietf validation, we could not use the correct namespace. This is in our TODO list.
- interleave capability. This is an unintended omission. Added to our TODO list. Thanks!

On the receivers. You are correct. That is work-in-progress. I will add to the draft a list of work-in-progress items to facilitate the discussion.

On the replay.  Section 2.11.1 is about replayComplete.  The replay log is mentioned in 2.5.1 and in the yang. This can be better presented. I will revisit it.

Thanks,

Alberto

Date: Wednesday, March 23, 2016 at 3:43 AM

Hi,

So you are claiming that an RFC 5277 client will work with this draft, even though the namespaces
are changed?  The :interleave capability has been completely removed.

I don't see any text about replayComplete except you augmented the
notification with a subscription-id. The entire replay buffer has been removed.
Perhaps your intent is to extend RFC 5277 instead of replacing it?

Andy

On Tue, Mar 22, 2016 at 7:13 PM, Alberto Gonzalez Prieto (albertgo) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Andy,

Thanks,

Alberto

Hi,

Andy

Length: 10 minutes
Presenter: Eric Voit

Thanks,