Re: Status of this memo [name remixing]

Christian Huitema <huitema@huitema.net> Tue, 27 April 2021 23:35 UTC

Return-Path: <huitema@huitema.net>
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 B582E3A258F for <ietf@ietfa.amsl.com>; Tue, 27 Apr 2021 16:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 KqAL2mOhdlCJ for <ietf@ietfa.amsl.com>; Tue, 27 Apr 2021 16:35:43 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D223A258A for <ietf@ietf.org>; Tue, 27 Apr 2021 16:35:42 -0700 (PDT)
Received: from xse235.mail2web.com ([66.113.196.235] helo=xse.mail2web.com) by mx136.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1lbXEu-0018LE-Jw for ietf@ietf.org; Wed, 28 Apr 2021 01:35:39 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4FVJ3y4h3wzBV4 for <ietf@ietf.org>; Tue, 27 Apr 2021 16:33:34 -0700 (PDT)
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1lbXCw-0001kl-Gh for ietf@ietf.org; Tue, 27 Apr 2021 16:33:34 -0700
Received: (qmail 28186 invoked from network); 27 Apr 2021 23:33:34 -0000
Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.58.43.58]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ietf@ietf.org>; 27 Apr 2021 23:33:33 -0000
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>, Lars Eggert <lars@eggert.org>
Cc: IETF discussion list <ietf@ietf.org>
References: <376f83f0-89a3-cd0e-1792-c8434bd8a5d2@gmail.com> <9ACE59FA-30B6-475A-AF6B-4B874E4A2788@eggert.org> <1804294246.5904.1619512137931@appsuite-gw2.open-xchange.com> <D653D3B2-7666-409A-B856-2A4B1BA958CA@eggert.org> <269463648.9898.1619530011972@appsuite-gw2.open-xchange.com> <4e9acbd7-07f6-3999-d08f-422742a94238@gmail.com>
From: Christian Huitema <huitema@huitema.net>
Subject: Re: Status of this memo [name remixing]
Message-ID: <5e00488c-d149-3c0a-b8f2-2c39ba460e0a@huitema.net>
Date: Tue, 27 Apr 2021 16:33:33 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <4e9acbd7-07f6-3999-d08f-422742a94238@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.235
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x9j7219Tb9QoiGKb6esGsuKj/EwzSHE5FGYwwjsNRPCHpU hMWnIW/5Z1Z+n7HPiQ3mD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7Imca8Ju4bezvmP+fyr6IQn/AJhQ6V51u76v35b1wNe/MvdLom48E g3of4Y9DlgiJ0nAJ2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NQ/T3Op6Um662jkOH4Bxha5PzEr+joRGaHWwOCfszfOK6 lyRQu8jeiP4UeMilrL4uDRojSVizNl0ce/s7u0P9b9Tml6eOMCV9kYYwkPx6ZsXvIUzTXkDAiiJi mGhLUFuS2lhaIetXfCg1JdAVrOwKfFGG4Rb3as1smnme8iD8KqBUoFIvD3sIcP1fhJPM6B/8KBgS 7I2qaHyMo4nz+D4IEj1I5TgnJ4xNz8rxHJKsrhKJ+dym1L8cD17Js0v4cp1Mf14BcjDEC6fDB01e 8LIr6TcKVNeVJ9BXyu9+ceCqThTYg2px1fSoqxQCCHnLMo/m9VKh99btUAanjnMCAH2co+fBoeG+ Hs0afhsY/5zhNYWRVYKU9W9tbmVXJBqdHHDmZEKhyNAv1N35kYWaEdgLurFV5oTvAcwA4rM3FkfW 8/1kE/e7sUnsVpINvARNxpFO
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/NqsTVhvdWUoNV070GD-OIxjcU88>
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: Tue, 27 Apr 2021 23:35:54 -0000

On 4/27/2021 4:17 PM, Brian E Carpenter wrote:

> On 28-Apr-21 01:26, Vittorio Bertola wrote:
>>
>>> Il 27/04/2021 10:41 Lars Eggert <lars@eggert.org> ha scritto:
>>>
>>> There was a suggestion recently to not serve I-Ds from ietf.org domains until they were adopted by the IETF. Do you think serving individual drafts from another domain would help make that distinction clearer?
>> URIs can help, because they are posted around to refer to documents, so they can contain prominent semantic "messages", either in the hostname or in the top path element. However, I think it would be even better to do this in the filename, as the filename persists even when the file is downloaded or attached. For example, you could reverse the order of the initial elements and things would already be much clearer:
>>
>> ietf-draft-<wg>-<subject>
>> irtf-draft-<wg>-<subject>
>> independent-draft-<author>-<subject>
> I think this, like the suggestion to post drafts to differently named servers, would make matters worse for several reasons:
>
> 1) If people already have intellectual difficulty understanding that a filename starting with "draft-" is only a draft, this difficulty will be even greater with remixed names or multiple servers.
>
> 2) I hesitate to write this, but "draft-" has beome a brand, although less so than "RFC".
>
> 3) We have a lot of tooling that (for better or worse) assumes the draft- naming conventions, and a single server for all drafts. That isn't only IETF official tooling; I'm sure many of us have our own scripts and working habits. That's a real economic cost.
>
> 4) We have a de facto agreement that all RFC streams use common practices as far as possible, including IPR regimes. Remixing names and splitting servers wouldn't change that, but would make it less evident.
>
> 5) It is not uncommon for drafts to jump ship (from a WG to AD-sponsored; from IRTF to IETF; from IRTF or IETF to Independent, etc.). Forcing name changes for this reason is just makework.

I definitely agree with what Brian said. In addition, as a rule, it is a 
rather poor idea to twist names to incorporate properties. The chances 
of ending up with an unstable mix of combinations are just way too high, 
and the effects on document management chains are not great.

Yes, there is a risk of confusion because a draft that I just submitted 
will look and feel exactly like one that a working group has been 
working on for three years. But that risk can be addressed in more 
productive ways than twisting names. If we believe that documents 
acquire different cachet and statuses by going through different hoops, 
then we should say so in the status of the document. Saying things like 
"this is an individual contribution to the IETF", or "this is a working 
document of the FOO working group", or "this is a research contribution 
to the IETF", or "this work was not updated since April 4, 2019, and is 
considered abandoned in the IETF" are all statements that would fit well 
in an updated status.

-- Christian Huitema

>> By the way, "independent" is not immediately clear. "Personal" or "unofficial" would IMHO be better.
> "Independent" refers to the Independent Submission RFC stream.
>
>     Brian
>   
>