At 01:09 AM 9/14/2014, Murray S. Kucherawy wrote:
On Sat, Sep 13, 2014 at 5:06 PM, Michael StJohns
<<mailto:mstjohns(_at_)comcast(_dot_)net>mstjohns(_at_)comcast(_dot_)net>
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