Re: [Netconf] Agenda Request

"Alberto Gonzalez Prieto (albertgo)" <albertgo@cisco.com> Thu, 24 March 2016 00:49 UTC

Return-Path: <albertgo@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39D612D1D4 for <netconf@ietfa.amsl.com>; Wed, 23 Mar 2016 17:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXpP1deGqRSW for <netconf@ietfa.amsl.com>; Wed, 23 Mar 2016 17:49:33 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59ED012DA0F for <netconf@ietf.org>; Wed, 23 Mar 2016 17:49:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23232; q=dns/txt; s=iport; t=1458780573; x=1459990173; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kKU881nuSMxMXZcliT5IsFpCbaF5M3ztY5T2wWEwh+o=; b=fgvqcOSKGQ/n+Te1nrDJixGIlU/cclXamNZbOddoeWio/ymCnAxvfasl pENhnGSqnPSu0S4qn6XXOjoTOdAGvfCxHmD1as1qyixjzu9pRiievb0ST bL1NV6toJv9W9jX5SmAIJzwCP/1qZt/MkBcbJtDiPUS3/fLpC06pXwUrb Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AWAgBIOPNW/4ENJK1egmdMU3oGrwuLTgENgXAXAQmFIkoCgUM4FAEBAQEBAQFkJ4RBAQEBBAEBAWsLEAIBCBEDAQEBDhoHIQYLFAkIAgQOBRuHdwMSDrwSDYR6AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSKYoI+gWY4DYUpBYdgiySEJTEBhXCGHoF1gWaETIhYaoZIh1QBHgEBQoNlaohQAh4DBBZ+AQEB
X-IronPort-AV: E=Sophos;i="5.24,383,1454976000"; d="scan'208,217";a="252858789"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2016 00:49:31 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u2O0nVwV028296 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Mar 2016 00:49:31 GMT
Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 23 Mar 2016 20:49:31 -0400
Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Wed, 23 Mar 2016 20:49:31 -0400
From: "Alberto Gonzalez Prieto (albertgo)" <albertgo@cisco.com>
To: Andy Bierman <andy@yumaworks.com>
Thread-Topic: [Netconf] Agenda Request
Thread-Index: AQHReCCXnxWOt0Dw+0uIkww9TXgdy59OZWuAgBZC+ICAAatAAIAAYwOA///30YCAAYMtgA==
Date: Thu, 24 Mar 2016 00:49:31 +0000
Message-ID: <D318F0DD.6ABA5%albertgo@cisco.com>
References: <FB2B427A-23BF-41C5-AEEF-45392D3EE535@gmail.com> <e0186f1a0e6448fa92459907e2e59e78@XCH-ALN-013.cisco.com> <D315FF4C.6A029%albertgo@cisco.com> <CABCOCHQFkaqEj6cFJsaW=eLZkD5pAAx0f0_Dg-GBpLx_8ykN+g@mail.gmail.com> <D317B403.6A7D7%albertgo@cisco.com> <CABCOCHSVTrtMsoKLtg4S8BD_w7HLDd-nARWuNTuckswLdbO_vA@mail.gmail.com>
In-Reply-To: <CABCOCHSVTrtMsoKLtg4S8BD_w7HLDd-nARWuNTuckswLdbO_vA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.1.160122
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.167.72]
Content-Type: multipart/alternative; boundary="_000_D318F0DD6ABA5albertgociscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/netconf/07asvt6UbhGErrjFDatwnyV1h3U>
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] Agenda Request
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Mar 2016 00:49:35 -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

From: Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>
Date: Wednesday, March 23, 2016 at 3:43 AM
To: Alberto Gonzalez Prieto <albertgo@cisco.com<mailto:albertgo@cisco.com>>
Cc: "Eric Voit (evoit)" <evoit@cisco.com<mailto:evoit@cisco.com>>, Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>, NETCONF <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: Re: [Netconf] Agenda Request

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) <albertgo@cisco.com<mailto:albertgo@cisco.com>> wrote:
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 <andy@yumaworks.com<mailto:andy@yumaworks.com>>
Date: Tuesday, March 22, 2016 at 10:18 PM
To: Alberto Gonzalez Prieto <albertgo@cisco.com<mailto:albertgo@cisco.com>>
Cc: "Eric Voit (evoit)" <evoit@cisco.com<mailto:evoit@cisco.com>>, Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>, NETCONF <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: Re: [Netconf] Agenda Request

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


On Mon, Mar 21, 2016 at 11:49 AM, Alberto Gonzalez Prieto (albertgo) <albertgo@cisco.com<mailto:albertgo@cisco.com>> wrote:
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)"
<netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org> on behalf of evoit@cisco.com<mailto:evoit@cisco.com>> wrote:

>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:netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>] On Behalf Of Mahesh
>Jethanandani
>Sent: Sunday, March 06, 2016 10:22 PM
>To: NETCONF
>Subject: [Netconf] Agenda Request
>
>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
>
>
>
>_______________________________________________
>Netconf mailing list
>Netconf@ietf.org<mailto:Netconf@ietf.org>
>https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
Netconf mailing list
Netconf@ietf.org<mailto:Netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf