Re: [rfc-i] draft-kuehlewind-update-tag/

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 26 March 2020 19:13 UTC

Return-Path: <rfc-interest-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6131E3A07BF for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Thu, 26 Mar 2020 12:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.451
X-Spam-Level:
X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=joelhalpern.com
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 WWUMIoLWo5hh for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Thu, 26 Mar 2020 12:13:49 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CB5E3A0747 for <rfc-interest-archive-SieQuei0be@ietf.org>; Thu, 26 Mar 2020 12:13:49 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id A828BF40714; Thu, 26 Mar 2020 12:13:37 -0700 (PDT)
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 1EF8BF40714 for <rfc-interest@rfc-editor.org>; Thu, 26 Mar 2020 12:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Authentication-Results: rfcpa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myPQS-4NRGgN for <rfc-interest@rfc-editor.org>; Thu, 26 Mar 2020 12:13:35 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by rfc-editor.org (Postfix) with ESMTPS id BD3FDF40713 for <rfc-interest@rfc-editor.org>; Thu, 26 Mar 2020 12:13:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 48pF5R1MRLz1p0dg; Thu, 26 Mar 2020 12:13:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1585250027; bh=GEK0wSzidioCTrhJ2eHKdCp9Lb4ah9dVIu/iu9r+TfA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=XkJ5frT+TD1TDzFSYc6Pns2bgKZ7cM8sUjWt/QrW8cUxjmAPQLhBNzUyreGkiSIUn jh8aS4XygXhDwDP44KRD/90xP9Po0FD+doxr2/+N+xICu74FezkB9Uf75cq9hSN0Z9 sdaX/aLLj8SELODqJTOqY5+MLnOJ6gMq9rI1ydgc=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 48pF5Q28Nhz1p0KT; Thu, 26 Mar 2020 12:13:46 -0700 (PDT)
To: Toerless Eckert <tte@cs.fau.de>
References: <30855.1585242882@localhost> <59F42CB0-6980-42B3-9A7E-24F601EF8A8D@strayalpha.com> <5023ce7d-2cc1-9163-b3c0-bc8c66ec6d7f@joelhalpern.com> <20200326185641.GZ30574@faui48f.informatik.uni-erlangen.de>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <f7bcff5b-76c1-87dc-458e-f5f0eab93321@joelhalpern.com>
Date: Thu, 26 Mar 2020 15:13:45 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200326185641.GZ30574@faui48f.informatik.uni-erlangen.de>
Content-Language: en-US
Subject: Re: [rfc-i] draft-kuehlewind-update-tag/
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
Cc: "rfc-interest@rfc-editor.org" <rfc-interest@rfc-editor.org>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: rfc-interest <rfc-interest-bounces@rfc-editor.org>

Actually, I have generally found that our practices for document content 
regarding updates are pretty good.
And to the degree they can be improved (I presume they can) that seems 
quite separate from the problem that the proposers have asked about. 
And it seems to me that the problem they have raised is one worth solving.

Yours,
Joel

PS: And our document content for updating documents does not engender 
the same kind of confusion and perpetual discussion.

On 3/26/2020 2:56 PM, Toerless Eckert wrote:
> I would appreciate if we would first or at least also work on guidance
> for what needs to go into an "update to RFCXXXX" section for new
> documents. Once we are clear about at the things that should be
> said (how prir doc is changed, what impact on interop thia
> results in, ..), it will be a lot easier to figure out if there are simple
> classifications that could go into metadata. Then its yet a third
> step whether we should try to expand/proliferate on our rather
> old metadata approach or go with newer approaches like what Mcr
> suggested.
> 
> Cheeers
>      toerless
> 
> On Thu, Mar 26, 2020 at 02:45:58PM -0400, Joel M. Halpern wrote:
>> (Resend.)
>>
>> Joe, we all know that the formal words we use do not have the same meaning
>> that they do in English.  Our standards are not, effectively, "requests for
>> comment".  They are standards.
>> We also know by observation that other people have understood "Updates" in
>> ways that are different from how you understand it.  Claiming that the
>> meaning as used for metadata on RFCs is "obvious to any English speaker" is
>> contradicted by the observable facts.
>>
>> Yours,
>> Joel
>>
>> On 3/26/2020 1:25 PM, Joe Touch wrote:
>>>
>>>
>>>> On Mar 26, 2020, at 10:14 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>>>>
>>>>> ???Updates??? means just that - it affects the base document in a way that
>>>>> MIGHT be hazardous to ignore. That means you need to read the doc to
>>>>> find out why, to what extent, and how that affects what you want to
>>>>> do.
>>>>
>>>> I wonder if you can recognize that this might not be the only way it has been
>>>> used in the past.  Maybe those uses were in error, but you've picked a
>>>> particular definition that wasn't always applied.
>>>
>>> I do. Adding terms doesn???t make that more clear or useful. Updates means changes of any nature that do not replace the prior RFC in its entirety.
>>>
>>> If that isn???t obvious to any English speaker, then these nuanced other terms that subdivide that category further definitely will not help.
>>>
>>> Joe
>>>
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest@rfc-editor.org
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 
_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest