Re: Last Call: Recognising RFC1984 as a BCP

[Brian E Carpenter <[e-mail]>]

Roy,

On 11/08/2015 10:53, Roy T. Fielding wrote:
>> On Aug 10, 2015, at 3:06 PM, Brian E Carpenter <[e-mail]> wrote:
>>
>> On 11/08/2015 05:34, Roy T. Fielding wrote:
>>>> On Aug 10, 2015, at 10:23 AM, Paul Hoffman <[e-mail]> wrote:
>>>>
>>>> On 10 Aug 2015, at 10:13, The IESG wrote:
>>>>
>>>>> The IESG has received a request from an individual participant to make
>>>>> the following status changes:
>>>>>
>>>>> - RFC1984 from Informational to Best Current Practice
>>>>> (IAB and IESG Statement on Cryptographic Technology and the Internet)
>>>>>
>>>>> The supporting document for this request can be found here:
>>>>>
>>>>> https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/
>>>>
>>>> Yes, please. What was discussed in 1996 really is a best practice today, and it has certainly been made the current practice.
>>>>
>>>> --Paul Hoffman
>>>
>>> Umm, the document is specifically worded as a position statement from the
>>> IAB and IESG.  There is no "current practice" described by it.  Rather, it is an
>>> argument against key escrow and limited key sizes; a sort of anti-pattern for
>>> an old practice.
>>>
>>> I'd rather it be left as an informational document, as it was approved,
>>
>> When RFC 1984 was published, the way BCP was defined by RFC 1818 made it impossible
>> to classify it as BCP. RFC 2026 expanded the definition of BCP considerably
>> and specifically mentioned "the results of community deliberations" and
>> "common guidelines for policies" and is explicit that a BCP can be a vehicle
>> for IAB and IESG statements subjected to community consensus. So we are a
>> few years late, but this action seems well within the rules.
> 
> That doesn't change the content of the text, which is not expressing a BCP
> in any shape or form.  It is an opinion piece, which is fine as Informational.
> The document does not describe common guidelines for policies, nor does it summarize
> the results of community deliberations.  It states an opinion of the IAB and IESG
> at that time regarding two very bad suggestions for key management.  The right
> opinion, IMO, but still just an opinion of a dozen or so individuals.

That isn't so. Trivially, it was more like two dozen people (IAB+IESG)
speaking as bodies put in place by the IETF community, not as individuals.
Non-trivially, we strongly believed at the the time that we were giving
the rough consensus view of the IETF as a whole. There was a vigorous
debate in plenary at IETF 32 (Danvers, April 1995) which made the strength
of opinion in the IETF about the need for strong crypto very clear.
Unfortunately I can't readily find any trace of minutes of that plenary.

The first draft of what became RFC 1984 was circulated and wordsmithed
within the IAB and IESG, starting June 1996. An IAB and IESG Statement
version was released to the media on July 24, 1996 and simultaneously
sent to the IETF list, with a statement of intent to publish it as
an RFC. There was a rush due to US Congressional hearings that week.

The only comments we got on the IETF list were supportive, although
there was no formal last call. The RFC version was posted August 19,
1996.

> Changing the document status serves no useful purpose.  At best, it provides a
> bad example of how to write other BCPs.  If you can't generate enough energy
> to re-edit the document as a consensus specification, 

The whole point is *symbolic*. What we (the IETF) thought in 1995/96
is what we think now, and the choice of RFC number was not accidental.
Promoting it to BCP, consistently with RFC 2026 as I pointed out
before, reinforces that nothing in the last 20 years has changed
the underlying logic.

Yes, if the RFC 2026 definition of BCP had been in force in July 1996,
we'd have worded it slightly differently and there would have been
a formal Last Call. But it wasn't, so we didn't.

   Brian


> then it surely isn't
> important enough to serve as a bad example of back-door standardization.
> 
> Why is it that security-related statements by the IESG need to avoid
> being subject to the same process as all our other specifications?
> 
> ....Roy
> 
>