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

[Brian E Carpenter <[e-mail]>]

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?

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