[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
- Re: [rfc-i] draft-kuehlewind-update-tag comments Joe Touch
- [rfc-i] draft-kuehlewind-update-tag comments Toerless Eckert
- Re: [rfc-i] draft-kuehlewind-update-tag comments Michael Richardson