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

Martin Bjorklund <mbj@tail-f.com> Sun, 29 July 2018 15:53 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 C9385130E6D; Sun, 29 Jul 2018 08:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable 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 P8cH1QhIOrwV; Sun, 29 Jul 2018 08:53:57 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 60026130DC8; Sun, 29 Jul 2018 08:53:57 -0700 (PDT)
Received: from localhost (h-155-4-133-90.NA.cust.bahnhof.se [155.4.133.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 91BFE1AE018A; Sun, 29 Jul 2018 17:53:56 +0200 (CEST)
Date: Sun, 29 Jul 2018 17:53:56 +0200 (CEST)
Message-Id: <20180729.175356.1841285666617255654.mbj@tail-f.com>
To: evoit=40cisco.com@dmarc.ietf.org
Cc: kwatsen@juniper.net, yang-doctors@ietf.org, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <727ae35abd394a85812168615acce2d3@XCH-RTP-013.cisco.com>
References: <727ae35abd394a85812168615acce2d3@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/EwjFx6BRy-j9RuPChQkOGDbS_bg>
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: Sun, 29 Jul 2018 15:54:00 -0000

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



/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