Re: Tracking resolution of DISCUSSes

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

 



What follows is not something I'm suggesting that we talk about anytime soon, but perhaps we should talk about it someday.


Ralph, I think I've already indicated why I (and others)
believe that systematically posting raw DISCUSSes to lists
would be the wrong move.

    Brian

On 2007-01-15 20:43, Ralph Droms wrote:
Following up on that, I suggest a requirement that any DISCUSSes be posted to that mailing list, along with conversation/resolution of the DISCUSSes.
I would very much like to see those last steps out in the open.

My initial connection with the IETF was the result of people (inside and outside the IETF) trying to interpret one data point (packet loss) that could mean two things (loss due to network congestion or loss due to packet corruption) in TCP. For people who have not suffered through this discussion - you really can't do it, and the only safe assumption is "loss due to network congestion", so the best efforts of our best minds to use a binary indicator to mean three different things have failed.

So, when I see a DISCUSS as the only indicator for at least two conditions - "we need to talk about this", and "not as long as I'm an AD" - I'm thinking we're causing problems for ourselves that we could fix.

I would NEVER say that ADs ballot DISCUSS casually, but I would say that ADs do think that a DISCUSS ballot is about having a discussion. ADs ballot DISCUSS for a variety of reasons described in previous postings, which can include anything from "major NIT - looks like a cut-and-paste in the IANA section, with the same value given to two different usages" - all the way to "violates basic laws of physics".

Since a document will not advance without the DISCUSS being resolved (there are various ways to do this), document editors are a lot more likely to freak out when they have a document that collects a DISCUSS ballot, and this is not good because people stop DISCUSSing and start negotiating - "my boss is waiting to see if I've wasted my on-clock time working on this document, what do I need to change for you to remove your DISCUSS?" being one example of the problem.

Not all editors fold up like cheap furniture when they see a DISCUSS, but some do. That's not good.

At the very minumum, DISCUSSes before a telechat are not as "interesting" as DISCUSSes that have persist more than a month after a telechat. The ADs really do work to remove DISCUSSes before telechats, and during telechats. At this stage, a DISCUSS is probably of interest to document editors and shepherds/WG chairs, and probably not of much interest to anyone else.

After the ADs have taken their best shot, if the ballot positions still include one or more DISCUSSes, that's really interesting to the entire working group, and if other working groups or external SDOs have dependencies on the balloted documents, it's interesting to them, too.

But all we know is that the document collected a DISCUSS, unless we start reading free-form text, so we can't easily tell how serious the problem was for the document.

It is too late to change the way TCP works (believe me when I say this!), but it may not be too late to change the way DISCUSS works.

And maybe the new General Area director could think about this, at some point.

Thanks,

Spencer

p.s. I had a longer exchange about why DISCUSS was like TCP with Dave Crocker in private e-mail. If you don't have a sense of humor, please stop reading now...

- We have two problems we want to know about, and how you respond depends on the problem you're having, so one indicator doesn't tell you everything you need to know.

- TCP is designed to bend over backwards to be friendly to the infrastructure, at the expense of throughput.

- the TCP design is specifically not intended to provide timeliness...

- but with DISCUSS, active agents are people rather than cpus, so the small matter of human reactions messes things up.


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

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