Minutes IETF118: rswg: Thu 10:45
minutes-118-rswg-202311091045-02

RSWG @ IETF-118

Thursday, 9 November 2023 at 11:45-12:45 CET

Chair slides:
https://datatracker.ietf.org/meeting/118/materials/slides-118-rswg-rswg-chair-introduction

\:musical_note:

Russ: chairs struggling to make progress; they're having a hard time
understanding where the group think the line between rswg policy and rpc
practice may lie.

Chairs think discussion of these questions may help:
Here are some questions that we think will help us understand the where

different people think the line belongs.

1. The XML schema for author address changes. Is the RPC required to
   post new XML for a published RFC (say RFC9876)?
2. An error in the XML for RFC 9876 is discovered. Is the RPC required
   to
   edit the XML file? Is the RPC required to post new publication
   formats for
   RFC 9876?
3. A new xml2rfc tool version is released, and the new tool produces
   the
   different layout for Table 1 in RFC 9876. Is the RPC required to
   post new
   publication formats for RFC 9876?

Lars Eggert: some things are stream specific, further complicating
matters

Robert Sparks: in practice there hasn't been too much controversy when
things came up

Pete: chairs hoped these questions might draw out opinions

Eliot Lear: answers: 1. no because required too strong, "may post" could
be better. 2. if erratum then no else SHOULD. 3. no, RPC may do it

Pete: Does that mean that 1 & 3 are not policy issues, but 2 is?

Eliot: No, none of them need to be policy.

Jay Daley: asks chairs about use of "required"

Russ: figured using that'd draw out better comments/answers, guessing
re-asking altered questions later might more likely capture consensus

Jay Daley: wrt q2 may differ if xml validates or not

Robert Sparks: could also be cases e.g. where dates are incorrect

Jay: some of this depends on whether we're embedding the xml in the pdf

Jay: also see the email I sent

Paul Hoffman: we do need a policy, but that should be "we trust the RPC"
so his answer is "not required" for all answers, but RPC might do it
anyway

John Levine: q1 is rswg question, 2 (errata) and 3 (done already) are
not. Thinks its worth making one round of incompatible changes nowish.
Feels strongly about . After such a change we should retire
before another.

Robert Sparks: wrt "required" we're really picking at who decides and
when and based on what authority. We need policy when, if we don't have
policy, the users of the series suffer. We want some principles that can
guide judgement calls by RPC. Should be a small set of principles,
leaving as much leeway as we can to do the right thing for consumers
(and then for producers).

Pete: does that mean none of these are really polcy? Robert: yep but
modulo what Jay said.

Colin Perkins: is confused. Not clear why we're discussing these as all
the answers are "it depends." He then describes such cases.

Stephen Farrell: These aren't policy things. Could give some policy
guidance. We don't have to be detailed about the reasons they need to do
these things. RPC should come to us if something mad will happen, but
otherwise leave it to them.

Jean Mahoney: RPC are here to serve the community, e.g. we can re-render
if that's what community want. If we did post new xml for all published
rfcs, there'd be ops considerations. We'd not do that for fun btw. There
are rare errors (e.g. date wrong) and we sometimes republished with new
RFC number. It'd have to be very beneficial to reader before we'd
re-render. We'll learn a lot the first time we do this. It'll get easier
after. We e.g. could experiment with , but not publish, then
report back. Thanks for trusting the RPC to make some of these
decisions.

Pete: does RPC feel they need some policy backing?

Jean: well.... if we go do some of this, some people who've not been
paying attention may/will freak out.

Pete: If you could say "rswg said it's ok" would that help?

Various: who handles the complaints? Answer: Jay

Jean: RPC does get a bit nervous about these things.

Mirja: rswg can only do things via RFC. Only RSAB can give day-to-day
advice. (Rumbling in the crowd)

Carsten Bormann: we should be documenting objectives, e.g. in RFCs. A
secondary function of this group could be to provide support via
discussion to collect consensus about objectives.

Carsten: RFC format is not well-defined by a grammar. So
change is maybe less than people think. Most of the changes are
semantic, not grammar.

Carsten: stability and accessibility objectives may be in tension and we
should be trying to add clarity for such things.

Alexis Rossi: agrees with what Paul said, we need to trust RPC and they
have a good track record so we don't need to put a leash on them.
"required" in questions is wrong, would run into tendency to prescribe
actions rather then set goals. If we are allowing RPC to use discretion
we need to be explicit about that in an RFC because some people in the
community may quibble.

Lars Eggert: happily agrees with Alexis. Notes RFC needed because people
will quibble. As stream-owner, notes RPC hesitate because they've been
burned in the past, so we need to get out of the mode of second guessing
what they do.

Lars: also likes think of objectives first, then thinking about what
policies help reach those objectives and then think about what documents
are needed to reflect that. Dealing with xml is not in the top 5 things
to discuss. Errata could be stream-specific, but objectives for how to
process errata could be dealt with by rswg. Generally wants to zoom out
a lot more.

John Klensin: See recent email to list. Seems most of us saying the same
thing. Trust RPC because some trust RSWG less. We should say (as policy)
getting things published in minimal time with quality is a clear policy.

Jay: agrees with Jean that an RFC is important. Also notes we may need
to that partly because of existing docs that nearly say immutability is
needed. Agrees that stating goals is good.

Robert: An rfc that tells rpc it can do x, may hit issues if/as a set of
community members who think rfc series shouldn't exist. Those people
aren't in the room but we need to consider they exist and we need to
talk to 'em to reduce friction.

Eliot: in this room, I heard pretty good consensus on faith in RPC use
of judgement. (Pete/Russ: yep, both more comfortale.) The people who
didn't show up may be in the rough, we'll deal with it.

Eliot: also: get on with it, we're blocking bunches of other issues,
e.g. accessibility, mathml, svg and doesn't want to see this stuff block
that stuff.

Pete: chairs felt resolution of this discussion could unblock those
other things

Eliot: as RSAB member, I hope resolving this discussion does unblock
some of those things soonish

Mirja Kühlewind: in general we should trust RPC as part of their role is
to ensure something stable. We shouldn't put a policy where there's not
a problem. If RPC is unsure, then maybe policy needed but also need a
solution. If someone is unhappy with RPC actions, they can also try
write an RFC.

Eliot: fine with that as long as we don't block.

Paul Hoffman: the people who don't like the rfc series are not for this
wg.

Lars Eggert: disagrees with paul; rfc series is output of IETF and there
are people unhappy with that. See "living document" discussion. Also
yang model outputs. People have valid reasons to want to maintain
non-RFCs. So this wg is the place to have those discussions.

Stephen Farrell: Agree with Lars, disagree with Paul. Need to give them
someplace to complain; this group might as well be where.

Eliot: Agree with Stephen.

Russ: chairs happier with this discussion hope it results in unblocking.

Lars Eggert: meta-issue wrt scheduling this slot. We doing this again or
what?

Russ takes real hum: concludes a regular slot would be ok.

Colin: stream managers needed => non regular slot.

Jay offers to buy lunch.

Mirja: breakfast better (note taker barfs)