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

Martin Bjorklund <mbj@tail-f.com> Mon, 30 July 2018 18:41 UTC

Return-Path: <mbj@tail-f.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 376B9130EAE; Mon, 30 Jul 2018 11:41:53 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 tJaKoxBTSzUW; Mon, 30 Jul 2018 11:41:51 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F1650130E2A; Mon, 30 Jul 2018 11:41:50 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 930BC1AE0290; Mon, 30 Jul 2018 20:41:49 +0200 (CEST)
Date: Mon, 30 Jul 2018 20:41:42 +0200 (CEST)
Message-Id: <20180730.204142.1505732335534077415.mbj@tail-f.com>
To: evoit@cisco.com
Cc: kwatsen@juniper.net, yang-doctors@ietf.org, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <77080682bf90495caec48436453e4750@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>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/M4-XjQqXHlTTs034P0ZNXIsc1RA>
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: Mon, 30 Jul 2018 18:41:54 -0000

"Eric Voit (evoit)" <evoit@cisco.com> wrote:
> Hi Martin,
> 
> > From: Martin Bjorklund, July 29, 2018 11:54 AM
> > 
> > "Eric Voit \(evoit\)" <evoit=40cisco.com@dmarc.ietf.org> wrote:
> > > Hi YANG doctors,
> > >
> > >
> > >
> > > We are trying to close on some YANG push drafts.  There is one YANG
> > > related question I would like to bounce off of you before making a
> > > suggested change.
> > >
> > >
> > >
> > > In the thread:
> > >
> > > https://www.ietf.org/mail-archive/web/netconf/current/msg15169.html
> > >
> > > is the following request:
> > >
> > >
> > >
> > > > From: Kent Watsen, July 26, 2018 1:48 PM
> > >
> > > >
> > >
> > > > <chair hat on>
> > >
> > > > ...
> > >
> > > >
> > >
> > > > Assuming no objections, to close the issues discussed in Montreal,
> > > > we're waiting
> > >
> > > > for the following updates:
> > >
> > > >
> > >
> > > >   ...
> > >
> > > >   sub-notif: modify config model to mandate a transport
> > >
> > >
> > >
> > > What I believe Kent is asking for is that the
> > > ietf-subscribed-notifications.yang model should be enhanced to mandate
> > > that transport specific call home parameters are augmented under the
> > > container “receivers”.  He wants to do this by incorporating a
> > > mandatory choice, with no cases being identified.  Cases would be
> > > added via augmentations in subsequent drafts.
> > >
> > >
> > >
> > > Specifically, Kent's proposal as per
> > >
> > > https://www.ietf.org/mail-archive/web/netconf/current/msg15148.html
> > >
> > > is "to make the augmentation of a "notif" model mandatory (see the '+'
> > > lines below), to ensure that there is always something more than just
> > > a name being configured per receiver.
> > >
> > >
> > >
> > >       container receivers {
> > >
> > >         list receiver {
> > >
> > >           key "name";
> > >
> > >           min-elements 1;
> > >
> > >           leaf name {
> > >
> > >             type string;
> > >
> > >           }
> > >
> > >    +      choice transport {
> > >
> > >    +        mandatory true;
> > >
> > >    +        description
> > >
> > >    +          "Defines the transport-specific configuration data
> > >
> > >    +           for the selected transport.";
> > >
> > >    +      }  "
> > >
> > 
> > In a generic model like this one, I think the construct with a
> > mandatory choice
> > is ok.
> 
> It sounds like YANG doctors don't have a technical objection to Kent's
> proposal of an empty mandatory choice.
> 
> >  However, I am not convinced that this is the best solution for this
> >  model;
> > it depends a bit if transport is defined per receiver or per
> > subscription.
> > 
> > I assume that an augmentation would be done like this:
> > 
> >   module ietf-netconf-subscribed-notifications {
> >     ...
> >     prefix nsn;
> > 
> >     identity netconf { ... }
> > 
> >     augment /subscriptions/subscription/receivers/receiver/transport {
> >       when 'derived-from-or-self(../../../transport, "nsn:netconf"');
> > 
> >       case netconf {
> >         // leafref to call-home config
> >       }
> >     }
> >   }
> > 
> > ... so that *if* the client configures the mandatory "transport" leaf
> > to
> > "nsn:netconf", then it also MUST configure the corresponding
> > netconf-specific
> > params.
> 
> I agree that this is what an augmentation would look like.  (And based
> on the "../../../transport", this augmentation assumes that the WG
> sticks with it previous position that a transport stays at the
> subscription level).

Right, the when expression needs tweaking if the transport leaf moves.

> As the proposed augmentation by itself enforces a specific set of
> NETCONF transport parameters are configured (in the form of the
> leafref when the transport is "nsn:netconf"), do you see the empty
> mandatory choice as providing value?  I am ok with either answer on
> this, I am just trying to get closure.

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


/martin



> 
> Eric  
> 
> > /martin
> > 
> > 
> > >
> > >
> > > At this point there is an open question from Andy on this approach.
> > >
> > > https://www.ietf.org/mail-archive/web/netconf/current/msg15149.html
> > >
> > >
> > >
> > > Andy’s says:
> > >
> > > “The notion of an empty mandatory choice really stretches the
> > > definition of YANG Conformance. This says you cannot possible
> > > implement the SN module without some other module augmenting it. Yet
> > > there is no way in YANG (besides import) to say the module bar needs
> > > to be present if module foo is present.”
> > >
> > >
> > >
> > > My first question to you is would you object to mandatory choice
> > > statements without corresponding case statements?  If you *do* have an
> > > issue with an empty mandatory choice, we should likely stay with the
> > > current solution.
> > >
> > >
> > >
> > > If you see no issue with an empty mandatory choice, I have a second
> > > question for you.  For all receivers in a subscription, the selected
> > > transport choice case in Kent’s suggestion above MUST match to the
> > > value of the “transport” leaf which is one level higher in the tree.
> > > I.e.:
> > >
> > >
> > >
> > >     +--rw subscriptions
> > >
> > >        +--rw subscription* [identifier]
> > >
> > >           +--rw transport transport {configured}?
> > >
> > >           +--rw receivers
> > >
> > >              +--rw receiver* [name]
> > >
> > >              +--rw (transport)
> > >
> > >                 +--rw :(NETCONF)
> > >
> > >                 |  +--rw (NETCONF specific call home parameters)
> > >
> > >                 +--rw :(HTTP2)
> > >
> > >                     +--rw (HTTP2 specific parameters)
> > >
> > >
> > >
> > > (Note on the tree above, I inserted the NETCONF and HTTP2 cases of
> > > transport for illustration purposes for the question below.  These two
> > > cases would actually be incorporated via separate augmentations to the
> > > ietf-subscribed-notifications.yang model.)
> > >
> > >
> > >
> > > Considering above, It seems difficult to enforce that the transport
> > > cases selected under all receivers for a single subscription MUST be
> > > identical, and also MUST match to the value of the “transport” leaf
> > > under the subscription.
> > >
> > >
> > >
> > > Would the YANG doctors have any issue with the structure Kent suggests
> > > above?  If no, would the YANG doctors then mandate that integrity
> > > checks per performed across the receiver case instances under a
> > > subscription?  And if mandated, how might XPATH be encoded considering
> > > transport cases are only added via augmentation?
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Eric