Re: [netmod] features in import

Andy Bierman <andy@yumaworks.com> Thu, 31 January 2019 15:32 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5938E12958B for <netmod@ietfa.amsl.com>; Thu, 31 Jan 2019 07:32:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level:
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 gODcRkjvHysf for <netmod@ietfa.amsl.com>; Thu, 31 Jan 2019 07:32:34 -0800 (PST)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 20CCC1286D9 for <netmod@ietf.org>; Thu, 31 Jan 2019 07:32:34 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id x85-v6so3060990ljb.2 for <netmod@ietf.org>; Thu, 31 Jan 2019 07:32:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q1999hFGtd7wlQzoxu6O/30ANn8Wl2FLG3Zs6Mbus4I=; b=DHN8yc2aRGyacSm81569KArsLDW39POel+o4dY9yzvW2Yk4G71c2x5Xa3WLt7JPB7j x+V5jN/JZ47J418LdkxV5XsojL5tuMMGlnfwOuzJjRsrNu/Rykb8o/ruo/2uNbRYpJNG 9oRzhxbJAUeBJ5K4uJT81O9mP0jTce4qTj4dv5tCUX7etzoF/weVPn8yhKrWfPMqta7z 8dSmF9CtcGIuGHcHIqWjaPHlcClP/PpgufV0uWJ2OdnK/4Co8eiyhHLO6ttEDhA7Z1WP oydxttDbfSnv9/m9pUSmLsb/k/sNAjlReHOmRIWmnKh+63ccezNSzsTrSO4yxl5tQqD/ WnAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q1999hFGtd7wlQzoxu6O/30ANn8Wl2FLG3Zs6Mbus4I=; b=L3v7M5RnPLrD9oCfD36B/DXXmHPbjUTOXNO6UmtskeUtQy+oqz86lHHRUR6qIuQ8XD kKC3YdMXy7kkcwHUy3Yi59zSl1N9V+OTEt4Cy7YNAXHxN+lkVMvnZqO7eJgyxMJRdIKO iiqQK6MO/9u2I9WVTpdIOGdvYR9c7xEmN3sFWxII2LkcCaUvxEWES25YsyGBQZBh9CR0 s0WD8bpz++kVOJ7u8dEub/WiBwomtFDzZhZMKdu/cFU+ywAUV8Xl4FdDEktVDIdhx7o5 NPilatYKFPzNUGoBkFgb64OnPHAyZ/s930/xot4NumO1km45zrKUSZtd2WVaqVE6NCVA bEFw==
X-Gm-Message-State: AJcUuke2TIHzBa4oXibUCOdW6rhVPcOqQW4w905LS/SgPVMq4Q7G2U4A JiPoGNXNs0Na/zm8/z40TNrZDTkqmret9iBWFjZrkQ==
X-Google-Smtp-Source: ALg8bN5za3ZhI5V/w3s7/GHI56bIrWJneh+3viJ1YXI9OrQkdYWOiAneeQHYBawrMrPtEfaGvHA549oZVkOjj2B9a24=
X-Received: by 2002:a2e:458b:: with SMTP id s133-v6mr30696948lja.170.1548948751901; Thu, 31 Jan 2019 07:32:31 -0800 (PST)
MIME-Version: 1.0
References: <CABCOCHRTOY_W6Z3Sc7ejm0j=vEdAE221wLveH8w04ekHQnc4Zw@mail.gmail.com> <20190131.094407.267764793396247491.mbj@tail-f.com> <CABCOCHTh7Kn+_bJwgp=CzQunXG2ZFea3Lc+wTvX-unSPEOzxOg@mail.gmail.com> <20190131.115828.2130777685875370834.mbj@tail-f.com>
In-Reply-To: <20190131.115828.2130777685875370834.mbj@tail-f.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 31 Jan 2019 07:32:20 -0800
Message-ID: <CABCOCHQ+3h=1EV3d4Yx6P03Q_ux5R5OX1p+bOeFhWRWCL5qtFA@mail.gmail.com>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: Ladislav Lhotka <lhotka@nic.cz>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000220bb80580c2bca6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-OG-LjZ5RjUj-Gomw1LobUpnQ9M>
Subject: Re: [netmod] features in import
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Jan 2019 15:32:37 -0000

On Thu, Jan 31, 2019 at 2:58 AM Martin Bjorklund <mbj@tail-f.com> wrote:

> Andy Bierman <andy@yumaworks.com> wrote:
> > On Thu, Jan 31, 2019 at 12:44 AM Martin Bjorklund <mbj@tail-f.com>
> wrote:
> >
> > > Andy Bierman <andy@yumaworks.com> wrote:
> > > > Hi,
> > > >
> > > > I do not agree these changes should be made at this late date.
> > > > It seems to me that in order to support a feature you have to
> implement
> > > it,
> > > > and therefore if any features are set then the module is
> implemented, not
> > > > imported.
> > >
> > > But this is not what RFC 7950 says about implement:
> > >
> > >    A server implements a module if it implements the module's data
> > >    nodes, RPCs, actions, notifications, and deviations.
> > >
> > > > All features should be set to false in an import-only module.
> > > >
> > > > IMO this interpretation holds for typedef modules like
> iana-crypt-hash.
> > > > We list that as implemented (because it is) and the features that are
> > > > supported are set.
> > >
> > > If a module consists only of typedefs, there is no problem.
> > > Conformance "import" or "import-only" modules exist in YL b/c modules
> > > may have a mix of typedefs and data nodes etc.
> > >
> > > So in the case that Lada brought up, a server would have to list the
> > > module as implemented with a certain set of features; and then also
> > > deviate all nodes/rpc/notifc etc as 'not-implemented'.
> > >
> > >
> > So what. Using deviate(not-supported) to cherry-pick what you want to
> > implement
> > out of a module is how it is supposed to work.
> >
> > A server has to implement a feature to advertise it.
>
> As per 7950, this is not true, as I pointed out earlier.
>
>
I think 7950 is wrong then


> Note that with current YL (RFC 7895), it *is* in fact possible to
> handle this case; you can list the features supported for an
> import-only module.  The new YL removes this possibility (by
> mistake).
>
>
It is not a mistake.
The draft was reviewed 100 times.
It looks intentional.

I still don't understand the logic behind implementing a feature in a
module you don't implement.
There are plenty of cases (augment) where the imported module must also be
an implemented module.  Not sure what problem is solved by listing the
module with
features as a real module.

I don't think the new YL should be changed at this late date.



>
> /martin
>

Andy


>
>
> > Therefore the module containing the feature cannot be import-only.
> >
> >
> >
> > > /martin
> > >
> > >
> > Andy
> >
> >
> > > >
> > > >
> > > > Andy
> > > >
> > > > On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund <mbj@tail-f.com>
> > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list
> for
> > > > > > import-only modules. But is it really so that features have no
> use in
> > > > > > such modules?
> > > > > >
> > > > > > For example, an enum can depend on a feature, and if it is
> inside a
> > > > > > typedef, it can also be in an import-only module. What if that
> > > feature
> > > > > > is defined in the same module?
> > > > >
> > > > > I think you're right, and that this is an unfortunate omission.
> > > > >
> > > > > The fix is simple though; we would have to add the leaf-list
> features
> > > > > to import-only.  Probably refactor the "feature" leaf-list into a
> > > > > grouping so it works like the grouping location-leaf-list:
> > > > >
> > > > >   grouping feature-leaf-list {
> > > > >     leaf-list feature {
> > > > >       type yang:yang-identifier;
> > > > >       description
> > > > >         "List of all YANG feature names from this module that are
> > > > >          supported by the server, regardless whether they are
> defined
> > > > >          in the module or any included submodule.";
> > > > >     }
> > > > >   }
> > > > >
> > > > > And then "uses feature-leaf-list":
> > > > >
> > > > > OLD:
> > > > >
> > > > >   grouping module-implementation-parameters {
> > > > >     description
> > > > >       "Parameters for describing the implementation of a module.";
> > > > >
> > > > >     leaf-list feature {
> > > > >       type yang:yang-identifier;
> > > > >       description
> > > > >         "List of all YANG feature names from this module that are
> > > > >          supported by the server, regardless whether they are
> defined
> > > > >          in the module or any included submodule.";
> > > > >     }
> > > > >
> > > > > NEW:
> > > > >
> > > > >   grouping module-implementation-parameters {
> > > > >     description
> > > > >       "Parameters for describing the implementation of a module.";
> > > > >
> > > > >     uses feature-leaf-list;
> > > > >
> > > > >
> > > > > And in the list "import-only":
> > > > >
> > > > > OLD:
> > > > >
> > > > >       uses location-leaf-list;
> > > > >
> > > > >       uses feature-leaf-list;
> > > > >
> > > > >
> > > > >
> > > > > /martin
> > > > >
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > >
> > >
>