Re: [tcpm] Presentation slot requests for IETF 108 (online)

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Fri, 03 July 2020 09:54 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229093A0BA3; Fri, 3 Jul 2020 02:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
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 qo4l_Hzs7954; Fri, 3 Jul 2020 02:54:11 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EF43A0B9F; Fri, 3 Jul 2020 02:54:10 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id E3F7525A17; Fri, 3 Jul 2020 11:54:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1593770048; bh=GzFh82oMu1T4QYoNQrFWrefBmXFAT8nBcldTJ+eJrWo=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=JZKuxWnQgWzRa90W1NMdUFBeDOnKUNeoQARx2dU58gvce5ICvEOktGPBMlpG1857i sDB0F9LFzWJcMcfQob1qirgZtOTJTAlNjNYMWBvGrc7IXXysigliy95Eni0/wqC4fu 3uhmAYD4yfwERqLaYFyXH8uq9itmd/jO2u1bq/yU=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaKCDwB6mHIe; Fri, 3 Jul 2020 11:54:08 +0200 (CEST)
Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 3 Jul 2020 11:54:08 +0200 (CEST)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Fri, 3 Jul 2020 11:54:07 +0200
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: tom petch <ietfa@btconnect.com>
CC: "tcpm@ietf.org" <tcpm@ietf.org>, "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>
Thread-Topic: [tcpm] Presentation slot requests for IETF 108 (online)
Thread-Index: AdZQQCmoc741dfI0S+mziKOl37MyoQABBo5AAA4+aKAAA93uAAAfcSkg////koD//93DsA==
Date: Fri, 3 Jul 2020 09:54:07 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DC87DE1@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2DC85322@rznt8114.rznt.rzdir.fht-esslingen.de> <202007021820.062IKW9I062065@gndrsh.dnsmgr.net>, <6EC6417807D9754DA64F3087E2E2E03E2DC87826@rznt8114.rznt.rzdir.fht-esslingen.de> <DB7PR07MB53403CE8939E4A68DA1E32F5A26A0@DB7PR07MB5340.eurprd07.prod.outlook.com>
In-Reply-To: <DB7PR07MB53403CE8939E4A68DA1E32F5A26A0@DB7PR07MB5340.eurprd07.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.48.165]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/wlE-OK_eE1WosR1t94JrXG85ssQ>
Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jul 2020 09:54:13 -0000

> Tim Wicinski has already mentioned that "update" metadata can be used to
> keep record of the history.
> 
> Also, I believe it is quite common in the IETF to rename I-Ds if they move
> between WGs. For individual submissions, this is probably not formally
> required, though.
> 
> The advantage of -tcpm- is that it is then more apparent on which list the
> discussion shall take place. Not all readers of I-Ds are familiar with all IETF
> internals.
> 
> <tp>
> which is why it is a bad idea to rename I-D IMHO when the WG changes since
> it then requires a datatracker wonk to know where to go in the maze of IETF
> related pages to find what it was in a previous life, something WG Chairs do
> all the time but mere mortals may not.  When OSPF became LSR, the I-D
> were NOT renamed and very sensible it was too:-)

Well, mere mortals may also not care much about the history of the document, diffs between versions, and the like. As soon as they do, they sooner or later run into datatracker, IMHO.

Thus, with chair hat off, I disagree that using the name of a changed WG is _always_ a "bad idea". But, well, my original statement was "it may make sense". And this includes the word MAY...

> The only time a change of identifier is sensible is when an individual draft is
> adopted which happens to be another aspect of IETF internals that most
> outside the IETF will not be familiar with!.

To me, there are tradeoffs and there is no such one-fits-all rule. But the last observation is probably correct. So, I really wonder if we discuss a relevant question here.

And, well, the specific I-D discussed here is an (expired) -01 version of a document that already has an "replaces" entry to an entirely different draft name... I may miss something, but for this specific example I don't understand why renaming would be a real-world issue.

Michael