Jay,
Thanks for the reading and careful comments. I'd like to, very
briefly, stress four things in case they were not clear:
(1) With the possible exception of my concerns about observers
(with or without further subdivisions), I do not believe that
any meeting-at-a-time decisions, procedures, or actions in this
area taken so far are improper, unreasonable, or inappropriate.
(2) I was trying to express the opinion that the issues raised
in Parts II and III were in need of further, and broader,
discussion. I did not intend to present anything that should be
taken as a final position, much less the position of the
community (see (4) below).
(3) To the extent to which the SHMOO WG, and the IETF more
generally, feel a need to establish and document principles,
rather than relying on the IESG, the LLC, or other processes to
make sequences of relatively short term decisions without such
guidance, the comments I made were intended to be about those
principles. Whether developing such principles is actually
worthwhile and meaningful and, in particular, whether there is a
tradeoff between effort spent developing them and making
progress on the IETF's technical work and how that tradeoff is
best balanced are separate questions, ones I deliberately did
not raise in my review.
(4) I think we all need to be very careful about how we use the
term(or claim) "IETF Consensus" or terms that can reasonably be
taken as equivalent to it. As I understand the IETF and its
principles, there is one, and only one, way in which IETF
consensus is determined. That involves a formal IETF Last Call
issued by the IESG, responses on the designated mailing list,
and an IESG determination based on those responses. Other
discussions, responses to consultations, discussions within
working groups, surveys, hums at plenaries, etc., may give
useful indications of how some portions of the community feel
about particular issues but they do not count as IETF Consensus.
No matter how many people participate in those other methods of
assessing opinion, there is neither a statistical demonstration
nor an IETF consensus principle that allows them to be treated
as sufficiently representative of the community to be a
substitute for IETF Consensus.
best,
john
--On Tuesday, January 24, 2023 12:03 +0000 Jay Daley
<exec-director@xxxxxxxx> wrote:
> John
>
> A few observations.
>
>> On 24 Jan 2023, at 05:32, John Klensin via Datatracker
>> <noreply@xxxxxxxx> wrote:
>>
>>
>> Borrowing a bit from recent discussions in several WGs about
>> IANA registrations, the IETF should recognize (and probably
>> indicate explicitly in the document) that a goal of zero
>> barriers to participation is probably unattainable. For some,
>> registration may be a barrier especially if it requires the
>> disclosure of personal identifying information. It would, IMO,
>> be entirely reasonable for the IETF to decide that such
>> disclosures (whether through a registration system or
>> otherwise) strike a reasonable balance with participation and
>> a process that is seen by others as open and transparent, but
>> how far it is reasonable to go in that direction should
>> probably be seen as a matter of principle like the rest of
>> this document and not a simple administrative procedure the
>> LLC should be making without IETF community guidance.
>
> For info - the PII collected for the fee waiver application is
> a subset of that collected during registration. So long as
> the principle of "don't ask for a reason" remains in place,
> there should be no reason to ask for anything that is not
> asked for at registration,
>
>> **Section 3, Pargraph 2**
>>
>> "without any barriers other than the application for the free
>> registration itself"
>>
>> Along the same lines as the comments above, we should
>> recognize that, for some potential participants, "applying"
>> for a fee waiver may constitute a barrier and that, in
>> particular, acknowledging lack of ability or willingness to
>> pay fees may feel burdensome even if the application does not
>> require any justification for the request. At a very minimum,
>> the IETF should consider very strongly advising the LLC to
>> take, and publicize, meaningful measures to keep the
>> identities of those who have have applied for fee waivers and
>> any information that may be disclosed by those applications
>> confidential. I gather that is current practice, but it
>> should probably be noted as a principle.
>
> During the consultation on fee waivers there was significant
> discussion about this and we were a long way from consensus on
> it. Some believed that it was important to share the list of
> those that received a fee waiver in order for the community to
> self-police it and thereby avoid both any abuse of the system
> and any need for the LLC to police. As this was an LLC
> consultation, rather than a consensus call, the decision was
> made to preserve the privacy of fee waiver applicants as
> transparency may put people off applying.
>
> If this were to now become a strong advisory in an RFC then I
> would suggest that the subject needs to be opened up for
> further discussion. While it is highly unlikely there would
> be consensus around a switch to transparency, there may well
> be an intermediate mechanism that can be agreed, such as a
> designated community member being asked to scan the list to
> verify the process is not being abused.
>
>
>>
>> The comments above are largely independent of the very helpful
>> analysis in Section 4 and addressing them should not require
>> changes to that analysis.
>>
>>
>> ***An Elephant Looking Into The Room ***
>> (not quite in the room)
>> (and a privacy issue, so maybe an invisible
>> elephant)
>>
>> Section 1 of the document carefully distinguishes between a
>> "participant" (which the rest of the document is about) and an
>> "observer". The latter is neither defined nor discussed
>> further. In the interest of keeping the document closely
>> focused on fee structures, that is probably reasonable and
>> appropriate. However, the open process principle defined in
>> RFC3935 can reasonably be extrapolated to argue that there
>> should be a mechanism for people to observe the IETF and its
>> working without "participating" in any meaningful way. Such
>> observers would presumably have no rights to intervene in a
>> meeting in any way (including asking to speak, making entries
>> in chat rooms or meeting notes, and so on) and, presumably,
>> would not want such rights For many years prior to the changes
>> that started around (or somewhat before) 2000, the IETF did
>> not make a strong distinction between observers and
>> participants in terms of ability to remotely access meetings
>> and meeting materials. However, other than the ability to
>> make very crude estimates from, e.g., connection statistics,
>> we didn't know how many of the former there were, much less
>> who they were.
>>
>> Although they do not constitute one of the observer categories
>> for which I am most concerned, if someone is considering
>> participation in the IETF but wants to try to understand how
>> things work before making a decision, observing all or part of
>> a meeting without making whatever commitment they might think
>> is implied by registering, identifying themselves, and asking
>> for a fee waiver might be an attractive option and ultimately
>> gain us more, and more diverse, participation.
>>
>> It has been said that we don't need to consider observers any
>> more because, e.g., they can always watch the meetings on
>> YouTube. Maybe that is true, at least unless we have observers
>> who have legitimate needs to see meetings and streams in real
>> time or close to it; people for whom the usual delay of a day
>> or more (occasionally a week or more) in getting materials
>> that participants could see or be involved with posted.
>> Proving the non-existence of such (potential) observers would
>> be no easier than any other proof of a universal negative.
>>
>> Perhaps it is reasonable for the IETF to abandon the idea (and
>> principles) of real-time observers. But, if so, that decision
>> should, as a matter of principles about how we make decisions,
>> be a matter of IETF discussion, rough consensus, and explicit,
>> documented, guidance to the LLC as appropriate, not one made
>> as an administrative action based, e.g., on the LLC or IESG
>> being confident they know what potential observers might be
>> like or require.
>
> The currently open IETF Community Survey 2022 [1] specifically
> aims to identify people who watch mailing lists but do not
> post to them, though it goes a step further and asks about
> "readers" and "monitors" not "observers" as shown below:
>
> Q1 How would you best describe your participation in IETF
> mailing lists? (this question cannot be skipped) ( ) I
> regularly post ("regular")
> ( ) I occasionally post ("occasional")
> ( ) I regularly read messages but never post ("reader")
> ( ) I monitor message subjects and occasionally read but never
> post ("monitor") ( ) I have recently subscribed and I am still
> deciding how I fit in ("new participant") ( ) I no longer read
> or post but I used to ("ex-participant") ( ) I have never read
> or posted to any IETF mailing list ("non-participant")
>
> For the analysis I will treat mailing list posting as a proxy
> for participation in general, for two reasons: 1. Someone who
> observes in real-time seems by definition to be more invested
> than an observer, except in the very edge case of a
> professional observer such as a journalist 2. identifying and
> asking about all the other avenues of participation is too
> complex for a survey.
>
> cheers
> Jay
>
>>
>> thanks.
>>
>>
>>
>> _______________________________________________
>> Manycouches mailing list
>> Manycouches@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/manycouches
>
> --
> Jay Daley
> IETF Executive Director
> exec-director@xxxxxxxx
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
