Re: [netmod] Does defining a feature require the module be implemented?

Andy Bierman <andy@yumaworks.com> Fri, 13 May 2022 16:05 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 85C1FC1594AC for <netmod@ietfa.amsl.com>; Fri, 13 May 2022 09:05:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXjZLi4cHNy2 for <netmod@ietfa.amsl.com>; Fri, 13 May 2022 09:05:21 -0700 (PDT)
Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711E9C159A3E for <netmod@ietf.org>; Fri, 13 May 2022 09:04:48 -0700 (PDT)
Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-2f7d7e3b5bfso95035077b3.5 for <netmod@ietf.org>; Fri, 13 May 2022 09:04:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kGEJLjOjQIm32YX9eYK0NqdOQs0OrOnit7VBhkdfXvc=; b=FSAGKiKH7eV3VoC/P8d6BFlUs/iX+jbKrsrBfyfdsJXfEO0MpBNnCFyZXnEmv9b1/1 EkdeSN9OtfM2DslWSRePgo/2Yyx3dPaSS7OPCW6X16cEZmd6rg2YviR5LzHFcEOrzeue KnaWsalDb0I5WrdDIt5wHCgN8RWFd8r3I3c1d1d2sejB9ZKtgIyk3eQbA7zt1GYqGMsE Krn+HxpZBvYwTvtwRdzOJi4P2yeVnukXMwOinqpwNq9QNz6328eigYX7A/Mtlwo1CaT2 ssAD4TXGi6CgfDIyY+35jlaioDwHJSWpe6CEEFk+1R33h0U9zN/h/u2M9S7sxH0M5LlJ zudA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kGEJLjOjQIm32YX9eYK0NqdOQs0OrOnit7VBhkdfXvc=; b=xkUomeKs3magzeaKvtUaVgDOUGi+tzxHGimXCi5Ons1Hm6WKMldTkKsoVIvKACmWdh 1UKSqt54IhsmRiqx2YYjH5DhFyPdgRON3xVLNCMB3uXW6Qna3L44mi4x35J/OOXrnicf Wimkf6YendcCKvnccgao8i8/Ow346fhsMmQcaYOG1xPp052ZBma3EN0ymLu1jzcmbjAm izY5OYLZ74iYS0bvQUtSrUZFRNrv5SSWmrbawLly+iHTADJY15tR2OgWKnaT9KiQU4Xx uwo6Xcas/0/sNXc/tPsGFUAi42W+vwHhNz3oM2X+7CAde+cCOLecKgjEXMWzyS0YwaYr MRhw==
X-Gm-Message-State: AOAM5335eVYEpLo7GzBqoGjraxe8pTugx+rTr5QviHaA7Mehg1/PHITb 536gpCirkXy8Y+uKHc6LvaWSDGOktQR98GdM/ii/P/yTIrc=
X-Google-Smtp-Source: ABdhPJzWIS9ngj+DnFA1krYi/ZfnbJ1nR+IBuuvB3ufVURmYyHre6jM8QV9p/5l2kPpY4OBpJI4oHg/LU+BIW7jzfdg=
X-Received: by 2002:a81:1787:0:b0:2fe:bc18:fcf6 with SMTP id 129-20020a811787000000b002febc18fcf6mr2874144ywx.159.1652457887161; Fri, 13 May 2022 09:04:47 -0700 (PDT)
MIME-Version: 1.0
References: <01000180a9eb37cb-85b9c576-c1eb-425a-b42c-b3cabe548fbb-000000@email.amazonses.com> <9ba4be2a-a9f4-8940-d470-efa385a2cb52@cesnet.cz> <01000180bdf26740-3d7da48c-9c93-4123-9298-161a294988b1-000000@email.amazonses.com> <4754acfc-8fa0-ad2b-52ad-36302c5aada9@hq.sk>
In-Reply-To: <4754acfc-8fa0-ad2b-52ad-36302c5aada9@hq.sk>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 13 May 2022 09:04:36 -0700
Message-ID: <CABCOCHR29ZO3t-JzY_sLb-z-CC-CTMTDxHZq_B4JwgnFyJOorQ@mail.gmail.com>
To: Robert Varga <nite@hq.sk>
Cc: Kent Watsen <kent+ietf@watsen.net>, Michal Vasko <mvasko@cesnet.cz>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005ef49f05dee6d5aa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/9eF6569zKsYGxcxcsQiFockzv74>
Subject: Re: [netmod] Does defining a feature require the module be implemented?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.34
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: Fri, 13 May 2022 16:05:25 -0000

On Fri, May 13, 2022 at 8:49 AM Robert Varga <nite@hq.sk> wrote:

> On 13/05/2022 17:03, Kent Watsen wrote:
> > True, the current YANG Library structure allows features to be declared
> > only for implemented modules, but I'm unsure how intentional that was.
> >
> > We always talk about how a module needs to be "implemented" in order for
> > its Identities to be defined, but we don't ever talk about the same
> > being true for Features.
> >
> > It seems that, if this is the case, there should be a note somewhere
> > about features used in "grouping" statements and hence the
> > exporting-module must be "implemented" for the grouping to be used as
> > intended.
> >
> > These sections from RFC 8407 don't say anything about it:
> >
> >   * 4.13. Reusable Groupings
> >     <https://datatracker.ietf.org/doc/html/rfc8407#section-4.13>
> >   * 4.17.  Feature Definitions
> >     <https://datatracker.ietf.org/doc/html/rfc8407#section-4.17>
>
> Right, I think we need to first clarify what RFC8525's:
>
> >            "An entry in this list indicates that the server imports
> >             reusable definitions from the specified revision of the
> >             module but does not implement any protocol-accessible
> >             objects from this revision.
>
> "reusable definition" seems to be an under-defined term. I think the
> intent is to cover not only groupings, but also typedefs and extensions.
>
>

I thought this issue was obvious and already settled with the
iana-crypt-hash module.
There are features related to the server implementation of data nodes
that use the crypt-hash typedef.

We list iana-crypt-hash (or any module that has features) in the
implemented modules.
The client needs to know this info and that is the only way to do it.

I think these should also include identities and features -- but that
> opens up quite a can of worms in terms of what a 'supported feature' is:
> - is it tied to a particular revision or does it apply to all revisions?
> - is it a property of imported or (ultimante) importing module?
>
> Regards,
> Robert
>

Andy


> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>