Re: Discussion of draft-hardie-advance-mechanics-00.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.Thomson@xxxxxxxxxx>  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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]