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

Kent Watsen <kent+ietf@watsen.net> Fri, 13 May 2022 15:03 UTC

Return-Path: <01000180bdf26740-3d7da48c-9c93-4123-9298-161a294988b1-000000@amazonses.watsen.net>
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 ACEE3C157B37 for <netmod@ietfa.amsl.com>; Fri, 13 May 2022 08:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=amazonses.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 VLeeyQMHx0BD for <netmod@ietfa.amsl.com>; Fri, 13 May 2022 08:03:43 -0700 (PDT)
Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5353C14F74D for <netmod@ietf.org>; Fri, 13 May 2022 08:03:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1652454221; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=AhfldkhEGr088HUK8BsaKJWrX0zCvrowhYLkvnVvRiM=; b=as7a8x4zs6JMwQxe1/+if2UEcVkucKEGdlKIGzJdtRaJh6RL0+CTPsigJOl524b2 0tnN50G2dxANAbH1rvSAceVIBO3YK5YGE0PS4X2hfsAsOYchoyuIBnLSMOCP/cO47uh 7kuX/eZxW2oGwN2Ty1zQEhf1Yzd/jd5Jyzx8VgSA=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000180bdf26740-3d7da48c-9c93-4123-9298-161a294988b1-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_152D4DF8-178F-4719-8222-3A0F5CBB65AC"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Fri, 13 May 2022 15:03:41 +0000
In-Reply-To: <9ba4be2a-a9f4-8940-d470-efa385a2cb52@cesnet.cz>
Cc: "netmod@ietf.org" <netmod@ietf.org>
To: Michal Vasko <mvasko@cesnet.cz>
References: <01000180a9eb37cb-85b9c576-c1eb-425a-b42c-b3cabe548fbb-000000@email.amazonses.com> <9ba4be2a-a9f4-8940-d470-efa385a2cb52@cesnet.cz>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2022.05.13-54.240.48.92
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/kWu-RgUnpN9rdUBZG_sjSO6HFzI>
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 15:03:46 -0000

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>

Kent


> On May 10, 2022, at 2:01 AM, Michal Vasko <mvasko@cesnet.cz> wrote:
> 
> Hi,
> 
> I would just like to explicitly mention that the current YANG library does not allow to report features for non-implemented modules and the feature list is in a grouping called `module-implementation-parameters`[1] so it would seem the authors of that RFC thought one must implement a module to enable its features.
> 
> Regards,
> Michal
> 
> [1] https://www.rfc-editor.org/rfc/rfc8525#page-11
> 
> On 9. 5. 2022 19:43, Kent Watsen wrote:
>> YANG Doctors,
>> 
>> 
>> Does "foo" need to be "implemented", in order for its feature to be define?
>> 
>> 	module foo {
>> 	  yang-version 1.1;
>> 	  namespace "https://example.net/foo";
>> 	  prefix "f";
>> 
>> 	  feature foo-feature;
>> 
>>           ...
>> 	}
>> 
>> 
>> Specifically, using  the previous YANG Library (RFC 7895), would this be possible:
>> 
>>       {
>>         "name": "foo",
>>         "feature": [
>>           "foo-feature"
>>         ],
>>         "namespace": "https://example.net/foo",
>>         "conformance-type": "import"
>>       },
>> 
>> 
>> Or does "foo" also need to be "implemented", in order for its feature to be defined?
>> 
>> 
>> PS: the answer to this impacts the "crypto-types and friends" drafts in the NETCONF WG, where it is assumed (and various tools agreed, sans a recent change in `yanglint`) that the implementation-status of a module is orthogonal to what features supported.
>> 
>> Thanks,
>> Kent
>> 
>> 
>> 
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod