Replying John and Pete in one go.... (I'm determined to try
but fail to keep the Narten number down this time:-)
On 12/08/15 09:08, John C Klensin wrote:
--On Tuesday, August 11, 2015 22:56 +0100 Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
On 11/08/15 22:43, Joe Touch 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
(I assume s/1918/1984/g.)
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.
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.
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'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.
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,
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
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.
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.