[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<CWLP265MB644915995F6D87F6F186BEF7C915A@CWLP265MB6449.GBRP265.PROD.OUTLOOK.COM>
Date: Wed, 16 Aug 2023 09:38:21 +0000
From: "Maglione, Gregorio" <Gregorio.Maglione@...y.ac.uk>
To: Paolo Abeni <pabeni@...hat.com>, Kuniyuki Iwashima <kuniyu@...zon.com>,
Jakub Kicinski <kuba@...nel.org>
CC: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Florian Westphal <fw@...len.de>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>, Stephen Hemminger
<stephen@...workplumber.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
>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?
From: Paolo Abeni <pabeni@...hat.com>
Sent: 11 July 2023 11:06
To: Maglione, Gregorio <Gregorio.Maglione@...y.ac.uk>; Kuniyuki Iwashima <kuniyu@...zon.com>; Jakub Kicinski <kuba@...nel.org>
Cc: David S. Miller <davem@...emloft.net>; Eric Dumazet <edumazet@...gle.com>; Florian Westphal <fw@...len.de>; netdev@...r.kernel.org <netdev@...r.kernel.org>; Stephen Hemminger <stephen@...workplumber.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.
Hi,
Please send plain text messages, and do proper quoting.
On Tue, 2023-07-11 at 09:31 +0000, Maglione, Gregorio wrote:
> The IETF marks MP-DCCP as EXP and is set to mark is as PS soon.
> Removing DCCP from the kernel would likely impact PS standardisation
> or better. If the reason for removal is the lack of a maintainers,
> then I have sufficient time for bug fixing and syzbot testing.
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.
> If, as Jakub suggests, DCCP has no users other than MP-DCCP, and as
> such shouldn't be maintained,
FWIW, I agree that in kernel user would help DCCP "de-deprecation"
> then are you suggesting that we investigate this license concern to
> allow for MP-DCCP to move upstream, or did you have a patch in mind?
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.
FTR MPTCP is already there, perhaps there is some possible convergence
between the 2 protocols.
Cheers,
Paolo
Powered by blists - more mailing lists