John C Klensin wrote: > Ole, > > I'd like to encourage you and your IAOC/Trustee colleagues to > think about this in a slightly different light, consistent with > other concerns I've expressed recently. I would hope very much that any experiment that I try to carry out at the ietf has no visibility at this level... The only difference between supporting this experiment and say asking the the network team to throw up the another vlan for some hot steaming nat66 action is: the need for willing participants to carry tags around with them. the question of data retention There have been experiments at every IETF that I've participated in, some have required voluntary participation, many are just various parts of the meeting teams trying news services or hardware platforms. insofar as I'm concerned the barriers to experimentation should remain minimal. In the past when the issue of data retention came up in the context of an experiment as for example in the case of the intrusion detection system at ietf 55 the stewardship answer was simply to destroy the data once the meeting had concluded. On the hosting side the one and only document in the ION series experiment that I know of has the following to say about the network hosting of experiments: The network provider MUST NOT view the IETF network as an experimental facility at the risk of impacting the IETF attendee experience. (Do not experiment with his/her favorite pet technology.) I've been far to active on this thread already, and since this has now deviated from layer 1 and 2 to layer 9 I will now shut up. > Without taking any position about the idea itself, some > significant fraction of the community seems to believe that this > type of RFID experiment is a policy matter. Another portion, > perhaps overlapping, believes that a version of the "eat our own > dogfood" principle says that we should set an example by > utilizing RFID only properly and with due consideration. Some > of that group believes that "properly and with due > consideration" includes at least some technical security and > privacy issues, others (again possibly overlapping) believe that > the IETF should not be performing experiments with information > collection that can even potentially identify individuals unless > there are clear and public privacy policies in place. > > I can find nothing in BCP 101 that encourages or authorizes the > IASA to go off and perform policy experiments on its own > initiative. I haven't seen any signs of a proposal for a 3933 > process experiment in this area. Such a proposal, or an > IESG-initiated effort with a Last Call, presumably would have > involved an I-D and a reasonable possibility for the community > to determine whether the relevant ducks were lined up. > > I also find nothing in the "guidelines [...]for regular > operational > decision making" (required by RFC 4071, Section 3.5, first > paragraph) that authorizes this sort of experiment. Indeed, > despite that requirement, I'm not sure I can even find such > guidelines. The only thing I can find is the "IAOC > Administrative Procedures" at > http://iaoc.ietf.org/documents/IAOC_Administrative_Procedures_7-17-08.pdf, > but they seem to be addressed to issues other than "regular > operational decision making" and, despite the date on the file, > the procedure document itself doesn't show an adoption date and > the Policy and Procedures page > (http://iaoc.ietf.org/policyandprocedures.html) seems to > indicate that they are just a draft. > > In looking for that material, I did find the Communications > Policy, which appears to be a substitute for the Guidelines > called for by RFC 4071. It makes interesting reading. For > example: > > -- Section 5.3.4 calls for the IAOC to "adopt annual > goals for the IASA and the IAD by December of each year > for the succeeding year". The Reports page of the web > site (http://iaoc.ietf.org/reports.html) contains a line > for such "Annual IASA Goals", but it isn't even a link, > so apparently either there are no such goals or the IAOC > doesn't believe that making them available to the > community is a priority. > > -- Section 5.3.7 calls for an "Operations Report" to be > submitted to the IAOC monthly and posted on the web > site. There is no evidence of integrated Operations > Reports on the web site. Not a single one. There are, > however, separate Financial Statements (three so far for > 2009 -- but those are covered separately in Section 5.2 > of the Communications Plan and are hence irrelevant to > the Section 5.3.7 requirement) and Monthly Reports from > the IANA (not the IAD). > > -- Section 5.3.8 says "The IAOC shall publish an IAOC, > financial, and vendor performance report online one week > before the IETF Meeting". I don't recall seeing that > report on a regular basis, only oral presentations at > the IETF plenaries. The "Plenary Reports" page > (http://iaoc.ietf.org/plenary_reports.html) shows only > IANA and RFC Editor reports associated with IETF > meetings in the last several years. Indeed, the last > "IETF Ops Report" shown there is from IETF 68 (Prague in > 2007, before this Communications Policy was adopted) > > -- Section 5.3.10 calls for contracts or contract > summaries to be posted on the web site within 14 days of > execution. I note, as an example, that AMS has been > providing Secretariat Services for over 20 months now, > but that the only Secretariat Services Contract posted > is the December 2005 agreement with Neustar. I don't > suppose that I need to point out to the IAOC that 20 > months (and a contract date presumably somewhat earlier > than that) is longer than 14 days. I also note that > not a single hotel contract, or summary thereof, has > ever been posted. > > -- Section 6 calls for annual reviews of the > Communications Policy, with community review and input > "during the annual review cycle". The Communications > Policy was apparently adopted on July 12, 2007. That > suggests to me that there should have been two such > reviews. I'm not aware of either having occurred. If > the IAOC has concluded that the Communications Policy > isn't practical, why hasn't the required review been > initiated and the Policy been revised (with community > review and input), rather than simply ignored in major > respects? > > I don't recall the community asking the IAOC or Secretariat to > initiate this RFID effort either. I haven't gotten the > impression that the IAOC has so much spare time on its > collective hands that it should be making work for itself or the > community. Certainly the list above strongly suggests that the > IAOC and IASA don't have sufficient time to even comply with the > policies that they adopted (or to effectively require that the > IAD comply with those tasks specifically assigned to him... many > of them by BCP 101 itself). > > I do see a provision in BCP 101 (middle of Section 3.1) that > says: > > "The IAD shall ensure that personal data collected for > legitimate purposes of the IASA are protected > appropriately; at minimum, such data must be protected > to a degree consistent with relevant legislation and > applicable privacy policies." > > Several people in the community with some experience on these > issues seem to believe that adequate protective procedures do > not appear to be in place, but we haven't heard from the IAD > about what measures are being taken. > > So... > > (1) To what extent does the IAOC believe it is reasonable to > adopt new and discretionary initiatives that require IAD and > IAOC supervision when the IAD and IAOC appear to be sufficient > overloaded so as to be unable to comply with a large number of > the IAOCs own procedures and requirements, both those explicitly > called for in BCP 101 and those which it adopted in December > 2007. > > (2) Is the IAOC supervising the IAD to be sure that adequate > protective procedures are in place for personally-identifiable > data as per the provisions above? > > (3) Given that such procedures do not appear to be covered by > contractual provisions that justify secrecy, when does the > community get to review those procedures? > > (4) For an experiment that was initiated by the IASA, without > the instruction, advice, or consent of the community, does the > IAOC have a procedure for determining how much "the ducks are > not lined up" or other negative feedback from the community is > sufficient to call the idea off? Or is the IAOC's model such > that, having initiated this idea, no amount of feedback will > produce any change in behavior... i.e., that the experiment will > go forward and any evaluation will be performed after the fact? > > The last question is particularly important because, if that is > the plan, everyone participating in the discussion on this > thread is wasting their time and yours. > > > I have not posted this inquiry as a Request for Review as > described in Section 3.5 of RFC 4071 for two reasons: > > (i) I do not consider the RFID experiment to be the main > issue here, only the decision process that leads us into > such experiments and the way of handling community > review and comments. If someone in the community who > does consider the RFID experiment to be a main issue > wants to use some of the text above to construct such a > request for review, he or she should feel free but > should note that RFC 4071 "normally" gives the IAOC 90 > days to respond. By my rough count, 90 days would put > us somewhere in December so that, if the IAOC decided to > do so, it could simply ignore the Request for Review, > carry out the experiment, and then indicate either that > the Request for Review had become irrelevant or announce > that it would adopt and follow new procedures sometime > in the future. > > (ii) BCP 101 provides for Requests for Review of > "decisions or action" of the IAD or the IAOC, not for > massive non-feasance as outlined above. One could > potentially construct a Request for Review based on > "...questions whether the IASA has created and > maintained appropriate guidelines" but I don't have > quite enough spare time on my hands right now to > initiate that effort. Again, if someone else is so > inclined, feel free to borrow text as needed. > > regards, > john > > > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf