From ekr@rtfm.com Thu Sep 28 09:09:39 2023 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99EE1C1519B8 for ; Thu, 28 Sep 2023 09:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20230601.gappssmtp.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJYsMjzMY3f1 for ; Thu, 28 Sep 2023 09:09:38 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF53FC1519B0 for ; Thu, 28 Sep 2023 09:09:24 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-d7f0a60a159so14950629276.0 for ; Thu, 28 Sep 2023 09:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1695917364; x=1696522164; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WJAx01dFgRFBSlliu09QMKllLTRairVmw0EnvIFT1gQ=; b=zLLJ805MAbCdKseDDRXgP9+TFqZBk7/hmruqxVABGDyjCNXk+5SmUunQ2AVgzITgSi WbWPVL6HziWj1DX1EinSxXNHjMCNb+Vz7Trx03//aNJ0avkYlnGfWO+XmoPKMZimZLKV Mb+RaH9NL9j9R0DYmP1Et08oAgJ8YLhBWIl+S/0nIk/6Si6rFjiDnDCp4v90JlFhvAnG jLjycB7LiR2+NJVLnod23zUSfMVyspJcVhOvZ3tUeeZQInprOg9oiDZPH1ESxdu82kIZ XU904Cs9aIBs2M2dj0364ZbcJVnUEtems+8ttIYXoU/rSoVIo/7SrtBtsbUPAyuhPTDI SNEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695917364; x=1696522164; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WJAx01dFgRFBSlliu09QMKllLTRairVmw0EnvIFT1gQ=; b=pXFiNMRzjtOmrLLjv7DAopxrQmlXafdbZrSj3/XrfmY0b14UXQSUBgz1jYtEIN67n0 9BlxFofNxPMPDdB5BUiH7oIh39aGWnUxDJJKj8hBrjlVHRTvZPmkDJ4DDdcWxwng0IjZ TcQgAZSsHUT1wV6sxJSR2hKGrfkS9p30vc6/xPQTMRu6GKQEsYqfBEDYqZf3jUhi+TbB rUh8q1kdPmhSAQmrt2vwAM9uMy+c9dz9xF050wJh6TrN1KBYZJgAmrHIQHjQfSQgQ4dc EpHnpfp7jvFi4C859ZeQRT3vO7SGX9qgynLXtQb7Na2dE3mPs/wTPwO/pBo98wy2HyJ1 hIlw== X-Gm-Message-State: AOJu0YxuUr9IUDtjImZB24sXh7XEep2yaGu0XfliPJlUBWBbT8yPYS0o tK5T6MhJ7zoBSQd/Fy0wW05mH7+2mkcdONGfipuH1g== X-Google-Smtp-Source: AGHT+IEdgA4avWS+xoM4eZzjxPMMeuQ3I/CpCCrKFx75yMdjG30Rv+xd3iwGGIcggxhaVay8QCrR09zLSQmu8d2S/iU= X-Received: by 2002:a25:c5c9:0:b0:d89:f292:6e80 with SMTP id v192-20020a25c5c9000000b00d89f2926e80mr1530927ybe.35.1695917363400; Thu, 28 Sep 2023 09:09:23 -0700 (PDT) MIME-Version: 1.0 References: <169587871859.41935.17692726615817157868@ietfa.amsl.com> <3c7a5635-6a18-445e-9483-22ebfe31e1d5@betaapp.fastmail.com> <459e63b6-ff7b-fb85-7e44-0ada8940d7c6@lear.ch> In-Reply-To: <459e63b6-ff7b-fb85-7e44-0ada8940d7c6@lear.ch> From: Eric Rescorla Date: Thu, 28 Sep 2023 09:08:47 -0700 Message-ID: To: Eliot Lear Cc: Joel Halpern , Martin Thomson , gendispatch@ietf.org Content-Type: multipart/alternative; boundary="00000000000003c31006066d88bb" Archived-At: Subject: Re: [Gendispatch] New Version Notification for draft-thomson-gendispatch-rfc-derivatives-00.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2023 16:09:39 -0000 --00000000000003c31006066d88bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 28, 2023 at 8:34=E2=80=AFAM Eliot Lear wrote: > If you don't mind me responding to this message: > On 28.09.2023 17:00, Eric Rescorla wrote: > > First, let me say that I agree that it's not desirable to have multiple > competing versions > of a different protocol, so I think on that we are on the same page. Wher= e > I think we > may disagree is on whether permitting people to use the text in IETF RFCs > in > their own specifications has a meaningful impact on whether that happens. > > There have *at least* been three institutions in particular where we > actually had to remind them that they couldn't modify our work and then > republish it. You mentioned ETSI. > If you are referring to eTS, I do not believe that this is what happened, as I said, ETSI was not using the TLS spec, but rather was effectively publishing an extension draft. -Ekr > It also happened at ISO once and at the ITU several times. Them doing > so would put implementors in a real bind because different jurisdictions > have different regulatory requirements as to which standard set to follow= . > This is about to get more complicated with CRA in Europe over the next fe= w > years. > > This is why I think we need to take things one step at a time, and even > taking a step where we have an approval process would require at least so= me > consideration. > > > It might be useful to start by putting the question of text aside. Suppos= e > that > I think that the IETF is taking protocol XYZ in the wrong direction. Unde= r > the current > IPR rules, I don't think anything precludes me from: > > 1. Writing a new document that is wire compatible with XYZ but doesn't us= e > the > words from the IETF specification. > 2. Calling that protocol "XYZ" in the document. > 3. Calling that specification an "RFC" and in fact using the same number > as the > IETF specification. > 4. Publishing the specification on my site. > > It's not just the IETF that has to worry about this, but it is a > series-wide issue. Mostly it's a non-issue, because I've never seen anyo= ne > actually do what you suggested. And what you are talking about is more a > trademark matter, rightWhat I *have* seen is a member of another body > take parts of our work, and want it to become Recommendation ITU-T > X.somethingorother. > > Regarding your comments about IANA, I largely agree with your analysis, > except that I think the license can enforce our IANA policy. > > All of this having been said, I do think it would be fine for the Trust t= o > have a process for how to release documents for derivative uses, so long = as > there is some sort of manual check. I had one document stuck in the > independent queue precisely because we ran into IPR... on an OLD RFC!!!! > And everyone was trying to do the right thing. So again, let's keep this > discussion going. > > Eliot > > > --00000000000003c31006066d88bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 28, 2023 at 8:34=E2=80=AF= AM Eliot Lear <lear@lear.ch> wrot= e:
=20 =20 =20

