--On Wednesday, January 25, 2023 11:22 +0000 Mirja Kuehlewind <mirja.kuehlewind@xxxxxxxxxxxx> wrote: > 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. I believe they are. I think that it would be really unfortunate if they fell through the cracks because I believe that some of them (maybe not all) are issues on which the IETF ought to be establishing principles and positions because, no matter what they look like on a given day, they may have implications about who does or does not participate in the IETF, how we are seen by governments, regulators, and the public as well as by those companies who use our standards, and so on. The IETF's survival probably does not depend on such decisions, but our long term credibility and relevance might. > 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. I think your assumption and what I believe to be desirable are closely aligned if not identical (hint: I think the GDPR was a bit of an overreaction and that, over time, it is likely to need, and probably get, some tuning). Having read Jason's note and reviewed the LLC (and almost everyone else's) privacy policy, let me describe just one example of the interaction between existing principle and the type of edge cases that concern me. As a sometime-statistician who spent many years working on issues of how to probe data that was published in aggregate form and combine it with other aggregated data in order to infer information at much lower levels of aggregation, "it will be published only in aggregate form" does not do much for me. Example: when last I paid careful attention to our attendance statistics, we had no attendees from Antarctica. Suppose a couple of people with addresses there registered for IETF 116. Had we been publishing data aggregated by continent, some adjustments would be necessary to avoid the "aggregate data" being easily analyzed in a way that would come close to identifying individuals. Now that example is silly (or I assume it is) because I am confident that LLC staff would notice an entry in an aggregate report with only one or two people in it and would research and implement some way to deal with it that would neither disclose information or turn those participants into second-class citizens. But there are far more complex multivariate (or multi-table) cases that are harder to detect and that are not appreciably less vulnerable to identification of individuals and data about them (want to read a couple of Ph.D. dissertations? I didn't think so). Consequently a principle that says "we will aggregate at a sufficient level to prevent disaggregation or deanonymization" is great as a principle (and, as principles go, maybe sufficient) but, as with many Internet security issues, what it means in practice depends to a considerable extent on the skill level, determination, and resources available to the attacker. My personal guess is that the statements in the present policy document are somewhere between "fine" and "about as good as we are going to get". However, where that connects with the SHMOO draft works like this. Suppose there were someone who wanted to participate in the IETF had what they believed to be a legitimate concern about disclosure of any information other than their names. They don't need to participate in surveys or provide demographic information, so they (and we) are ok there. If they are able and willing to pay a registration fee, I imagine they would figure out a way to do that without disclosing any additional information, even if that required establishing a chain of intermediaries who could get an envelope to Fremont with some significant amount of cash in it and a registration confirmation number on the front. But, suppose they decide to apply for a fee waiver. There is nothing in your draft that says "if someone applies for a fee waiver, the LLC is expected to collect the absolutely minimum amount of information required to allow..." (whatever it is they decide they need to allow) "and the community will be told what information is to be collected so that potential applicants can made informed decisions". It that either necessary or desirable? I don't know, but I don't think it is an administrative decision. Is someone who might consider applying for a fee waiver enabled to ask what information will be collected if they do and ask without identifying themselves (and, if they are today, is that guaranteed long-term)? The privacy policy does not answer that question and the same comment about administrative decisions versus IETF policies apply. Similarly, if there is a policy about having the information checked by "some individuals" (and I agree with you and Jay about both the discussion and the appropriateness of doing that), do we have specific rules, or do we expect the LLC to develop and publish specific rules, about who those individuals can be (or the characteristics they are expected to have) and what personal confidentiality obligations they assume? Do we expect that their identities be public? If not, are potential applicants for fee waivers allowed to ask who will be doing the review and to object to specific reviewers and ask that they be kept away from the data? If they can ask, do we expect them to specify a reason and are we willing to have that reason be treated as extremely sensitive? You can, I trust, see where this is going. The question is whether, at the level of principles, the IETF should say "keep the data confidential except when disclosure is necessary, e.g., to prevent or detect bad behavior", whether that should be supplemented by "and tell the community what you are doing" and/or "we expect that you will be really careful, optimizing the policies to encourage both maximum (and maximally diverse) IETF participation and non-disclosure of any data a potential participant might consider sensitive (whether the rest of us do or not)".. or whether we (and any potential participants) will read the current privacy policy as requiring all of that. Personally, I think the latter would be a stretch and I am not nearly as sensitive about disclosure, of, e.g., where I live than people who are significantly concerned about such disclosures. I am reminded that we had a micro-flap a couple of months ago about whether it would be reasonable for someone to post an I-D, and whether it would be possible to have that I-D generate IETF work and evolve into a BCP, without disclosure that person's name or affiliation, instead providing only a first name that was probably an alias and an email address that provided no identifying information. Parts of the above are, I believe, part of the same question. I, personally, believe that transparency of the process is important enough that it would be reasonable for the IETF to say "no, if you want to write documents or influence standards, we (and the world) need to know who you are, at least at the name and maybe affiliation level". But, again, that should be an IETF decision, possibly one informed by external consultation, not one made by accident via an administrative procedure. Finally, the above is, to some extent, a reason for my discussion of Observers. If we intend to impose what amount to information disclosure conditions as a condition of participation, do we want to be able to tell those for whom those conditions are unacceptable that they can observe in real time or it is acceptable to tell them "if you don't want to meet the conditions to be a participant, you can always catch up later on what happened". While I (obviously) have a fairly strong opinion about that, what I think is more important is that be an IETF decision, not a side-effect of some administrative ones. best, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call