Re: [Rfcplusplus] IRTF stream considerations

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 13 July 2018 05:12 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: rfcplusplus@ietfa.amsl.com
Delivered-To: rfcplusplus@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32986130DF0 for <rfcplusplus@ietfa.amsl.com>; Thu, 12 Jul 2018 22:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 WzRib3pFNkjZ for <rfcplusplus@ietfa.amsl.com>; Thu, 12 Jul 2018 22:12:24 -0700 (PDT)
Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A27D1294D7 for <Rfcplusplus@ietf.org>; Thu, 12 Jul 2018 22:12:24 -0700 (PDT)
Received: by mail-pf0-x241.google.com with SMTP id q7-v6so20827397pff.2 for <Rfcplusplus@ietf.org>; Thu, 12 Jul 2018 22:12:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1r5vaRBXeUNqZYjaSi6Pv9HGakD9ZNLs5J5FjoH3QkI=; b=n1AEkFMqghiCM8TmMMMpZ3nh3QAKLS4Bj08PrpS5oiD+VL+wjqT953SRW+KAlOOLwR mhF8aKu7PjeEvdYVYgv7/IsgB1b93S4H9vF5NZeN+kjpEn+V2qNxrhnTeWWNJ7ELz8CE xK4GVHDua7d9clUYPsBzGqXQDyhDSucSUPxVs8eY7iZK9Th4yJZ3uuO2kdZsh9yQ4pRO MqTTzEpk/lTSXygFZF8GPYeQME/IqY/Bwdbvml+jd0FyQZ809lkvg3/PnFnVMY7pPdLF KyJfIBoY+DVf/078jbB+fiTXpQI1aI/i68ZuBh86p2AVViTYZUeg2CzMd1AyRz7EclFH zLXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1r5vaRBXeUNqZYjaSi6Pv9HGakD9ZNLs5J5FjoH3QkI=; b=IKUe2tfBLcS3NRqkhxSwL7XddBSHdaRkEHsr6ANpyEJRulGio4lB68M4IXkj45qdoF bXKGPQrFXrin5PpXUX3Eh5pOSij/bTFCQ7vKXxcBlk9W7QW5v8EEMlK7SplVQkHnn2ZI 6nf4r51vIVZ3raN40AVmc2kXkU6V5uDZ35DGVXHpUMbVHmTc86sSxkt7KQOefgArC0g3 /LSqlGQM1gIIZMiDEdOVrztG9lPJSSpAimOulEvtKXTZTNxFuhmkpUgbxjjXl1k2TFsv jMt5ox7agDVKTyOxb/l0c1qXhGyqNKDnWwTNFel4vtuMiVCuzKEmDIi6CYexw5TJsuSy P7EA==
X-Gm-Message-State: AOUpUlFpC1cjMIrAV+Dk/lBtJ4thGGxg1F4s9lan2J0Go3NzfgQfbIiP NpL5FYp56hvk7KDaDCh9/Fmutg==
X-Google-Smtp-Source: AAOMgpf5eTu46ojV65B9AbVN1cYSoGIG4iWe2xMV8hGZqEqkeGyjZGs52C9FArUPB/Fm6gL1fCYNJg==
X-Received: by 2002:a63:1d5e:: with SMTP id d30-v6mr4810999pgm.12.1531458743683; Thu, 12 Jul 2018 22:12:23 -0700 (PDT)
Received: from [192.168.41.146] ([219.88.101.10]) by smtp.gmail.com with ESMTPSA id s12-v6sm36149443pfm.41.2018.07.12.22.12.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 22:12:22 -0700 (PDT)
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Adam Roach <adam@nostrum.com>, Allison Mankin <allison.mankin@gmail.com>, "Rfcplusplus@ietf.org" <Rfcplusplus@ietf.org>
References: <CAP8yD=vm+jRxdi3ZUncoFZNDYKOQKvFaphT7gxb5o1tDXWmumA@mail.gmail.com> <b69b370c-317b-284f-85d1-1353c67a3043@gmail.com> <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <c2c450a6-4f14-6325-8c54-6ecee4e0983f@nostrum.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> <CA+9kkMCP+66+dxcukbG4BN24heH5oVHP6fJB0tZ3xA+Gsc2-QQ@mail.gmail.com> <0eefb84e-1a2b-4bbe-9e33-35a49b4db161@gmail.com> <CA+9kkMAkxcPttoa6oXaE_HECvb-d1nqj+h1Ke3W3qXbtAqVNZA@mail.gmail.com> <97585f4a-1761-762c-83d7-15284364e46e@gmail.com> <CA+9kkMAgfDS6nVeVHaqu-=_MdDeMzAvni4Pv0FUeMD9F-jomLg@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <47e90834-aa80-3325-920e-8bcc12c604d2@gmail.com>
Date: Fri, 13 Jul 2018 17:12:27 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CA+9kkMAgfDS6nVeVHaqu-=_MdDeMzAvni4Pv0FUeMD9F-jomLg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfcplusplus/zrpLgP77-6ME9HCEbhYQQ6_Jr0Q>
Subject: Re: [Rfcplusplus] IRTF stream considerations
X-BeenThere: rfcplusplus@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: For discussion of the RFC++ BoF proposal and related ideas <rfcplusplus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rfcplusplus>, <mailto:rfcplusplus-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfcplusplus/>
List-Post: <mailto:rfcplusplus@ietf.org>
List-Help: <mailto:rfcplusplus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rfcplusplus>, <mailto:rfcplusplus-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2018 05:12:28 -0000

