Subject: Re: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 1 Sep 2006 11:02:32 GMT

In <[email-masked]> Harald Alvestrand <[email-masked]> writes:

>I believe we have reached a resolution of all issues raised at WG Last 
>Call time against draft-ietf-usefor-usefor-08, and 
>draft-ietf-usefor-usefor-09 has been published.

>As I said in my June 27 message concerning the processing of Last Call 
>issues, I'm hereby issuing a poll for determining whether we have WG 
>consensus that the issues have been resolved and the document can be 
>sent to the IESG for processing.

>I'm hereby asking the WG members to say that they regard one of the 
>following statements as true (filling in details as necessary):

I am saying E - in effect a "write-in" vote for agreeing that it is
correct, and then keeping it on ice until at least USEPRO is done.

If that is not acceptable, then I vote for A:

>A - The specification has resolved all the issued raised at Last Call. 
>It is ready to be sent to the IESG.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 08 Sep 2006 03:32:11 -0700

You now have 6 days to state your opinion, if you have not already done so.
I'll list the opinions of all the people I have received opinions from 
soon after Sept 14.

                      Harald

Harald Alvestrand wrote:
> B - The specification has not resolved an issue raised at Last Call. 
> It's critical that this should be resolved before passing it to the 
> IESG. The issue number is #......
>
> C - The specification has a fatal technical error, not raised at Last 
> Call, and it is critical that this should be resolved before passing 
> it to the IESG. The error is....
>
> D - This effort is futile, we should abandon the document and close 
> the WG.
>
> E - I do not agree with any of the above statements, and wish to say ....
>
> This poll will close two weeks from now, on Thursday, September 14, at 
> 07:18 GMT.
>
> For the chairs,
>
>                       Harald Alvestrand
>
>
>

---

From: Ken Murchison <[email-masked]>
Date: Fri, 08 Sep 2006 08:30:20 -0400

> It is ready to be sent to the IESG.

The few nits from Charles and Frank notwithstanding, I believe the 
document is ready.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 13 Sep 2006 08:53:35 -0700

Half a day. The number of comments is still relatively low.

                     Harald

Harald Alvestrand wrote:
>> I believe we have reached a resolution of all issues raised at WG 
>> Last Call time against draft-ietf-usefor-usefor-08, and 
>> As I said in my June 27 message concerning the processing of Last 
>> Call issues, I'm hereby issuing a poll for determining whether we 
>> have WG consensus that the issues have been resolved and the document 
>> can be sent to the IESG for processing.
>>
>> A - The specification has resolved all the issued raised at Last 
>> Call. It is ready to be sent to the IESG.
>>
>> This poll will close two weeks from now, on Thursday, September 14, 
>> at 07:18 GMT.
>>
>> For the chairs,
>>
>>                       Harald Alvestrand
>>
>>
>>
>
>

---

From: Richard Clayton <[email-masked]>
Date: Wed, 13 Sep 2006 18:01:58 +0100

In message <[email-masked]>, Harald Alvestrand
<[email-masked]> writes

