Subject: Re: [saag] Fwd: Last Call: Recognising RFC1984 as a BCP

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 11:11:52 -0700

(forwarded from SAAG):
On 8/10/2015 6:14 PM, Daniel Kahn Gillmor wrote:
> On Mon 2015-08-10 16:34:38 -0400, Joe Touch wrote:
>> I disagree with this change of status.
> 
> Is your disagreement on process grounds or because you disagree with the
> analysis or sentiments expressed in RFC 1984?

Both.

As a process issue:

	- The analogy to ASCII  (RFC20) is not helpful. That is a
	factual document; this is an op-ed piece.

	- It makes sense to move existing RFCs to "Historic",
	but in all other cases (ASCII included) it is much
	more common and in keeping with the IETF process to
	issue a new RFC

As a content issue:

	- we cannot issue a "last call" on a BCP unless
	the doc is open for edits

	- BCPs should make recommendations to protocol
	designers, users, implementers, and operators

	this document speaks more to governments, which is
	a policy role I feel ought to stay closer to the ISOC
	and out of the IETF/IRTF

While I appreciate the kitsch of desperately clinging to the originally
issued RFC number, the document further lacks the clear and technical
advice to EVERYONE I expect for the topic covered. Some missing issues
are noted below.

IMO, a BCP on this topic should stick to the facts, avoid wandering into
policy and governmental issues, and make clear recommendations to the
IETF community. The current RFC fails in all these regards.

Joe

----

	- the fact that lazy programming is the cause of a large
	amount of security issues (buffer overrun)

	- the concept that "crypto everywhere" is as vacuously useful
	as "crypto nowhere"

	- it makes no direct key size recommendation (as a BCP should)

	- it makes no algorithmic diversity recommendation (as, IMO,
	a crypto BCP should)

	- it makes no statement on the computational complexity of
	crypto algs and their relationship to adoption and deployment
	(as, IMO, a crypto BCP should)

	- it makes a claim about certification authorities being
	both legitimate and necessary, when they are the antithesis
	of some valid and useful crypto systems

	- it fails to address the slipshod way in which public keys
	are often signed by others, e.g., using a "government issued ID"
	as proof (who of us would know an invalid ID if we saw one?)

	(i.e., "key signing parties are a hazard to public key crypto"
	IMO)

	- it makes no statement about the relationship of the keys to
	the data, i.e., it does not warn against bare reuse of keys
	(vs., e.g., using the keys with session info to derive a
	session key)

	- it does not address how salts or seeds are generated safely,
	and why using header fields you "don't know" isn't the same
	as using random info.

	- it fails to address ways in which actions, rather than
	content, expose information (e.g., the packet patterns)

	- it fails to address the potential benefit of out-of-band
	verification or salts

The list goes on.

----

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Aug 2015 22:17:58 +0100

Hi Joe,

My own reactions below...

On 11/08/15 19:11, Joe Touch wrote:
> 	- The analogy to ASCII  (RFC20) is not helpful. 

I don't know what analogy you mean. The status change document
only says:

"The closest precedent we have for this status chage is the change of
RFC20 to Internet Standard. [4] That shows that if the text of an RFC
is acceptable, the age of the RFC isn't material in discussing proper
RFC status."

I think that's just useful information as that specific point was I
think raised when the RFC20 status change was considered.

> That is a

I don't think that's a relevant process point at all.

> 	more common and in keeping with the IETF process to

Again, that doesn't seem to me to be any kind of process
objection of substance. We can and do change the status of
RFCs without modification, sometimes to historic sometimes
not. If you object to such status changes then you need to
write an I-D I guess that changes the process. (In case it
helps see [1] for the list of recent status changes that
were last called as in-place status changes.)

[1] https://datatracker.ietf.org/doc/rfc-status-changes/

> 	the doc is open for edits

The last-call is not on the RFC but on the status-change document.
That can succeed or not. One of the possible outcomes to such a
last call is to decide to edit the relevant RFC, in which case
the status change would not happen. I see no process nor content
issue here that I understand.

> 	designers, users, implementers, and operators

See my earlier answer to Roy. [2]

[2] https://www.ietf.org/mail-archive/web/ietf/current/msg94274.html

> 
> 	this document speaks more to governments, 

I disagree. Again I'd point at my earlier answer to Roy.

> which is

I think folks generally agree that such policy things are better
left to ISOC. I think it's equally clear that for example you and
I wouldn't agree on what we consider policy things in all cases.

> While I appreciate the kitsch of desperately clinging to the originally

Kitsch and "desperately clinging" are purely pejorative I think.

> issued RFC number, 

I don't myself think that's such a big deal but if we have a way to
keep 1984 as the number, doing so is cute and worth doing I'd say.

> the document further lacks the clear and technical

We disagree. See below for some responses.

> 	amount of security issues (buffer overrun)

Off topic. This is not a document trying to cover all vulnerabilities
nor important ones, nor rank vulnerabilities.

