[rfc-i] draft-kuehlewind-update-tag comments

Toerless Eckert <tte@cs.fau.de> Wed, 25 March 2020 22:23 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 913F73A0DB2 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Wed, 25 Mar 2020 15:23:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=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 XYKbW50MTbo8 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Wed, 25 Mar 2020 15:23:48 -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 8BFFD3A0D91 for <rfc-interest-archive-SieQuei0be@ietf.org>; Wed, 25 Mar 2020 15:23:48 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id A7FA2F406F7; Wed, 25 Mar 2020 15:23: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 CE246F406F7 for <rfc-interest@rfc-editor.org>; Wed, 25 Mar 2020 15:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
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 zxVxOR_ABeAR for <rfc-interest@rfc-editor.org>; Wed, 25 Mar 2020 15:23:28 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) by rfc-editor.org (Postfix) with ESMTPS id F4172F406D6 for <rfc-interest@rfc-editor.org>; Wed, 25 Mar 2020 15:23:20 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A0BD254804A for <rfc-interest@rfc-editor.org>; Wed, 25 Mar 2020 23:23:25 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 989F2440040; Wed, 25 Mar 2020 23:23:25 +0100 (CET)
Date: Wed, 25 Mar 2020 23:23:25 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: rfc-interest@rfc-editor.org
Message-ID: <20200325222325.GP30574@faui48f.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Subject: [rfc-i] draft-kuehlewind-update-tag comments
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: rfc-interest <rfc-interest-bounces@rfc-editor.org>

I like to solve the problem. I am not sure the proposed solution is
sufficient though.

On the nitpicking style, i am not sure that the distinction of
New MUST -> Amends New "optional" is a good way to define
the distinctions:

If i was an operator, i would primarily like to understand the
interoperability effects. We the new document be expected to
interoperate in all circumstances with the old version RFC ?
Security Amendmends certainly will the need option to kill
backward compatibility (old RFC had a now broken security scheme).

I would feel a lot easier to conclude what would need to be
done if there was a collection of different example "use cases",
and challenge the community to come up with new "use cases" where
the proposed solution does not work well enough.

I "feel" that it would be better not to try to solve our issues
nly with as few as possible tags, but also ponder what a good
amendment/extensions text in an RFC should look like.
E.g.: separate section summarising "Changes" over the prior
RFC is IMHO a good approach.

"This rfc replaces the following text in prior RFC with the
text outlined in section xx of this rfc. This impacts
interoperability as follows".

Just an example.

Cheers
    Toerless
_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest