On Thu, Sep 16, 2010 at 6:13 PM, Joel M. Halpern
Two very different kinds of questions occur to me, reading this.
Firstly, the one really good thing about our current draft advancement
process is that we go look carefully and figure out what pieces of the RFC
have not been implemented. Given that this takes work, it is unlikely to be
raised in a verifiable fashion during a "call for objections." There is a
big gap between "I didn't implement that part and I don't know anyone who
did" and "no one implemented that part." While getting the removals right
takes work, it is also a very good thing.
You're right that it takes work, and, sadly, it mostly doesn't happen
as a result. It's a good theory, but the practice has diverged in
the common case.
With this procedure in place, any member of the community can
say "This has bits that didn't get implemented by anyone"; if someone
then steps forward to shepherd the document through the objection,
the issue may be resolved (by demonstrating that others did or by producing
a new document that doesn't contain those pieces). If no one is willing
to work through the objections, the default assumption is that the first
speaker was either right or is working on something no one else cares about
much. That holds the doc at its current level, which leaves us no worse
off than where we are now.
Secondly, I can not tell what constitutes a legitimate objection. I presume
"I don't like this protocol" is not a relevant or useful objection. Even "I
think the protocol should have made a different design choice," which is
actionable, would seem to be inappropriate. You seem to imply that there are
some things beyond errata that are appropriate. But I think we need rather
more clarity on what those might be. Was it your intention to spell those
out later, iff the community is interested in the basic idea?
Actually, I was thinking in terms of the IESG's current "discuss criteria", but
it shouldn't ever be spelled out too far in my opinion; it requires
But I thoroughly agree that "I don't like this protocol/design choice" is not
valid, and would be quickly dispatched by an IESG considering it.
Adapting the discuss criteria (or something like it) would be useful guidance,
and it this gets sufficient traction, it certainly could be done.
Thanks for reading the doc,
On 9/16/2010 8:53 PM, Ted Hardie wrote:
On Thu, Sep 16, 2010 at 5:40 PM, Thomson, Martin
The current process involves a (weak) proof of interoperability to
advance; interoperability is not even mentioned in this draft. Is that
rather significant change intentional? Or did you want negative
interoperability reports ("Vendor A is doing it wrong, so the spec must
be unclear or have features that are unwanted") to considered
I had a similar question. The proposal seems to suggest that there be no
difference in the requirements or guidelines that a specification must meet
at each stage. Is this intentional? Is it the intent to remove these more
Yes, this is intentional. The current gates for proposed standard are
high. If a doc passes them and no
one finds new issues in two years of use, it is probably done. If
there are issues (filed errata, an ongoing
effort at a -bis, community reaction that it is not really in use), I
think two years will probably find them
well enough for a draft designation (and five for full).
Just my two cents,
If that is not the intent, then there still needs to be some definition
of what is expected of a specification at a particular maturity such that
objections can be assessed by the IESG.
Ietf mailing list
Ietf mailing list