> 	- the concept that "crypto everywhere" is as vacuously useful

I don't find that concept in the document at all, nor in any relevant
IETF document. You seem to be knocking down a non-existent strawman.

> 	- it makes no direct key size recommendation (as a BCP should)

Off topic. This is not recommending use of specific algorithms (where
key size/strength becomes an issue) but the non-use of a class of
crypto that forces one to do key escrow of the kind described. This
is not a generic crypto primer nor HOWTO nor a BCP about how to use
crypto in IETF protocols. You seem to be criticising some document
which is not RFC1984 that you would prefer was the subject of an IETF
last call, but the detail of what is not here but in that non-existent
document is not useful in the context of this IETF last call I believe.
(Note I refer back to this point a number of times below when I say
"see above.")

> 	- it makes no algorithmic diversity recommendation (as, IMO,

Off topic, see above. (Separately, I would welcome your comments on [3]
which is also currently in IETF LC btw.)

[2] https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/

> 	(as, IMO, a crypto BCP should)

Off topic, see above.

> 	of some valid and useful crypto systems

Legitimate is fine, necessary is ok in that context and both are
actually about the abstract concept of a PKI which I think is
still considered basically correct. While we might use the work
"necessary" there were we to write this today, that I think is
ok.

> 	as proof (who of us would know an invalid ID if we saw one?)

That is not a quote from 1984. You seem to be criticising text that
is not there? Or are you postulating some other BCP about PKIs?

> 	(i.e., "key signing parties are a hazard to public key crypto"

Same problem as above - the quoted text above is not a quote from
1984.

> 	- it fails to address the potential benefit of out-of-band

All 4 of the above points are IMO off topic, so once again: see above.

> The list goes on.

The problem with your list is that it is not dealing with this last
call of the status change of RFC1984 I think. It really looks to me
like you're saying that there is some other document that you would
prefer be written. That's a fine wish, but I don't think the details
of what you think ought be in that document are very useful in terms
of helping the IESG evaluate this last call.

Cheers,
S.

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 14:43:16 -0700

Hi, Stephen,

As to the process issue, I see absolutely no rationale for not opening
this to a -bis style editing cycle except the hope of clinging to a
already issued RFC number.

As I've pointed out to others, there are cases where standards-track
docs have been promoted or demoted as-is because changing the doc would
mean changing the protocol. That's not an issue here.

As to the content:

On 8/11/2015 2:17 PM, Stephen Farrell wrote:
...
> nor important ones, nor rank vulnerabilities.

It's a statement on "cryptographic technology and the Internet". AFAICT,
the biggest holes we have in that technology are in the sloppy
implementation.

> IETF document. You seem to be knocking down a non-existent strawman.

I'm saying that the document, as a BCP, ought to discuss how crypto is
used, and make the case that crypto should be used where needed. It is
not a panacea. The subtext of the current document hints otherwise.

> (Note I refer back to this point a number of times below when I say

Point taken, but my counterpoint is that a document that speaks to
governments and voters is "off topic" for the IETF.

But let's concede that we've both made that point and omit the remainder
that fall into that class...
...

> "necessary" there were we to write this today, that I think is

certification authorities are legitimate and necessary *for PKI*. There
are other systems, though (I would not consider PGP based on "PKI").

> is not there? Or are you postulating some other BCP about PKIs?

I'm claiming the document is flawed in not addressing this issue. If you
think it's OK to claim that certificate authorities are necessary, then
why is it OK for PGP to use haphazard keysigning parties?

> Same problem as above - the quoted text above is not a quote from

Same thing - flawed by omission.

I consider this issue to be distinct from the more technical, specific
ones you claim are "off topic".

> of helping the IESG evaluate this last call.

A document that clearly indicates the technical reasons why certain
policies are ineffectual or inappropriate is fine. This document might
be a step in that direction, but it has problems that ought to be fixed.

A document that pontificates on those reasons has no purpose in the
IETF. I recognize that there are many others on this list who prefer to
waste their time endorsing such proclamations, but I will not.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Aug 2015 22:56:02 +0100

> already issued RFC number.

Late here sorry so just on this for now - that was discussed on the
saag list. From that and from chats with folks the main argument for
doing this in-place was that the text is considered good enough as-is
and a belief that we'd not do much better despite what'd likely be a
long and likely fractious discussion of the kind I guess you are
arguing would be better.

The RFC number was less of a deal, really, for almost everyone I
think.

S.

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Aug 2015 04:08:09 -0400

--On Tuesday, August 11, 2015 22:56 +0100 Stephen Farrell
<[email-masked]> wrote:

>> As to the process issue, I see absolutely no rationale for
>> not opening this to a -bis style editing cycle except the
>> hope of clinging to a already issued RFC number.
> 
> Late here sorry so just on this for now - that was discussed
> on the saag list. From that and from chats with folks the main
> argument for doing this in-place was that the text is
> considered good enough as-is and a belief that we'd not do
> much better despite what'd likely be a long and likely
> fractious discussion of the kind I guess you are arguing would
> be better.

Stephen, it seems to me that the desire to make the point that
1984 represents time-tested ideas can be combined with the
desire to make more nuanced statements in some areas --areas
where either 1984 was weak or hasn't really stood the test of
time if one examines the details and/or where 1984 doesn't offer
enough normative guidance -- could both be accommodated by
creating a new document as a supplement or addendum to 1918 and
then moving both to BCP.  I'm still not positive that is the
right solution, but it would at least allow the community to
have a serious discussion on the provisions of 1918 (and what
needs supplementation) consistent with a normal IETF Last Call.

Given that there is controversy about, at least, details and
style, the effect of the procedure now being followed is to
force the community into the equivalent of an up or down vote.
That is uncomfortable for at least some of us who find little to
disagree with about the text of 1918.

However, there seems to be resistance to discussion of such a
two-document approach, one that I'm having trouble
understanding.   If the ultimate answer is "too much work" or
"not enough interest to do the work", then I suggest we have no
meaningful consensus about the status change and it should be
dropped.

    john

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Aug 2015 13:25:52 +0100

Replying John and Pete in one go.... (I'm determined to try
but fail to keep the Narten number down this time:-)

> creating a new document as a supplement or addendum to 1918 and

(I assume s/1918/1984/g.)

> needs supplementation) consistent with a normal IETF Last Call.

Discussion of whether or not the text of 1984 is good enough
as-is is entirely in scope for this last call. There is nothing
at all blocking such a discussion.

> force the community into the equivalent of an up or down vote.

That's in the nature of any in-place status-change I guess.
We can change the status-change document of course if that
is useful, (as you suggest in the other thread) but when it
comes down to it this is a yes/no thing in that the outcome
will or will not be a change to the status of RFC1984.

> two-document approach, 

What resistance? I think I've seen people look at the issues
and conclude that new text is not needed. That is not at all
anything like "resistance to discussion."

> one that I'm having trouble

I didn't hear folks say "too much work" but rather "good enough
as-is" and "not going to get better despite what'd be an inevitable
chunk of debate." I interpret that latter point as being that
we'd certainly use different words if we re-wrote 1984 today but
that those new words wouldn't really be significantly better so
if the text as-is is good enough, then it's better to not change
it at all. I guess there is also a dislike of make-work, and
if you conclude that new text wouldn't be usefully better then
new text would only be make-work.

If people disagree that the 1984 text is still good enough, that
is of course a reasonable objection to make as part of this last
call. (In which case pointing out exactly what text isn't good
enough and saying why would be what one ought do I guess.)

On 11/08/15 22:18, Pete Resnick wrote:
> 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.

So we disagree about that, which is fine. I do think some insurance here
is a worthwhile goal. I hope that you do agree that this is something
about which reasonable folks can reasonably disagree?

I would point out however that in the case of the IANA transition stuff
the ianaplan WG seems to have had a much easier time doing its work
compared to e.g. the folks within ICANN (CCWG) who didn't have stuff
done ahead of time.  While it's an entirely different area, I think
that is a useful point to consider.

I also think that if any new mandatory key escrow proposals do reach
the IETF, then it will not simply be one person proposing an I-D. It'd
likely be a whole bunch of companies and an industry consortium all
pushing for doing something bad because their customers/govts say
they have to, so I would prefer that we had the discussion now while
we can do that without the commercial pressures that would be
involved if we did wait until a crowd turn up with those bad ideas.

But that's the thing about insurance in cases like this where there's
no good way to estimate the probability of bad outcomes: we won't know
for sure we need it until it's too late.

>
>> 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.

Just asserting "fluff" isn't very compelling is it?

>
> 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.

Heh. Regardless of easy/hard, I and it seems others do think that
the text we have is good enough and does sufficiently well define
a class of crypto solutions that we do not want, and if that turns
out to be the rough consensus at the end of this LC (and subsequent
IESG evaluation) then such additional text isn't needed.

The real downside though of new text is not really that we won't
have consensus that mandatory key escrow is bad, the problem is
that as usual many folks will prefer that some other target be the
topic of new text. (See Joe Touch's mail for some examples.)
And as I said above, I think it's unlikely new text would be
significantly better.

We have text. It's seems good enough. And I don't see a reason
to make life unnecessarily harder out of some fixation with process.
(I do get that you and I don't agree on that last point:-)

>
> 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.

I agree that our process discussions tend to be pretty horrible, but
I don't agree with you that we ought not try make them the least
horrible we can. And there is no "sneaking" going on here (nor
"purporting" nor trying to close down discussions). This is an open
entirely normal IETF LC, not an exercise in sneaking things in, out
or sideways. (Can you tell that such accusatory language is, well,
let's just say, unhelpful? ;-)

>
>> 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.

And it's just fine that you don't care what other folks think and
make up your own mind having read the material.

The quoted statement is however accurate. What you conclude from
that accurate statement is another matter.

(But if you conclude that the quoted statement is asserting that
the IETF have consensus or some WG have consensus then you are
plain wrong as it just does not say that.)

> If that was the consensus question being asked on
> saag, it was a bad one.

The quoted text was not a question asked, it is a part of the
outcome of the saag discussion and input to this last call.

> We come to consensus on technical content. If
> saag had consensus on some technical points, write those down and
> propose it as a BCP.

Hmm. Have you read the mail thread on saag about this? If you
had and/or were at the saag session in Prague this should be clear
enough. At no point has there been anything like a rough consensus
to write new BCP text on this topic. That was suggested but really
has no significant support and had quite a few folks arguing against.
And I also checked on that in Prague where I think there were zero
or almost zero hands up preferring that option.

Cheers,
S.

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Aug 2015 15:48:59 -0400

Stephen,

One more comment and then I think I would like to be recorded as
not being in favor of reclassification, especially one done this
way, but will move on.

--On Wednesday, August 12, 2015 13:25 +0100 Stephen Farrell
<[email-masked]> wrote:

>> 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.
> 
> So we disagree about that, which is fine. I do think some
> insurance here is a worthwhile goal. I hope that you do agree
> that this is something about which reasonable folks can
> reasonably disagree?

Sure.  But if "insurance" is the motivation, I note that it does
not appear as motivation in the
"status-change-rfc1984-to-best-current-practice-00" writeup.
More important, I question what effect you think it would have.
Anything said in any RFC, regardless of status, can be
overridden by a replacement RFC if the latter gets consensus.
We have no policies or procedures that could be used to prevent
an I-D from being posted and discussed even if it contradicted
an existing BCP (or, for that matter, proposed a protocol that
would work only with changes in the speed of light).    So, in
particular...

>...
> I also think that if any new mandatory key escrow proposals do
> reach the IETF, then it will not simply be one person
> proposing an I-D. It'd likely be a whole bunch of companies
> and an industry consortium all pushing for doing something bad
> because their customers/govts say they have to, so I would
> prefer that we had the discussion now while we can do that
> without the commercial pressures that would be involved if we
> did wait until a crowd turn up with those bad ideas.

So we either maintain 1984 in its current status or we promote
it to BCP.  Then, in a few years, that "whole bunch of companies
and industry consortium" come along and say "we want to do this
and we want to do it in the IETF".  More likely (and consistent
with the above), they say "we are being forced by our
governments and customers to do this and we think that, if we
can do it in the IETF, the community can help to find a way to
do it that maximizes interoperability and minimizes damage even
though you and we would rather not have it happen at all".
Certainly the debate that followed would be "interesting" and
probably heated.  Certainly some people would cite 1984 (whether
it was a BCP or just Informational).  However, unless we had
gone completely nuts by then, I'd assume (or at least hope) that
we could have an intelligent discussion in which the moral
purity of avoiding that sort of work would be weighed against
minimization of damage to the working Internet.  

At the risk of being slightly pessimistic but very pragmatic, if
the relevant bunch of companies collectively employed (or
supported) a significant fraction of the IESG and were
determined to make the IETF take the work on, I'd predict that
either we've have an open, and more or less clean-slate,
discussion of the issues and tradeoffs or we'd end with with
enough sponsor/employer-forced resignations to paralyze the IESG
for an extended period.... and that whether 1984 was or was not
a BCP would have no effect on those scenarios at all.

As I suggested in a slightly different context a few days ago, I
hope that, if we are ever faced with the option of "helping"
people by getting them disconnected from the Internet because
they can't access it in the way we would like, we consider those
tradeoffs rather carefully.  Again, faced with that choice, 1984
(regardless of status) would be useful input, but it is hard to
imagine a classification decision made today (one way or the
other) changing the outcome significantly.

> But that's the thing about insurance in cases like this where
> there's no good way to estimate the probability of bad
> outcomes: we won't know for sure we need it until it's too
> late.

Again, I might feel differently about this if I saw real
"insurance" value and the ability to insure against future
changes in our environment.   But, again following your
description above, I'd expect, at best, the following sequence
of events:

 (1)
	draft-PeopleWhoWorkForABunchOfCompanies-Enforcing-Key-Es
	crow-00 gets posted, updating several X.509, TLS,
	S/Mime, and other specs.
 (2) You, SAAG, and/or the IESG say "you can't do that, it
	violates RFC 1984, which is a BCP".
 (3)
	draft-PeopleWhoWorkForABunchOfCompanies-Enforcing-Key-Es
	crow-01 gets posted, adding to the earlier text "updates
	1984" and explaining that the circumstances that
	justified it have changed.

then, maybe,

 (4) You, or your successor, try to assign that draft to
	a WG that is loyal to 1984 and hostile to the idea of
	key escrow or some other example of badness.  
 (5) A Bunch of Companies (or people working for them)
	appeal that decision as preempting any realistic
	community discussion that could lead to consensus and,
	in the process and, as part of the appeal, demand that
	none of a list of specific ADs be allowed to be
	responsible for the WG that should be created because
	they had already shown themselves as unalterably opposed
	and rigid about the outcome.

Regardless of the outcome of that appeal, the IETF and the
Internet probably lose.   If things get sufficiently nasty,
those companies say, possibly without bothering to appeal or
waiting for the outcome if they do, "the IETF has become
unresponsive to the operational realities of the Internet, we
know where we can have a discussion of these issues and develop
standards".   Then they withdraw all support for IETF
participation, all sponsorship of meetings, etc., and take their
work to the ITU.   That would leave us in a state of grace
because we didn't violate our 1984-enshrined principles.  It
would also leave us out of business.

Now I wouldn't expect scenarios nearly that dramatic to unfold,
partially because I think we are, as a group, more sensible than
to get trapped in that sort of situation.  But the point is that
your "insurance" does nothing to constrain the decision in the
way I'd assume you would like, nor would it mitigate the
consequences.  

Indeed, if that bunch of companies, etc., are what you are
concerned about, we are probably better off without 1984 as a
BCP.  With its current status, the IESG and the community are in
a very strong position to say "We have a set of principles,
described in RFC 1984, that say we don't intend to do that sort
of work. Do you really think circumstances have changed enough
that we should either revisit the principles or make an
exception, and if so how?".   It seems to me that could be the
beginning of a healthy discussion.  By contrast, if a BCP can be
used to justify a "we can't do that work under any
circumstances" position, it guarantees an adversarial
interaction, probably with exactly the companies whose support
and products we need to keep working and to continue to be
credible.

    john

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Aug 2015 21:05:25 +0100

Hiya,

One bit more of explanation...

> "status-change-rfc1984-to-best-current-practice-00" writeup.

That's correct. The text in the status change document is a summary
of the discussion to that point, whereas the insurance idea is why
I think doing this is a good idea (and that can be debated of course
as you've done). I didn't include that in the status change document
as I'm not sure that's a common motivation amongst those that would
like to see this status change happen.

Cheers,
S.

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Aug 2015 15:08:37 -0500

> overridden by a replacement RFC if the latter gets consensus.

Any statement of the IAB's or IESG's or IETF's opinion is temporary and
thus symbolic, with the only enduring things here being deployed
Internet protocols and the text of the RFCs.  Therefore this effort is
symbolic, yes.

But symbols matter.  This whole exercise started with someone wanting
the IETF to work on interception capabilities for ISPs who are required
to implement them.  And we said no.  Just now, days ago.  And it was
easier to reconfirm a previous opinion that that been debated years ago
and written into an RFC than it would have been to debate it de novo --
the weight of the past debate, consensus, and publication status helped.

RFC1984 was symbolic then and helped us now.  That's proof that symbolic
acts have at least somewhat more than social signaling value, which in
turn is motivation enough for restating the RFC1984 opinion: so it may
help again in the future.

I do think that RFC1984's content doesn't make for much of a BCP by
itself, but paired with RFC2804 [as proposed by Michael R.] it does --
enough to quiet my misgivings about having BCPs whose content isn't
typically BCPish.

Nico
--

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Aug 2015 05:25:02 +0900

> Anything said in any RFC, regardless of status, can be overridden by a
> replacement RFC if the latter gets consensus.

even camus did not conclude that, because the world is absurd, that we
should not act.

randy

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Aug 2015 17:06:17 -0400

--On Thursday, August 13, 2015 05:25 +0900 Randy Bush
<[email-masked]> wrote:

> even camus did not conclude that, because the world is absurd,
> that we should not act.

Unlike Roy, Joe, and some others, I don't fundamentally object
to reclassifying 1984 (and object less if the BCP category
sweeps up other documents that are judged similar).  Independent
of the principles 1984 expresses, I am uncomfortable with making
a document with its statements and style a BCP, but I'm
pragmatic about that and can live with it if we are clear about
what we are doing and why.  I do feel that we should have some
justification that makes sense.   The SAAG meeting discussion
has been cited frequently, but I can find nothing in the IETF-93
minutes that identifies the motivation and justification and
what appear to be a few votes (including that only half the
people in the room claimed to understand the issues).

If people believe it is time to make another political statement
but see the best way to do that as reclassifying 1984 rather
than that writing a new statement, that is ok with me as long as
we understand that political statements can have costs and that
we are willing to accept those costs.

Finally, I don't want to see bogus justifications because they
ultimately discredit the IETF, however slightly.   The statement
you quote above was caused by comments that seemed to imply
that, if we moved 1984 to BCP, it would somehow provide
"insurance" against the IETF doing work of the variety
discouraged by 1984 in the future even if there was strong
pressure, perhaps even consensus within the community, to do so.
I think that "insurance" claim is bogus.  YMMD, of course.

While I would hope that the people who want this change really
have (quoting Stephen) "a common motivation".  I think it is
obligatory to pull out the motivations, be explicit about them,
and discard those that don't hold water.  If those come down to
"because it makes us feel good", I'm ok with that as long as
there is at least rough consensus behind the statement.

Again, YMMD... and many those who are strongly opposed to the
IETF doing "political" things probably dislike my position and
concerns as much as they dislike statements of the 1984 sort,
BCP or not.

     john

---

From: Michael StJohns <[email-masked]>
Date: Thu, 13 Aug 2015 11:26:29 -0400

At 05:06 PM 8/12/2015, John C Klensin wrote:
>justification that makes sense. 

I mostly agree with John as above.  But I've got a few housekeeping questions:

1) Unlike the publication of a new RFC and its associated dates, there isn't any way to permanently associate the change of status date with the RFC.  At some future time (and here I'm talking 10-20 years), will it ever be important to be able to identify when the change was made (without having to do email archeology)?  Changes to Historic require the submission of an RFC to mark the change - why wouldn't this change also require such  a document.  From the IESG web page:

>A major advantage of a status-change document is that it adds traceability: when the now-Historic RFC is displayed in the datatracker, there is a pointer directly to the status-change document, making the explanation more readily accessible. See <http://tools.ietf.org/html/rfc5617>RFC 5617 for an example: 

2) According to RFC 2026, BCPs are documents of the IESG, not the IAB and IESG together.  Should that be reflected on any change of status in the document itself?  Or is the language in 2026 incomplete and we should spend a little time updating things there?

And one minor nit:

RFC1984 seems pretty OK with the idea of passwords as a security mechanism. While that's only a single aside in the document, reaffirming that passwords are OK in 2015 seems like a bad idea.

> For example,
>   conventional passwords, credit card numbers, and the like must be
>   protected by strong encryption, even though some day more
>   sophisticated techniques may replace them.  Encryption can be added
>   on quite easily; wholesale changes to diverse systems cannot.

"Encryption can be added on quite easily"??  

Just thoughts - but I think the tracker question is important to consider prior to this status change.

Mike

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Aug 2015 13:57:39 -0400

--On Thursday, August 13, 2015 11:26 -0400 Michael StJohns
<[email-masked]> wrote:

>> sweeps up other documents that are judged similar).
>> Independent of the principles 1984 expresses, I am
>> uncomfortable with making a document with its statements and
>> style a BCP, but I'm pragmatic about that and can live with
>> it if we are clear about what we are doing and why.  I do
>> feel that we should have some justification that makes sense. 
> 
> 
> 1) Unlike the publication of a new RFC and its associated
> dates, there isn't any way to permanently associate the change
> of status date with the RFC.  At some future time (and here
> I'm talking 10-20 years), will it ever be important to be able
> to identify when the change was made (without having to do
> email archeology)?  Changes to Historic require the submission
> of an RFC to mark the change - why wouldn't this change also
> require such  a document.  From the IESG web page:
> 
>> A major advantage of a status-change document is that it adds
>> traceability: when the now-Historic RFC is displayed in the
>> datatracker, there is a pointer directly to the status-change
>> document, making the explanation more readily accessible. See
>> <http://tools.ietf.org/html/rfc5617>RFC 5617 for an example: 

The date issue had not occurred to me, but I concur.  I suppose
the tracker could be modified to show a "last status change"
field and link for all documents whose status had changed, but
obviously this isn't going to happen before this proposed change
is processed (if it is).

It also raises another variation on my concern about just
documenting these things in the tracker.   We've historically
tried to take the notion of RFCs as an archival series quite
seriously.  The more often we place critical information about
RFCs and their status (history, metadata, etc.), in separate
databases, the more complex preserving the "archival" condition
becomes.  In particular, if we have expectations that the
tracker can be considered an archival source on a par with the
RFCs themselves, it is likely to be necessary to make sure there
is dated backtrace capability (or equivalent) and that we be
sure that the tracker database is managed in a way that
guarantees its accessibility for a really long time (some
approximation to "forever").

I'm not sure how much the community actually cares but, if we
do, it is another reason to be careful about these
reclassifications, how they are documented, and where.

best,
    john

> 
> 
> 2) According to RFC 2026, BCPs are documents of the IESG, not
> the IAB and IESG together.  Should that be reflected on any
> change of status in the document itself?  Or is the language
> in 2026 incomplete and we should spend a little time updating
> things there?
> 
> And one minor nit:
> 
> RFC1984 seems pretty OK with the idea of passwords as a
> security mechanism. While that's only a single aside in the
> document, reaffirming that passwords are OK in 2015 seems like
> a bad idea.
> 
> 
>> For example,
>>   conventional passwords, credit card numbers, and the like
>>   must be protected by strong encryption, even though some
>>   day more sophisticated techniques may replace them.
>>   Encryption can be added on quite easily; wholesale changes
>>   to diverse systems cannot.
> 
>

