> If people can tamper with the process without traceability, is the process > open? OK, let me see if I understand what you're saying. You're saying that because of the lack of protection on just one of the many means of getting public information the IETF has produced, that someone is going to take advantage of this to make some sort of nefarious change to some standards document, draft, etc. and by doing so manage to change the outcome of a standards process. If this is what you mean, then we've move to discussing what Bruce Scheier calls a "movie-plot threat", and I suggest that you enter your idea into the into the next contest Bruce runs. It should do well there. > ... > HTTPS protects a user (presumably) from someone knowing which standard that > downloaded or which mailing list archive they might have read. If there is > pervasive passive monitoring, it doesn’t protect them from being recognized as > having gone to IETF. And if you really have enough passive monitoring - > determining which standard gets downloaded might be possible too, watch for the > traffic spike, and check the size. (It’s really easy for those reading NFS :) > .) Because the passive monitor can get all the standards too, and know their > size just as well. Which is why we should - and do - offer https access. And prefer it, if possible. But as you note - and as I have noted previously - this doesn't do squat about traffic analysis, including but not limited to size checks. Perhaps rsyncing the entire document collection is the best approach if size checks really are a concern. Ned