So far, I've just held the DISCUSS ballot that's been the formal process to keep this discussion open. It's time to start paddling the oar that I've stuck in. It seems that there are still three points that Dave has: 1. A general point: the document doesn't seem to have had the review and scrutiny that one would expect for a significant process change. 2. Simple duplication of text from 2026 (in Section 3.2) is not a good idea, as it invites future divergence. 3. Section 4 should be removed, as it weakens the statements made elsewhere in the document and invites criticism, and is in effect self evident anyway. To point 1, I have a couple of notes in response. I agree that this is a formal process change -- some say it's not, but is only documenting what we already do, and I think that's ignoring the fact that, notwithstanding that, this document *does* change the formal definition of what Proposed Standard means. It doesn't matter that it's "merely reflecting reality"; it's still a formal change. That said, I believe that the light volume of comments is because (1) it *is* reflecting reality, and that's mostly not controversial and (2) a lot of this was discussed when RFC 6410 was being developed, and these changes are really artifacts of that discussion (which did not lack in participation). Further, the document has been out here for discussion; the opportunity has been here, and IETF folks aren't normally shy if they have things to say. So, while I understand Dave's concern, I don't share it. But Dave goes on: > 2. I also wonder whether we shouldn't circulate the draft more > broadly, outside of the IETF, to request the comments. Will it accomplish > what we want it to accomplish? We could post it to the new-work mailing list, or explicitly send it out through our liaisons. It's likely, I think, that it would get little attention that way, though we won't know unless we do it. On the other hand, we don't normally send our process documents out that way -- we didn't do that with the draft that became 6410, for example. I have no objection to soliciting external reviews and comments, but I'm doubtful that it'll be useful. On point 2, Olaf says this: >> There was a suggestion to remove the characterization of Internet >> Standard (for completeness) I think that is a matter of taste and not >> of content. I think that's not really addressing the core of Dave's concern, which isn't that the repetition is unnecessary (which would be a matter of taste), but that it's actually harmful, in that future changes could leave us with two divergent definitions of "Internet Standard". On this, I'll note that we're already somewhat along that path, as 6410 quoted text from 2026 in its definition of "Internet Standard". And I'll also note to things along that line: a. 6410 tweaked the definition of Internet Standard, in order to merge in aspects of Draft Standard. That this document quotes 2026 without also bringing in the changes from 6410 somewhat misstates things (in a small way, but nonetheless...). b. 6410 had the opportunity to do the same thing, copying the definition of Proposed Standard (which it did not change) from 2026, and it didn't do it. Instead, it said this: The stated requirements for Proposed Standard are not changed; they remain exactly as specified in RFC 2026 [1]. No new requirements are introduced; no existing published requirements are relaxed. I suggest that that's a better approach, and would suggest that Section 3.2 would be better done this way: The stated requirements for Internet Standard are not changed; they remain exactly as specified in Section 2.2 of [RFC6410], as it updates Section 4.1.3 of [RFC2026]. On point 3, I'll note that Section 4 is in this document exactly in response to my comments. I was concerned that as this document tightens the formal criteria for PS, it's likely to cause even more strictness in IESG approval. We've always had the option (and have not infrequently exercised it) to approve a document at PS that *does* have known limitations. This is from Section 4.1.1 of RFC 2026: A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. Without Section 4, I believe we are removing the option that the second sentence gives the IESG, and I want to be absolutely sure we want to do that, before we do. It's my opinion that we don't want to remove it, and that's the purpose of Section 4. > My concern about section 4 is that it only serves to invite criticism of > IETF documents. The statements in Section 4 really apply to all technical > specifications and all organizations that publish them. We never achieve > perfection and we always reserve the right to produce a better version. I believe that Section 4 is saying more than the things that apply to all technical specifications: it's not just saying that they're not perfect and that we might find problems later. It's meant to say that we might, sometimes, approve specifications at Proposed Standard that we *know* to have imperfections and limitations, and we're approving them anyway. And what it's adding to what 2026 says about that is that when we do that, we'll explicitly say so in the document. Perhaps you have a suggestion for different wording, Dave, that will address your concern while still addressing mine? Barry