---

From: Pete Resnick <[email-masked]>
Date: Thu, 13 Aug 2015 15:10:54 -0500

Mike,

I think there are a couple of factual mistakes in here, though I don’t 
think they’ll change either of our opinions about this particular 
document:

On 13 Aug 2015, at 10:26, Michael StJohns wrote:

> 1) Unlike the publication of a new RFC and its associated dates, there 
> isn't any way to permanently associate the change of status date with 
> the RFC.  At some future time (and here I'm talking 10-20 years), will 
> it ever be important to be able to identify when the change was made 
> (without having to do email archeology)?

A change in status of a Standards Track document (whether up in the 
Standards Track or down to Historic) requires a “Standards Action” 
notification, and that gets documented in the IESG minutes. Not an ideal 
markup system (only half better than email spelunking), but the process 
is there. (See 2026 6.1.3, and RFC 7100.)

> Changes to Historic require the submission of an RFC to mark the 
> change

Not according to 2026 6.4. All it requires is a Last-Call and then the 
notification procedures in 6.1.3.

> 2) According to RFC 2026, BCPs are documents of the IESG, not the IAB 
> and IESG together.

Well, they go through IESG review, but they’re documents that are 
“viewed as having the technical approval of the IETF”. That said, 
2026 does recognize the IAB as a potential author of a BCP:

    While it is recognized that entities such as the IAB and IESG are
    composed of individuals who may participate, as individuals, in the
    technical work of the IETF, it is also recognized that the entities
    themselves have an existence as leaders in the community.  As 
