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

Andy Bierman <andy@yumaworks.com> Thu, 02 August 2018 00:00 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 17D2C130EB8 for <netconf@ietfa.amsl.com>; Wed, 1 Aug 2018 17:00:25 -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=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 SHAwzsDdEblX for <netconf@ietfa.amsl.com>; Wed, 1 Aug 2018 17:00:21 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 8F92F130ED3 for <netconf@ietf.org>; Wed, 1 Aug 2018 17:00:19 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id f8-v6so325921ljk.1 for <netconf@ietf.org>; Wed, 01 Aug 2018 17:00:19 -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=e5p4XMuyJqhDZJq5nXVFyLufnOvotus6FF9vZMdExsw=; b=HPGTchtvl+v//pqCtAql6bFYrlwsBHl9Z4BZ6wNfnyAxIuWK4C92qDAO94jUaLfD0f ftTUhxXPo3hSdeli702tm0pVhxALVSFYiY7wYPp9qzoLjnhQ8DddeuSaSTSoUkpsL0B4 g71uUCwsQqVJAXFJA3+8rRzniBblqfFA6kZgfgt2mudzGqhmbZAllzl8IO5DX0hRZsoM 5x3CWBocrazClpn1FO/nJqiWby4ArzUupTDnLr+1MBjKuftLAqbrO0OSsfh250puniMZ sa0J8a0WlLqy5BkKMsgW5/UUkVPPD7hCWlMfPJaWDGheS+d8V97Dx5rzT++hF7/LjdFU zgYA==
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=e5p4XMuyJqhDZJq5nXVFyLufnOvotus6FF9vZMdExsw=; b=VxRg9REMJayWZ6NK0K7sOo8yesOQVYWZGS30jsruWUPKYx09RC/ewvMEkZmoAbho2R RZHcbmwqmmsUnP0c/ifggGAyjH3yDYo5nDn0fPgksTaRwuMzHuEpvm6ze15yeFjNT8vT cIjW19+TKgTNIQccmGatd1ovhIK3pP0+bG3K4nJ5tVX6VSpqUNdl2H9jMTqpvtCPZfn5 rUMlaZyE8NSTMWatkWbbr15oDwMvIWdPI1FOUdXaRqn4/SxcJjUFGgDUh7saKNLM5OxA /BN1fXu1UotiMbaw0hnOr/GuJJbTkgY6Vz8W+jktSgE1nUTExJ01JKeWZKOtGb2I7hC+ xJCw==
X-Gm-Message-State: AOUpUlEdWju1wE2RaLUdfkSQf/F5/F+Kp7vVjlV3vMBf14pYpRD1Qoa3 pIklkNOUztt8lOQgkQiJ6VOcZFXTnSmiN0/rWO2D3w==
X-Google-Smtp-Source: AAOMgpcXwe5zRtamMR0A68KKQkOvugHp78fNt2lOFkTArHDtr9oqBzl1Dwniqb9/3R6BX6aQFw08Hs+rfbgajG3NSis=
X-Received: by 2002:a2e:9a16:: with SMTP id o22-v6mr303229lji.17.1533168017534; Wed, 01 Aug 2018 17:00:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 17:00:16 -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 17:00:16 -0700
Message-ID: <CABCOCHQn6aVV6iEL8pCUAf1QGNQM=1GNEtyX9iTV03Cm1tpivQ@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="0000000000001100520572687fc2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/BErX3u1Ial7qUxyACU9J5PpCyIc>
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: Thu, 02 Aug 2018 00:00:25 -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.
>


It really is not OK, and has never been OK, which is why I think the next
version of YANG
should try to get this right.

As a client developer, I want to know the contract in advance, without any
missing clauses.
With a self-contained module (only internal + augment + uses) the entire
contract is clear
(at least module names are specified, maybe not revisions on imports  (Ver
DT will fix that)

A mandatory choice depending on 100% external augments is not
self-contained.
It is not a complete contract.

IMO, the way to fix it is to expand the conformance for YANG modules so
that packages
could be specified, or perhaps virtual external dependencies. YANG catalog
says what a vendor
does implement. YANG Conformance says what a vendor is supposed to
implement.
The client developer needs to know both.


Andy



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



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