# Minutes of the the RFC Editor Future Development Program ## 18 February 2020 A recording of this meeting can be found [here](https://cisco.webex.com/recordingservice/sites/cisco/recording/playback/2b50f6faa50541928c935e58ab81f7c5). The password is **jPFp4pjW**. The meeting was convened by your chairs, Eliot Lear and Brian Rosen. The Note Well was presented. The agenda was bashed. There were no additional agenda items. We noted during the bashing of the agenda that Issue 13 had passed the consensus check. The primary agenda item was to go over the text that Adrian had provided, regarding what are Issues 15 and 16. The chair asked that we not spend time trying to wordsmith on small issues so that we could get to the bigger ones, and the group pretty much honored that request. The chair reminded the group that one issue that Adrian's proposal did not explictly address was composition of the Approval Body, but that people should keep that in the back of their minds. ## Main body of Adrian's Proposal: Steps A through E We examined Adrian's proposal, based on the steps he listed. The group agreed to steps A through E with the following notations: * a WG last call (B) should run between between two and four weeks, depending on the issue at hand. * The community comment list (C) will evolve over time. * If a member of the oversight body is going to be absent from discussion of a document or an issue (D), an alternate should be sent. * It was requested that the text around discussion by approval group (E) be merged with (C) (Community last call). **NOTE** this does not mean that these items should occur concurrently, just that the text should be adjacent. * A comment was made about process for individual submissions. The action here is to propose text if that is desired, so that it can be discussed. ## Step F: Approval by Approval Body There was a substantial amount of discusion around what positions members can take. Everyone agreed on "Yes" (always a good start). The rest require more discussion. In particular, the following points were made: * Because members of the approval body are expected to have signaled concerns earlier in discussion, some argued that DISCUSS should be changed to NO. * Others were concerned that the use of "NO" was quite strong vocabulary and would rather put aim the effort in a positive direction toward resolution of open issues, rather than definitive process stops. * Another view held that we have a lot of running code for DISCUSS, and not much for no, so we should stick to what we understand. The contrary view held that DISCUSS was not necessarily the right model here. * People raised concerns with "Abstain", that people on this body should all have affirmative points of view, and that a "NO" was a clearer answer than "Abstain" when someone had real objections. * It was suggested that rather than offering a "Recuse" option, that if a person has to recuse, they provide an alternate. It was pointed out that this may be problematic for the ISE, but we didn't explore this in depth. In general, there was a sense that the DISCUSS/NO debate would lead to the same conclusion: the document would be returned to the WG for further processing, and that in either case, those voting no should make their concerns known. And so, it is the connotation of the terms that is at issue. We noted this, and that we needed to take this to the list for further discussion. ## G. Reasons for a Discuss There was a healthy discussion about what reasons a DISCUSS could be held. Adrian listed three reasons: * The proposal would cause significant harm to one of the streams * The proposal would cause significant harm to the series * The proposal would cause inconvenience to a group of consumers, the benefit of the change does not outweigh the cost of the inconvenience, and that inconvenience could be overcome by using a different approach. There was no discussion or concern raised about the first reason. However, there was concern raised about the latter two as giving license for AB members to vote "DISCUSS/NO" for overly broad reasons. One view is that because an open working group has worked to build consensus, that consensus should be respected, and that only if something were to really break a stream should the AB send something back. Another view is that because not all streams are the same, it is possible that the IETF would run roughshod over the other streams, without due consideration for the long term risks to the series. The point was made that it took the IESG a long time to build out "DISCUSS" or "non-DISCUSS" criteria, and that we need some running code. The action is for EKR and Joel to write out some ideas to address concerns raised. Others are encouraged to do so as well. ## Second half of G (work proceeds if) The only issue raised was whether there were to be quorum rules or whether alternates would be required. **This is where we stopped.** ## Next meeting The next meeting will be at IETF 110. See the Meeting Agenda for time and date. ## AOB No AOB. ## Special Thanks Thanks to Rich Salz for taking minutes, and to Adrian Farrel for putting together the proposal.