Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice? (was RE: YangPush now)
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 27 July 2018 15:19 UTC
Return-Path: <j.schoenwaelder@jacobs-university.de>
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 516701292AD; Fri, 27 Jul 2018 08:19:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 FzD1_DPBydZn; Fri, 27 Jul 2018 08:19:23 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id 8E59A130EBD; Fri, 27 Jul 2018 08:19:23 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id B7D73239B174; Fri, 27 Jul 2018 17:19:22 +0200 (CEST)
Date: Fri, 27 Jul 2018 17:19:22 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Eric Voit (evoit)" <evoit@cisco.com>
Cc: Kent Watsen <kwatsen@juniper.net>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20180727151922.ds74qzetcxiqg3is@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Eric Voit (evoit)" <evoit@cisco.com>, Kent Watsen <kwatsen@juniper.net>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
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> <643f32911e094f649c5007c5524112be@XCH-RTP-013.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <643f32911e094f649c5007c5524112be@XCH-RTP-013.cisco.com>
User-Agent: NeoMutt/20180716
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/RwjF3da9776rJcyHUskuNm0O0FY>
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:19:27 -0000
On Fri, Jul 27, 2018 at 03:03:21PM +0000, Eric Voit (evoit) wrote: > > 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? > I understand Andy's comment not as a YANG issue but a more general question whether it is desirable to have a standard without a mandatory to implement standard transport. This goes beyond YANG syntax. > 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?) There is only one standard filtering mechanism (NACM) and that does not filter on the encoding (and it would be a bad layer violation to filter on the encoding). Since encodings may be negotiated by a transport, the single encoding argument falls apart as well. > > (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. I am still clueless. What is a 'transitions of transport'? My naive understanding of a subscription with a receiver and two transport is that the data goes to both. Or is the idea that these serve has failover backups? But then this may interact with similar features in the call-home documents (I did not check again but I think there were some failover mechanisms in there some time ago). > > (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. > OK. But then, I have not yet understood why the transports have to be the same in the model. (Which does not preclude that an implementation has a deviation that requires the multiple receivers of a subscription to use the same transport. And all this is only becoming an issue if an implementation does actually support multiple transports.) /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/>
- Re: [Netconf] [yang-doctors] YANG Doctor question… Andy Bierman
- Re: [Netconf] YANG Doctor question: empty mandato… Kent Watsen
- Re: [Netconf] YANG Doctor question: empty mandato… Andy Bierman
- Re: [Netconf] [yang-doctors] YANG Doctor question… Robert Wilton
- Re: [Netconf] [yang-doctors] YANG Doctor question… Andy Bierman
- Re: [Netconf] YANG Doctor question: empty mandato… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Robert Wilton
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Andy Bierman
- [Netconf] YANG Doctor question: empty mandatory c… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Juergen Schoenwaelder
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Juergen Schoenwaelder
- Re: [Netconf] [yang-doctors] YANG Doctor question… Juergen Schoenwaelder
- Re: [Netconf] [yang-doctors] YANG Doctor question… Robert Wilton
- Re: [Netconf] [yang-doctors] YANG Doctor question… Robert Wilton
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Juergen Schoenwaelder
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Juergen Schoenwaelder
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Andy Bierman
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Andy Bierman
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] YANG Doctor question: empty mandato… Kent Watsen
- Re: [Netconf] YANG Doctor question: empty mandato… Kent Watsen
- Re: [Netconf] YANG Doctor question: empty mandato… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Juergen Schoenwaelder
- Re: [Netconf] YANG Doctor question: empty mandato… Juergen Schoenwaelder
- Re: [Netconf] YANG Doctor question: empty mandato… Alexander Clemm
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Andy Bierman
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Andy Bierman
- Re: [Netconf] [yang-doctors] YANG Doctor question… Robert Wilton
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] YANG Doctor question: empty mandato… Kent Watsen
- Re: [Netconf] YANG Doctor question: empty mandato… Andy Bierman
- Re: [Netconf] YANG Doctor question: empty mandato… Einar Nilsen-Nygaard (einarnn)
- Re: [Netconf] YANG Doctor question: empty mandato… Einar Nilsen-Nygaard (einarnn)
- Re: [Netconf] YANG Doctor question: empty mandato… Henk Birkholz
- Re: [Netconf] YANG Doctor question: empty mandato… Andy Bierman
- Re: [Netconf] YANG Doctor question: empty mandato… Andy Bierman
- Re: [Netconf] YANG Doctor question: empty mandato… Kent Watsen
- Re: [Netconf] YANG Doctor question: empty mandato… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] YANG Doctor question: empty mandato… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… tom petch
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund
- Re: [Netconf] [yang-doctors] YANG Doctor question… Kent Watsen
- Re: [Netconf] [yang-doctors] YANG Doctor question… Eric Voit (evoit)
- Re: [Netconf] [yang-doctors] YANG Doctor question… Martin Bjorklund