Re: [Rfced-future] iRSE comments on the new RFC editor structure

Eric Rescorla <ekr@rtfm.com> Sat, 06 November 2021 01:14 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9A13A0C97 for <rfced-future@ietfa.amsl.com>; Fri, 5 Nov 2021 18:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20210112.gappssmtp.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 Pr_z_b4oyOOK for <rfced-future@ietfa.amsl.com>; Fri, 5 Nov 2021 18:14:04 -0700 (PDT)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 3EE3C3A0C93 for <rfced-future@iab.org>; Fri, 5 Nov 2021 18:14:04 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id x9so11198532ilu.6 for <rfced-future@iab.org>; Fri, 05 Nov 2021 18:14:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=calXmDwaXUHHOVcrL0jax7M0z2VRgvw4VZNWgt1zQ6s=; b=G4k5ru20pVFyFBb3M4wKP0C8fim6XstUfcWjDQrZcHjt18jXC9EijRl9nHbDaJMy2p eoaiB5oCM/EuokDXEoSAxvVVmtWquAc7M0nYtJQ+Jjpo77IIKCgZMIf6I0KVyWUxuIz5 oG6tY7mi/fp4nK7GGWKXTITR8mq+oqEm+FFAa+VEVDFJMk1YvthP9++BLTSVcUHVykvC NO023EWZ8LwrOjbTJ79ltcCnwCmh0fkIw9UFx/RHA4gGWVjLagC4x/otH0lxNgnm188X GuIXsSrmuDmgp5KK4PU4lymiJ0894TlJ8JUCRfyZw+bj6RnWTYlAg9/wbpyNV8mOiEFs lxFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=calXmDwaXUHHOVcrL0jax7M0z2VRgvw4VZNWgt1zQ6s=; b=ajCPLxOuo8A53ju+i+iiMRsmWo1Op2UeIk/fzJRZbYmBz6l59pA6OFannvB4L9r+P0 F9SBF1dXZqB5hNk7fiokjEuQC07EiAqzmKnkD3MG4f8sWhja7Uu2IIwES1CdyqwITYrp DVOlOlUK2wurj4Ju1k0mKNvGHFEe7yUudOxd4/BLtsaWqzNAGcrFtygHYg3ncs3s3iYR p3P+fjXyLyJXkOdhJlLKx6YVhkWuGZNDmbK815YQtdAbbsJFfPOUmrStB8WENeLyODme msAMi+R7R/OsqVtDQOIxJZM40zNH/TiPoxgyey7+pIx7JpzVImSc9i/n0jFlt4BBZtun CCXA==
X-Gm-Message-State: AOAM533d50Olh17231uCffEbhCpuCsNRGV5SaaYereIoF7RAc6+02zp2 02SlX54ijgXsrs6glIJTfOVuKGoNMkljdPMnZB3/tA==
X-Google-Smtp-Source: ABdhPJzy5Anj0JnPKHYoigjLpwb0X6XCesLjO+xrzFs6XYerwWO5CEawqZY7zBu7rQ1W+9NJqakP91XE3WUqwtXwDQ8=
X-Received: by 2002:a05:6e02:20ea:: with SMTP id q10mr19305620ilv.10.1636161241202; Fri, 05 Nov 2021 18:14:01 -0700 (PDT)
MIME-Version: 1.0
References: <C1FC0A42-C56E-48EC-A4E1-6095F635EA6B@mnot.net> <50897D59-8C2A-4D1B-B239-3689E34C5C7A@ietf.org> <C16D8E8B-6B1A-40C3-B814-60F5A90E6645@mnot.net> <B7FC484B-93A1-432D-ACBA-1333CAD01FBC@kuehlewind.net> <ac6fa83c-4da8-822a-5630-ba30dc427de2@lear.ch> <2A4B74AC-33BA-4593-8B62-E15B962CDB1A@kuehlewind.net> <82a8b930-2203-8a97-2b82-5ee8ab935140@gmail.com> <B17AD1EE-6940-4CB8-8AD7-43BC9E03F7D4@kuehlewind.net> <4942ef86-8c86-26a1-52a0-2418cf0690dd@gmail.com> <CABcZeBPheEyr9Oj1Ytd2D-v_vs1nPqrQofHMZQM6g+HbTgj8pw@mail.gmail.com> <08c35327-c30f-4834-9efa-e47e6d9304da@joelhalpern.com>
In-Reply-To: <08c35327-c30f-4834-9efa-e47e6d9304da@joelhalpern.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 05 Nov 2021 18:13:24 -0700
Message-ID: <CABcZeBOXR9Oyue25cjtSZgag1XWsXstP9EA4BeGryoqFGANcSQ@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, rfced-future@iab.org, Mark Nottingham <mnot@mnot.net>
Content-Type: multipart/alternative; boundary="00000000000093d4fe05d0147932"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/TUwA7sW0_S9J3n95S0NMaUVYW5g>
Subject: Re: [Rfced-future] iRSE comments on the new RFC editor structure
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Nov 2021 01:14:10 -0000

