Re: BCP97bis

John C Klensin <john-ietf@jck.com> Mon, 18 October 2021 20:25 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3B13A0A83; Mon, 18 Oct 2021 13:25:25 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkIxr73oGFGj; Mon, 18 Oct 2021 13:25:21 -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 323303A0A8D; Mon, 18 Oct 2021 13:25:21 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1mcZCB-000PgM-9i; Mon, 18 Oct 2021 16:25:19 -0400
Date: Mon, 18 Oct 2021 16:25:12 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Carsten Bormann <cabo@tzi.org>, ietf <ietf@ietf.org>
Subject: Re: BCP97bis
Message-ID: <4A4AC64447CE346479AC2395@PSB>
In-Reply-To: <CAL0qLwZwSjwaMxB-CX4LxQh1AAtxrzMH8Nn=TO7dyh-sDH1-WQ@mail.gmail.com>
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <CAL0qLwa4ChOsuMkmoP_sAGv3Wn2AcSz1OkijmxZzP+MGvnwviA@mail.gmail.c om> <849D7F9E-8AD4-4CE8-A66C-358FB1F2E6AE@tzi.org> <3AC61568-DBDC-4ADB-9935-9C53333AE7E2@akamai.com> <CAL0qLwZvCq7R=WBFsrwf51CKSN8ur0Yj-F=VOHnP=hQD0ooj-A@mail.gmail.com> <890A4965-D847-4606-849C-A0C8D8FD3B0C@akamai.com> <83AE1023E61C0D81DA726D6B@PSB> <CAL0qLwZwSjwaMxB-CX4LxQh1AAtxrzMH8Nn=TO7dyh-sDH1-WQ@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/8uvy9LwpwNa5hWMdd1J5jsSri9w>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Oct 2021 20:25:26 -0000


--On Monday, October 18, 2021 10:30 -0700 "Murray S. Kucherawy"
<superuser@gmail.com> wrote:

>...
>> The solution to the latter type of situation is not to be sure
>> free copies of [BigDoc] are available to anyone who might (or
>> should) be interested in the hope they will read them, but for
>> the IESG to push things more in the direction of RFC 20 and
>> good summaries about exactly what the actual requirements are
>> in practice.  There are many much more recent examples that
>> have done just that.
>> 
> 
> So then the way to resolve this problem might be to codify
> exactly the practice you're proposing: If the primary target
> document is not freely available, craft an RFC that captures
> the important requirements of it so we can use that as our
> reference.  That document can then be normative for our future
> work on that topic.  It's more work for the IETF, to be sure,
> but if we say this is the process then at least working groups
> will know what's expected of them as far ahead of time as
> possible.

I think so.  I would hope that the language used would still
leave the IESG with discretion for unusual cases but that seems
to me a better way to go.  We do need to be careful about one
thing, which is that, if the externally referenced document
changes out from under our specification, e.g., X3.4-1968
evolves into ANSI INCITS 4:1986, the development of any new IETF
document that depends on the original RFC should include a check
to be sure the changes are not significant wrt our work and, if
they are, should include, an explanation and necessary updates.

To pick a somewhat more recent example than RFC 20, RFC 3339
contains the sort of summary I think we should be looking for.
It defines a profile of ISO 8601:1988 but contains sufficient
ABNF and explanation that any reader who was not trying to check
up on the authors would not need to review 8601:1988 itself.  I
note that ISO 8601:1988 had already been replaced by ISO
8601:2000 by the time the RFC was published.  That is noted by
an un-cited reference to the latter; I am suggesting that it
should have been required to contain a short section or appendix
that either stated that there were no substantive changes in the
ISO documents that would affect the specification between the
1988 and 2000 versions or a brief discussion of the changes and
their effects.  And, of course, the implications of those issues
came up in the discussion prior to chartering of SEDATE and,
while draft-ietf-sedate-datetime-extended-00 still references
8601:1988 as normative, without some explanation that is an
invitation to future problems if only because, AFAIK, one can
not even obtain the 1988 specification from ISO except, perhaps,
for historical research purposes.

    john