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

"StJohns, Michael" <msj@nthpermutation.com> Sat, 06 November 2021 03:07 UTC

Return-Path: <msj@nthpermutation.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 804143A1085 for <rfced-future@ietfa.amsl.com>; Fri, 5 Nov 2021 20:07:31 -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=nthpermutation-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 4xd_bc6kru8y for <rfced-future@ietfa.amsl.com>; Fri, 5 Nov 2021 20:07:26 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 CF0AF3A1084 for <rfced-future@iab.org>; Fri, 5 Nov 2021 20:07:25 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id x27so22533978lfu.5 for <rfced-future@iab.org>; Fri, 05 Nov 2021 20:07:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NUTq5IWA8B0MI+aYGQfkZjGa78Fj+Km1enK2bls0K+Y=; b=lNU0i89Ik+8dkZ6jkOc6Qj/orK8BDQtKNHVsq3Ikc2ZcpDc8HtkNTsc6njnXSaAsIf Pb3EeFdp/nCRoL3bBPpwWNvWe8Xv6M1WYZPgn6frhNlfe56WadNaDNUCn65EzYSLw2l7 S0oZRzX3154Z/+FZVlt49zTdMnzQPB5XCPtnD+gaz6lZLJDojREuqDRh2r+bzTHRZLBH eCQzjadODOT4xJR3rIfI1RQ+5iiBiehZHTNHGH8vBRismwhzNQHrqbQ3F8b2oed9kyIk IWcmoITMIvK5c9GBfnF0jt2oUpWAMYZzChjbHDChFYLJQqVQbXE67p99HWRzKhmpmCrd ydGQ==
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=NUTq5IWA8B0MI+aYGQfkZjGa78Fj+Km1enK2bls0K+Y=; b=73HBbBHxVkJIuhUHR6SNbwxEc2rgBsanFoK94HSQ/DmWo3uE+qhRj0Lh0RlOJekXO/ 8+5nJbICtpEbyH76wfg9ucvvbOF3E0Z5NV1Brt3e/hhNSvmAtyjSqFSLn2Kcza3Ul9lX eWPI5voOYkkwf+Xr4++ofpj+kUn5IhB3DaE5ykv6x5X0idwMPGee0tstafsiEfI8f+GI 0fjsGvCKMwbC59wQxR/evp3oQGBXOwICwHS8nFOn98mwE4/p0lMvmskHRrkO6QUqsDp9 0JDVy+slOZ0bFJ0o/VKEepog4S0+t/YulWehONEUzh3QEK/6SOcFKvvQSctZrd/0z4z8 cYiw==
X-Gm-Message-State: AOAM531u/BJ48zWg/MucbekS9U3jvStP5ZUmeXbUOEzoqzf+YmaWPEVD fcgDJPRPz8ktYUHb3/KE/8kqavVDXnq/3cgyn2D8dRFVg7O9mA==
X-Google-Smtp-Source: ABdhPJzAsOBjt/wt/OlUbA2+hhevzafBZ5A3rW5q1Vn0/8N2vziRglsml9Pf5+B+DOqDvK5wxfcksI//4+d92ZxMEeg=
X-Received: by 2002:a05:6512:ad1:: with SMTP id n17mr58034132lfu.247.1636168042450; Fri, 05 Nov 2021 20:07:22 -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> <CABcZeBOXR9Oyue25cjtSZgag1XWsXstP9EA4BeGryoqFGANcSQ@mail.gmail.com> <cb575fba-595e-2497-c743-3188a7cf64bd@joelhalpern.com>
In-Reply-To: <cb575fba-595e-2497-c743-3188a7cf64bd@joelhalpern.com>
From: "StJohns, Michael" <msj@nthpermutation.com>
Date: Fri, 05 Nov 2021 23:07:11 -0400
Message-ID: <CANeU+ZCCwvGtNe6P7XL9GSuLPbmTf5LKWjW1q1_F_MOMFSBYiw@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Eric Rescorla <ekr@rtfm.com>, rfced-future@iab.org
Content-Type: multipart/alternative; boundary="000000000000f6a1e605d0160eee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/8D58kWt6hwtFnyhcx4PN9-BKhdM>
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 03:07:32 -0000

I’m mostly ok with the LLC beginning it’s actions once the document is
approved for publication.  We do need to manage expectations, as simple
things might incur out of proportion costs and may require LLC to twiddle
its budget.  Or may just not be possible immediately. To be clear, the
authors may not use AUTH48 to expand upon what was approved.



EKR - I think it’s in your corner to propose text?

Mike

On Fri, Nov 5, 2021 at 22:39 Joel M. Halpern <jmh@joelhalpern.com> wrote:

> I could live with declaring that policy determined by the RSWG / RSAB
> takes effect when the RFC is approved for publication.
> Yours,
> Joel
>
> On 11/5/2021 9:13 PM, Eric Rescorla wrote:
> > 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
> > <mailto: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>
> >     <mailto: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>
> >     <mailto: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>
> >     <http://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> <http://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>
> >      >     <http://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>
> >      >     <mailto: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>
> >     <http://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>
> >     <mailto: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>
> >      >     <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>
> >     <mailto: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>
> >      >     <https://www.iab.org/mailman/listinfo/rfced-future
> >     <https://www.iab.org/mailman/listinfo/rfced-future>>
> >      >
> >
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>