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

Andy Bierman <andy@yumaworks.com> Wed, 01 August 2018 16:09 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 A943F129C6B for <netconf@ietfa.amsl.com>; Wed, 1 Aug 2018 09:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] autolearn=ham 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 uvOFCODdlv9M for <netconf@ietfa.amsl.com>; Wed, 1 Aug 2018 09:09:39 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 0AC36130F36 for <netconf@ietf.org>; Wed, 1 Aug 2018 09:09:39 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id a134-v6so13700775lfe.6 for <netconf@ietf.org>; Wed, 01 Aug 2018 09:09:38 -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=YAbcCIBUfFKC6cusfI2/OfEEmBYAcThOdPmNvq78E9c=; b=XZe9dCgGUsWi3vB/LH6bYtRtdHCB5/nx/2S4+6BSbqv3MmampJBzFEZReivzGKN5mU rgaShdhm6w06io0AaxuWuozkUkITA32h8629wAuibegEf8IXilRP8M2I0NrX6jQLRgIv mtYOGGXeF2yrCEdeAEODHZD+rnVMLeylEVnsI/cZVFpoy6PZHIBj79xcIRp9mFb610Lf vzCL1rK0JBqqxaJ1BFqFmLAVmF5aNriNGPS40DlzQab76CZb7aNAvPXrBdnH5FFIsSVc Xc8agKHoKIbRhI9ZKuNhI04AoiaXv/fa4fuvSdlXFYb5xAx63Kw2goGQ/0jMXXiJN1Cw LKqA==
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=YAbcCIBUfFKC6cusfI2/OfEEmBYAcThOdPmNvq78E9c=; b=INDCaLte4WXFb34s2FKlhpyIVOoZV2UaCUb7asrVyaWGM1JApGbxXwiog6YXsejqZ0 i/5kdrZ4wBVpFHwuqrEu6OJ79CeKBcuClOQqMAo6BXXXVWCaGxemxdOmVa5pJGUxhU3h au5IhJrn8np6RHJEHNy19t4dMeutRSN1aJCUYTM6oLboslK8G6vevRTH3/qh90QzPPKl LhP+iJTus89GLJCk2B+53D3Il9KG7txcaHrTOKPdRDgIk+obgEfTdLLUdQJ0se+9s6Qy eki2EPbFFzSuTQehQA9J2fMPSU4qddZXY5641UDeWs5WXBB2WiKELylDL4oxlZSTFmYi WIXQ==
X-Gm-Message-State: AOUpUlFRqObsgNv3EZSUfRN5/p8SEBQ5TfefLBURQyL2HC+Qw1eBH/U3 XpzLdcYozO6lDhT5M3tJo1txJbkkn7zHbejV3zcNhA==
X-Google-Smtp-Source: AAOMgpfda2QPz/XiroxWwZRigAp/dmI0/I6KvAyuORt1Qjyme+t+yQe62IHYw/2bUaQqsLDZDrQKAxFX35/JgmFy1/A=
X-Received: by 2002:a19:b598:: with SMTP id g24-v6mr16687478lfk.129.1533139777093; Wed, 01 Aug 2018 09:09:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 09:09:35 -0700 (PDT)
In-Reply-To: <05ee68cd-ccc0-6803-6c71-b3952ee5608d@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> <CABCOCHQPYyWgXS8Y_n5PN-AEQ5myQXX5s0KvkjQnfAh4VOMbrA@mail.gmail.com> <05ee68cd-ccc0-6803-6c71-b3952ee5608d@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 1 Aug 2018 09:09:35 -0700
Message-ID: <CABCOCHRtg9jB0=b5bPPT3MS0QJcwgAY24Fg0RewXhPMR8Y+O0w@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: "Eric Voit (evoit)" <evoit@cisco.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ce1dfb057261ebc7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/xGjI01usmFXAMLLoE8Xi8mSugKU>
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: Wed, 01 Aug 2018 16:09:43 -0000

On Wed, Aug 1, 2018 at 9:01 AM, Robert Wilton <rwilton@cisco.com> wrote:

>
>
> On 31/07/2018 21:31, Andy Bierman wrote:
>
>
>
> 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 think that "empty choice + mandatory true" it is OK from a conformance
> perspective.  The concept seems similar to an programmatic interface,
> abstract class, or even the abstract identity idea that has been proposed
> for YANG.  If a server implements the module but no augments of the choice
> then it cannot be configured because the constraint will always fail.
> Andy, is your concern that tooling will warn that part of the model is
> unusable?
>

That is possible.
I agree with Juergen that a mandatory empty choice clearly indicates that
the module is incomplete
and unusable on its own.  Is that a feature?

Andy


>
> I have to say that much prefer the option of putting "mandatory: true" in
> the choice than "MUST provide an implementation" in the description because
> the former is machine readable whilst the latter is not.
>
> However, I would also be fine not to have the "mandatory: true", but with
> the choice description to state something along the lines that the empty
> choice is to allow for augmentations of different transports, and
> configured subscriptions may not be usable unless at least one transport
> case statement is available."  But perhaps some implementation will provide
> the flexibility of defining a single transport for all subscriptions (if
> this is feasible).
>
> One other observation that could affect the decision here is that YANG
> allows "mandatory: true" to be removed in a future revision in a backwards
> compatible way, but doesn't allow it to be added.
>
> Thanks,
> Rob
>
>
>
> 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/>
>>
>
>
>
> _______________________________________________
> yang-doctors mailing listyang-doctors@ietf.orghttps://www.ietf.org/mailman/listinfo/yang-doctors
>
>
>