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.
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?
Yours,
Joel
On 9/16/2010 8:53 PM, Ted Hardie wrote:
On Thu, Sep 16, 2010 at 5:40 PM, Thomson, Martin
<Martin(_dot_)Thomson(_at_)andrew(_dot_)com> wrote:
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
objections?
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
conditions?
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,
Ted
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.
--Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf