Subject: Re: SMTP draft -09 WG last call

From: Chris Newman <[email-masked]>
Date: Sun, 07 Feb 1999 21:03:40 -0800 (PST)

On Mon, 25 Jan 1999, Chris Newman wrote:
> This is a WG last call on the SMTP draft -09.  Please take the time to
> review this draft and send editorial changes to the editor.  If there are
> any substantive open issues remaining, please post them to the list.  If
> at least four people support a proposed substantive change, it will be
> open for debate; otherwise we will assume rough concensus for the current
> technical state of the draft.
> 
> The WG last call will end in one week (Feb 2).

There were lots of comments on the last call, so it is likely a new
document revision is needed.  Unfortunately, there are over 100 messages
which need to be distilled into a list of specific changes to the document
(excluding comments failing to meet litmus test above).  This would
normally be my job, but I have jury duty this week so I have an
unpredictable schedule.

Would a neutral party (e.g., someone who didn't express strong opinions
during the debate) be willing to take a crack at a single short list of
specific document changes from the past 100 messages?  This could save a
lot of time.

		Thanks,
		- Chris

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Feb 1999 08:29:41 -0000

John Klensin's editorial policy for smtpupd is to make changes _without_
prior approval from DRUMS. This has given his own changes an advantage
over changes from everyone else; people who disagree with him have had
the burden of reviewing several different drafts of a poorly structured
27000-word document. Very few people have had the time to do this.

Chris Newman announced a one-week Last Call on smtpupd-09 on 25 January.
A few days later I sent 18 objections to the mailing list:

   * 9 objections to poorly written text that accidentally prohibited
     or discouraged common, well-known, beneficial features; and

   * 9 objections to troublesome changes that had been added to the
     document by Klensin without DRUMS approval.

Some of Klensin's changes had _already_ been rejected by DRUMS.

Newman stated a policy formulated at the December IETF meeting: he would
assume consensus against any objection that wasn't stated by four
people. But what does this mean for issues where there was never
consensus in the first place?

I posed a question for Newman after one of my objections: ``In cases
like this, where DRUMS has _already_ agreed that the document should be
changed, are you still demanding that four people speak up?'' He didn't
respond.

Over the remaining few days of the Last Call period there were several
dozen messages commenting on my objections. Some issues were discussed
heavily; others, apparently lost in the flood, weren't discussed at all.
This document obviously has too many problems to be solved in one week.

Now Newman has asked someone to prepare a summary of the discussion,
excluding objections that weren't raised by four people. He hasn't
stated that there will be a new Last Call period. And he still hasn't
answered my question.

---Dan

---

From: Keith Moore <[email-masked]>
Date: Mon, 08 Feb 1999 09:31:58 -0500

> prior approval from DRUMS. 

There is no process rule that requires an author to have prior approval
before putting something in a document.

Working groups are good at sanity checking, but not very good at synthesis.
This means that on many issues the document's authors have the burden of 
figuring out what is likely to be approved by the working group, and the
working group has to decide whether they like it.

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Feb 1999 17:26:28 -0500 (Eastern Standard Time)

> working group has to decide whether they like it.

Indeed.   As I have explained several times, the editorial 
process that I've followed, in an attempt to get things to 
a conclusion in faster than geological time is, more or 
less:

 * If a consensus emerges --at a meeting or on the list-- 
around particular text, and that text fits, it goes in.  
If, in my judgement as editor, the text would further 
complicate an already-too-complex and inconsistent writing 
style, I try to paraphrase it so that it does fit in.

 * If, as is more often the case, we apparently have 
consensus on the general nature of a fix, but not text, I 
will try to make up some text that I think reflects that 
consensus/conclusion.  When I can't figure out how to do 
that to my satisfaction, I ask for text on the list and/or 
in informal inquiries and, usually, _nothing_ goes in until 
some text emerges from somewhere.  This, in addition to 
some plain errors and accidental omissions (see below), is 
a major reason why some apparent agreements about what 
should be done have not been reflected in the 
immediately-subsequent draft.

  * Unfortunately, we frequently --subjectively, still more 
often than in the cases above-- have situations in which it 
is clear, from logic or consensus, that the text is 
ambiguous, plain wrong, or permits alternate 
interpretations that would interfere with interoperability 
if the wrong options/interpretations were used in 
combination.  In those situations, I have tried to make up, 
and insert, strawman text.  A private note, or a personal 
observation, pointing out ambiguous or inconsistent text, 
if persuasive, is sufficient to get the text changed -- I 
don't wait for a WG vote, although WG consensus that change 
was not desirable would certainly cause the change to get 
undone.   In the overwhelming majority of these cases, I 
have no strong personal preference between "A" and "not A", 
although I do have a strong preference (and believe that 
the DRUMS charter requires) that we make a choice and 
document it.  So the strawman text is just a mechanism for 
focusing WG attention on the issue and one possible 
solution.  If I get it right (deliberately or 
accidentally), we save a bit of time, but the main thing is 
to get something written that can be discussed and 
consensus determined.

And "section X" has been used, to the best of my ability, 
to document changes that I believed were substantive and/or 
potentially controversial and to focus the WG's attention 
on them.  There has been no attempt to "slip anything by"; 
I just don't work that way.

