Re: [dispatch] [rfc-i] Advice when converting W3C ED to I-D

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 16 September 2023 20:41 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C15C14CE24 for <dispatch@ietfa.amsl.com>; Sat, 16 Sep 2023 13:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level:
X-Spam-Status: No, score=-2.199 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.091, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7HHJXKq4SGpS for <dispatch@ietfa.amsl.com>; Sat, 16 Sep 2023 13:41:18 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 1326CC14CEF9 for <dispatch@ietf.org>; Sat, 16 Sep 2023 13:41:18 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id 41be03b00d2f7-5779055a474so2680262a12.0 for <dispatch@ietf.org>; Sat, 16 Sep 2023 13:41:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694896877; x=1695501677; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=znBnQ5mwV9YKPRa9Pj+7qGbP4SM1k0gR0YiWeHnbDRc=; b=fZXnqmju79HhGG1ABkGmg73LQZqTv9/7BNW4FFLwCJQ6QYiwbsNizelofUb6H4cSTk 0pBXDETt59d5KTeR2+d3uqPM7JaCQwvRKNajSAmVBBD1zVMk/IZ1nJ0kE8iia1JU0SRA 8l07RmbW1G5BOEfDW0pRr4gInU8kHjsatuT9b+4qsCCoiHhE/7LsIbrDNfNCtclx79cF Gfz5Z4Hr8ZUc405LK+uLwqrbyXEJjSvwUQyN4fu64HTOG/YpOLrdvWcbcVWuzdXGZeiQ hYXAFJAq7oYH/KLZdFflERoUDDG0D4JMyeYanC5k0QpZG5i6MozRh9jD7bcSRfUjnOO8 mLiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694896877; x=1695501677; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=znBnQ5mwV9YKPRa9Pj+7qGbP4SM1k0gR0YiWeHnbDRc=; b=bx72RbF6hVwVdsy9CRX/s1CFxMq53FyT1VbVYqWe+igpRXoLOXKle6we9RG5QJRySB UeEXqT2yBO9bT0RVPeOkij5nEtjqX97kB/LrpZ6+6sdHFjvHAxQZHMFJi3GXrtW6LZ8n QxlwxAPHO9ZCH12skaJNs26SqejXG3jZLVSWDHmVybVFwEGk2OmEP1N+F+fMYt54YkG4 BICZg+7DslDwlXZQZtyBDVqXCU1zXiO1Dx426lxH3jtt5th6YXvXsN5VxIr/A2Dwprpr mu4NDdYYYiGEmShSdSK0LQLyvHUWOgjYt+mopKpZzIAHG7ulz4UJ49vSLM5MZ3z3eIlT JBlw==
X-Gm-Message-State: AOJu0YyKmFYKJlnqtTBiM85NokIgF1Qrz3XtZ/2N9VhVjnWeQxtTlvMm IDiQhtt49lH69j6ZIHeZDio=
X-Google-Smtp-Source: AGHT+IECxc3P2vlpJE+4JFT+kGlSZs7Svgi9YT/PSOPRDbWxtu9cn1BWAg+QMGeFfUZlC2hJcEhRrg==
X-Received: by 2002:a05:6a21:7189:b0:157:eb32:e739 with SMTP id wq9-20020a056a21718900b00157eb32e739mr5082928pzb.32.1694896877423; Sat, 16 Sep 2023 13:41:17 -0700 (PDT)
Received: from ?IPV6:2406:e003:110d:5301:8cb6:a2c:7461:4047? ([2406:e003:110d:5301:8cb6:a2c:7461:4047]) by smtp.gmail.com with ESMTPSA id cg10-20020a056a00290a00b00682a908949bsm108004pfb.92.2023.09.16.13.41.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 Sep 2023 13:41:17 -0700 (PDT)
Message-ID: <3bed3227-35d2-7eaf-75f5-d0c24d6fb38c@gmail.com>
Date: Sun, 17 Sep 2023 08:41:11 +1200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Eliot Lear <lear@lear.ch>, tom petch <daedulus@btconnect.com>, Rahul Gupta <cxres@protonmail.com>, "rfc-interest@rfc-editor.org" <rfc-interest@rfc-editor.org>, "dispatch@ietf.org" <dispatch@ietf.org>
References: <FC5975A9-E5B2-4853-88D5-1B0A797DE82F@tzi.org> <4cv1A92QvTpimy732OIF2k6A0wFytnq0aCO4VyOOAfzcdhCGIxpdF79iedbG3XJbbhKOO3RZxRmcF2ctcK5jxv7J-apkFJkD6eu6Bcy9fak=@protonmail.com> <VI1PR07MB6704265F4B7264A8D8DB3B94C6F6A@VI1PR07MB6704.eurprd07.prod.outlook.com> <03b87591-a1a4-c175-9ebb-d144bf2a424a@lear.ch>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <03b87591-a1a4-c175-9ebb-d144bf2a424a@lear.ch>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/_Haxft0Rs9BdHRtU4vW6ZF2zxwk>
Subject: Re: [dispatch] [rfc-i] Advice when converting W3C ED to I-D
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Sep 2023 20:41:22 -0000

On 17-Sep-23 02:38, Eliot Lear wrote:
> I agree with others; there is no standard way to separate all of what is normative v. informative.  However, it is perfectly fine to be explicit in a draft.  A good example of how this was done was in DKIM, RFC 6376.  Here is a snippet:
> 
>>     DKIM supports multiple digital signature algorithms.  Two algorithms
>>     are defined by this specification at this time: rsa-sha1 and rsa-
>>     sha256.  Signers MUST implement and SHOULD sign using rsa-sha256.
>>     Verifiers MUST implement both rsa-sha1 and rsa-sha256.
>>
>>        INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some
>>        senders might prefer to use rsa-sha1 when balancing security
>>        strength against performance, complexity, or other needs.  In
>>        general, however, rsa-sha256 should always be used whenever
>>        possible

In RFC 8994, the WG decided to label the sections explicitly, e.g.

4.  Requirements (Informative)
5.  Overview (Informative)
6.  Self-Creation of an Autonomic Control Plane (ACP) (Normative)

     Brian