leaders
    in the Internet technical community, these entities should have an
    outlet to propose ideas to stimulate work in a particular area, to
    raise the community's sensitivity to a certain issue, to make a
    statement of architectural principle, or to communicate their
    thoughts on other matters.  The BCP subseries creates a smoothly
    structured way for these management entities to insert proposals 
into
    the consensus-building machinery of the IETF while gauging the
    community's view of that issue.

My read has always been that the IAB and/or IESG can create a document 
for the purposes above, it goes through an IETF discussion/edit, and 
then it can become a BCP of the IETF.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Michael StJohns <[email-masked]>
Date: Thu, 13 Aug 2015 17:07:24 -0400

At 04:10 PM 8/13/2015, Pete Resnick wrote:
>Mike,
>
>I think there are a couple of factual mistakes in here,

I'm pretty sure I differ with you on whether they constitute factual mistakes versus different interpretations.

> though I don't think they'll change either of our opinions about this particular document:
>
>>1) Unlike the publication of a new RFC and its associated dates, there isn't any way to permanently associate the change of status date with the RFC.  At some future time (and here I'm talking 10-20 years), will it ever be important to be able to identify when the change was made (without having to do email archeology)?
>
>A change in status of a Standards Track document (whether up in the Standards Track or down to Historic) requires a "Standards Action" notification, and that gets documented in the IESG minutes. Not an ideal markup system (only half better than email spelunking), but the process is there. (See 2026 6.1.3, and RFC 7100.)

