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

John C Klensin <john@jck.com> Mon, 18 September 2023 22:15 UTC

Return-Path: <john@jck.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 E6DCFC15108A; Mon, 18 Sep 2023 15:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 BW254XbTIqJg; Mon, 18 Sep 2023 15:15:49 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B797C13AE4C; Mon, 18 Sep 2023 15:15:43 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1qiMWn-00030Z-9L; Mon, 18 Sep 2023 18:15:37 -0400
Date: Mon, 18 Sep 2023 18:15:30 -0400
From: John C Klensin <john@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Eliot Lear <lear@lear.ch>, tom petch <daedulus@btconnect.com>, Rahul Gupta <cxres@protonmail.com>, rfc-interest@rfc-editor.org, dispatch@ietf.org
Message-ID: <FB169B84C5D2EF14DF7CCA9E@PSB>
In-Reply-To: <3bed3227-35d2-7eaf-75f5-d0c24d6fb38c@gmail.com>
References: <FC5975A9-E5B2-4853-88D5-1B0A797DE82F@tzi.org> <4cv1A92QvTpimy732OIF2k6A0wFytnq0aCO4VyOOAfzcdhCGIxpdF79iedbG3XJbbhKOO3RZxRmcF2ctcK5jxv7J-apkFJkD6eu6Bcy9fak=@protonmail.com> <VI1PR07MB6704265F4B7264A8D8DB3B94C6F6A@VI1PR07MB6704.eurprd07.pr od.outlook.com> <03b87591-a1a4-c175-9ebb-d144bf2a424a@lear.ch> <3bed3227-35d2-7eaf-75f5-d0c24d6fb38c@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/ABAwuDVjqBO3Hll76taUYZZcoBg>
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: Mon, 18 Sep 2023 22:15:55 -0000


--On Sunday, September 17, 2023 08:41 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

> 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,

Unless there is a plan about stepping back from the longstanding
principle of allowing considerable flexibility on a per-document
basis as long as there is (i) a sensible reason, (ii) the
document is internally consistent, and (iii) the document is
clear, it seems to me that your comment, Eliot's advice, and
other comments including Joel's are roughly consistent even
though they might lead to somewhat different results.  

I think the conclusion when they are taken together is that W3C
has different norms, conventions, and vocabulary than the IETF
and that, in the general case, automated mapping from one of
their documents to one of ours is unlikely to work and may
create something that is conceptually different from the
original.  Some of the differences derive from WC3 being a
membership organization while the IETF is a different sort of
creature.   Two particularly important examples have not even,
AFAICT, come up in the discussion: Even though the required text
is usually generated as boilerplate rather than spelled out by
authors, our IPR rules are largely based on an obligation to
disclose while W3C's, at least when last I paid careful
attention, involved an obligation to release rights.  Similarly,
our requirement for a Security Considerations section and what
is supposed to be in it, have, AFAICT, no strong W3C parallel.

So, my advice to authors wanting to move a document over is that
it is necessary to at least minimally understand the IETF's
rules and requirements and then rewrite accordingly.  That may
involve some, perhaps even a lot of, copying and pasting but
those operations then will require some hand=editing of the text.

best,
   john