[chasing, so I've had a look]

#2.1

   The text below uses ABNF to specify restrictions on the syntax
   specified in [RFC2822]; this grammar is intended to be more
   restrictive than the [RFC2822] grammar.  Articles must conform to the
   ABNF specified in [RFC2822].

   Articles must also conform to the restrictions specified here, both
   those that are expressed as text and those that are expressed as
   ABNF.

just keeps negating itself as each sentence follows the next, so why not
one paragraph saying:

   The text below uses ABNF to specify restrictions on the syntax
   specified in [RFC2822]; this grammar is intended to be more
   restrictive than the [RFC2822] grammar.  Articles must conform to the
   ABNF specified in [RFC2822] and also to the restrictions specified
   here, both those that are expressed as text and those that are
   expressed as ABNF.

#3.1.3

   Implementations MUST NOT generate two Message-IDs where the
   only difference is the case of characters in the <id-right> part.

isn't quite right, someone else might have made it:

   Implementations MUST NOT generate a Message-ID where the only
   difference from another Message-ID is the case of the characters
   in the <id-right> part.

#3.1.4

   A newsgroup component SHOULD NOT consist of digits only and SHOULD
   NOT contain uppercase letters.  Such components MAY be used only to
   refer to existing groups that do not conform to this naming scheme,
   but MUST NOT be used otherwise.

much nicer (and more consistent) as:

   A <component> SHOULD NOT consist solely of digits and SHOULD
   NOT contain uppercase letters.  Such components MAY be used to
   refer to existing groups that do not conform to this syntax,
   but MUST NOT be used otherwise.

#3.2.7

   NOTE: Since clocks on various agents are not necessarily
   synchronized, the <date-time> in this header field may not be
   later than the Date header field, as be expected.  Agents MUST NOT
   alter a pre-existing Date header field when adding an Injection-
   Date header field.

the "may not" is unfortunate... so

   NOTE: Since clocks on various agents are not necessarily
   synchronized, hence the <date-time> in this header field will not
   inevitably be a later value than that in the Date header field.
   Agents MUST NOT alter a pre-existing Date header field when adding an
   Injection-Date header field.

#3.2.9

   NOTE: If the "posting-host" <parameter> identifies a dial-up
   point-of-presence, the "posting-account" or the "logging-data"
   <parameter> may provide additional information about the true
   origin of the article.

I can see nothing special about dial-up, so:

   NOTE: The "posting-account" and "logging-data" information provide
   further ways to identify the article origin when "posting-host" is
   insufficient for that purpose.

Also, given that there is a statement

   Some pieces of information have privacy implications; this
   is discussed in [I-D.ietf-usefor-useage].

The earlier sentence (which isn't about syntax issues):

   "In order to limit the exposure of personal data, it SHOULD be given
   in a form that cannot be interpreted by other sites."

should be completely removed and hence the whole topic of SHOULDs
should be left to USEAGE

#3.2.10

Earlier in #3 it says "The following header fields defined in this
document do not allow comments (CFWS):"  and a list follows.

but References:  uniquely says: " Comments in CFWS between message
identifiers can cause interoperability problems, so comments SHOULD NOT
be generated, but MUST be accepted."

Is this because people currently create them ?  Why not just ban them
here as well using the general ban in #3 ?  What's the value of this
special status for References ? This just complicates to no purpose :(

#3.2.13

I still strongly believe that the structured format for User-Agent is
whistling in the wind. This is branding, not protocols! Since it doesn't
affect interoperability it should be removed.

Also, in several places  "comments" should become "<comment>s" for
consistency, and to avoid any possible confusion with <comments>  :) In
fact, a general sweep through ensuring that syntactic elements are
enclosed in angle brackets when appearing in commentary would be
extremely desirable.

>>> E - I do not agree with any of the above statements, and wish to say 

the above things need fixing, my apologies if any of them are too
repetitious. Once fixed then I'd move to an (A)

I'm still not impressed by all the chattiness and random use of similar
words for subtly different activities.  If the IESG responses are along
those lines than I think I'd feel like (D).

- -- 
richard @ highwayman . com                       "Nothing seems the same
                          Still you never see the change from day to day
                                And no-one notices the customs slip away"

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 13 Sep 2006 20:14:47 +0200

Richard Clayton wrote:
 
 [comments between referenced Message-IDs] 
> Is this because people currently create them ?

AFAIK it's because 2822 allows this before mail2news gateways.

> This just complicates to no purpose :(

If we ban it completely gateways have to strip these comments
(or trust that nobody uses them).  On the other hand a UA for
mail and news has to support them.  Why would that be better ?

Frank

P.S. about 3.2.13, of course it's whistling in the wind, but
just saying <unstructured> isn't really better.  I prefer to
keep it as is (= derived from HTTP), but adding a note that
this might turn out to be a case of wishful thinking is okay.

---

From: [email-masked] (Ralph Babel)
Date: Thu, 14 Sep 2006 00:34:27 +0200 (CEST)

> I'm hereby asking the WG members to say
> that they regard one of the following statements
> as true (filling in details as necessary):

The correct answers are B, C, D, and E.

> This poll will close two weeks from now,
> on Thursday, September 14, at 07:18 GMT.

Without reasonable deadlines for internal review, these
issues probably need to be dealt with outside this WG -
naively assuming that anyone will still care at that point.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 13 Sep 2006 23:58:07 -0700

Richard,

Richard Clayton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
>   
.... nits removed....
> repetitious. Once fixed then I'd move to an (A)
do you regard any of the things you listed as FATAL TECHNICAL ERRORS?

I'm sorry - but the Last Call, where it was appropriate to raise issues 
of nits and style, was sent out on May 25, and closed on June 8. It is 
now 3 months later.

If we're EVER going to close on this document, at some point, the chair 
has to say "No more small changes are going to be accepted".
> those lines than I think I'd feel like (D).
I would certainly feel like that too, in that case....
> -----BEGIN PGP SIGNATURE-----
> Version: PGPsdk version 1.7.1
>
> iQA/AwUBRQg5hpoAxkTY1oPiEQLeIwCg/IDweWefEKYKbVZsQpXgCc5HawIAmgNh
> 2u1Zo0MZLNth1I7xsX/iVANL
> =19Dk
> -----END PGP SIGNATURE-----
>
>

---

From: Richard Clayton <[email-masked]>
Date: Thu, 14 Sep 2006 11:52:48 +0100

In message <[email-masked]>, Harald Alvestrand
<[email-masked]> writes

it's very confusingly expressed and could mislead

a nit

a nit

the use of an uncapitalised "may not" is poor quality

the concentration on dialup (rather than dynamic IP address allocation)
may lead the naive into traceability problems

>>   in a form that cannot be interpreted by other sites."

this sentence requires a change to many server systems which may not be
in the least bit appropriate for some of them anyway. That's a flaw both
on the wire and in the split between the concerns of this document and
USEAGE

the References: issue was answered by Frank. I withdraw this one.

the structured field for User-Agent remains a flaw. There's absolutely
no processing reason for requiring this structure, nor can I envisage
one :(

>>consistency, and to avoid any possible confusion with <comments>  :)
>>In fact, a general sweep through ensuring that syntactic elements are

IMHO, this is indicative of the general quality of the document :(

>has to say "No more small changes are going to be accepted".

I understand your frustration, and in particular I apologise to you and
to the group for not having found the time to look at the document until
right on the deadline. 

Most of the changes should be completely uncontroversial, but the two
which are not : the "posting-account" obfuscation and User-Agent
structure I have raised before -- I, probably unwisely, didn't bang on
about them. So if you rule them closed, so be it.  Fixing them wouldn't
raise the quality of the document -- merely make it more accurate in
describing the current approach to what appears in header fields.

- --

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 14 Sep 2006 15:31:08 +0100

Harald Alvestrand wrote:

>>> have WG consensus that the issues have been resolved and the 
>>> document can be sent to the IESG for processing.
>>>
(As a contributor) There are some minor issues from Richard Clayton that
I think should be addressed. But as far as I am concerned none of them
is a showstopper. So I am for (A).

>>> C - The specification has a fatal technical error, not raised at 
>>> Last Call, and it is critical that this should be resolved before 
>>> passing it to the IESG. The error is....
>>>

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 14 Sep 2006 11:01:36 -0400

So, will the chair accept this entry to a poll after an arbitrary
deadline, but not relevant comments from Mr. Clayton because they
are after an arbitrary deadline?

Since we are outside our charter, then I suppose anything goes.

 > Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])
           by rufus.isode.com (submission channel) via TCP with ESMTPA
           id <[email-masked]>; Thu, 14 Sep 2006 15:31:09 +0100
[snip]

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 15 Sep 2006 09:58:02 GMT

>[chasing, so I've had a look]

Whilst I think most of Richard's emendations are improvements, and might
well get added if ever we have to do another draft, I think they are
unnecessary given that we are at Last Call.

>   Injection-Date header field.

The revised text seems a little awkward. Note that Ken has already
fixed the missing "might".

>I can see nothing special about dial-up, so:

If I say
  posting-host=clerew.man.ac.uk
then that pretty well ties the article down to me. But if I say
  posting-host=80.175.135.89
then all you can establish is that that IP belongs to newnet.co.uk, which
does not help much.

The wording was written in that form (it has been there a long time) just
to emphasise that merely identifying the host making the NNTP connection in
the posting-host parameter would not always be good enough. And yet that
is the way the current NNTP-Posting-Host header is normally used.

>should be completely removed and hence the whole topic of SHOULDs

I tend to agree with you, but that matter was discussed and people wanted
that wording in there, so in it went.

>Is this because people currently create them ?  ...

It is because RFC 2822 defines it that way, and we need a good reason to
depart from RFC 2822 (we had a good reason for Message-ID). And articles
might be gatewayed in from email.

>affect interoperability it should be removed.

We inherited it from HTTP, which is the only protocol to have standardized
that header so far.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 15 Sep 2006 12:38:16 +0100

>is the way the current NNTP-Posting-Host header is normally used.
[as a contributor] I agree, that the text as written is fine.

>that wording in there, so in it went.
[as a contributor] I think it is reasonable to discuss Security 
considerations for different header fields in USEFOR itself.

>We inherited it from HTTP, which is the only protocol to have standardized
[as a chair] I don't hear any rough consensus to support Richard on 
this, so no change.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 15 Sep 2006 12:49:20 +0100

>   here, both those that are expressed as text and those that are

[as a contributor] I like the new text.

>   difference from another Message-ID is the case of the characters

[as a contributor] That looks a bit better.

>   NOT contain uppercase letters.

[as a contributor] Yes, this is more readable.

>  Such components MAY be used to

[as a contributor] Either this or the original sentence is fine with me.

>the "may not" is unfortunate... so

[as a contributor] Indeed, I stumble on it every time I read the sentence.

>   inevitably

[as a contributor] I would change "will not inevitably" to "might not".

[...]

>enclosed in angle brackets when appearing in commentary would be

Chairs discussed this with Ken and decided that the current text is good 
enough. If you can point out specific places where lack of <comment> is 
problematic, we can reevaluate.

---

From: [email-masked] (Ralph Babel)
Date: Fri, 15 Sep 2006 14:49:55 +0200 (CEST)

Charles Lindsey wrote:

> Whilst I think most of Richard's emendations are
> improvements, and might well get added if ever we have
> to do another draft, I think they are unnecessary given
> that we are at Last Call.

| You got that backwards, I'm afraid.
|
| It's not the "stage" that determines what can be done to
| the draft; it's the state of the draft that determines the
| "stage" - and as anybody who doesn't just want to get it
| out the door can see, the draft is in a rather bad shape.

http://www.imc.org/ietf-usefor/2002/Aug/0217.html

---

From: [email-masked] (Ralph Babel)
Date: Fri, 15 Sep 2006 14:49:55 +0200 (CEST)

Forrest J. Cavalier III wrote:

> So, will the chair accept this entry to a poll after an
> arbitrary deadline, but not relevant comments from Mr.
> Clayton because they are after an arbitrary deadline?

You don't seriously expect an answer to this one,
do you? After all, the "chair" didn't answer your
earlier questions either.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 15 Sep 2006 14:32:33 -0400

Richard Clayton wrote:

I've resolved your issues regarding 2.1, 3.1.3, 3.1.4, and 3.2.7; in 
most cases using your suggested text.

> I can see nothing special about dial-up, so:

How about:

NOTE: If the "posting-host" <parameter> fails to identify a fixed host 
(e.g. dynamic IP address allocation), ...

---

From: Richard Clayton <[email-masked]>
Date: Fri, 15 Sep 2006 23:10:40 +0100

In message <[email-masked]>, Ken Murchison
<[email-masked]> writes
>most cases using your suggested text.

Thank you, they look just fine.

If no-one else is going to speak up about User-Agent or the "posting
account" SHOULD then there's clearly no consensus on those issues :(

>(e.g. dynamic IP address allocation), ...

"fails to identify the host" ...     as Yoda might put it, there is no
fixed, only allocations that have yet to change :)

- --

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 16 Sep 2006 01:59:16 +0200

Richard Clayton wrote:

> If no-one else is going to speak up about
[...]
> the "posting account" SHOULD then there's clearly no
> consensus on those issues :(

It's defined to be a "killfile-id".  In theory it would make
sense to move the first SHOULD to USEAGE with the details, as
you've proposed it, but in practice we don't know when USEAGE
will be ready, and it's a serious issue.  No nice compromise,
but I don't think it's wrong.  I'd feel bad about this issue
with no caveat at all.

Frank

---

From: Richard Clayton <[email-masked]>
Date: Sat, 16 Sep 2006 10:06:25 +0100

In message <[email-masked]>, Frank Ellermann
<[email-masked]> writes
>will be ready, and it's a serious issue.  

I don't think that it's an issue whose resolution will be changed by
this document

>No nice compromise,

it does say further down at the end of the section

   It is a matter of local policy which of the above <parameter>s to
   include.  Some pieces of information have privacy implications; this
   is discussed in [I-D.ietf-usefor-useage].

but we pick out just one of the four and put a SHOULD on it. Now I don't
think it's a SHOULD because many other things within the article may
make this irrelevant (and it may, for example, be policy within an
organisation that articles written by employees may not have obfuscated
origins, so requiring their server to obfuscate just one parameter is
just daft).  However, if you really think it's a SHOULD then it seems
entirely inconsistent to apply it to just one header field line

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 16 Sep 2006 22:49:43 +0200

> account" SHOULD then there's clearly no consensus on those issues :(
I think there's no consensus to change, at least..... we've discussed 
this before.
> fixed, only allocations that have yet to change :)
actually the posting-account or logging-data may provide additional 
information about the true origin of the article in all cases, so if we 
want to be logically stringent, the part before the comma adds no 
information...... but I'm fine with Ken's suggestion. It's only a note - 
no behaviour needs to change based on this, and no article is rendered 
conformant or non-conformant by the tweaks to this wording.

                    Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 16 Sep 2006 23:44:45 +0200

> earlier questions either.
I did not see any questions for which an answer would further the 
purposes of the group, so I said nothing.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Sat, 16 Sep 2006 21:13:24 -0400

> purposes of the group, so I said nothing.

I admit that was a rhetorical question, and I expected no answer.

Charters and Rules of Order are not hoops.  If you can't stay
within them, the process is broken and the work product is
invariably flawed.

We are wayyy past charter on the simplest part, USEFOR.  Since USEPRO is
going to be more controversial, on what basis and schedule
does the chair proceed?

---

From: [email-masked] (Ralph Babel)
Date: Sun, 17 Sep 2006 13:28:41 +0200 (CEST)

Forrest J. Cavalier III wrote:

> Harald Alvestrand wrote:
>
>> I did not see any questions for which an answer would
>> further the purposes of the group, so I said nothing.

Let me quote one of Forrest's points you ignored:

| Disband.
|
| Everytime we do an Internal Last Call, people come up
| with about the same number of remaining issues. Those
| familiar with software engineering will notice that
| defect discovery rates that are constant indicate
| there are many, many issues remaining, and that the
| process that produced the product was most likely broken.
|
| Once again I call on the chair to justify continuing this
| WG when we are several years and several chairs passed the
| original charter. The current charter was to complete ALL
| documents by April 2005 or disband. Instead there is no
| current date estimate for even completing the first
| document of three.

By the current charter, this WG has long lost its mandate.
Only two options are left: recharter or disband. Face the
ugly truth. Don't try to wait the criticism out.

> Charters and Rules of Order are not hoops. If you can't
> stay within them, the process is broken and the work
> product is invariably flawed.

Yup. Welcome to Usefor!

> We are wayyy past charter on the simplest part, USEFOR.
> Since USEPRO is going to be more controversial, on what
> basis and schedule does the chair proceed?

Again, don't expect an answer.

---

From: Ken Murchison <[email-masked]>
Date: Sun, 17 Sep 2006 08:35:01 -0400

Richard Clayton wrote:
> Hash: SHA1

I changed it to:

NOTE: If the "posting-host" <parameter> fails to deterministically 
identify the host (e.g. dynamic IP address allocation), ...

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 17 Sep 2006 19:12:30 +0200

I'll answer this one.

A WG that has pushed one document out the door has some basis for 
guessing what it'd take to finish another; with active management, my 
personal guess is about a year for USEPRO. If the management isn't 
active, it won't finish.

A WG that has not pushed a document out the door has no basis for saying 
that it's going to finish another one.

WRT the "number of remaining issues" gibe: While I have not been around 
for the previous Last Calls (and, as I indicated in my reply to some of 
Richard Clayton's comments, I do believe in the "last" word in the name 
of Last Call), I saw no really important technical issues raised at this 
Last Call.

The group has given proof positive that it can find any number of 
wording changes that would result in a slightly better document. So I 
regard it as one of the Chair's important tasks to *stop* such changes 
at one point in the document's lifecycle.

I think this point has now arrived for the USEFOR document.

                        Harald

---

From: Russ Allbery <[email-masked]>
Date: Sun, 17 Sep 2006 10:22:18 -0700

My feeling, from answering public questions about Usenet protocols, is
that having this document published is a clear improvement over having
people continue to rely solely on RFC 1036.  It's still not the standard
that I'd personally like to see, but I think it's what's reasonable to
expect someone to be able to produce given how few resources we have to do
the work and given the controversy.  There are still some bits in it that
I expect to be generally ignored, but there are way more of those bits in
RFC 1036 right now.

Note that this position is independent of whether USEPRO is ever
published.  I'm not horribly optimistic that it will be, but I think the
format specification is useful on its own.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: [email-masked] (Ralph Babel)
Date: Sun, 17 Sep 2006 19:39:09 +0200 (CEST)

Russ Allbery wrote:

> Note that this position is independent of whether USEPRO
> is ever published. I'm not horribly optimistic that it
> will be, but I think the format specification is useful
> on its own.

Yes - even regardless of whether this format specification
ever becomes an RFC, cf. s-o-1036. With all the dangling
forward references to a nonexistent USEPRO, it's not
likely to anyway.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Mon, 18 Sep 2006 11:52:12 -0400

Harald Alvestrand wrote:

> personal guess is about a year for USEPRO. 

Hah.  That's a wish, not an engineering manager's estimate.  This is
not the IWTF.

This is what you wrote on 5/18/2005:  (Yes, 2005!)

 > As far as I can tell from the documents and discussion, the group is fairly
 > close to being able to emit some documents; this is good - but the group
 > has also been working on these documents since 1998 (when I was its first
 > AD, in fact), without finishing any - which is a VERY long time for an IETF
 > working group.

And on 7/1/2005, you wrote:

 > Our plan was to close as many tickets as possible by today, allowing Ken to
 > produce a clean -05 draft reflecting those resolutions, in preparation for
 > a WG Last Call on the usefor document.

And this is what you wrote on 9/4/2005,

 > OK, here's our result on injection-info.
 > A total of 3 people answered. Possible conclusions:
 >
 > - The rest doesn't really care about this bit
 > - The group is tired and doesn't want to form more opinions
 >
 > I can certainly believe tiredness. I did not make the timeline I suggested,
 > and have severely underestimated the amount of time and energy it takes me
 > to get even proposed closure on issues.
 > In terms of value for energy spent, closing the group may be a better
 > alternative.

And now it is 2006.

The chair is capable of seeing there is a process problem here.

If the chair is not able to identify what the problem is and the appropriate
fixes,  the chair should recommend the WG disband, or resign.  Considering
that this is not the first chair to have the same problem, I invoke Drucker:
(paraphrasing....) Any organizational position in which two capable, well 
selected people, failed is unfillable.  The organization must change so that
the position is not part of it.

If the chair can explain why his estimates from this year 2006 will be any
different from last year 2005, then I think we should also consider....

1. Who didn't participate in the poll within deadline, and estimate how many
people will be around a year from now.  John Stanley, Seth Briedbart, Bruce 
Lilly, Alexey Melnikov, Graham Drabble were recent participants, but
did not have the time or inclination to respond within deadline.

2. Of the people who participate, estimate person-by-person how many of those 
actually have real-world experience running or writing production news server 
software.

Remember this from 5/25/2005?  Has the situation improved?

 > So far, about 20 people (out of 49 subcribers) have answered my poll.
 > Most people gave a "range" for their commitment out of my list, so I'm
 > giving "ranges" for how many people are in each category:
 >
 > 1 (glance): 6-3 (pessimist says 6, optimist says 3)
 > 2 (read): 10-8
 > 3 (comment): 4-6
 > 4 (review): 0-3
 >
 > To me, this indicates that we have a serious risk of a shortage of
 > reviewers, but still have some interest..... I hope it's enough to make a
 > decent finish for the documents

3. Out the door is not the same as passing IETF last call.  And since there
is no way to have interoperating implementations without USEPRO, there is no way 
that USEFOR can get accepted as a standard.

4. A WG that took this long to push the SIMPLEST document out the door,
cannot expect to push a more complicated one out the door in far less time.

 > If the management isn't active, it won't finish.

True, but irrelevant to your point.

> that it's going to finish another one.

True, but does not support your point, either.

---

From: Richard Clayton <[email-masked]>
Date: Mon, 18 Sep 2006 17:43:40 +0100

In message <[email-masked]>, Forrest J. Cavalier III
<[email-masked]> writes

>cannot expect to push a more complicated one out the door in far less time.

I note that draft-ietf-usefor-usepro-05 has timed out...  since I owe
the group a little of my time I will commit to promptly reviewing a
current version if an -06 is created...

... I expect to say [and invite the WG to agree] that whole swathes of
it describe vaporware and should be immediately discarded (unless
several writers of server software suddenly pop-up and commit to the
significant effort involved in implementing new functionality, MIME
handling capabilities and other architectural changes...).

Cutting it down from the current 54 pages to around 30 should be rapidly
possible; it can then be judged how contentious it is ... for an example
removing a number of entirely speculative forward looking statements
about how the current lack of security/accountability might be addressed
would alone save more than a page!

- -- 
richard                                                   Richard Clayton