--On Wednesday, August 28, 2013 07:21 -0700 Dave Crocker <dhc@xxxxxxxxxxxx> wrote: >> RFC 5507 primarily raises three concerns about TXT records: > > RFC 5507 is irrelevant to consideration of the SPFbis draft. > > Really. > > RFC 5507 concerns approaches to design. However the SPFbis > draft is not designing a new capability. It is documenting a > mechanism that has existed for quite a long time, is very > widely deployed, and has become an essential part of Internet > Mail's operational infrastructure that works to counter abuse. >... Dave. I may be violating my promise to myself to stay out of SPF-specific issues, but this does not seem to me to be an SPF-specific issue. I suggest to you that the notions of IETF change control and consensus of the IETF community are very important to the integrity of how the IETF does things. The question of where and how the IETF adds value comes in there too. If some group --whether an IETF WG or some external committee or body-- comes to the IETF and says "we have this protocol, it is well-tested and well-deployed, and we think the community would benefit from the IETF publishing its description" that is great, we publish as Informational RFC (or the ISE does), and everyone is happy. If that group can get IETF community consensus for the idea that the spec should get a gold star, someone writes an Applicability Statement that points to the other document and says "Recommended", we push any quibbles about downrefs out of the way, and we move on. However, it seems to me that, for anything that is proposed to be a normal standards track document, the community necessarily ought to be able to take at least one whack at it on IETF LC. That "one whack" principle suggests that one cannot say "this was developed and deployed elsewhere and is being published as Experimental" (which is what, IIR, was one thing that happened in the discussion of 4408) and then say "now the design quality of SPF is not a relevant consideration because it has been considered elsewhere and widely deployed". If the IETF doesn't get a chance to evaluate design quality and even, if appropriate, to consider the tradeoffs between letting a possibly-odious specification be standardized and causing a fork between deployed-SPF and IETF-SPF, then the IETF's statements about what its standards mean become meaningless (at least in this particular type of case). Now I think it is perfectly reasonable to say, as you nearly did later in your note, that SPF-as-documented-in-4408bis is sufficiently deployed and would be sufficiently hard to change that the community should swallow its design preferences and standardize the thing. One can debate that position, but it is at least a reasonable position to take. Modulo some quibbles, it probably the position I'd take at this point if I were willing to take a position, but it is different from saying "can't discuss the design choices". Things would also be very different if the present question involved updating or replacing an existing Proposed Standard. If design decisions were made in that earlier version (and that went through IETF LC and got consensus), I think it would be perfectly reasonable to say "the IETF community looked at that before and it is now too late". You've done that before, I've done it before, and I don't think anyone who isn't prepared to explain why, substantively and in terms of deployment, it isn't too late should be able to object. But, in the absence of demonstrated and documented IETF consensus --independent of WG consensus, implementation consensus, deployment consensus, silent majority consensus, or any other type of claim about broader community consensus-- I don't think one can exclude a discussion of a specification's relationship to various design considerations, if only because "that may be deployed but the IETF should not endorse it in that form by standardizing it" or even "if the community that is advocating this won't allow design issues to be discussed, then there is no IETF value-added and the IETF should decline to standardize on that basis" have got to be possible IETF community responses. > To consider RFC 5507 with respect to SPFbis is to treat the > current draft as a matter of new work, which it isn't. No, it is to treat the current draft as a matter of work that the IETF is being asked to standardize for the first time... which, as far as I can tell, it is. I think those distinctions about standardization (including the value-added and change control ones) and what can reasonably be raised on IETF LC are important to the IETF, even for those who agree with you (entirely or in part) about what should happen with this particular specification at this particular point. YMMD. best, john