Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice?
Andy Bierman <andy@yumaworks.com> Wed, 01 August 2018 18:42 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 C78B0130E51 for <netconf@ietfa.amsl.com>; Wed, 1 Aug 2018 11:42:08 -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 DmuE33quShIo for <netconf@ietfa.amsl.com>; Wed, 1 Aug 2018 11:42:05 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 B673E130E4C for <netconf@ietf.org>; Wed, 1 Aug 2018 11:42:04 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id y17-v6so17730874ljy.8 for <netconf@ietf.org>; Wed, 01 Aug 2018 11:42:04 -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=qerboX9+GO3Tfuya8o1IApSBrJaaulxlCfc+nXSbljE=; b=vzgVo3zghddIa/1f59oOUhSYH0ALT9j2qzIKl+4EysLaoB6blxoZg12gEm+Mwio2Uc s1g6DI9QSaigxLf6Nvf1MQtEFXzZhUc1S7XQDBWH5E5zhUnof0jloNAnbdRdGkJta1Bg jA635YXVnLgFGLdGrLatKWQ0AVDK493uPAKX9ypkVAsE2Ex3aZ+ZuxKZ4YshyX81sODg jIMQdomUwuRsCOCNatGTSq6560Ewdz3ijwoouITNXGhby3po64KZD+ZcoqVaIy2kLvqi 58z2zsL/JBuBm2aMvgY6kvIjf2nzPeUevfA/ubU2mXppXwnuvuxueNrGw6Oh0B5LBlEQ al9A==
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=qerboX9+GO3Tfuya8o1IApSBrJaaulxlCfc+nXSbljE=; b=QE7OXSrNbNPFRMTB+Gb6vVc2r413jvucdn9yUbLSzYpvGdMWT0P2XejBx1zPjaWcMB cgWSV2oplucJBcSpyEXfV+KlJnh3FIzUiYy4uoXmdo2eM9ZmKyhTTyO64pP5j5FaiAaZ NqmqbN+G9UKjS2eH5FCgbAB6/92C2rZ1UdkrCf+8hl0yCpsMeFbURProA23k/C+fov3o jEs/X6J9BpETjz+k1MW84F15XQJ6epg3h50shKCKS3zTlyWG2yjo3KpxgvhOcEnre/z2 Nlq+HyPVVjb0j2JiSTOlaDnGG4OhE9f8fmjONprw5CUqy4dg2XlzilRbYXnHesuQH6BB 971g==
X-Gm-Message-State: AOUpUlEteLBvM0nZcqfzgo2kwy6hHXkJJtZZN8i1uut2GKMbj7ybxBZq t6xJetVlaoV0E7V8m1GxDgXK7C6jKhzJgm2SpBwUeg==
X-Google-Smtp-Source: AAOMgpcYB8BvJDxIFuvtFehlElVoXEH9ST9Z7WcsUZuh9d4zWhwlQcjQ/mPQpJzhKhyADD/1h5xJM219XA1B4EPvS00=
X-Received: by 2002:a2e:2ac3:: with SMTP id q186-v6mr19587584ljq.123.1533148922859; Wed, 01 Aug 2018 11:42:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 11:42:01 -0700 (PDT)
In-Reply-To: <958669b9-c523-3c43-eca4-fbc255fc1bc8@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> <CABCOCHRtg9jB0=b5bPPT3MS0QJcwgAY24Fg0RewXhPMR8Y+O0w@mail.gmail.com> <958669b9-c523-3c43-eca4-fbc255fc1bc8@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 01 Aug 2018 11:42:01 -0700
Message-ID: <CABCOCHRv9VGTwkvcnQz+VZDXK=+5pp-mdxQjdRmE=kXZPSDSXQ@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="000000000000ef66410572640c70"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/nj12l7-iY9bZTBvZ7WkdN09hTfk>
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 18:42:09 -0000
On Wed, Aug 1, 2018 at 9:48 AM, Robert Wilton <rwilton@cisco.com> wrote: > > > On 01/08/2018 17:09, Andy Bierman wrote: > > > > 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? > > Yes, making that indication is the whole purpose of adding the "mandatory: > true" to the empty choice. Note, that I see that the "mandatory true" is > there to say that every configured subscription must have a transport > configured, which if true, doesn't seem unreasonable. I.e. my main point > is that I don't have an issue with this generic YANG design. > > It just seems strange that the model designers are positive the solution belongs in a case-stmt inside this choice. So positive that MUST is in order, which means harm to the Internet will happen if this choice is not provided, with no possibility of any exception ever. That's why I suggested SHOULD in the first place, which would go in the description-stmt. I can imagine a vendor augmenting this choice with a <not-used/> leaf, just to get rid of the validation error. Andy In this particular instance, I'm also fine if "mandatory: true" is left > out, but I don't really agree with writing the equivalent of "mandatory: > true" in the description, that seems like a poor compromise. > > However, this is probably all bike-shedding. I think that any of the > discussed solutions is acceptable, as long as it is obvious to the readers > of the YANG modules that a case statement must be provided for it to be > useful, and I make the assumption that sane vendors won't enable the > "configured" feature, if there is no actual way of configuring usable > subscriptions. > > Perhaps Eric can propose his preferred choice, and we can see if anyone > still objects, otherwise maybe we can move on? > > Thanks, > Rob > > > > > 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 >>> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g> >>> > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> >>> >> >> >> >> _______________________________________________ >> yang-doctors mailing listyang-doctors@ietf.orghttps://www.ietf.org/mailman/listinfo/yang-doctors >> >> >> > >
- 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