If you don't mind me responding to this message:

On 28.09.2023 17:00, Eric Rescorla wrote:
=20
First, let me say that=C2=A0 I agree that it's not desirab= le to have multiple competing versions
of a different protocol, so I think on that we are on the same page. Where I think we
may disagree is on whether permitting people to use the text in IETF RFCs in
their own specifications has a meaningful impact on whether that happens.

There have at least been three institutions in particular where we actually had to remind them that they couldn't modify ou= r work and then republish it.=C2=A0 You mentioned ETSI.

If you are referring to eTS, I do not believe that this is what= happened, as I said, ETSI was not using the TLS spec, but rather was effec= tively publishing an extension draft.

-Ekr

=C2=A0

=C2=A0 It also happened at ISO once and at the ITU several times.=C2=A0 Them doing so would p= ut implementors in a real bind because different jurisdictions have different regulatory requirements as to which standard set to follow.=C2=A0 This is about to get more complicated with CRA in Europ= e over the next few years.

This is why I think we need to take things one step at a time, and even taking a step where we have an approval process would require at least some consideration.


It might be useful to start by putting the question of text aside. Suppose that
I think that the IETF is taking protocol XYZ in the wrong direction. Under the current
IPR rules, I don't think anything precludes me from:

1. Writing a new document that is wire compatible with XYZ but doesn't use the
words from the IETF specification.
2. Calling that protocol "XYZ" in the document.<= /div>
3. Calling that specification an "RFC" and in fa= ct using the same number as the
IETF specification.
4. Publishing the specification on my site.

It's not just the IETF that has to worry about this, but it is a series-wide issue.=C2=A0 Mostly it's a non-issue, because I'v= e never seen anyone actually do what you suggested.=C2=A0 And what you are talking about is more a trademark matter, rightWhat I have seen is a member of another body take parts of our work, and want it to become Recommendation ITU-T=C2=A0 X.somethingorother.

Regarding your comments about IANA, I largely agree with your analysis, except that I think the license can enforce our IANA policy.

All of this having been said, I do think it would be fine for the Trust to have a process for how to release documents for derivative uses, so long as there is some sort of manual check.=C2=A0= I had one document stuck in the independent queue precisely because we ran into IPR... on an OLD RFC!!!!=C2=A0 And everyone was trying to do the right thing.=C2=A0 So again, let's keep this discussion go= ing.

Eliot


--00000000000003c31006066d88bb--