FWIW, I was anticipating that these statements would go through the same
process as RFCs, they just wouldn't be published in the series.

With that said, if we can agree that RFCs published by the RSWG/RSAB
venue either have immediate effect upon RSAB approval or expedited
publication in the RFC series, I don't object to them being published as
RFCs.

-Ekr



On Fri, Nov 5, 2021 at 4:34 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:

> I think there is a basic problem with this approach (at the bottom) of
> RSWG statements.
> IESG statements are made by people appointed by and responsible to the
> community.  We permit them to make statements that do not necessarily
> have rough community consensus when decisions need to be made.  because
> they are our seleccted leaders.
>
> Allowing the RSWG to issue statements does not match that pattern at
> all.  These statements are not, by the rules we have written so far,
> even subject to review by the RSAB.  They do not require community
> review and acceptance.
>
> People keep saying that RFCs are a lot of work.  What the numbers that
> others have produceed show is that the work is in the working group and
> community rough consensus process.  Either we retain that part of the
> process, and thus the work, or we ditch that and have an unaccountable
> body able to exercise authority of the workings of the RPC.
>
> For me, I would rather retain the work.  if the thing being done does
> not have a long enough impact to be published, then it is clearly not
> Policy.  Its tactics.
>
> Yours,
> Joel
>
> On 11/5/2021 7:25 PM, Eric Rescorla wrote:
> >
> >
> > On Fri, Nov 5, 2021 at 3:58 PM Brian E Carpenter
> > <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>>
> wrote:
> >
> >     Hi Mirja,
> >
> >     On 05-Nov-21 22:31, Mirja Kuehlewind wrote:
> >      > Hi Brian,
> >      >
> >      >> On 4. Nov 2021, at 21:02, Brian E Carpenter
> >     <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>>
> >     wrote:
> >      >>
> >      >> On 05-Nov-21 02:10, Mirja Kuehlewind wrote:
> >      >>> Actually, that's a bit overly simplified I guess. RFC3710 say
> >     “[The IESG] also
> >      >>>     administers IETF logistics, including operation of the
> >     Internet-Draft
> >      >>>     document series and the IETF meeting event.”
> >      >>> However, if you further read on, the RFC says "The IESG has web
> >     pages
> >     as part of the IETF web (www.ietf.org <http://www.ietf.org>)”.
> >      >>> This RFC was written before the datatracker was widely used and
> >     when the old ietf.org <http://ietf.org> page was still up. From the
> >     RFC it seems, however, quite
> >     cleat that all matters related to the datatracker are clearly in
> >     scope for
> >      >> the IESG, however, there are probably parts of the ietf.org
> >     <http://ietf.org> side where
> >     authority is not fully clear or lies with some other entities (e.g.
> >     information about the LLC or the IAB…).
> >      >>
> >      >> Well yes. It isn't actually said very clearly in RFC 8711, but
> >     the implication is that the LLC provides tools and the IETF web
> >     site, and controls the RFC Editor contract, which implies the RFC
> >     tools and web site.
> >      >
> >      > I have to slightly disagree here. Jay nicely separated 4
> >     different angles about the website strategy, function design,
> >     content, and infrastructure. While the LLC or RPC is responsible for
> >     the infrastructure of running
> >     and maintaining the website, there is a gap in who owns the content
> >     and functions design decisions. And based on my own interactions
> >     with the RPC I believe they also don’t want to be responsible for
> >     the content,
> >     beyond just reflect what’s written down in RFCs, as that would
> >     require more community responsibility.
> >      >
> >      > While the IESG has authority about (at least most parts of) the
> >     IESG website content, I don’t think it should be the RPC or LLC that
> >     has
> >     authority about the RFC editor website content and I don’t think
> >     that’s what RFC8711 says because otherwise this would also be true
> >     for IETF website.
> >
> >     I agree with that. As others have made clear, the boundary between
> >     policy
> >     and implementation is somewhat subjective, but except in
> >     emergencies, the
> >     RPC and LLC are not supposed to make policy.
> >
> >      > So I think we have a gap here. I don’t think the RSWG has the
> >     right structure to fill that gap (as these things don’t require
> >     policy, aka Jay’s point about strategy for the webpage) but
> >     decisions. For me the only available option is the RSAP (or
> >     something entirely new but I really hope we won’t end up adding more
> >     bureaucracy and positions to the model)...
> >
> >     Agreed, sort of. But I observe that when needed, the IESG sets
> >     policy by issuing an IESG Statement. I see no reason why the
> >     RSWG/RSAB can't issue a formal statement when the topic is not
> >     suitable for an RFC. If there are words in the draft that forbid
> >     that, we should remove those words.
> >
> >     So, someone proposes in the RSWG that the RFC Editor web site should
> >     be unavailable on the day of the full moon. There is rough consensus
> >     for this, the RSAB agrees, and puts out a formal Statement saying
> >     so. The RPC implements this.
> >
> >
> > I agree with this. This is consistent, I think with our practice of
> > having non-RFC IESG statements that still have substantive force.
> >
> > -Ekr
> >
> >          Brian
> >
> >      >
> >      > Mirja
> >      >
> >      >
> >      >
> >      >> But as I have quoted to the point of boredom, it also says that
> >     the LLC "is expected to respect the IETF community's wishes". As far
> >     as rules go, I believe that's all we've got. It's enough, but it
> >     does seem that our
> >     draft should empower the RSWG/RSAB to *express* those wishes. We
> >     can't change RFC 8711, because we're not the IETF.
> >      >>
> >      >>    Brian
> >      >>
> >      >>> Mirja
> >      >>>> On 4. Nov 2021, at 13:59, Eliot Lear <lear@lear.ch
> >     <mailto:lear@lear.ch>> wrote:
> >      >>>>
> >      >>>>
> >      >>>> On 04.11.21 13:57, Mirja Kuehlewind wrote:
> >      >>>>> I agree authority about the content of any page should not
> >     sit with
> >     the the LLC. For the ietf.org <http://ietf.org> page and the
> >     datatracker the authority is with the IESG which a board of
> >     community members selected by community member.
> >      >>>>
> >      >>>> Precisely where does it say that?  Maybe we can model that
> >     language.
> >      >>>>
> >      >>>> Eliot
> >      >>>>
> >      >>>> <OpenPGP_0x87B66B46D9D27A33.asc>
> >      >>
> >      >> --
> >      >> Rfced-future mailing list
> >      >> Rfced-future@iab.org <mailto:Rfced-future@iab.org>
> >      >> https://www.iab.org/mailman/listinfo/rfced-future
> >     <https://www.iab.org/mailman/listinfo/rfced-future>
> >      >
> >      > .
> >      >
> >
> >     --
> >     Rfced-future mailing list
> >     Rfced-future@iab.org <mailto:Rfced-future@iab.org>
> >     https://www.iab.org/mailman/listinfo/rfced-future
> >     <https://www.iab.org/mailman/listinfo/rfced-future>
> >
>