Hiya, Responding to a few things at once: On 10/08/15 22:29, Eliot Lear wrote: > The question I would still > like clearly answered is the one that Dave Crocker asked. What is the > intended effect? This may have already been answered sufficiently well by Brian, but in addition to what he said I think that this status change is just recognising reality as we do treat RFC1984 as a BCP. And formally recognising that could also avoid us having to deal with arguments about RFC status or the age of the RFC should someone start to argue afresh for the IETF to e.g. support mandatory key escrow. (I'm not aware that we're about to see any such argument btw so that last is more insurance than anything.) On 10/08/15 23:53, Roy T. Fielding wrote: > That doesn't change the content of the text, which is not expressing > a BCP in any shape or form. RFC1984 says: "Security mechanisms being developed in the Internet Engineering Task Force to meet these needs require and depend on the international use of adequate cryptographic technology." I read that use of "require... adequate" (and the rest of the text) as defining a class of crypto that we do not accept for use with IETF protocols so I think there is real BCP here even if there are no MUST statements. On 10/08/15 21:18, Dave Crocker wrote: > The supporting document asserts consensus within the ad-hoc saag group > has a number of basic problems. So the document is an individual > submission but relies on purported group rough consensus that was never > established. The supporting document says: "Based on the the saag list discussion and questions considered at the saag meeting at IETF93, the security area of the IETF appears to have rough consensus to change the status of RFC1984 to BCP in-place, without changes to the text." The "appears to" is important there. As you point out, we don't have a formal way to establish rough consensus via saag so this IETF LC is what matters. I certainly was not trying to pretend (nor "purport") that we have a better grasp of consensus than is the case. OTOH, we also have nearly 20 years of happily using the RFC as if it were a BCP and I do think that counts too. > First, saag is an accidental group that had no specific, documented task > for considering this draft. As such, some who might have wished to > participate in thoughtful discussion of this topic had no way to know > about it. Using an area mailing list like saag as the venue for early discussion here is entirely appropriate. > Second, discussion on the list was entirely ad hoc, with no convergence > and (rough) consensus processes. The only consensus-related process > concerning this document was during the saag session during the IETF > meeting in Prague. There was no followup on the saag mailing list or > any other. Wrong. I posted twice to the saag list since Prague saying that this IETF LC was the plan. There was no objection. > Hence the supporting document's second paragraph's reasons > for rejecting an effort to revise the document have no documentable > foundation. See the earlier mail thread. And at the Prague IETF session there was a (to me) clear consensus to not re-open the document for edits. > As an example of the randomness of the mailing list discussions, points > I raised about the reasons a revised document is needed to respond to > the current pervasive monitoring concerns received no substantive > responses. > > Making a carefully-considered (rough) consensus choice against concerns > is one thing. Ignoring them completely is quite another. I think the mail thread on saag, and the meeting room in Prague showed a clear consensus to not re-open this document for edits. (Some of the mails to that effect preceeded yours.) But this LC will tell if I'm right or wrong there. > ... > > > In sum, I think the revised document should: > > 0. Establish the current context including examples of related public > contributions. One recent publication would be obvious to include... > > 1. Provide statements of IETF principles about the nature and > requirements for privacy-related technologies, explicitly citing > relevant examples that would violate this. > > 2. Explain every 'what' with a 'why'. For each thing claimed to be good > or bad, explain the implications of ignoring the claim. > > 3. Give guidance that IETF efforts can use in designing new mechanisms, > formats, etc. Yes, doing the above would certainly have merit but more as part of an exercise to revise BCP72, especially your #3 above which would also require a very significant level of effort. (If there's more folks interested in working on those topics I'd be happy to try help regardless of whether that's seen as revising BCP72 or as being better handled some other way.) In any case your list seems to me clearly separable from this status change. Cheers, S.