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)