Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-10.txt

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 22 January 2019 22:22 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA430131139; Tue, 22 Jan 2019 14:22:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 76oeYLOrlN9r; Tue, 22 Jan 2019 14:22:12 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 E32B5128B14; Tue, 22 Jan 2019 14:22:11 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id z13so87749lfe.11; Tue, 22 Jan 2019 14:22:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h6HoPKTJgX3BEZpm0bYv//zcCnlywY7zCGypX+QQcvU=; b=Ejcfx1E+22f5AiVZbWi5+Mj5EvH3rakJ8ux6e9yZNBZ8HpOwFUNO6MvNKnVMFP9nf3 f4Xe9+fbPVEfkKiRKASB6zjnZt4A35ZwMwwpmn/rt2P1LCsy7xvvykqS5eUwokkUYJXf wGVef0fpHjDGgIotgLYIy8yxVp3GpMtS2jRd0ZA0Ce/H3g+O9+o/unllFemvwiRw8LdZ lYYMI9YLGjaIykCL/WZ9Jk8BWXAkLFtZjb4UdmL3cvzj6MOkuJC/wsNyL0/AV14MQxe0 Z9AE3w76G2D5HWSqa316y4pFMYEH6pm9gM7p7FZu69gPFRVoYOLFfYXF50qn1wkbOK1P izQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h6HoPKTJgX3BEZpm0bYv//zcCnlywY7zCGypX+QQcvU=; b=ZZDX8KDiGwljh3zu2Ze5MR2Q+vtEG4kQV1a+KLPtl+Qh734RSwOBiDjKsrwbvTN9AV 6oUCI0piIsqy+yLg3bq+y7pVioa6xsezSC8iQXy4AMk3txWYNLrG7a53Do+TDeoHLqJl ypSx/G6eMTb13BjFJbBbNubddhmJRFSd0JfiFCoKPv+VgxpGAIP50VW1HW1IlH3ePsQz FY1DNQqMnPSZcrGkfSvVxHIn/PhnakoQYL/wmUEuL0tR1WOp+QyMbmqaWFJjpC2LNRVc tNU2eNk2y/cwFbyCQCqBQV2+u3A8jakwOvNdztbuHxzeTMJi3UoSQWiqpfoRQ2JQpszf Dcfw==
X-Gm-Message-State: AJcUukfwvr9pYnV7luYaHEsRmjNa8wsxktVC7NdMpXCNvZESmCo2zJx5 DqXx1FSFOhXHqXK/ORv3CKXSy9KQO3keK3Whj90=
X-Google-Smtp-Source: ALg8bN4DXIqHE8otP/XipYvEixpSeh5FqV+cLB70Xp/Mwo0Wx6h5l5dVXqvkuC5deUyQ6VhenCdFEqfAkKi/buxBtdI=
X-Received: by 2002:a19:41c4:: with SMTP id o187mr13602876lfa.32.1548195729940; Tue, 22 Jan 2019 14:22:09 -0800 (PST)
MIME-Version: 1.0
References: <154775953855.10322.13019924919889018658@ietfa.amsl.com> <4A1F8C46-9E3A-4F0C-B1CF-E2582100349F@inria.fr> <3BAA052F-FCB2-43CB-8F09-996EB76C1170@kuehlewind.net> <CE03DB3D7B45C245BCA0D24327794936303F0C7A@MX307CL04.corp.emc.com> <CAKKJt-f6rHpdynqzOCj729Vfeb83s7KAYSpVXhbUdOkGtZUcMQ@mail.gmail.com> <AC42A254-263C-4773-B5B2-38903F2CCD39@inria.fr>
In-Reply-To: <AC42A254-263C-4773-B5B2-38903F2CCD39@inria.fr>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 22 Jan 2019 16:21:57 -0600
Message-ID: <CAKKJt-fRC=+eNJESVtGUbftc6K1PbVqbW=pMnzeGN8qU+nS9dw@mail.gmail.com>
To: Vincent Roca <vincent.roca@inria.fr>
Cc: "Black, David" <David.Black@dell.com>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, Emmanuel Baccelli <emmanuel.baccelli@inria.fr>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Belkacem TEIBI <belkacem.teibi@gmail.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary="00000000000086a92705801368e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/-NJklYy006vkhGLlcZAfMLfLxEc>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-10.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Jan 2019 22:22:15 -0000

Hi, Vincent,

On Tue, Jan 22, 2019 at 3:43 PM Vincent Roca <vincent.roca@inria.fr> wrote:

> Dear Spencer, Mirja, David, all,
>
> Thanks a lot for help. From the official IETF counsel answer (I never saw
> it before), I see the best option is
> to engage discussions with the two TinyMT32 authors.
>
> I’ll do that tomorrow, keeping only Wes in CC (our shepherd) to avoid
> annoying you all (otherwise tell me).
> I’ll let them choose between two options:
>
> - they authorize us to remove their copyright and licence (since I also
> understand there’s a slight difference
>   in the licence) in the existing I-D;
>
> - or they co-author with us a new I-D that only focusses on the core PRNG
> that we add as normative reference
>   to this I-D. In that case we'll just keep the two mapping functions in
> the RLC I-D (it’s really specific to RLC and
>   masking is **usually a bad practice**).
>
> Cheers,
>

