On Sat, Sep 13, 2014 at 5:06 PM, Michael StJohns <mstjohns@xxxxxxxxxxx> wrote:
- As far as I understand, Murray is proposing "no change in effective behavior" in the first pass, so whether or not we manage to get an RFC through before the next nomcom or not, the publication of a simply updated 3777 is really nothing more than clean up without any change in effect to the current Nomcom, nor in the behavior of any follow-on Nomcom.
Correct, that's the intent.
Â
- Given that there's a real cost (can you say Last Call?) to the community as a whole for each and every RFC action, I'm underwhelmed at the idea of opening up 3777 without making a commitment to actually address its warts.
On the other hand, isn't the cost of an IETF Last Call on what amounts to consolidation of already-approved documents, and nothing else, a fair bit less than the real cost of a typical IETF Last Call on new, updated, or otherwise not-yet-approved work? Given the no changes constraint, the Last Call reviewers only need to confirm that the consolidation was done correctly and the result is still understandable. There's nothing new to debate here.
Have you see an IETF Last Call (humorous rhetorical question)? More seriously, I appreciate your optimism, but empirical evidence (e.g. the 5 or 6 messages with language changes for your draft, as well as every other Last Call in recent history) would suggest that the chances of getting this through last call without pain are slender if not non-existent.
Â
- That's a long winded way of saying no. If there were a pressing need for the current Nomcom, I'd suggest they use the "operational discretion" portion of the document. If there were a well understood set of changes that have been incorporated in practice, but not in documentation, I *might* say yes. Neither of these appear to apply - hence, "No".
I'm on the current NomCom (and was on the last one too), and I think it would be reasonable for me to say that both of them sure thought it would be nice to have had this work done ahead of time. I wouldn't say it's a pressing need, but if one NomCom after the next seems to have the same sentiment, then it's probably work that's due or even past due.
Instead, let me suggest you do the above - but to a specific ID stage. Let the/a Nomcom adopt the operations section of a specific ID as part of their 3777 permitted operational discretion. That deals with the Nomcom's particular problems without the need to deal with the RFC process.
It also leaves the clock ticking as each ID expires after 6 months. That will ensure that instead of just saying "its good enough" we have incentive to go ahead and fix the issues that have occurred.
Â
- To be blunt, we're already... *sigh* splitting nits about the meaning of certain sections, words, word combinations, etc. I'd really rather not go through that more than once every 5 years or so.
By that reasoning, it's time, since RFC3777 is more than ten years old and all but one of the applied updates are at least five years old. I suggest that doing this first will make it easier to do the follow-on work you're suggesting, especially since a diff to this document (when published), and thus to the true current practice, will be very easy to generate.
We didn't open up 3777 to add the interim fixes because it was "too hard". If we're not going to open 3777 up for substantive changes, then I see no reason to publish what is nothing more than a cosmetic reworking of existing and documented practice. It's work for the editor, but more than that its work for the RFC staff, for the IESG, for the IAOC and for the IAB (yup - all have to sign off on it).
Instead, let's do it the right way. Get the Chairs (IAB, IETF and IAOC) to appoint a design team in the general area and provide a page or two of things they think need to be fixed. Solicit the community for any other issues. Draft the first public version of the document to be feature complete for those issues and have text for each approach to solving each identified problem.
-MSK
I do understand the desire to take small bites - I just think you're trying to solve your first problem (Nomcom process) the wrong way.
Mike