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 06:05 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 81D19130DFE; Thu, 26 Jul 2018 23:05:13 -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 5ioSbtYj251j; Thu, 26 Jul 2018 23:05:10 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id ABB42130DDC; Thu, 26 Jul 2018 23:05:10 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 5DDEB2386A02; Fri, 27 Jul 2018 08:05:08 +0200 (CEST)
Date: Fri, 27 Jul 2018 08:05:07 +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: <20180727060507.v7ljp6au4i46ezs3@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1b58e76f527442c3a0fa34437b9f0cd4@XCH-RTP-013.cisco.com>
User-Agent: NeoMutt/20180716
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/6JucAYyFdyV0e26Z3nhTRVz5eb4>
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 06:05:14 -0000

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,
(2) seems unclear (why are multiple identitical subscriptions for
    different transports cheaper than one subscriptions with multiple
    transports?)
(3) I do not understand
(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.

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