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

["Joel M. Halpern" <[e-mail]>]

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]>> 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]>>> 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]>>>
>      >     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 <[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>> 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]>>
>      >      >> 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]>>
>      > 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>>
>      >
>