Thursday, November 19, 2020, 12:00-14:00 ICT (UTC +7)
Chairs: Francesca Palombini, Pete Resnick
Recordings: TODO
Minute takers: Pete Resnick, Rich Salz, Francesca Palombini
(Chairs)
Slides: https://datatracker.ietf.org/meeting/109/materials/slides-109-gendispatch-chairs-00
Going over administrivia & agenda bash. One document so no change to agenda. Review of ground rules, conclusions the WG can make.
(Adrian Farrel / Dave Crocker / Brian Carpenter / Michael Richardson / Fernando Gont)
Brian Carpenter presenting slides. Several co-authors. This is a BIS, not starting from zero. Experience shows clarification needed to avoid confusion and potential conflicts about wg adoption of documents. RFC7221 was just written, AD sponsored, no real detailed community review. Deliverable would be an update and clarifications, not replacement; deliberately no changes to the RFC nor to IETF rules (this is informational).
Adrian points out 7221 has roots in WG chair training circa IETF 80 or so. Never goal to write rules, just be guidance and informational.
Pete (from the floor) asks if BCP is okay? Brian says no, might be harmful because it tries to over-regulate, guidance is better. Adrian agrees. Peter clarifies BCP consensus is higher bar within IESG. Can still be informational.
EKR against publication of this document, informational guidance treated as rule is a not a good idea. Leave discretion to the chairs as currently have. Would prefer to dispatch to “don’t do this.”
Christian agrees with EKR; shouldn’t be a pseudo standard - either the rule of the law and is what the IETF agrees on, or is not published. Also, we need to figure out how to get appropriate review if this gets dispatched straight to Last Call - not enough review from chairs. Adrian agrees this was an issue for 7221.
Brian says you are not considering the “members” (participants, document authors) constituency. I think that means we have a real problem.
Christian says this group should identify the review process before it decides to progress the document.
Bron says as a WG chair, wants guidance on how to behave and “coverage” for how to behave in case of an appeal. Would prefer clear guidance or rules. Support it as BCP.
Michael says he proposed this because he saw silly states in WG where documents were not adopted for no reason. I want this document to say, “This is not a rule; you can do what is right.” So to others: Should we make clearer rules, or do something else, or is there just no problem?
MNot: I see three options I have no preference:
David Schinazi: Hard to see value of this doc as an RFC. There is value in having it written. Make it a web page if it’s simply advice. If we see misbehavior and need a BCP, then so be it. But an Informational RFC will be seen as law, which would be bad. (Michael responds in jabber that dispatching this to the EDU team would be acceptable to him.)
Eliot: we already have a document, so we should make it as good as possible. Also, the current document as written says, “Non-normative”, so it’s clear. (EKR points out in Jabber that even with such text, it can be taken as “rules”.)
Bob Hinden: Would like to see it dispatched so it can be worked on in some work.
EKR: Even with such “non-normative” text, it can be taken as “rules”; cf. 7282. If we actually need formal clarification, we can add to 2418.
(queue cut, slides resume)
Brian: done presenting. How to dispatch? A WG seems out of proportion, but we need to figure out how to do something.
Christian: Not convinced that we should have such a thing, and I don’t believe the argument that Informational will mean it won’t be taken as rules.
Brian: I like the idea of putting it on the website, like “Tao” document as descriptive not normative. Christian agrees. But confusion may still persist.
MNot: Are you opposed to other mechanisms WG’s use to “slow down” drafts, etc? Brian: Not at all, WGs should still have discretion; they look at websites, not RFCs to figure out things work. MNot: agree with that last part.
Pete: If the problem with 2418 and 7221 is people thinking there are rules, do we need a rule that says there are no rules, it’s under chair discretion?
Brian: yes, but I don’t have the energy to do 2418bis.
Andrew Campling: It would be good to give clarity to chairs what the rules are or, even if it is to discretion, what the boundaries might be. BCP would be good to do that.
Rüdiger: Having information in multiple places, especially if it is attempting to “fix” existing RFCs, is likely to lead to confusion.
Robert Wilton: the process is kind of opaque for newcomers. Leads to problems. Don’t have suggestion for how to handle that.
Rüdiger: I can see a point to putting on the web such as the “How we work” section. Avoid creating confusion about precedence of various information sources.
Oliver: Agree with Rüdiger. Having the information in two different places is a really bad idea. We shouldn’t avoid putting things in an RFC; standards are also hard to navigate in RFCs, this does no more damage. Francesca: are you okay with an information RFC and link from the website? Oliver: yes. It can be hard to find things on the website, so better indexes (sic) pointing to the RFCs.
Eliot: Why is 7221 not-normative a problem but 7282 not-normative not a problem? Maybe it was the way it was written. Also, I am concerning we are stalling this work (small update) and yet not have the stomach to complete the very large process.
Pete: some felt informational was worse than BCP. (did i get that right?)
Christian: One thing to write observations “how we see things have been done” versus “suggestions” which are often taken as rules.
Francesca: Agreement we need more clarity. Agreement on more training or better way to share information; not sure how that helps dispatch this document.
Alissa: Anyone opposed to updating website, or incorporate that information into future training?
Pete: then what’s the process for doing that? Do we need to update 2418 to clarify what that webpage is about. We got 7221 in the doc serie. There seems to be some reason to change state, maybe do the webpage first then figuring out what to do with the doc serie is an option.
Alissa: website is a collection of things. Different things are captured in different formats.
Pete: objections to getting this information on the website first and then think about how to obsolete 7221/ update 2418?
Andrew: seems odd to update website before document.
Henrik: agree if we’re publishing something, publish it first.
Mnot: Which has precedence website or 7221? Not everyone thinks 7221 has greater precedence.
Pete: I don’t have clear idea we have overcome objections in either direction, so I’m not sure we’re on the same page.
Mirja: I think this is more about training and making the information where people can find it. Don’t think that our rules are not clear. The problem we have is providing the right information to the right people. Francesca agrees.
Pete: What can we live with? If updating 7221 is not the right thing to do, what is the right thing to do?
EKR: We don’t need to define what we can live with. This document does not have consensus to move forward, it can just die.
Pete: consensus that 7221 as it stands needs clarifications. Given that, what’s the right thing to do?
EKR: I’m fine with the website, but I think that the way of phrasing that this has to come to some consensus of way forward is not the way to think about this problem.
Robert: if 7221 is wrong, it should be fixed (or obsoleted) and then work on the website. Reminds me of the “living RFCs discussion.”
Oliver: wants consensus, so update RFC first. So let’s not proceed quickly, quickly to put it on the website before we agree on what to write on the document. RFC has a clear process.
Alissa: the force of the website is much less. We would just provide some guidance not be used as rules. It would be a shame, for example, if we can’t update the guidelines that we give to new people because we can’t get them in RFCs for 8 years.
Oliver: link the datatracker of the document to the website.
Pete: suggestions to the tools team might be out of scope for what we can dispatch. Is there any text that we could put into an update to 7221 that could remove some of the concerns with an informational being taken too normatively?
Francesca: Questions in the jabber chat about whether it’s OK for a website to override an Informational RFC. If it doesn’t override it doesn’t need to be published. Question to the authors: does it override?
Michael: I don’t know how to absorb all of the comments. Absolutely we need to put something on the website and improve the training. 7221 is being ignored until now and hasn’t caused any great disaster. IESG could mark it as historic. I would be ok with updating the website.
Francesca: I think I hear more people supporting the “updating the document”?
people disagreeing with that understanding in the chat
Pete: I am reluctant to declare EKR and Christian etc in the rough. We are going to bring this to the mailing list anyway, but it’s going to be unpleasant for the chairs to summarize the possible outcomes.
Rich: Mostly agree with EKR/Christian/Mark. If we are worried about growing participation, that info should really be on the website and not simply point to some RFC.
Pete: We will need to summarize and bring questions to the mailing list to figure out how to procede.
Lorenzo: We operate on RFCs and yet we can’t write an RFCs that describes how we operate. We want to get people to write RFCs but we can’t get them to read RFCs because they are hard. Objections to making people read RFCs seems silly. Whatever we do we are going to end up with a document in the limbo which used to be authorative guidance. Updating the RFC is the simplest path forward. We can’t update RFCs, really?
Bron: Having advice that is stronger than guidelines is useful. Trying to do middle ground with no strong meaning is wasting time. If guidelines is all we need then on a website is fine.
Rich: Lorernzo’s point is wrong. There is a world of difference between technical document and write a technical document that describes human behavior. That is really hard to write.
Francesca: I hope that despite being shockingly hard and controversial this is anyway useful.
Pete: Let’s move this to the list. Might be useful to bring the wg chairs into the discussion. We stayed in the lines of not dive into the details of the document.
Lorenzo: Please look at https://www.ietf.org/archive/id/draft-per-app-networking-considerations-00.html. Could this be a gendispatch item?
Mirja: We updated the “Updates” tag document. Please go have a look.