I am in complete agreement with Pete on this matter. If there's a need for a BCP covering this matter - and I believe there is - write one. RFC 1984 isn't it. Moreover, the more urgent this need is, the more important it is to dot the i's an cross the t's. Ned > On 11 Aug 2015, at 6:52, Stephen Farrell wrote: > >> 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.) > Changing the status seems to fill a well-needed gap, and I suspect that > it’s just a rationalization to be able to make the political > statement. If someone should argue in the future for the IETF to support > nastiness, that’s the time to confirm that we have consensus not to do > that, and to write that down in the form of an IETF BCP. In other words, > I don’t buy this as a justification. > > 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. > Read that in context. This is part of the fluff in the intro, not a > directive. True and good fluff, mind you, but not a BCP statement. > 1984 is written from top to bottom as the opinion of the IAB and IESG, > not a BCP. Had I known then what I know now, I might have objected to > the IESG signing on to the statement (because the IESG should only be > making consensus statements for the IETF, IMO). But it was a different > time, and I’m OK with that. > If you really think the IETF needs to make a consensus statement on this > topic (and see above for why I’m not convinced of the necessity), > write a new intro which says, “Recent questions caused the IETF to > revisit the ideas in RFC 1984. The main points of 1984 are no longer > just IAB and IESG opinion. The IETF has consensus for these principles, > and they guide how we write our documents.” Include (without the > “this is just an opinion” qualifying text) what’s in 1984. Publish > to the IETF list. After some discussion, Last Call. Done. Easy. > If it’s not easy, routing around the damage of the IETF by trying to > use the status change mechanism to “sneak it in” is just worsening > our state of horror. > > 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." > Bogon alert! I don’t give a rodent’s rear that any group of IETF > humans (other than the IESG) has a rough consensus to make any document > any particular status. If that was the consensus question being asked on > saag, it was a bad one. We come to consensus on technical content. If > saag had consensus on some technical points, write those down and > propose it as a BCP. > You haven’t (IMO) sufficiently addressed the objections to the status > change. Either leave “good-enough” alone and let this remain as it > is, or write a proper BCP version and Last Call that. > pr > -- > Pete Resnick <http://www.qualcomm.com/~presnick/> > Qualcomm Technologies, Inc. - +1 (858)651-4478