Yes but as I noted - finding that in the IESG minutes requires email archeology. There is nothing associated with the document itself, nor for that matter with the RFC index system that indicates that a document was made a BCP on a date other than the date it was published.

>>Changes to Historic require the submission of an RFC to mark the change
>
>Not according to 2026 6.4. All it requires is a Last-Call and then the notification procedures in 6.1.3.

https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html  While you are correct that 2026 only requires what you say it does, I read the IESG statement on saying "no, we're not doing it that way any more and it's our call".

And the reason that was put in place is pretty clear:

>We have reclassified RFCs as Historic through different mechanisms and with different documentation over time. All reclassifications have suffered from a common problem: there is no direct reference from the RFC that has been made Historic to the explanation of why that action was taken. 

Finally, the section in that document that begins "The current process, then, of moving an RFC to Historic..." no longer just permits the simple last call.   

Or do you believe that page is not the current process?

>>2) According to RFC 2026, BCPs are documents of the IESG, not the IAB and IESG together.
>
>Well, they go through IESG review, but they're documents that are "viewed as having the technical approval of the IETF". That said, 2026 does recognize the IAB as a potential author of a BCP:
>
>   themselves have an existence as leaders in the community.  As leaders
>   structured way for these management entities to insert proposals into
>My read has always been that the IAB and/or IESG can create a document for the purposes above, it goes through an IETF discussion/edit, and then it can become a BCP of the IETF.

