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

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

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