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

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

 



Hi Ted,

[Bcc to the person quoted in this message]

At 16:01 20-09-10, Ted Hardie wrote:
For protocols where interoperability with others' implementations is
important for your customers'
view of your product, there is probably enough benefit to get the
involvement; if you look bad because
other people aren't able to read the spec, you have some incentive.
But that may no longer be the
common case.

Yes.

I understand that "objection based processing" was not the most polite
way to word this in my draft,
and I'm sufficiently chastened to change it in the next version.  But

The term you used was clear and it got the idea through.

I think any system we base on a periodic
assessment like the above has to have a default of "advance".  The

Setting a default of "advance" encourages objection instead of support. This might encourage an adversarial model. It may already be happening within the IETF as strong discontent could be viewed as such.

current Proposed standards
get a lot of scrutiny and generally are pretty good.  If we don't do
"default advance", we are adding
friction to the common case, where they should move forward.

Implementation reports used the "default advance". These documents do not get a lot of scrutiny. I don't know the number of Proposed standards that fall through the cracks.

We also have the much harder task of judging the consensus on
documents based on what is likely
to be small amounts of commentary.  That's tough, but getting more
than small amounts is
likely going to be substantial amounts of work.  For substantial

Yes, on one hand the person determining consensus asks for commentary but he/she don't want too much commentary as it turns each document into too much work then.

amounts of work, our current
criteria for draft are much cleaner: two interoperable implementations
from different code bases and license
grants.  For the record, I still think that it useful data to have,
but my personal read is that the community
as a whole doesn't see the value in it for things that work.  So the
common case stays at proposed.
Things get moved up when they're already being pruned of things that
didn't work or because some
external force requires them to.

You can placate some vendors by throwing in some features or rewriting the base specification in such a way that the change becomes an intrinsic part of it. That makes pruning a near-impossible task.

Maybe a single stage with revisions at that stage is all we really
need.  But I suspect the opportunity to raise and
resolve issues would be valuable, especially if the "default advance"
attracted the attention.

The current situation is a "single stage". It is based on RFC branding. It might work as follows:

 1. Coax or harass AD to get sponsorship for the I-D.

 2. Push proposal into a WG and let it simmer for some time, if applicable.

 3. Last Call the I-D.  If the author is unlucky, he/she might come across
    strong opposition to the proposal.

 4. Pray that a member of the IESG does not raise a DISCUSS.

 5. Make the changes to address imperial edict, if applicable.

 6. Declare victory when RFC is published.

There isn't any incentive to advance to Draft as:

 (a) It's not common practice.

 (b) The author does not even know that Draft exists.

 (c) The author does not need more grief.

There seems to be an assumption that there is widespread agreement on what the documents represent, i.e. consensus. If that assumption holds, it is simply a matter of defining the mechanics. draft-hardie-advance-mechanics-00 focuses on the mechanics for advancement of documents along the standards track. Whether I agree with it or not is inconsequential as it has the merit of putting an idea into words to "fix" the statu quo. If not changing the current state of affairs is the worse outcome, would people who do not support the proposal change their stance from "objecting" to neutral?

I may be taking the off-topic ramp or it may be read as an attempt to derail this proposal by getting into the mechanics of consensus. Nevertheless, I'll quote a person that is participating in an IETF WG for the first time:

"I leave to the Chairs of this WG the right to dismiss them [the comments made],
   and I'll accept it if that happens." [1]

Would the mechanics of consensus work better if a participant takes such a stance and send substantive comments? Does a "+1" mean that a participant has actually read and understood the proposal? In other words, would it be better if participants explained why they support a proposal?

I'll re-purpose some text from BCP 27:

  The "standards of evidence are materially beyond what can be reasonably
  accomplished".  A pragmatic approach is to leave it to the advocates to
  make a convincing argument that the specification fulfills the
  requirements.  The "specific way to make the argument is left to the
  advocate".

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/vwrap/current/msg00256.html
_______________________________________________
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]