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

["StJohns, Michael" <[e-mail]>]

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]>
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]> 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]>> 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>>
>> >      >
>> >
>>
>> --
>> Rfced-future mailing list
>> [e-mail]
>> https://www.iab.org/mailman/listinfo/rfced-future
>>
>