Re: Stream differences (Was: legal consultation)

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 07 May 2026 19:53 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ietf@mail2.ietf.org
Delivered-To: ietf@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 3ACABEAD1BC6 for <ietf@mail2.ietf.org>; Thu, 7 May 2026 12:53:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1778183633; bh=JYn12MU/3PCXNHdvNEzENc9anfEpglXegs3fnbm4ToU=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=cgIvTz2jWuopZn9rkMIr1T58OWoO5yRYhY3D5JZSoi78xv9BbRvwaJVzwUoaYkE3f AwYnHd+ZJ+guDQ4Ecy5SdxXDNtiaWNcEPfz9Zw2qK7rjyx4JGO1hNmCbyJumovttys LAle8oJ9q0lsvcUVc6O+zihE3pI+g4uVznOQ3LZE=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsB7LibIpY7G for <ietf@mail2.ietf.org>; Thu, 7 May 2026 12:53:52 -0700 (PDT)
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 7C40CEAD1B2E for <ietf@ietf.org>; Thu, 7 May 2026 12:53:50 -0700 (PDT)
Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-82fa8d6425bso601693b3a.0 for <ietf@ietf.org>; Thu, 07 May 2026 12:53:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778183630; x=1778788430; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=vhPW/rwsIalG5A7Wo+1A9pPAitFvRXpczkuCT/vgauw=; b=gpV2X5HLuCXGkIQROvq+4VpcT6Mjq6Y6HumODoTuxY4u8n8gD39Bc5msfgIOq7K140 wk3ytX8WCSEZVvtAd4pH6sDq8c1lUcFSoetV4zI4zBDidUsYhlMXc/B6+BnBbphwKWsT jhVkg2p/lp2dctQkxJUHeRN7SyDWzNSz/0oKIzTywWaS8hSKobh+qdmBRvipqhLjz8IN r438BW70OClwcUQ6oddLyYR77XmRwFg9DfLtZHKdbEkrsFxW1pIeY93z61Btk9QKK1D5 s0CtXFhoy4Q8ilVldCLmmqyt8f8n6CynO5ksWrOYo9EZOzkU53QX6lwuB3oDs8GgzJmN wZJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778183630; x=1778788430; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vhPW/rwsIalG5A7Wo+1A9pPAitFvRXpczkuCT/vgauw=; b=kH5VJT3iqQa2Bjki/i/+uNjtMgL7AwSLVG47pRDcgYSrrCUEgKDjKHQJL+BzSjP2YJ ur4VA3LUeANEE/KotSQHhp8JjwAMcVspCjFgDFdKJS/veFODxmBwnhJFnpg6yboi0waf tylZjRTsOT/ERIAOJlvPcFbUWpYL3FQEtaxuGvhM9cXDZnIbsLGd8rZxdzuXUDWMGAZb 9yVcufm7efsU817MJdQdwPZdik28ZA0ohCSzg2nP5y0h5eB+TitDEyuDPU4MLnhN0Q/b rD/Elfask1OgOi+pLvwBLbV0YZI5JIQGJMkPbxHmCr5lnoK/tfJ/2/Ee0ftbRB6DyNJC Sq3w==
X-Forwarded-Encrypted: i=1; AFNElJ8KBJHOHTW8Vx3Q3EI0x4/r15P538flLrBKzDxAp9kUfZFjkeOdRWVhZ6/FAGzJpweHGLA/@ietf.org
X-Gm-Message-State: AOJu0Yw2wVAiX8lJf86bpB+ZGBbfCZLmVUpJ9bA1JkIXwgstH7O2Xgbl b0vCXxGrs2DWfN33D59lHF7UhAyc3ODXMQv6z+yonTbwVKIbvZXMcr4K
X-Gm-Gg: AeBDievBvswqKaFmKpalAJvo+Nfjv0pyALIUi8sOIvw9D28n/FH5hQTN4LlwqeGN4CN U1lTB71fQbUzpCKfmaO5Q5T6EDN0BN5KxGEE1DPruIFcr8hHiN4vEopt5CHPyMlTKeXS2YqkZ6L lwk/EsGRucXz3RBpeNuKNgLT4qGlQbeCtBMpaRJE3V4KJR337ORN+GVY1YYHIuf997NsWfgxUt2 AP3QShcx0i+UF/H8imADrtbGUNS/N22nulbjGrZnLk3eMBwLvKFI+bFc8uNkHs+4Jl60U8bCyDz IvqglyhIuK1ousE2SIelnnD+9Aao//GsZHveJR7X0470lXJ7PdMkKsgOKkcREegsyL8kb1lhY29 n5XcNi1CDoleo74e2vjyMNj+3wvrU/RK2qJRIf4KrZ2jhkFckXWLuoiIcPEEZasSq7jqMB4tn7w vuT1oaILaQL4m2cb0pifP3AkYBJZWF3DZv7ZAb8MQSPgxTspswJcR4QbeGCRUEa6rDYUBd0y0P2 xxPiby4e/yNuMlZESbVBJOVpe1A
X-Received: by 2002:a05:6a00:84c:b0:835:38fc:b9a with SMTP id d2e1a72fcca58-83a5e35d378mr9188908b3a.49.1778183629514; Thu, 07 May 2026 12:53:49 -0700 (PDT)
Received: from ?IPV6:2404:4400:a100:1829:5956:ca53:df83:6568? ([2404:4400:a100:1829:5956:ca53:df83:6568]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-839679c8629sm9837811b3a.36.2026.05.07.12.53.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 May 2026 12:53:49 -0700 (PDT)
Message-ID: <3c3913ee-ea91-4e32-b0ff-7e917deb7fe1@gmail.com>
Date: Fri, 08 May 2026 07:53:43 +1200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Stream differences (Was: legal consultation)
To: Jay Daley <exec-director@ietf.org>
References: <CAChr6Sy1jsjNzh1qMEDVx7ABp_1_uPkfx_tY-T7zPpXTdZiXtQ@mail.gmail.com> <877bpgb7bq.fsf@josefsson.org> <c7aae006-be27-4beb-9553-0b8efb4bd600@gmail.com> <87o6iradux.fsf@josefsson.org> <1896fe87-2494-424a-9893-592b856291f9@gmail.com> <0959C770-3C7F-4763-9382-3B2CEBC0F5C0@ietf.org>
Content-Language: en-US
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <0959C770-3C7F-4763-9382-3B2CEBC0F5C0@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID-Hash: SYHBCJBVXSCBSPLUFLQFDPDR7DQFWNNU
X-Message-ID-Hash: SYHBCJBVXSCBSPLUFLQFDPDR7DQFWNNU
X-MailFrom: brian.e.carpenter@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Simon Josefsson <simon@josefsson.org>, Rob Sayre <sayrer@gmail.com>, IETF discussion list <ietf@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/0_L4DKgVYrl3wI7LcTtHziu4hf8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-owner@ietf.org>
List-Post: <mailto:ietf@ietf.org>
List-Subscribe: <mailto:ietf-join@ietf.org>
List-Unsubscribe: <mailto:ietf-leave@ietf.org>

On 08-May-26 07:49, Jay Daley wrote:
> 
> 
>> On 7 May 2026, at 19:58, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>
>> On 07-May-26 19:16, Simon Josefsson wrote:
>>
>> The IETF cannot remove the option globally. The IETF can only remove it
>> for the IETF stream. The other streams can make their own decisions.
>>
>>> With your proposal, the complexity is increased, and coupling different
>>> streams to different set of legal terms.
>>
>> That is already the case. Each stream is different.
>>
>>> It also begs the question how
>>> to deal with a single document switches back and forth between streams,
>>> or handling contributions received for each situation.  If we really
>>> don't want to go down into that complexity rabbit hole, I suggest to
>>> avoid it.
>>
>> We are already there, and have been since the separate streams were
>> properly defined. For the IETF it would get simpler, for the other
>> streams nothing would change.
> 
> Hmm, not quite.  All of the streams explicitly adopt RFC 5378 or BCP 78
> 
> Three reference RFC 5378:
> - IRTF stream in Section 3 of RFC 5743
> - Independent stream in Section 4 of RFC 5744
> - IAB stream in Section in Section 4 of RFC 5745
> 
> With this same language:
> 
>> During Internet-Draft submission, authors who intend to submit their
>> document for publication in the XXX stream will grant rights as
>> described in [RFC5378]. To request that the contribution be
>> published as an RFC that permits no derivative works, an author may
>> use the form specified for use with RFC 5378.
> 
> 
> One references BCP 78
> - Editorial stream in Section 3.2.2 of RFC 9920
> 
> So obsoleting either RFC 5378 or just the derivatives clauses has an immediate knock-on effect that has to be resolved, with the current status quo being that the streams are aligned,

Good catch, but that could be fixed by careful wording.

      Brian