Re: [Netconf] YangPush now

"Eric Voit (evoit)" <evoit@cisco.com> Wed, 18 July 2018 03:41 UTC

Return-Path: <evoit@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 A367D130E89 for <netconf@ietfa.amsl.com>; Tue, 17 Jul 2018 20:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, 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 9YA68NgmaL_4 for <netconf@ietfa.amsl.com>; Tue, 17 Jul 2018 20:41:23 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8DE130EA2 for <netconf@ietf.org>; Tue, 17 Jul 2018 20:41:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38466; q=dns/txt; s=iport; t=1531885282; x=1533094882; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=1fXltXMuG/fTELhy8/eXuAu0lKBp2njq7npIg+Qx4E0=; b=GunuViIdiUyvp4DFo7C3+gt4jTShaWrH557d7cG7JWcKBGThaHkrpviw GjLeRqPdbXtO/F0e+upFVLOuNpYQsyNIBkywMO/6osZk0WCCmB4HEEnCw SsXob8LMyW6JcHE5xzGOLOaSOn3q2UDUqsUWkY6eaZz8xtPIPS9wtxsSQ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C5AAAutk5b/4wNJK1ZAxkBAQEBAQEBAQEBAQEHAQEBAQGCU0wqY38oCoN0iASMPYIMdZREFIFmCxgBCoQDRgIXglkhNBgBAgEBAgEBAm0cDIU2AQEBBAEBIQohGAgZAgIBCBABAwECAQwBEwcDAgICGQwKARQJCAIEAQ4EAQcTAgICgjRMgRtkD6oqgS6KSgWIfYFXP4ERglw1gw4LAQEBARiBEwESAQkcCAkJARURgjqCVQKZXAkCjx2BS4QRgm2FJId9iXACERSBJB04JjtxcBU7gmkJCoISF3oBCYJBM4RhhT5vAQ+KRIEfgRoBAQ
X-IronPort-AV: E=Sophos;i="5.51,368,1526342400"; d="scan'208,217";a="144093303"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2018 03:41:21 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id w6I3fKUu019602 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Jul 2018 03:41:21 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 17 Jul 2018 23:41:20 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Tue, 17 Jul 2018 23:41:20 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Tim Jenkins (timjenki)" <timjenki@cisco.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] YangPush now
Thread-Index: AQHUHhHrAK87NKpG2E+Ouz7jjC6MRKSUNnVA
Date: Wed, 18 Jul 2018 03:41:19 +0000
Message-ID: <a54850668bfb4483b89f4c2b15bf5f44@XCH-RTP-013.cisco.com>
References: <2E1BAD12-EFF2-4E35-B232-57A4C4490989@cisco.com> <20180717055030.7bmzlychtznf3mso@anna.jacobs.jacobs-university.de> <18622ABD-DB9F-406C-836F-64649F3D8FF6@cisco.com> <20180717172036.hhuoq6fzs7ctblpf@anna.jacobs.jacobs-university.de> <CABCOCHS8cfqKLaQe9M4tu-2zkZ5=6-a2FEv+idJwZiW_btx_Zw@mail.gmail.com>
In-Reply-To: <CABCOCHS8cfqKLaQe9M4tu-2zkZ5=6-a2FEv+idJwZiW_btx_Zw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.243.239]
Content-Type: multipart/alternative; boundary="_000_a54850668bfb4483b89f4c2b15bf5f44XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/u6Mt9jazFM1YgN5Uwu_yzWlLn2o>
Subject: Re: [Netconf] YangPush now
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 18 Jul 2018 03:41:27 -0000

From: Andy Bierman, July 17, 2018 5:06 PM


Hi,

I agree with Juergen that there are TBD features in SN.

I also agree with the co-authors that it would be too much work to refactor now.
It should be faster to complete SN then split it and start over.

The main issues here seem to be:
 1) no end-point for the configured receiver

<Eric> There should not be any endpoint in SN.   Endpoint specifics would need to be exposed in the transport document.

Note that we tried for years to have something transport independent for receivers in SN.   I.e., there was an endpoint “address” in the SN from 00-v13.   Kent and Martin argued it out of the SN draft.  For more on this, there is plenty extensive email alias archive on this subject.   As a result, with v14, “address” is gone.

To summarize Kent & Martin’s argument which led to the v14 change: current endpoint “address” might be confused with call home.  We won’t agree with anything that might conflict with call home.  It is better to do nothing if we can’t agree on something.  By doing nothing, vendors can augment in what is needed.

For v14 we didn’t just ignore the hole removing “address” made of course.  Many email iterations over the last several months have proposed YANG augmentation code for those people who *do* want a leafref to netconf-server.yang now.  So if it makes this “endpoint completeness” issue go away, I would happily put an informational appendix into NETCONF-notif.  This appendix would include the necessary augmentations to the leafref which Kent and I worked through.

But we should go no farther than an informational appendix on this.  The current solution of doing nothing is actually a far more compelling answer than the inserting a mandatory (but then deviated away) leafref to an unimplemented ietf call home model.   This would allow the “solution is complete” answer to match to what dominates the industry: vendors who have their own key and call home infrastructure.


 2) CallHome procedures and server requirements such as
     processing normal NC or RC requests on the session

This is described in draft-ietf-netconf-netconf-event-notifications, section 5.2.

 3) no MUST or SHOULD implement values for transport