All of that said, the process has not been infallible and 
there have been errors, omissions, slip-ups, and things 
that have fallen through the cracks.  I, perhaps 
unfortunately, don't have a job that permits me to give 
this my undivided attention for days at a time, or to 
generate (or frequently even read) dozens of email messages 
a day on the subject.  Like many other types of systems, a 
sufficiently high noise to signal ratio can simply 
overwhelm me to the point that I go off and do something 
else for a while and, occasionally, things have just gotten 
forgotten when that has occurred.  I apologize, but that is 
how it is and I have to rely on the WG to help catch those 
things and remind me.   And, as I've indicated before, I 
just don't read abusive notes.

So that is it.  If there is something in the text that 
someone doesn't like, and it doesn't represent a horse that 
has been kicked to death many times over, let's raise it 
with the WG --ideally with proposed substitute text so we 
all know what we are talking about-- reach some sort of 
conclusion, and move forward.

    john

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Feb 1999 10:10:17 +0800

John,

You are among the more compulsive responders to input, and you are quite 
explicit that you view it as part of your duty to be that way, by virtue of 
holding a formal position in the organization, in this case editor of a 
relevant document.

With respect to technical input your view makes sense, although the burden 
it places on you can be -- and in this case, has been -- onerous.  That's 
why I think it is equally reasonable to do some filtering, though one must 
then debate how much.

With respect to personal attacks, including process challenges, let me 
claim that you do NOT need to pursue the matter unless and until there is a 
formal request from the management hierarchy.

My reason is simple:  Such attacks can and do become a deprivation of 
service attack, as well as being horribly painful.  Unless there is further 
indication that the challenge has legitimacy, the target of the challenge 
should not feel obligated to respond.  The target probably has much better 
things to do with their time, and the nature of the challenge does not 
pertain to the actual content of the work.

In this case, you are very unlikely to have to spend that energy, because 
the complaint against you is so thoroughly bogus.  Perhaps the IESG will 
wish to query you.  In this case, I doubt they will see the need.

The DRUMS working group has been run quite well and has operated over a 
long period of time, with only one participant claiming (rather regularly, 
but without any other participants supporting the claim) that those in 
charge are making process errors.  In fact it is worth noting that the 
claim is that each and every person in charge is making constant process 
errors.  (I think the operative word, here, is paranoia?)

Hence if you sit back and let others handle the complainant, I believe the 
problem will go away.  It is a small amount of buffering we can offer to 
those who put in the community work which exposes them to this sort of 
bogus fire.

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
PRESIDENTS DAY OPEN HOUSE, 2/13
<http://www.brandenburg.com/misc/presday/presday-invite.gif>

Dave Crocker                                       Tel: +60 (19) 3299 445
<mailto:[email-masked]>             Post Office Box 296, U.P.M.
                                         Serdang, Selangor 43400  MALAYSIA
Brandenburg Consulting
<http://www.brandenburg.com>                       Tel: +1 (408) 246 8253
Fax: +1(408)273 6464             675 Spruce Dr., Sunnyvale, CA 94086  USA

---

From: "D. J. Bernstein" <[email-masked]>
Date: 12 Feb 1999 06:35:40 -0000

> around particular text, and that text fits, it goes in.  

Your document says that SMTP clients ``MUST'' wait for the QUIT reply.

The working group told you to change that to ``SHOULD.''

You didn't.

I asked the DRUMS chair whether four people had to state this objection.
He ignored my question.

The DRUMS chair then asked for a summary of the discussion, excluding
objections that hadn't been stated by four people. He's still ignoring
my question.

---Dan

---

From: Brad Knowles <[email-masked]>
Date: Fri, 12 Feb 1999 09:41:57 +0100

On Thu, Feb 11, 1999, John C Klensin <[email-masked]> wrote:

>              In those situations, I have tried to make up, 
>document it.

    I don't know how possible this is at this late stage, but it would be
helpful for me to have some sort of tagging that said something like "[
strawman text follows ]" and "[ strawman text ends ]", so that I have
some idea as to what has been argued about before (and hopefully some
sort of consensus has arisen) and what is a relatively new proposal that
might need some attention focussed on it.

    Other than that, I have to say that I think you've done an excellent
job on a very hard (and obviously totally thankless) task, and everyone
in this WG, the IESG, the IETF, and the International standards community
as a whole owes you a great deal of gratitude.  All I ask is that you
don't ask me to take over for you.  ;-)

-- 
  These are my opinions -- not to be taken as official Skynet policy
 ____________________________________________________________________
|o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|
|o| Systems Architect, News/mail/FTP Admin   Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49         B-1140 Brussels       |o|
|o| http://www.skynet.be                     Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
                The Sky is no longer the limit

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Feb 1999 18:49:54 +0800

>some idea as to what has been argued about before (and hopefully some

Brad,

The problem of documenting the history of argumentation is real and 
difficult, but it is something separate from the specification, itself.

In any event, what is essential to distinguish "at this late stage" is the 
difference between "it would be helpful" and "it is essential for basic 
viability".  Given your use of the former term, the response needs to be 
"save it for the revision or a later document".

d/

---

From: John C Klensin <[email-masked]>
Date: Fri, 12 Feb 1999 12:33:05 -0500

> might need some attention focussed on it.

I'll see what I can do for -10.  Tried something like that for a
while, but it just got too messy relative to just trying to 
point the changes out in section X.1 (and to call special 
attention to the really serious ones in X.2 and email notes to 
the list).

Thanks for the kind words.

    john