I can live with the reading of the text.    But does that then mean that the IAB of the current era should be giving its approval as a group prior to asking the IESG for its approval?  Given that it is a joint statement and both groups are listed as authors.

Later, Mike

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Aug 2015 22:09:26 +0100

On 13/08/15 22:07, Michael StJohns wrote:
> Yes but as I noted - finding that in the IESG minutes requires email
> archeology. There is nothing associated with the document itself, nor
> for that matter with the RFC index system that indicates that a
> document was made a BCP on a date other than the date it was
> published.

Is this [1] what you're after?

S.

[1] https://www.rfc-editor.org/status_changes.php

---

From: Pete Resnick <[email-masked]>
Date: Thu, 13 Aug 2015 16:31:45 -0500

On 13 Aug 2015, at 16:07, Michael StJohns wrote:

> archeology.

Or web site archeology.

> There is nothing associated with the document itself, nor for that 
> matter with the RFC index system that indicates that a document was 
> made a BCP on a date other than the date it was published.

As Stephen points out, there is a web page for status changes.

> https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html  
> While you are correct that 2026 only requires what you say it does, I 
> read the IESG statement on saying "no, we're not doing it that way any 
> more and it's our call".

That page says: “The current process, then, of moving an RFC to 
Historic status is to follow one of these, depending upon the level of 
documentation and discussion of the documentation required:”

