netdev - Re: DCCP Deprecation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <CWLP265MB644901EC2B8353A2AA2A813CC915A@CWLP265MB6449.GBRP265.PROD.OUTLOOK.COM>
Date: Wed, 16 Aug 2023 15:26:07 +0000
From: "Maglione, Gregorio" <Gregorio.Maglione@...y.ac.uk>
To: Stephen Hemminger <stephen@...workplumber.org>
CC: Paolo Abeni <pabeni@...hat.com>, Kuniyuki Iwashima <kuniyu@...zon.com>,
	Jakub Kicinski <kuba@...nel.org>, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Florian Westphal <fw@...len.de>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Rakocevic, Veselin"
	<Veselin.Rakocevic.1@...y.ac.uk>, "Markus.Amend@...ekom.de"
	<Markus.Amend@...ekom.de>, "nathalie.romo-moreno@...ekom.de"
	<nathalie.romo-moreno@...ekom.de>
Subject: Re: DCCP Deprecation

> Is the scheduling in the kernel? If so yes, it will cause a MP-DCCP not to be accepted.
> If it is all done in userspace, then it leaves option for someone to reinvent their own open source version.

The protocol works at the kernel level, and has a GPL scheduler and reordering which are the default algorithms. The GitHub implementation includes some non-GPL schedulers and reordering algorithms used for testing, which can be removed if upstreaming.

From: Stephen Hemminger <stephen@...workplumber.org>
Sent: 16 August 2023 16:00
To: Maglione, Gregorio <Gregorio.Maglione@...y.ac.uk>
Cc: Paolo Abeni <pabeni@...hat.com>; Kuniyuki Iwashima <kuniyu@...zon.com>; Jakub Kicinski <kuba@...nel.org>; David S. Miller <davem@...emloft.net>; Eric Dumazet <edumazet@...gle.com>; Florian Westphal <fw@...len.de>; netdev@...r.kernel.org <netdev@...r.kernel.org>; Rakocevic, Veselin <Veselin.Rakocevic.1@...y.ac.uk>; Markus.Amend@...ekom.de <Markus.Amend@...ekom.de>; nathalie.romo-moreno@...ekom.de <nathalie.romo-moreno@...ekom.de>
Subject: Re: DCCP Deprecation 

CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and believe the content to be safe.

On Wed, 16 Aug 2023 09:38:21 +0000
"Maglione, Gregorio" <Gregorio.Maglione@...y.ac.uk> wrote:

> >As Kuniyuki noted, a relevant record of contributions to netdev would
> >help/be appreciated/customary before proposing stepping-in as
> >maintainer of some networking components.
>
> Admittedly I have minimal netdev experience, I thought helping with an unmaintained protocol with no users would have been good experience. However, if we're looking to upstream MP-DCCP then our project would no longer require a DCCP maintainer.
>
> >IMHO solving the license concerns and move MP-DCCP upstream (in this
> >order) would be the better solution. That would allow creating the
> >contributions record mentioned above.
>
> MP-DCCP is open source under GPL-2. The scheduling and reordering algorithms are proprietary, however, they are not necessary to MP-DCCP and can be omitted. Is that enough to solve the license concern?

Is the scheduling in the kernel? If so yes, it will cause a MP-DCCP not to be accepted.
If it is all done in userspace, then it leaves option for someone to reinvent their own open source version.