Hi John,
thanks for your review. I applied your nits below in github and we will fix that in the next version.
For the others issue, I understand from the on-going discussion that those issues are probably separate issues or at least beyond the scope of this document.
Particularly for you first issue on information disclosure, quickly some further remarks: the document requests to publish aggerated data (which we usually do in the plenary report), but does not explicitly request to keep other data confidential. However, my assumption is that individual registration data (except the name in the participants list) is treated as confidential anyway (given things like the GDPR). If we as a community want to give further guidance about this to the LLC, we should probably work on some general guidance. Also as Jay said for the fee waiver I believe the discussion in the working group indicated that we want to be able to have this information checked (not publicly but by some individuals) in case misuse is suspected.
Mirja
On 24.01.23, 06:32, "John Klensin via Datatracker" <noreply@xxxxxxxx> wrote:
Reviewer: John Klensin
Review result: Ready with Issues
This is a review of draft-ietf-shmoo-remote-fee-05 at the
request of the ART Area Review team. From the perspective of
any interests or perspectives unique to the ART Area that I can
identify, the document is substantially ready to go. A few
quibbles and nits aside, the document is well-written (probably
above recent IETF averages) and mercifully short. And from the
additional perspective of someone who has intermittently
followed (and even less frequently participated in) the SCHMOO
work, it appears to be consistent with WG discussions and rough
consensus.
The comments that follow are rather more personal ones than
anything that should be construed as being on behalf of the ART
Area. They fall into three categories/ parts that I hope will
be helpful to the IESG in considering the document:
Quibbles and Nits
More Substantive Issues with the Document and Its Coverage
An Elephant Looking Into The Room
I have deliberately not read other Last Call reviews before
preparing these notes, so there may be some redundancy.
***Part I: Quibbles and Nits***
** Section 1, paragraph 3:
"there was no longer a distinction between remote and on-site
participants for those meetings"
Of course there was a distinction: there were no on-site
participants during that period. The important point is that,
when on-site meetings resumed with remote participants (in
larger proportions than before), efforts were made, and
continue to be made, to minimize the distinction that then
returned.
** Section 1, paragraph 2:
Current:
either due to financial reasons...
Should probably be
New:
due either to financial reasons...
** Section 4, last paragraph:
Current/Old:
simply lost of business interest
Should probably be
New:
simply loss of business interest
***Part II: More Substantive Issues with the Document and Its
Coverage***
Most, if not all, of the issues in this and the subsequent part
of the review were raised on the WG mailing list but do not
seem to be reflected in the document. AFAIK, those omissions
represent WG consensus, but I hope the IESG will assure itself
that they also represent IETF consensus.
**End of Section 1 and end of Section 2**
The last sentence of Section 1 reads "In both cases, even a
small registration fee can be a barrier to participation" and
the last one of Section 2 says "If the free option requires
additional registration steps, such as applying for a fee
waiver, those requirements should be clearly documented."
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.
**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.
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.
thanks.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
