Re: [Rfced-future] AUTH48 process for RSWG? WAS Re: iRSE comments on the new RFC editor structure

[Eric Rescorla <[e-mail]>]

On Fri, Nov 5, 2021 at 8:54 PM Brian E Carpenter <
[e-mail]> wrote:

> Hi Mike,
>
> I think that's wrong. At least for the IETF stream, any WG document that
> gets to AUTH48 is the work of the WG, and the authors are really editors on
> behalf of the WG. The AUTH48 goes to the authors, and iirc to the WG
> chairs, the shepherd, and the sponsoring AD. Correct behaviour is that if
> (and only if) there is an issue that is not editorial, the proposed change
> is taken briefly to the WG list. (Briefly, that is, if it is
> non-controversial. If it proves to be controversial, AUTH48 can take 48
> weeks...)
>
> Why would the RSWG be different?
>

This was my expectation as well. Of course, in AUTH48, the eponsoring AD
has some latitude to determine whether a given change is de minimis. I
agree with Mike that in this case, there just shouldn't be discretion.

-Ekr


> Regards
>     Brian
>
> On 06-Nov-21 16:16, StJohns, Michael wrote:
> > As I wrote the stuff below, I realized that we hadn’t considered the
> AUTH48 and author/editor centric stuff in the publication process.  Unlike
> IETF WG documents, or for that matter most other stream documents,
> editorial stream documents will always (mostly?) be the product of the
> whole RSWG not a specific author or set of authors.  That suggests that
> AUTH48 queries may need to be sent to the entire WG, with anything
> more complex than phrasing and comment placement needing WG input.
> >
> > Consider the above a partially formed thought.
> >
> > Mike
> >
> >
> >
> > On Fri, Nov 5, 2021 at 23:07 StJohns, Michael <[e-mail]
> <mailto:[e-mail]>> wrote:
> >
> >     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 <[e-mail]
> <mailto:[e-mail]>> 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 <
> [e-mail] <mailto:[e-mail]>
> >          > <mailto:[e-mail] <mailto:[e-mail]>>>
> 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
> >          >      > <[e-mail] <mailto:
> [e-mail]> <mailto:[e-mail] <mailto:
> [e-mail]>>
> >          >     <mailto:[e-mail] <mailto:
> [e-mail]>
> >          >     <mailto:[e-mail] <mailto:
> [e-mail]>>>> wrote:
> >          >      >
> >          >      >     Hi Mirja,
> >          >      >
> >          >      >     On 05-Nov-21 22:31,
> Mirja Kuehlewind wrote:
> >          >      >      > Hi Brian,
> >          >      >      >
> >          >      >      >> On 4. Nov 2021,
> at 21:02, Brian E Carpenter
> >          >      >     <[e-mail] <mailto:
> [e-mail]>
> >          >     <mailto:[e-mail] <mailto:
> [e-mail]>>
> >          >     <mailto:[e-mail] <mailto:
> [e-mail]>
> >          >     <mailto:[e-mail] <mailto:
> [e-mail]>>>>
> >          >      >     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>>
> >          >     <http://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>> <http://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
> >>
> >          >      >     <http://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 <
> [e-mail] <mailto:[e-mail]>
> >          >     <mailto:[e-mail] <mailto:[e-mail]>>
> >          >      >     <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>>> 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>>
> >          >     <http://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
> >          >      >      >> [e-mail] <mailto:
> [e-mail]> <mailto:[e-mail] <mailto:
> [e-mail]>>
> >          >     <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>>
> >          >      >      >>
> 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>>
> >          >      >     <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
> >          >      > [e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>
> >          >     <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>>
> >          >      > 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>>
> >          >      >     <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
> >         [e-mail] <mailto:[e-mail]>
> >         https://www.iab.org/mailman/listinfo/rfced-future <
> https://www.iab.org/mailman/listinfo/rfced-future>
> >
> >
>
>