I'm a little late responding... Sent from my iPhone > On Aug 11, 2015, at 7:52 AM, Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote: > > > 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. I agree that this consensus was clear in the meeting and is now being discussed on lists following the usual process. Thanks, Kathleen > >> 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. > >