Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice? (was RE: YangPush now)

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 27 July 2018 15:03 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 08388130DED; Fri, 27 Jul 2018 08:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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 9MlljBso9nuS; Fri, 27 Jul 2018 08:03:23 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2E2130DC6; Fri, 27 Jul 2018 08:03:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3128; q=dns/txt; s=iport; t=1532703803; x=1533913403; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YBaaBYEIPaZhY3hjJfN3CrmYA5FJzcQhOXt5CTLLtL8=; b=FNwy2hTiuWkVNBJqtVCbPGHo/7afPgOKjs59c/W0qxARRYD8wUhl4rJh WrW16cRU0X+mBnGdiLRHKkWRJ6O5XlBzv/8dUq20THkWrxhSvEolzrfhk 8hAj0DaIagz6mX0VFhzVmF5Xu5RUCL6IjTXV+/gISar/onhTmvCRgA8tG U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnAQAxM1tb/4ENJK1YAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDIAQqY38oCpg1ggyXSwsjhANGAoJ7ITcVAQIBAQIBAQJ?= =?us-ascii?q?tHAyFNgEBAQMBOj8FCQICAQgOAgUDDREQGxclAgQODYJNTIF3CA+vPoo9BQW?= =?us-ascii?q?IfReBQT+EI4MbAgGBPwEBPxEVhG8gApoLCQKPLI4Okg0CERSBJDMigVJwFYM?= =?us-ascii?q?kgiUXEYNnhGGFPm8BjReBH4EbAQE?=
X-IronPort-AV: E=Sophos;i="5.51,409,1526342400"; d="scan'208";a="426687139"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2018 15:03:22 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w6RF3MAF020847 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Jul 2018 15:03:22 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; Fri, 27 Jul 2018 11:03:21 -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; Fri, 27 Jul 2018 11:03:21 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: Kent Watsen <kwatsen@juniper.net>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [yang-doctors] YANG Doctor question: empty mandatory choice? (was RE: [Netconf] YangPush now)
Thread-Index: AQHUJS2cZg8w9iUFbU+0+L6a3bxq1aSiIzgwgAC1BICAADdbkA==
Date: Fri, 27 Jul 2018 15:03:21 +0000
Message-ID: <643f32911e094f649c5007c5524112be@XCH-RTP-013.cisco.com>
References: <727ae35abd394a85812168615acce2d3@XCH-RTP-013.cisco.com> <20180726221120.bv3mtlitoqqov2zm@anna.jacobs.jacobs-university.de> <1b58e76f527442c3a0fa34437b9f0cd4@XCH-RTP-013.cisco.com> <20180727060507.v7ljp6au4i46ezs3@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180727060507.v7ljp6au4i46ezs3@anna.jacobs.jacobs-university.de>
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.118.56.234]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/1qWa-KzU-jGnLnUJ0elKniVUB10>
Subject: Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice? (was RE: 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: Fri, 27 Jul 2018 15:03:25 -0000

Hi Juergen,

I am fine either way if we incorporate the proposal or not.  Do you have the proposed construct is technically acceptable from the perspective of the YANG doctors?

Also below are some thoughts on your other points...

> From: Juergen Schoenwaelder, July 27, 2018 2:05 AM
> 
> On Thu, Jul 26, 2018 at 11:35:04PM +0000, Eric Voit (evoit) wrote:
> >
> > One transport for all receivers was a voted WG decision at IETF 101.
> Some of the reasons from threads like:
> > https://www.ietf.org/mail-archive/web/netconf/current/msg13875.html
> > https://www.ietf.org/mail-archive/web/netconf/current/msg14899.html
> >
> > include:
> > (1) Simpler YANG model
> > (2) Simpler implementation possible as a single configured
> > subscription need be connected to only one transport
> > (3) Simpler implementation in that there is no expectation set on the
> publisher that there will be no transport loss if the transport type is
> reconfigured for a particular receiver mid-subscription.
> > (4) Separation of implementation/troubleshooting concerns, as only one
> > transport is involved
> >
> 
> With the proposed choice construct, I think
> 
> (1) does not hold,

Agree.  

> (2) seems unclear (why are multiple identitical subscriptions for
>     different transports cheaper than one subscriptions with multiple
>     transports?)

Deep within the archived discussions, there were implementation consideration points made about managing content and security filtering across different transports and encodings for a single subscription.  (E.g., what happens if filtering happens after encoding and a change is made to the subscription or security filters, how do you ensure the all filtering is applied at the same event boundary?)

> (3) I do not understand

There are a set of implications which can be avoided.  For example controllers (which are receivers) will be consuming these events.  Controller based applications are less likely to have an expectation that there will no event replication for a single subscription-id for a publisher when that subscription-id transitions from one transport to another.  

> (4) I do not understand (since you can easily distinguish the receiver
>     and label log messages by receiver)
> 
> If we would be serious about simplification to lower the point of entry, we
> would have only a single receiver for a configured subscription. Allowing
> multiple receivers as long as they use the same transport seems like an
> arbitrary CLR.

Yes, this was considered.  However there are use cases where identical event streams must be sent for receiver redundancy reasons.  The current design can support that possibility.  Beyond that, there are deployment proof points from oc-telemetry.yang that this is a desirable capability.

Eric
 
> /js
> 
> --
> 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/>