This sounds like a way forward to me, and I apologize for apparently
managing to notify every single person at the IETF except the guy who was
going to resolve this issue :-) ...

Believe me, that was not my plan!

Mirja and I were talking with Magnus yesterday (and exchanging e-mail this
morning) about which AD gets which working groups, but the default would be
Magnus would be responsible for TSVWG, so I cc him directly on this e-mail
(I'm sure he's on TSVWG, but he may be filtering working group e-mail at a
lower priority than e-mail sent directly to him).

We also talked about this draft, so he'll be aware of the background if we
don't get it approved before Wednesday evening in Prague.

Wes is an excellent shepherd and is one of the TSVWG chairs, but if
anything comes up that you two need a quick response to, please feel free
to include me.

And best wishes in your conversations with the TinyMT32 folk.

Spencer


>   Vincent
>
>
> Le 21 janv. 2019 à 23:52, Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com> a écrit :
>
> Hi, David,
>
> On Mon, Jan 21, 2019 at 8:44 AM Black, David <David.Black@dell.com> wrote:
>
>> Hi Mirja,
>>
>> > There are currently two contradicting copyright statements.
>>
>> I respectfully disagree, as use of multiple copyright statements for code
>> is common, particularly when a BSD code license is used.
>>
>> However, the IESG clearly needs the view of IETF legal counsel on this
>> topic - when might we expect to see that, and how can I help?
>>
>> Thanks, --David
>
>
> (snip)
>
> There's been a certain amount of to/cc trimming and adding on Mirja's
> discuss thread, by multiple ADs, and maybe by other folk, so I'm not sure
> who has actually seen this response from the IETF counsel, Brad Biddle.
>
> So, at least we are all starting from the same place now?
>
> Spencer
>
>  > Am 14.10.2018 um 00:25 schrieb Brad Biddle <brad@biddle.law>:
> >
> > Alissa and all — I think the inclusion of BSD-licensed code with a third
> party copyright notice is inconsistent with the literal requirements of
> BCP 78, as Mirja and Adam suggest in then thread below. Further, I don’t
> think that the TLP provision or blog post that Adam cites necessarily
> suggest support in spirit for this approach (I believe each are making
> different points, described further below). I agree with Adam’s conclusion
> that there is likely little practical impact here of including BSD licensed
> code with a copyright notice of a third party instead of the IETF, given
> that the rights are functionally identical either way. But think there are
> several reasons to NOT simply proceed with this as our practice, absent an
> explicit decision to do so and and effort to align our practices and IPR
> documents accordingly:
> >
> >       • Of course, we should follow the rules we set for ourselves, and
> the “additional copyright notices are not permitted” [1] rule is clear.
> BCP 78 does have an explicit exception process that that doesn’t seem
> applicable here. I don’t read either TLP Section 4 [2] or the cited blog
> post [3] as providing or suggesting additional exceptions. The TLP Section
> 4(c) provision that Adam cites is focused on clarifying that a party that
> takes a license from IETF under BSD terms is not simultaneously subject
> to Section 3’s more restrictive terms — i.e. it’s a different question than
> what we’re discussing here. Likewise, I understand the blog post to be
> focused on when an IETF copyright notice is required, and not focused on
> the idea of a third party notice. So: I think we have an unambiguous rule
> of no third party copyright notices.
> >
> >       • More substantively, the rights that the IETF gets under our
> normal BCP 78 terms and the rights we get when licensing in code under BSD
> terms are not identical. BCP 78 enables essentially unlimited future use by
> the IETF. BSD licensed code comes with some additional (modest)
> restrictions, such as the requirement to always provide particular required
> notices and disclaimers with any reuse. If we take in contributions under
> different terms, we have to make sure we manage our use to map to those
> terms. Our normal BCP 78 model avoids this problem: we get all
> contributions in under identical, broad terms.
> >
> >       • Here, and I suspect in future cases if we were to make this a
> practice, it’s not clear that labeling the code with only third party
> notices is appropriate. In this case I gather that there were some IETF-specific
> tweaks. Assuming these are reflected in copyrightable elements of the code,
> it’s inaccurate to only list the original copyright owners and not IETF.
> >
> > I suggest that we ask the authors of this code to provide to IETF as a
> normal BCP 78 “Contribution,” and then include the code with an IETF
> copyright notice. If they don’t want to do so (or can’t for some reason),
> then I suggest removing the code from the draft.
> >
> > If there is a desire to include third party BSD code on a ‘license-in =
> license-out’ basis, I think that’s potentially feasible, but I’d suggest we
> explicitly change our rules to address this scenario, and consider whether
> there are are practical implications for how we manage our contributions if
> we have materials coming in under two different licensing models.
> >
> > Please let me know if you think I’m missing something. Happy to discuss
> further, of course.
> >
> > Thanks,
> > Brad
> > (IETF legal counsel)
> >
> > Brad Biddle | brad@biddle.law | +1.503.502.1259 (mobile) |
> http://biddle.law
>
>
>