Hi. Since I've been cited in my co-author capacity, a few comments... Note that, while I supplied an earlier draft for use as a starting point, left the question of whether to list me as co-author to SM, and agree with what this draft is trying to accomplish, I've been trying to stay out of this one. The reasons may become clear below. --On Friday, May 24, 2019 09:49 +0000 Spencer Dawkins at IETF <spencerdawkins.ietf@xxxxxxxxx> wrote: > I'm still jet-lagged at RIPE, but just to try to contribute to > this discussion in a helpful way ... > > On Fri, May 24, 2019 at 9:15 AM S Moonesamy > <sm+ietf@xxxxxxxxxxxx> wrote: > >> Dear Mr Rescorla, >> At 03:45 AM 20-05-2019, Eric Rescorla wrote: >> > I'm not on any kind of I*, but when I was, the idea behind >> > an IAB shepherd was not that primarily that they provided a >> > review but that they helped the proponents of the work >> > navigate the IETF process (especially the BOF process) and >> > get to a crisp problem statement, etc. I never thought of >> > it as a requirement, but rather something that was intended >> > to result in a more productive discussion. >> > > This is actually written down in more detail in > https://www.iab.org/documents/correspondence-reports-documents > /2012-2/iab-member-roles-in-evaluating-new-work-proposals/, > which seems to be one of the more obscure practices at IETF, > since when I was on IESG and referred to it in discussions > with IESG and IAB members, people often told me they hadn't > seen it. Once upon a time, there was general agreement that, if something was a "real" procedure, it was agreed upon by community consensus, published in the RFC Series, and then generally adhered to. IESG (and IAB) statements, when made at all, were general guidance to the community about how the IESG (or IAB) intended to do its work, rather than rigid rules: if special circumstances arose, good sense would always be applied rather than prior statements about procedures. In that same long-ago time, if an IESG or IAB member, or the whole bodies, started behaving as if they had somehow been anointed with imperial, or perhaps divine, wisdom or authority, the community had, and used, corrective methods that were far faster and less ambiguous than the recall mechanism, typically methods that were applied at plenaries and that often involved, at least metaphorically, airborne application of ripe fruit. My impression is that the community at that time was far more concerned about several members of the IESG (or of the IAB) getting together to force someone out who was taking strong positions that didn't agree with the majority view than it was about serious and objective malfeasance or non-feasance. Like more good stories starting with "once upon a time", some aspects of that era are at least a bit mythical. But I think things have actually changed and that, in particular, the use by the community of plenaries as a control function for any issues significantly more important than the quantity or quality of cookies has largely vanished. Among other effects, that makes the recall mechanism the community's first line of defense against bad behavior rather than a second or third level method. If that is true, it better be equally available to all participants in the IETF and it better be fair. It should also be usable in practice, but those are actually separable problems. > The IAB could have changed that practice last week at their > retreat, or could have decided it needed to be changed, but > AFAIK, the 2012 version is still operative (the IAB has become > way more transparent, but they still review their meeting > minutes before they publish them). > > This might also be useful information for other people > proposing IETF 105 BOFs, of course ... Right. Perhaps more useful than a proposal for one on the subject of recalls; see below. >> Thank you for providing the above information. >> >> The short draft was intended to be narrow in scope (re. crisp >> problem statement). Some time back, I served as editor of a >> draft which was discussed at length on this mailing list. My >> co-author also served as editor of other drafts. He has much >> more experience than I do with respect to getting drafts >> through the IETF process. As the co-author who is presumably being referenced, I believe I have learned three things about process change proposals in the last decade (I see NEWTRK as a turning point; others may have different impressions): (1) While we can make, or at least pretend we can make, purely technical decisions about protocol standards, procedural ones are inevitably a matter of taste. That turns "whose taste?" into an important question, especially if there are tradeoffs involving who might be helped or put at risk by a particular decision. (2) Procedural change proposals that originate with (or are actively discussed within) the IESG and that are written up by one AD and sponsored/shepherded by another, are going to go through. I presume there is a level of community consensus against such a proposal that would kill it but, given that much of the community won't spend time engaging with and commenting on procedural changes and that the IESG determination of rough consensus is inherently somewhat subjective, almost any proposal generated and handled that way is going to be accepted, published, and, unless it explicitly says otherwise, treated as a set of firm rules. (3) Procedural change proposals that do not originate with the IESG and that don't have immediate strong support from within the IESG have, statistically, a grim future ahead of them, especially if their effect would include either changing the IESG's responsibilities or increasing the ways in which the community can hold the IESG, or IESG members, accountable. Especially with procedural proposals, rather than technical ones, the IESG has a rather wide range of options for killing something about which they are not enthused, starting with insisting on a BOF or two, forcing discussions off the IETF list and into one for which people who are not strongly committed to procedural issues won't sign up, claiming that the BOF does not show sufficient support (easily encouraged by scheduling a F2F BOF, appointing leadership who are skeptical about, or hostile to, the idea) or even concluding that there is insufficient support on the mailing list to justify holding a BOF, broadening scope sufficiently to make convergence in a WG before everyone runs out of energy, etc. Because each of those decision points involves an IESG evaluation of consensus and whether the topic is worth more community time, separating entirely reasonable decisions from abusive behavior is generally going to be impossible. With NEWTRK, we even saw the IESG receive documents on which the WG had consensus and refuse to initiate an IETF Last Call (and make it clear than an appeal would go nowhere). I hope and trust that this draft is viewed with enough interest in the community and the IESG that it will be an exception to the above and, in particular, that SM will submit a proposal for either a virtual BOF or one in Montreal, that the BOF will confirm that it is appropriate to go ahead with this narrow piece of work, and that a WG, if needed at all, will be confirmed quickly and can progress rapidly and without F2F meetings. But history does not lead to optimism. >> As a comment about IETF process, it was pointed out to me >> that a Working Group Chair cannot author drafts within >> his/her working group. > > I was only on the IESG for six years, but AFAIK, this isn't > quite right. > > It's common, in TSV at least, for WG chairs to author drafts > in their own WGs. What we don't do, is have WG chairs shepherd > their own documents. The idea is that you don't get to declare > consensus on your own document. At the same time, if the topic of the work is controversial, this lends itself to abuse... especially so if there is a personal or business relationship between the WG Chair/author and the relevant AD. Even if some other AD, perhaps from some other area, takes over formal responsibility for the document, if the document is controversial there is going to be at least a faint whiff of suspicion about improper relationships. > This is the same thing as me authoring drafts while I was on > the IESG (I did), but not being the responsible AD for > publication. > > But both of those are practices - the operative principle is > to Do The Right Thing. Yep. best, john
