Russ
I should explain the reasons why I don’t use an I-D for such things as this consultation. In explaining this, I want to note that I still have a lot to learn, may make some incorrect assumptions and have yet to hear from more than a few people on this, so this is by no means set in stone. 1. Historically, the way that the LLC and the previous IAD have consulted with the community has not been through I-Ds but through documents with freeform structures. Here are some examples that predate me: As this is the process that I inherited and most processes here are carefully negotiated over many years and strongly protected once agreed, I chose to stick with that. 2. Conceptually, the LLC consults on the policies/statements that it needs to document and follow in order to implement the consensus instruction/guidance/delegation it receives from the community in the form of RFCs. The purpose of LLC consultations is for the LLC to receive community input on these proposed policies/statement and the LLC then decides what of that input to incorporate into the published version. This is quite distinct from community consensus and the "decisions are made on mailing lists" practice that is a fundamental part of that model. As you’ll see in John’s reply to your message this is already a matter of confusion for some. I see it as important that we manage that confusion by separating out both the process for determining community consensus from the consultation process used by the LLC, and the form of the documents and outputs of that process. We can then be clear that community consensus, which by its very nature instructs/guides/delegates to the LLC, follows the "I-D -> mailing list decisions -> consensus -> RFC" path, whereas LLC decisions on how it will implement that consensus follow the "proposal -> consultation -> LLC decision -> publication" path. 3. Practically, the output of these consultations is generally some form of policy/statement that is published on the IETF website and so the consultations consist of two "documents", the transient consultation wrapper and the substantive proposed text that moves towards temporary permanence until it is further reviewed and amended. This is different from the I-D process where either the whole document is transient as it automatically times out, or it proceeds to genuine permanence as an RFC. Neither of those paths fit with the way the output of an LLC consultation is used. If we use an I-D that times out while the substantive text inside it is published then that could be misleading to those picking up on the process later. The alternative of the I-D progressing to an RFC is equally problematic as the sorts of policies/statements the LLC consults on will change more regularly than the RFC process is designed for, and more importantly, it is a core part of the LLC construct and my role in particular that the LLC should not have any influence over the standards setting process which becomes messy if the LLC relies on that same process for its own operational policies. Finally, I would certainly be willing to try and put more structure around our consultations, our policies/statements and even our engagement generally. Someone not too far from this conversation once suggested that had Internet Operational Notes (RFC4693) worked out and still been in use today then we could square this circle by the LLC drafting and issuing those. Jay -- Jay Daley |
