ietf
[Top] [All Lists]

Re: Last Call: Recognising RFC1984 as a BCP

2015-08-11 16:20:44
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