You will notice that following #1 does *not* require a new I-D/RFC, but 
only a status change document.

>> My read has always been that the IAB and/or IESG can create a 
>> document for the purposes above, it goes through an IETF 
>> discussion/edit, and then it can become a BCP of the IETF.
>
> I can live with the reading of the text.    But does that then mean 
> that the IAB of the current era should be giving its approval as a 
> group prior to asking the IESG for its approval?  Given that it is a 
> joint statement and both groups are listed as authors.

Well, that’s just another example of why I object to just making this 
a BCP instead of re-writing it so it’s clear what the document means. 
My read of what’s supposed to happen is that the IAB (and/or IESG) 
tosses something over the wall, the IETF would chew on it, and publish 
whatever they came up with as a BCP. This thing being written as a joint 
statement of the IESG and IAB doesn’t sound like an IETF consensus 
statement. It should take all of an hour to rewrite this into a draft 
that doesn’t sound like a joint opinion of the leadership. I don’t 
see why someone doesn’t just do that.

pr

---

From: Michael StJohns <[email-masked]>
Date: Thu, 13 Aug 2015 17:47:01 -0400

>[1] https://www.rfc-editor.org/status_changes.php

Yes.   Now that I know that it exists I can work back and find it.   I actually looked on the site map and didn't find it.