This is on purpose.  IoT is not going to want a NETCONF transport default.   The current draft allows identities to be added for transports supported by a platform.  It is not possible to configure a transport the platform doesn’t have.

I would like to get YANG Push done but not at the expense of the review cycles.
There is nothing stopping the WG from working faster (e.g. virtual interim).

If the WG chairs agreed to a final set of issues as input to the meeting.  And agreed to abide by what came out of this interim as binding, final consensus, it might be a possibility.

Just declaring everything done gets it out of the WG faster,
but may not mean the RFC will be out faster.

Topics #1 & #2 above are transport specific.  It would seem getting SN & YP to review beyond the WG should speed the final process.

Eric


Andy




Andy


On Tue, Jul 17, 2018 at 10:20 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>> wrote:
I see several pieces but I do not see how the pieces give me a
workable solution nor do I see how such a solution gives me
interoperability.

If I configure a subscription, how does the flow of notifications work
over NC and RC? How do I configure where the connection goes?  What is
the RC resource that provides me the notification stream?  How will
all of this work if the endpoints in the future want to negotiate
different encodings?

Since you said you implemented this: What exactly did you implement,
what did not leave out, what did have to add to make it work?

/js

On Tue, Jul 17, 2018 at 01:20:55PM +0000, Tim Jenkins (timjenki) wrote:
> Juergen,
>
> To flip this around, I don’t understand where the difficulties are.
>
> But here’s what I see:
>
>   1.  The format of the update notifications should be the same whether the subscription is dynamic or configured for a given transport and encoding. I believe we have that.
>   2.  There are some differences in out of band notifications when I last read the drafts in details; these were explained by the different connection setup contexts. But this is otherwise unrelated to configured subscriptions.
>   3.  Since the transport specific details are now separate from the base line drafts, it allows transport specific behaviour to decide how the connections (for configured subscriptions) are to be setup. We have usable variations of “call home” or “dial out” or whatever you want to call it for the cases we need. Admittedly, we do have to provide augmentations for some of the protocols, but then, that’s the intent of the design.
>
> BTW, my comment below was sent last week. I have no idea how/why it arrived on the list after the IETF meeting yesterday.
>
> Tim
>
> --
> Cisco Systems Canada Co.
> 2000 Innovation Drive
> Kanata, ON, Canada, K2K 3E8
> Preferences <http://www.cisco.com/offer/subscribe/?sid=000478326>
> Unsubscribe <http://www.cisco.com/offer/unsubscribe/?sid=000478327>
> Privacy <http://www.cisco.com/web/siteassets/legal/privacy.html>
>
> From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>>
> Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>>
> Date: Tuesday, July 17, 2018 at 1:50 AM
> To: "Tim Jenkins (timjenki)" <timjenki@cisco.com<mailto:timjenki@cisco.com>>
> Cc: "netconf@ietf.org<mailto:netconf@ietf.org>" <netconf@ietf.org<mailto:netconf@ietf.org>>
> Subject: Re: [Netconf] YangPush now
>
> I do not think that configured subscriptions have been fully worked
> out. Nor do I see how I configure something that actually works.
> Since you have implemented this, perhaps you can help me to understand
> how all this actually works with the text in the current IDs.
>
> /js
>
> On Mon, Jul 16, 2018 at 11:10:52PM +0000, Tim Jenkins (timjenki) wrote:
> Hi,
> As an implementor of the drafts, I suggest enough already: we've been going down this path for quite some time.
> Please publish both sets (dynamic and configured, and SN and YP) together.
> Thanks,
> Tim
> > Hi,
> >
> > It might be useful (at least to me), if the draft authors could explicitly indicate what their preference is, and also which of the choices below they think would lead to the work completing most quickly.
> >
> > Thanks,
> > Rob
> >
> >
> > On 12/07/2018 19:48, Kent Watsen wrote:
> > I would like to strongly +1 retaining the configured subscriptions
> > (not necessarily in the Push draft itself for the sake of expediting
> > WGLC or
> > modularity)
> > Ah, so here's another hum question: with or without yang push..
> >
> > hums now are:
> >
> >  1. dynamic subscriptions ~ configured subscriptions
> >   a. dynamic first, then configured (published sequentially)
> >  b. dynamic and configure together (published in parallel)
> >
> >   2. subscribed-notifications ~ yang-push
> >     a. SN first, then YP  (published sequentially)
> >     b. SN and YP together (published in parallel)
> >
> > Eric/Alex: please include a slide with this somewhere in your preso.
> >
> > Thanks,
> > Kent // chair
> _______________________________________________
> Netconf mailing list
> mailto:Netconf@ietf.org<mailto:Netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf
> --
> Cisco Systems Canada Co.
> 2000 Innovation Drive
> Kanata, ON, Canada, K2K 3E8
> Preferences <http://www.cisco.com/offer/subscribe/?sid=000478326>
> Unsubscribe <http://www.cisco.com/offer/unsubscribe/?sid=000478327>
> Privacy <http://www.cisco.com/web/siteassets/legal/privacy.html>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org<mailto:Netconf@ietf.org><mailto:Netconf@ietf.org<mailto:Netconf@ietf.org>>
> https://www.ietf.org/mailman/listinfo/netconf
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>

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

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