ietf
[Top] [All Lists]

Re: Last Call: Recognising RFC1984 as a BCP

2015-08-11 06:52:49

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.