![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Hi John,
Your notes are convincing to me. In effect, you are saying that if the IESG and IAB members cannot function well together, let's hear about it before the nomcom cycle. I missed the sentence "The petition and its signatories must be announced to the IETF community" in my earlier reading of RFC 3777.
With that condition in place, draft-klensin-recall-rev-00 looks ok to me. Thanks.
The trouble is, all this is based at best on thought experiments. As a potential victim of recall, I don't want to dive too deep into the debate, but my assumption is that if there was a near-critical-mass situation in the IETF or IAB (*) there would be enough energetic neutrons flying out that 10 or 20 people in the community would know about it. So I'm not convinced that John's proposed change is likely to change the measured rate of recall petitions. But I can't find any particular downside, and it does seem fair.
John, please add some words about the BCP 101 recall process for the IAOC.
(*) er, if anybody thinks that's the case today, please let me or Leslie know. Not that we don't have contention, of course.
Brian
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.