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.farrell@xxxxxxxxx> 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.