Later, Mike

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Aug 2015 13:07:19 +0100

Hi Pete,

On 13/08/15 22:31, Pete Resnick wrote:
> It should take all of an hour to rewrite this into a draft that doesn’t
> sound like a joint opinion of the leadership. 

I think it's really great that someone can actively participate in
the IETF for many years and serve terms on the IAB and IESG and still
produce statements like that that are a real masterpiece of unfounded
but boundless optimism and naivety:-)

While it might only take one person one hour to craft new text,
that is utterly irrelevant here, sort of like saying that doing a
hard thing is easy because all you have to do is start.

I think it's been said before but the answer to you (with which
I know you disagree) is that the resulting text wouldn't really be
any better, that it'd take an awful lot more than an hour's effort
(as folks just would not resist the temptation to add/change/etc
once text is open for edits), that we would lose what some people
consider a benefit in affirming the existing text, and that we'd
be doing all of that for what are in the end process-minutiae
reasons.

And yes, I know you think there is a distinction that needs to be
made there and (after we IM'd) I know you know (and disagree with) at
least the arguments I've seen/made against that, so I'm pretty sure
we do understand one another, and, should the eventual outcome of
all of this be that we do make this status change in-place, that
it'll be safe to say your preferred approach was considered but
not adopted.

S.

---

From: manning <[email-masked]>
Date: Fri, 14 Aug 2015 05:59:43 -0700

I think Pete has it.  

"documents, like football game plans, are not easily drafted in a stadium, with thousands of very interested fans participating, each with their own red pencil, trying to reach a consensus on every word.”  - J.Postel

manning
[email-masked]
PO Box 6151
Playa del Rey, CA 90296
310.322.8102

---

From: John Leslie <[email-masked]>
Date: Fri, 14 Aug 2015 09:05:18 -0400

Stephen Farrell <[email-masked]> wrote:
>> It should take all of an hour to rewrite this into a draft that doesn???t

   I wouldn't describe Pete as "naive"...

> hard thing is easy because all you have to do is start.

   Nonetheless, many wise men (and women) have repeated the saying,
"The journey of a thousand miles begins with one step."

   I find it discouraging that so many folks here have spent hours
posting, "Taking that first step would be stupid!"

> any better,

   That depends on what we're trying to accomplish!

   If all we want is to "feel-good" about saying RFC1984 was important
then and still is important today, then reclassifying as BCP is
by definition better (because we avoid saying anything which could
possibly be interpreted as contradicting some minescule part of it.

   But if we mean to influence folks which are in a position to act,
then almost anything shorter would be better. (IMHO)

   Hopefully, many of us can agree that almost anything that Pete
wrote _would_ be shorter and better for _that_ purpose.

--
John Leslie <[email-masked]>

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 14 Aug 2015 09:36:24 -0400

I support reclassifying RFC 1984 as a BCP now.

People who want to start work on a replacement document that they view as
superior are welcome to do so.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 15 Aug 2015 00:15:28 +0200

> superior are welcome to do so.

Well said, I agree.

/Simon