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

Kent Watsen <kent+ietf@watsen.net> Mon, 23 May 2022 13:57 UTC

Return-Path: <01000180f1350b6f-2eb3399c-dbcb-4103-9458-63d9822722bc-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 9D7CAC15E3E3 for <netmod@ietfa.amsl.com>; Mon, 23 May 2022 06:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 UkPJgsoz_ITI for <netmod@ietfa.amsl.com>; Mon, 23 May 2022 06:57:08 -0700 (PDT)
Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77847C159A38 for <netmod@ietf.org>; Mon, 23 May 2022 06:57:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1653314227; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=yj+YoDLql7K1OmsrDZAqTU9F9DuYxrAWjAfo+gBIM9U=; b=NJCeTJs0xPKffUsB7eRZ762SvUUprijkUvkTIzIVHP2udhlACsyA2PyxcDA3amlC DO+x1ytWvXds5jsIMufJk5tslhnSyvYNvpTmFbR0mRYHRPo+KCP/OvN1TSuG2MX9GeP q35GYaQCJ+TxAfg7QtR/i3yrIyDXd7ClGOJvw+Uc=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000180f1350b6f-2eb3399c-dbcb-4103-9458-63d9822722bc-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2598FFC1-A8AC-468F-BFAD-05D132AC304F"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Mon, 23 May 2022 13:57:07 +0000
In-Reply-To: <CABCOCHR_pb4JSpjFA0PAX2a4bybkVxu9xRx=AxRkWs9QVFC9Qg@mail.gmail.com>
Cc: Martin Björklund <mbj+ietf@4668.se>, "netmod@ietf.org" <netmod@ietf.org>
To: Andy Bierman <andy@yumaworks.com>
References: <01000180a9eb37cb-85b9c576-c1eb-425a-b42c-b3cabe548fbb-000000@email.amazonses.com> <20220518.080543.825575420363032441.id@4668.se> <01000180d793d6ee-f82a4a03-28d8-4f8b-909e-7306a7fc565b-000000@email.amazonses.com> <20220519.090452.636208001533389643.id@4668.se> <CABCOCHQMregbZwY0vOZbYkjwzzPp-JHjDK3tWcVnw_fj3+zv8w@mail.gmail.com> <01000180e19bcd37-22dd5fc0-b39b-4d92-ab51-7bbbfbe653e1-000000@email.amazonses.com> <CABCOCHR_pb4JSpjFA0PAX2a4bybkVxu9xRx=AxRkWs9QVFC9Qg@mail.gmail.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2022.05.23-54.240.8.88
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/F8vTJha3oxiQGbDGd6NYQDt9Tco>
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: Mon, 23 May 2022 13:57:09 -0000

Hi Andy,

> I feel vindicated, but also feel that Martin is right about this being the solution for now.  I don't even feel that it is necessarily bad.  But I do think we should act on this in some way.  Here are some options:
> 
> 1) put a "document only" errata on RFC 8525.
> 2) put a "document only" errata on RFC 7950.
> 3) put a "document only" errata on RFC 8407.
> 4) file a YANG Next issue.
> 5) some combination of the above.
> 6) anything else?
> 
> 
> I do not think an Errata can fix this issue because the split
> between 'module' and 'import-only-module' was intentional.

My intention for using the "hold for document update" Errata (I wrote "document only" before) is only to better document the behavior that exists currently, so it doesn't have to be rediscovered again later.  Martin pointed to an RFC section that didn't list features explicitly, leaving it open for interpretation.  Patching such sections would be good.  As for RFC 8407, maybe Section 4.17 (Feature Definitions) could say something?  

Following are a couple excerpts from https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata:

Hold for Document Update - The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update. 

And (I added the underline):

Changes which are simply stylistic issues or simply make things read better should be Hold for Document Update. 

Would you be willing to offer some text for an RFC 8407 "hold for document update" errata?   If Martin does the same for the section he found, I think we would be covered.  It seems is worthy effort, yes?

Kent // contributor


> 
> Going back to iana-crypt-hash (again).
> 
>  - the features are not intended for use in any if-feature-stmts
>  - each feature is related to one variant for values of the crypt-hash type
> 
> Features are like identities.
> They are completely decoupled from the schema tree and simply
> use the parent module to create a unique QName for reference in other statements.
> 
> Perhaps we should work on some proposed edits for yang-next.
> 
> 
>  
> Kent
> 
> Andy
>