> The proposed difference is in the label which is applied during
> the experiment, nothing more.

They would be denied the use of the abbreviation RFC and an RFC number
in the series that was started in 1969, and presumably therefore
of the ISSN number and a DOI in the same family.

That is chucking out of the RFC series as far as I'm concerned. It
couldn't be plainer.

Regards
   Brian

On 13/07/2018 15:30, Ted Hardie wrote:
> On Thu, Jul 12, 2018 at 6:45 PM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> 
>>
>> But the draft we are supposed to be discussing says:
>>
>>>>    This documents proposes reserving the "RFC" label for those documents
>>>>    that are the product of the Internet Standards Process [RFC2026].
>>
>> The BOF text in the wiki says:
>>
>>>> This would allow "RFC" to be reserved for standards-related documents,
>>
>> If that isn't "chucking out", I don't know what it is.
>>
>> (The theory that this is a reversible change is very dubious, as
>> others have pointed out.)
>>
>>
> Describing the theory that it is reversible as doubtful is a fair comment.
> It may be difficult to roll back a change, and that's well worth
> discussing.  But that's different from asserting that the proposal intends
> any stream to be "chucked out", in any of the meanings I find
> <https://idioms.thefreedictionary.com/chucking+out>.  They are not being
> closed, defunded, or sent off to other organizations; they continue to use
> the same facilities, represent the same streams, and carry on with the same
> managers. The proposed difference is in the label which is applied during
> the experiment, nothing more.
> 
> Arguing against some other proposal comes close to either failing to credit
> your colleagues with the plain of their words or arguing against a
> strawman, neither of which I hope you intend.
> 
> Now I really must pack a suitcase.
>>
>> Travel safely, and I look forward to seeing you in Montreal.
> 
> Ted
> 
> 
>>    Brian
>>> Ted
>>>
>>>
>>>
>>>
>>>> and that is (IMHO) so fundamental
>>>> that a major and as yet undefined effort is needed to discover whether
>>>> this is acceptable to the whole Internet technical community.
>>>>
>>>> The previous changes were administrative by comparison.
>>>>
>>>> Regards
>>>>    Brian Carpenter
>>>>
>>>> On 13/07/2018 03:57, Ted Hardie wrote:
>>>>> Slightly off-topic, but perhaps important
>>>>> On Wed, Jul 11, 2018 at 8:54 PM, Brian E Carpenter <
>>>>> brian.e.carpenter@gmail.com> wrote:
>>>>>
>>>>>> There's a real difference, in my opinion, in that the definition of
>>>>>> the streams was a codification of existing practice, and the format
>>>>>> update was something people have been requesting for many years.
>>>>>> Neither of them showed any signs of being fundamentally contentious.
>>>>>>
>>>>>
>>>>> I'm not sure what you mean by "fundamentally contentious", but both
>>>>> proposals had many months of discussions and, in some parts, quite
>>>> serious
>>>>> opposition.  Contentious would have been a word I would personally have
>>>>> used to describe the format update, for example, and I'm not sure why
>> you
>>>>> would disagree.
>>>>>
>>>>> This time, we've seen a much more radical proposal which, if carried
>>>>>> forward, would fundamentally change the series. In that case you can't
>>>>>> duck the question of authority and who calls consensus.
>>>>>>
>>>>>>
>>>>> I'll note that the proposed experiment borrows many elements of the
>>>> format
>>>>> discussion's process.  While there is no question that the final format
>>>>> documents were published by the IAB, the face-to-face discussions were
>>>> all
>>>>> hosted at IETF plenary meetings, for the same reason:  it's the place
>>>> where
>>>>> the largest number of stream contributors are together at the same
>> place
>>>>> and the same time.  It also borrows the rollback method inherent in the
>>>>> format proposal (double RFC publication, first with trial format, then
>>>> with
>>>>> final format).  If you have other methods in mind that would produce
>> more
>>>>> transparent discussion or more opportunity to test the results as we
>> go,
>>>>> I'd personally be interested in hearing them.  But this BoF follows the
>>>>> pattern we have used recently, at least to my eyes.
>>>>>
>>>>> regards,
>>>>>
>>>>> Ted
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>    Brian
>>>>>>
>>>>>> _______________________________________________
>>>>>> Rfcplusplus mailing list
>>>>>> Rfcplusplus@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/rfcplusplus
>>>>>>
>>>>>
>>>>
>>>
>>
>