Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice?

Andy Bierman <andy@yumaworks.com> Tue, 31 July 2018 20:32 UTC

Return-Path: <andy@yumaworks.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 0B0B6130E80 for <netconf@ietfa.amsl.com>; Tue, 31 Jul 2018 13:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Level:
X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 SY91Y-Gu2OjR for <netconf@ietfa.amsl.com>; Tue, 31 Jul 2018 13:31:58 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7FE130E0C for <netconf@ietf.org>; Tue, 31 Jul 2018 13:31:57 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id b22-v6so11688681lfa.3 for <netconf@ietf.org>; Tue, 31 Jul 2018 13:31:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UAYxSbw52dAH0OlhRcRxzKHTElNaJURiXkEvUOxc304=; b=GBBsXxOmqyvEngR7yEigR7rsDM05laM8W7wp6AcV5yBmIk3OPnX2LxRgY+uvL28Kqq VS91ItiROYR9oD2VXJjlarzzyM9/u9Pvf9QTpNCiPOfZW+j9S0lh/Xxv9mEONMXIawHg 0q7r/1yYKZXSyQYNtOD+R5F4N1rlkbM9u3Jkwm67gfr8cl15EWoa5WAqOWgIuJU0P6ab WQWBLvUy/hIrUb3r+5kcv7cFmSzQXqKHVhCaysqe7WeJmIvcQYxOuRj9y4C6JyDI7vla 8bt2jTFKk1Ucmng5Q4I2c4myyH3mV6H7xFjkma57axzZjHbjJbjMwolW1sCWywHbSK51 OVdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UAYxSbw52dAH0OlhRcRxzKHTElNaJURiXkEvUOxc304=; b=Zk6+wUbPQ5JtR7B3aUp1XEq9w8EhqjSmLbBCfxIxSnMI12OEFHas4hHzy0DWLd5o5J OeVaC4i31hHZoJ5EdQmoMYPh1hzfH8NRy97Yj/tTHzM7npobAq3YZtKfSpNZgQMuH1CD eNUeqpvX8O1LJtH2KWEnHLof7IHm4XwhXbruCFjPfQIYwuHaxeAxvBxWBW0UCAezsTYG R10Csb3dDAOU9aie+LHtPGSWsfZgJ4KjdSb3PviiusCR6bAI5iJt/iQr1NmBWZsxoBYH oucXaqYn6zeQs0iO9mKQaub/6lDd6OwmU2cMC9mjd+B18AIq7OrDI0/9ZLk6BQuRkzsj KOVQ==
X-Gm-Message-State: AOUpUlHkbRtVpZs/xCUB1IfHB3VNRxFgshQ2lM06Cpr8NWIIOHOfudNF NztjPIiYbFc9MIqy/7asSOjSWCyulRlgHepbz8W5Qw==
X-Google-Smtp-Source: AAOMgpe5ZG66ILSURTODrNtsqGDxZVlnYqEDHFm+dY7EdTeJzzBB8R4UDsl2nt/uQo2gzNO5jsQ6roeFS15Kdp1UM8c=
X-Received: by 2002:a19:c3c7:: with SMTP id t190-v6mr13572361lff.108.1533069116020; Tue, 31 Jul 2018 13:31:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Tue, 31 Jul 2018 13:31:54 -0700 (PDT)
In-Reply-To: <b8dc903dc04a46088bcca106ac45c4fc@XCH-RTP-013.cisco.com>
References: <727ae35abd394a85812168615acce2d3@XCH-RTP-013.cisco.com> <20180729.175356.1841285666617255654.mbj@tail-f.com> <77080682bf90495caec48436453e4750@XCH-RTP-013.cisco.com> <20180730.204142.1505732335534077415.mbj@tail-f.com> <20180731174827.n5r2jebon45s2cxy@anna.jacobs.jacobs-university.de> <b8dc903dc04a46088bcca106ac45c4fc@XCH-RTP-013.cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 31 Jul 2018 13:31:54 -0700
Message-ID: <CABCOCHQPYyWgXS8Y_n5PN-AEQ5myQXX5s0KvkjQnfAh4VOMbrA@mail.gmail.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000013b3b50572517875"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/HgMKKrhiQYtjVQ3Z44UItZgf0aM>
Subject: Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice?
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: Tue, 31 Jul 2018 20:32:02 -0000

On Tue, Jul 31, 2018 at 12:39 PM, Eric Voit (evoit) <evoit@cisco.com> wrote:

> > From: Juergen Schoenwaelder, July 31, 2018 1:48 PM
> >
> > On Mon, Jul 30, 2018 at 08:41:42PM +0200, Martin Bjorklund wrote:
> > >
> > > The empty mandatory choice does provide value since it requires that
> > > some transport-specific parameters are configured.  However, can we
> > > assume that all transports require configuration parameters here?
> >
> > Can you have a receiver without any transport parameters?
> >
> > > It is probably safest to not have a mandatory choice, and instead
> > > ensure that each transport augements the proper params -- and since
> > > this is YANG 1.1, the transport params that are augmented can actually
> > > be marked as mandatory.
> >
> > Frankly, an empty mandatory choice quite clearly says "this is
> incomplete and
> > unusable without an augmentation".
>
> My read above is the YANG doctor's position is that we should *not* use
> the empty mandatory choice.  Let me know if I got this wrong.
>
>
I do not think a consensus call has been done yet, but I agree with Juergen
and already raised the point that YANG conformance does not handle a
"MUST augment" use-case very well.

I prefer the MUST be in the description-stmt for the choice,
instead of "mandatory true". (I prefer SHOULD but if the WG wants MUST)


Andy





> That would mean that each transport document supporting configured
> subscriptions would then augment transport specific parameters to
> "/subscriptions/subscription/receivers/receiver".   And (assuming the
> "single transport" decision of IETF100 isn't changed), that the identity
> "transport" could be leveraged to enforce that only a single transport
> specific set of credentials are associated with a receiver.
>
> A sample YANG augmentation for NETCONF would then look like:
>
> module ietf-netconf-subscribed-notifications {
>
>   prefix nsn;
>
>   import ietf-netconf-client { prefix ncc; }
>   import ietf-subscribed-notifications { prefix sn; }
>
>   identity netconf {
>     base sn:transport;
>     base sn:inline-address;
>     description
>       "NETCONF is used as a transport for notification messages and
>        state change notifications.";
>   }
>
>   augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
>    when 'derived-from(../../../transport, "nsn:netconf")';
>    description
>       "This augmentation allows NETCONF specific parameters to be
>       exposed for a receiver.";
>     leaf netconf-endpoint {
>       type leafref {
>         path "/ncc:netconf-client/ncc:initiate/ncc:netconf-server" +
>                 "/ncc:endpoints/ncc:endpoint/ncc:name";
>       }
>       mandatory true;
>       description
>         "Remote client which need to initiate the NETCONF transport if
>         an existing NETCONF session from that client is not available.";
>     }
>   }
> }
>
> Which results in:
>   +--rw subscriptions
>      +--rw subscription*
>         +--rw transport         transport  {configured}?
>         +--rw receivers
>            +--rw receiver*
>               +--rw nsn:netconf-endpoint    leafref
>
> 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/>
>