General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: "Livingood, Jason" <jason_livingood@comcast.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] "Very interesting L4S presentation from Nokia Bell Labs on tap for RIPE 88 in Krakow this week! "
Date: Wed, 22 May 2024 15:10:42 +0200	[thread overview]
Message-ID: <CD47E80D-AE88-434C-A289-0A87A6BAF36E@gmx.de> (raw)
In-Reply-To: <421E9E11-618B-4D6E-A905-D7C5F9457A3D@comcast.com>

Hi Jason,

> On 22. May 2024, at 14:48, Livingood, Jason <jason_livingood@comcast.com> wrote:
> 
> > in the IETF the gap between the 'no politics' motto  There have always been politics at the IETF and in every other SDO, open source project, etc. – it is human nature IMO.

[SM] I agree, but most other organisations openly accept that, it is only the IETF that claims to abhor politics. The IETF however publishes https://datatracker.ietf.org/doc/html/rfc7282 arguing against exactly the kind of horse-trading happening out in the open. The solution is IMHO not to try to enforce rfc7282 but to accept that politics is unavoidale and implement processes that takr that into account. As is the IETF rules allow chairs and ADs tremendous leeway without recourse or checks and balances.
BUT, I do admit that even with my limited experience with the IETF I have also seen WGs were the IETF process works really well, civil and productive, so not all is bad, but IMHO TSVWG demonstrates how easily that can derail or be derailed on purpose. Like when for a humming event (cough, ECT(1) input or output, cough) dozens of members appear that seem to never before or after have given any attributable input on a draft...


>  > And the fact that WG members see no harm in having private only strategy discussions with chairs and ADs.
>  In my personal experience at the IETF, when you are lead author or editor of a working group document it is routine to strategize with WG chairs and even ADs on how to keep the document moving forward, how to resolve conflict and achieve consensus, and how to be well-prepared for meetings. That IMO is a sign of WG chairs and ADs doing their job of developing standards on a timely basis.

[SM] Chairs and ADs function as arbiters in the process (whether they like it or not) and I like my arbiters neutral and unbiased. What would be the harm to have the discussion how to keep a document moving forward open on the mailing list? Doing it in secret is IMHO not a good optic (even if, what I assume and hope nothing untowardly happens).
My understanding is that "timely basis" is a far too important factor in recent years, I prefer no RFC over sup-standard RFCs. 



Regards
	Sebastian


>   JL



  reply	other threads:[~2024-05-22 13:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-21 15:31 Frantisek Borsik
2024-05-21 16:18 ` Jonathan Morton
2024-05-21 17:13   ` Livingood, Jason
2024-05-21 17:32     ` Sebastian Moeller
2024-05-22  5:40       ` [Bloat] Fwd: " Sebastian Moeller
2024-05-22  8:47         ` Frantisek Borsik
2024-05-22 12:48         ` Livingood, Jason
2024-05-22 13:10           ` Sebastian Moeller [this message]
2024-05-22  9:37       ` [Bloat] " Jonathan Morton
2024-05-22 12:30         ` [Bloat] [EXTERNAL] " Livingood, Jason
2024-05-22 12:27       ` Livingood, Jason
2024-05-22 12:54         ` [Bloat] [EXTERNAL] " Sebastian Moeller
2024-05-22 17:37           ` Sebastian Moeller
2024-05-23  0:06 [Bloat] " Livingood, Jason
2024-05-23  6:16 ` Sebastian Moeller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CD47E80D-AE88-434C-A289-0A87A6BAF36E@gmx.de \
    --to=moeller0@gmx.de \
    --cc=bloat@lists.bufferbloat.net \
    --cc=jason_livingood@comcast.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox