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

[Eliot Lear <[e-mail]>]

Ok.

What I am hearing is that we should add a sentence saying that policies 
take upon approval by the RSAB, regardless of the timing of publication 
of an RFC.

Eliot

On 06.11.21 04:54, Brian E Carpenter 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?
>
> 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>
>>
>>
>