Hi, let's up-level a bit. This document instructs the IETF LLC to try its hardest to make unlimited free remote participation available. It leaves the details of how this is done mostly to the operational side. I think this is feature, not a bug. We have too many process RFCs that codify operational details, and those parts don't age well. I would strongly urge to think twice before adding operational aspects to this document, unless absolutely necessary. Related to your second point, I don't quite understand how you interpret the establishment of (a guidance for) unlimited remote fee waivers as moving us closer to a "pay-to-play model". I think it's doing the exact opposite. Running the IETF, its meetings, and it's associated functions such as the RFC Editor has a cost. A part of that cost has always been borne by the participants, and until our endowment is a few orders of magnitude larger than it is now, we have no other option. The IETF has always chosen to recover some of that cost from the people who actively participate in its meetings, but not - for example - from the people that only participate via email. The community can certainly discuss whether this is still the correct approach to recover a part of our operational costs. But that certainly goes beyond this document and the current charter of SHMOO. Thanks, Lars On Jan 30, 2023, at 19:10, John C Klensin <john-ietf@xxxxxxx> wrote: >> For the fee waiver one can see all needed information here: >> >> https://www.ietf.org/forms/116-registration-fee-waiver/ >> >> So I believe the requester can make an informed decision. > > I believe that is correct although I can find no requirement or > principle, in this document or elsewhere, requiring that form, > or what it discloses, or how early it is expected to be > available, for future meetings. IMO, it would be a terrible > idea for the IETF to get bogged down in the details, but a > statement of principle about that information being available > long in advance, even a meeting or more in advance, would be > reasonable. So would a statement allowing exceptions if > exceptional circumstances arise if the LLC encounters such > circumstances and is willing to explain them to the community. > >> However, if you want to change or discuss that, I still >> believe it's out of scope of this document and better >> connected with the broader question about identify and privacy >> of participants as you discuss below. I encourage to start a >> separate discussion and probably rather on the gendispatch >> list (or of course even better propose a draft if you have >> concrete proposals for policy). > > Here is where I have a different concern, one I have alluded to > earlier and to which I hope the IESG will pay attention and > discuss ... ideally without holding up this document. First of > all and right now, I believe there is momentum and context for > thinking about the broad set of issues associated with remote > attendance at meetings, including what people need to "pay" to > attend. "Pay", and "costs" below, are in quotes because I'm not > just talking about fees, I'm including what it is reasonable to > expect people to give up in terms of disclosure of information, > making applications for fee waivers and other special treatment > if needed, and so on. It also includes questions about > > -- what alternatives exist if those "costs" are judged, by the > potential participant, to be too high and > -- ones about the risks to the IETF, and its effectiveness and > reputation, should there be a perception that we are moving more > toward "pay to play" even if there fee waivers or other > exceptions. > > To say "not in scope for this document" is fine. To say > something closer to "not in scope for SHMOO, take it to > GENDISPATCH" is not only a stretch from how I read the SHMOO > charter (YMMD, of course) but, assuming that it were not simply > a way to kill discussion (intentional or not), it pushes things > in the direction of Yet Another WG with responsibilities and > scope that overlaps an existing one. IMO, such WGs are an > all-around problem: if the same people join both mailing lists > and participate in both, it is wasted administrative (and other) > overhead. If they don't, we end up with fragmented discussions > and reduced perspectives and review prior to IETF LC. And, > either way (and at least IMO), every additional WG is more work > for relevant ADs and the IESG in general, resulting in more > tendencies toward AD overload, pressures to make the IESG bigger > (and possibly more difficult for it to function as a coherent > body or be "managed"), and perhaps reduced willingness of people > to be candidates for those positions. Those possible > side-effects are certainly not SHMOO's problem, but I don't > believe we should be reading SHMOO's scope narrowly enough to > push the community toward them. > > Of course, the other problem with sending the questions off to > GENDISPATCH is that the issues are complex enough that I would > assume that things will drag out to at least IETF 116 and > possibly longer, losing whatever momentum and thoughts that > people have in their minds today. > > Lars? IESG? Some guidance here would be helpful. If you want > notes, or even a skeleton for a draft, sent off to GENDISPATCH > (but with the understanding that I will recommend that > GENDISPATCH assign the work to SHMOO), I'm willing to try to do > that but, because I think it is a bad idea, I won't do so > without some explicit guidance. > > thanks, > john > > >
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
