Subject: Re: Gen-art review of draft-ietf-usefor-usefor-10.txt

From: Frank Ellermann <[email-masked]>
Date: Fri, 06 Oct 2006 20:57:33 +0200

Harald Alvestrand wrote:

 [about [FWS in the prose]
> one possible solution is to replace "[FWS]" with the text
> "optional FWS" where that is the intended meaning.

 1:  Not in the note about <unstructured> in chapter 2.2,
     there it's [FWS] as seen in the ABNF of RFC 2822.
 2:  The ..."comments (CFWS):"  at the begin of chater 3 is
     also okay.
 3:  3.1.4 (see below) Newsgroups
 4:  3.2.4 (see below) Distribution
 5:  3.2.6 (see below) Followup-To
 6:  The [CFWS] in chapter 3.2.8 Injection-Info is okay
 7:  Both CFWS without square brackets in 3.2.10 References
     are okay
 9:  The [FWS] in appendix B about Newsgroups isn't wrong.
10:  The CFWS in appendix C about References is okay (see 7).

My editor claims that's all outside of ABNF.

> the [FWS] in the text (not grammar) of section 3.1.4 should
> have been "FWS" without brackets

Makes sense.

> same for section 3.2.4, 3.2.5, 3.2.8

s/3.2.5/3.2.6/ (3.2.5 is Expires, no explicit FWS issue)

IMO the [CFWS] in 3.2.8 is okay.  With that we'd get three
cases of s/[FWS]/optional FWS/ in the prose:  3.1.4, 3.2.4,
and 3.2.6

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Gen-art review of draft-ietf-usefor-usefor-10.txt
Date:  Fri, 06 Oct 2006 20:57:33 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 36
Sender: [email-masked]

Harald Alvestrand wrote:

 [about [FWS in the prose]
> one possible solution is to replace "[FWS]" with the text
> "optional FWS" where that is the intended meaning.

 1:  Not in the note about <unstructured> in chapter 2.2,
     there it's [FWS] as seen in the ABNF of RFC 2822.
 2:  The ..."comments (CFWS):"  at the begin of chater 3 is
     also okay.
 3:  3.1.4 (see below) Newsgroups
 4:  3.2.4 (see below) Distribution
 5:  3.2.6 (see below) Followup-To
 6:  The [CFWS] in chapter 3.2.8 Injection-Info is okay
 7:  Both CFWS without square brackets in 3.2.10 References
     are okay
 9:  The [FWS] in appendix B about Newsgroups isn't wrong.
10:  The CFWS in appendix C about References is okay (see 7).

My editor claims that's all outside of ABNF.

> the [FWS] in the text (not grammar) of section 3.1.4 should
> have been "FWS" without brackets

Makes sense.

> same for section 3.2.4, 3.2.5, 3.2.8

s/3.2.5/3.2.6/ (3.2.5 is Expires, no explicit FWS issue)

IMO the [CFWS] in 3.2.8 is okay.  With that we'd get three
cases of s/[FWS]/optional FWS/ in the prose:  3.1.4, 3.2.4,
and 3.2.6

Frank

To: [email-masked]
Xref: clerew local.usefor:23669
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: USEPRO: Path header
Date: Thu, 5 Oct 2006 11:49:41 GMT
Lines: 39
Sender: [email-masked]

In <[email-masked]> Bill McQuillan <[email-masked]> writes:

>On Wed, 2006-10-04, Charles Lindsey wrote:
>> [I am proposing to s/trusted identity/verified identity/ throughout this
>> chapter, as it seems to convey the sense better; anyone have any
>> problems with this?]

>I wonder if it might be more accurate to refer to a "verified identifier"
>and to s/identity/identifier/ in the subsequent text.

Actually, looking at the instances of "trusted" in that chapter, the
phrase used is usually "trusted identity of the source" or "trusted
source" or "trusted agent". I probably ought to make the usage
consistent.

There are also some occurrences of "trusted" that should remain as such
(e.g. whether you are going to trust some issuer of cancels or control
messages even though his identity is not in doubt).

>Since what is being verified is a name rather than an agent itself, this may
>make it clearer that there could be aliases either known or unknown.

I think what you are identifying is the source of the article; then
whether the name supplied matches that source; and finally you use that name
in an Injection-Info or in a <path-diagnostic>.

So I think what you have is indeed a "verified identity of the source",
whatever wording you choose to use. But I am open to further opinions

-- 
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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: USEFOR last call, point of order
Date:  Thu, 05 Oct 2006 17:08:02 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 26
Sender: [email-masked]

Russ Allbery wrote:
 
> the current USEFOR draft is superior to RFC 1036 as guidance for
> implementors on Usenet today, and I think it's silly to have a superior
> document be left in semi-permanent limbo the way that Son-of was.
[...]
> it seems to me that it's better for the general community to publish it

+1

> I'm willing to keep working provided that people are still reviewing
> and we seem to be converging on something useful.  I think we mostly
> did that with USEFOR.  Whether we can do that with USEPRO is very iffy,
> but we haven't really tried yet, and I don't want to give up without
> even trying.

+1.  Getting it right for USEPRO based on Usefor-10 is IMO possible, we
have a clean data structure (= usefor, the format), and most procedures
(= usepro) on this data should be obvious.  Nothing radical, maybe some
controversies about MUST vs. SHOULD wrt new implementations, there's no
showstopper in sight from my POV.  I hope that the s-o-1036 parts about
gateways will be integrated into USEPRO (and IIRC that was already okay
in all USEPRO drafts):  Above all avoid loops.

Frank

Date: Thu, 5 Oct 2006 00:33:39 -0700
From: Bill McQuillan <[email-masked]>
To: Usenet <[email-masked]>
Subject: Re: USEPRO: Path header
Sender: [email-masked]

On Wed, 2006-10-04, Charles Lindsey wrote:
> [I am proposing to s/trusted identity/verified identity/ throughout this
> chapter, as it seems to convey the sense better; anyone have any
> problems with this?]

I wonder if it might be more accurate to refer to a "verified identifier"
and to s/identity/identifier/ in the subsequent text.

Since what is being verified is a name rather than an agent itself, this may
make it clearer that there could be aliases either known or unknown.

-- 
Bill McQuillan <[email-masked]>

To: [email-masked]
Xref: clerew local.usefor:23665
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: NIGGLE: uppercase, upper case, upper-case
Date: Wed, 4 Oct 2006 21:07:13 GMT
Lines: 19
Sender: [email-masked]

In USEFOR, I find two occurrences of "uppercase", and one each of "lower
case" and "lower-case". I think we discussed this before, and agreed on
"uppercase" (but seemingly the change did not propagate to the lower
occurrences).

In USEPRO, I am intending to use "uppercase" and "lowercase" wherever they
occur. If this is agreeable, then I suggest Ken just adds these two
aberrations to his niggle-list.

-- 
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

To: [email-masked]
Xref: clerew local.usefor:23666
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: USEPRO: Path header
Date: Wed, 4 Oct 2006 21:23:55 GMT
Lines: 348
Sender: [email-masked]

Since USEFOR is now on its way to IETF Last Call, I presume it is now in
order to discuss USEPRO.

I would like to start with the Path header, because we made a lot of
changes to that in USEFOR, and USEPRO needs to catch up. I also have
various other tidyings to propose, but they can wait a couple of days
while I sort them out. So please let us just stick to the Path header for
the moment.

The following text deals with all the changes which seem to be required.
There are alternatives suggested at several places which need to be
discussed, and there is a special request to Richard Clayton to explain
the reasons why demon still need to use the <path-nodot> "demon", so that
I can include it in the example.

Share and Enjoy!

2.3.  Identification of news servers

[There are two alternative texts which have been proposed:]

   In order to record the passage of articles through the network, news
   servers need to identify themselves by means of a <path-identity>
   (F-3.1.5), which can appear in Path, Injection-Info and Xref header
   fields. Whatever <path-identity> is used in the Path header field
   SHOULD be used also in any Injection-Info header field (and it would
   be normal to use it in any Xref header field also).
[Maybe that last sentence moves elsewhere.]

        NOTE: Such <path-identity>s may also be suitable for sending
        email to news server administrators (see [USEAGE]).

[1st alternative]

   <Path-identity>s can take the following forms (in decreasing order of
   preference):

   1. A fully qualified domain name (FQDN) that SHOULD be resolvable in
      the DNS (whether via an A, AAAA or MX record or an equivalent
      CNAME), thus guaranteeing a unique identity. Ideally, it will also
      provide a means to contact the administrators by email (according
      to [RFC 2142], the forms "usenet@server" and "news@server" are
      common addresses for a news server administrator).

|  2. Some other (arbitrary) name in the form of a <path-nodot>, and
|     believed to be unique and registered at least with all other news
      servers sending articles directly to the given one. This option
      SHOULD NOT be used unless the earlier option is unavailable (e.g.
      because the server in question is not connected to the Internet),
      or unless it is of longstanding usage and cessation would be
      unduly disruptive, or unless the earlier option is provided as
      well.

[2nd alternative]

   <Path-identity>s can take the following forms (in decreasing order of
   preference):

   1. A fully qualified domain name (FQDN) that can be resolved to an
      email server via an MX, A or AAAA record according to the
      procedures of [RFC 2821]; this guarantees that the name is unique,
      and makes it easy to contact the administrators if needed.

   2. A fully qualified domain name (FQDN) that is guaranteed to be
      unique by the administrators of the domain; for instance, the
      uniqueness of "server.example.org" could be guaranteed by the
      administrator of "example.org" even if nothing is stored in the
      DNS for that name.

|  3. Some other (arbitrary) name in the form of a <path-nodot>, and
|     believed to be unique and registered at least with all other
      news-servers sending articles directly to the given one. This
      option SHOULD NOT be used unless the earlier options are
      unavailable, or unless the name is of longstanding usage and
      cessation would be unduly disruptive, or unless one of the earlier
      options is provided as well.

   According to [RFC 2142]], the forms "usenet@server" and "news@server"
   are common addresses for a news server administrator.
[end of alternatives]

|       NOTE: Although domain names are case insensitive and it is
|       intended that <path-nodot>s should also be so, it is customary
|       to render them all in lowercase, since many implementations
|       compare them case sensitively for reasons of efficiency.

|       NOTE: A news server administrator who chooses a <path-nodot>
|       which turns out not to be unique (disregarding case) will have
        to bear the consequences.

|       NOTE: An IP address is not permitted as a <path-identity>,
|       although it may still appear in a <diag-identity>. Since the
|       syntax permits a colon (":"  which, prior to this standard, was
|       an alternative to the "!"  delimiter) within any <diag-identity>
|       which takes the form of an <IPv6address>, it would be unwise to
|       choose as a <path-nodot> anything composed solely from four or
|       less hexadecimal digits.

3.2.  Transitional Arrangements

|    o The new style of Path header field, using a <diag-match> to allow
|      "!!"  as a delimiter> and introducing <path-diagnostic>s (which
|      can be distinguished from <path-identity>s by their leading ".")
       is already consistent with the previous standards. However, the
       intention is that relaying agents should eventually reject
       articles in the old style, and so this possibility should be
       offered as a configurable option in relaying agents. User agents
       are unaffected.

7.  Duties of Various Agents

   In this section, the word "trusted", as applied to the source of some
   article, means that an agent processing that article has verified, by
   some means, the identity of that source (which may be another agent
   or a poster).
[I am proposing to s/trusted identity/verified identity/ throughout this
chapter, as it seems to convey the sense better; anyone have any
problems with this?]

7.2.  Duties of an Injecting Agent

   In the normal course of events, an article that has already been
   injected into a Netnews network will never pass through another
   injecting agent.  So, if an injecting agent receives an otherwise
   valid article that has already been injected (as evidenced by the
   presence of an Injection-Date header field, an Injection-Info header
|  field, or more than one occurrence of the <diag-keyword> "POSTED" in
   a Path header field) it MAY choose to reject it, but otherwise SHOULD
   cause it to be relayed, as it stands, by a relaying agent (7.3).

7.2.1.  Proto-articles

        NOTE: An article that is offered for reinjection has, by
        definition, already been injected once, and is not therefore to
        be considered as a proto-article.  Hence a genuine proto-article
|       will not contain any Injection-Date header field nor the <diag-
|       keyword> "POSTED" anywhere in its Path header field, though that
        header field MAY contain <path-identity>s corresponding to
        machines traversed between the posting agent and the injecting
        agent proper.

7.2.2.  Procedure to be followed by Injecting Agents

   10.  It MUST then prepend the <path-identity> of the injecting agent,
|       followed by '!.' and the <diag-keyword> "POSTED", and then a
|       further "!",  to the content of the Path header field; this
        header field SHOULD then be folded if it would otherwise result
        in a header line of excessive length.

7.3.  Duties of a Relaying Agent

   In order to avoid unnecessary relaying, an article SHOULD NOT be
   relayed if the <path-identity> of the receiving agent (or some known
|  alias thereof) appears as a <path-identity> in its Path header field.
|  But note that the <tail-entry> (which follows the last "!") is not a
|  <path-identity>, although not all current implementations observe
|  this distinction.

|  For this to work, each relaying agent needs to insert it own <path-
|  identity> (chosen according to 2.3) into the Path header field. It
|  MAY insert more than one <path-identity> for itself (in which case
|  the leftmost should be the one by which it is known to its immediate
|  neighbours), but where an article passes through several relaying
|  agents at the same site it MAY omit the <path-identity>s for some of
|  them (but NOT the one which finally relays it to an outside site).

|  It MAY (and usually SHOULD) also add a <path-diagnostic> giving
|  additional information concerning the route taken by the article
|  through the network.  A <path-diagnostic> consists of either the
|  special <diag-match> "!" (which effectively replaces the standard
|  delimiter "!" by "!!"), or it is composed from a <diag-keyword> usually
|  followed by a <diag-identity>. The following are the only <diag-
|  keyword>s defined by this standard:
|    o "POSTED" (already introduced in Step 10 of 7.2.2), which is never
|      followed by a <diag-identity>;
|    o "SEEN", whose following <diag-identity> indicates the trusted
|      identity (see 7) of the agent from which the article was received
|      (but makes no claim as to whether it matched the <path-identity)
|      inserted by that agent);
|    o "MISMATCH", whose following <diag-identity> indicates the trusted
|      identity of the agent from which the article was received and
|      asserts that it could not be reconciled with the <path-identity>
|      (supposedly) inserted by that agent.
|  Other <diag-keyword>s beginning with "X" MAY be used by a relaying
|  agent to make some assertion not envisaged here, but other (non-"X")
|  <diag-keyword>s MUST NOT be used unless defined by some extension to
|  this standard.

|       NOTE: The <diag-keyword> "MATCH", which might have indicated the
|       trusted identity of the source agent with an assertion that it
|       agreed with the <path-identity> inserted by that agent, has NOT
|       been provided, since the special <diag-match> conveys exactly
|       that meaning for this commonly occurring case.

|       NOTE: Whilst <diag-keywords>s are case insensitive, it is
|       intended that they should normally be rendered in uppercase.

   A relaying agent processes articles as follows:

|     1. It MUST/SHOULD establish the trusted identity of the source of
         the article and compare it with the leftmost <path-identity> of
|        the existing Path header field's content.  Except possibly when
|        relaying to other hosts on the same site, It then MUST or
|        SHOULD, as indicated, prepend to that content (from left to
|        right) the following:
|        o (MUST) its own <path-identity>;
|        o (MUST) a "!" delimiter;
|        o (MUST/SHOULD) if the trusted and existing identities match, a
|          <diag-match> (effectively converting the "!" delimiter into
|          "!!");
|        o (MUST/SHOULD) alternatively, where the identities do not
|          match (or have not been determied to match), a ".", the
|          <diag-keyword> "MISMATCH" (or "SEEN"), another ".", a <diag-
|          identity> indicating the trusted identity, and finally a
|          further "!";
|        o possibly further <path-identity>s etc. as above, identifying
|          itself.
|     This header field SHOULD then be folded if it would otherwise
|     result in a header line of excessive length.
[The "MUST/SHOULD"s above were all "MUST" in the previous drafts.
Discussion is needed to resolve this.]

|       NOTE: Since each agent at one site can be assumed to be aware of
|       the identity of the others (and of itself), it would be most
|       unusual for their <path-identity>s to be separated other than by
|       "!!". Thus the presence of a single "!", unless followed by a
|       "." and some <diag-keyword>, can be taken as signifying an agent
|       that has not yet been upgraded to conform to this standard.

|       NOTE: Whilst the presence of a "MISMATCH" would normally
|       indicate that the existing Path was bogus in some sense, it
|       could also indicate that the ralaying agent was improperly
|       configured to recognise the identities or aliases used by its
|       neighbours. Administators of relaying agents should therefore
|       periodically monitor the <path-diagnostic> being inserted so as
|       to avoid this.

        NOTE: In order to prevent overloading, relaying agents should
        not routinely query an external entity (such as a DNS-server) in
        order to determine a trusted identity (though a local cache of
        the required information might usefully be consulted).

7.3.1.  Path Header Field Example

|     Path: bar.isp.example!.SEEN.news3.foo.isp.example!foo.isp.example
|        !!foo-server!.MISMATCH.2001:DB8:0:0:8:800:200C:417A
|        !dubious.site.example!!old.site.example!barbaz!!baz.isp.example
|        !.POSTED!dialup123.baz.isp.example!not-for-mail

        NOTE: That article was injected into the news stream by
|       baz.isp.example, as indicated by the <diag-keyword> "POSTED"
        (complaints may be addressed to [email-masked]). The
        injector has chosen to record that it got it from
        dialup123.baz.isp.example. "not-for-mail" is a dummy <tail-
        entry>, though sometimes a real userid is put there.

        The article was relayed, perhaps by UUCP, to the machine known,
        at least to old.site.example, as "barbaz".

        Barbaz relayed it to old.site.example, which does not yet
|       conform to this standard (hence the single '!' delimiter). So
        one cannot be sure that it really came from barbaz.

|       Old.site.example relayed it to a site claiming to be
|       dubious.site.example, and claiming (by using the '!!'
|       delimiter) to have verified that it came from old.site.example.

|       Dubious.site.example relayed it to "foo-server" which, not being
|       convinced that it truly came from dubious.site.example, and
|       knowing that it in fact arrived from a host with the IPv6address
|       [2001:DB8:0:0:8:800:200C:417A], inserted the <path-diagnostic>
|       "!.MISMATCH.2001:DB8:0:0:8:800:200C:417A" (that is not to say
|       that [2001:DB8:0:0:8:800:200C:417A] was not a correct IPv6
|       address for dubious-site.example, but simply that that
|       connection could not be substantiated by foo-server).

        "foo-server" is a locally significant name within the complex
        site of many machines run by foo.isp.example, so the latter
        should have no problem recognizing foo-server and using a '!!'
|       delimiter. It was not strictly necessary to insert the <path-
|       identity> "foo-server" as well as "foo.isp.example" (but maybe
|       some site elsewhere had some reason to test for it).
[Please could Richard Clayton provide a more plausible reason why "foo-
server" might be a <path-nodot> here?]

|       It then went to bar.isp.example which determined (by reverse
|       DNS) that it had come from news3.foo.isp.example, but had taken
|       no steps to check whether that was a known alias for
|       foo.isp.example (which it probably was). Strictly, it SHOULD
|       have made such a check, and then inserted either a "!!" or a
|       "!MISMATCH..." according to the result.

|       Presumably bar.isp.example then delivered the article to its
        direct clients.

|       It appears that foo.isp.example, foo-server and baz.isp.example
        decided to fold the line, on the grounds that it seemed to be
|       getting a little too long.  Note that folding and whitespace is
|       permitted before (but not after) any "!"  (but not within a
|       "!!"); hence continuation lines will always start with either
|       "!" or "!!".

7.4.  Duties of a Serving Agent

A serving agent processes articles as follows:

|  1. It MUST/SHOULD establish the trusted identity of the source of the
      article and modify the Path header field as for a relaying agent
      (7.3).

7.8.  Duties of a Moderator

   5. Any variant header fields (2.4) MUST be removed, except that a
      Path header field MAY be truncated to only those entries following
|     its "POSTED" <diag-keyword>.  Any Injection-Info header field (F-
      3.2.8 SHOULD be removed (and if not, the injecting agent will do
      so, as required in 7.2.2).

-- 
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

Date: Wed, 04 Oct 2006 11:38:39 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: USEFOR last call, point of order
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:
> 
> 
>>I really appreciate your detailed response.
> 
> 
>>>My suggestion, however, is that the better course of action given that the last
>>>call has begun is to comment on technical issues in the document itself rather
>>>than the process that has gotten us to this point.
> 
> 
>>1. It is my opinion that most of the technical issues in USEFOR are going to 
>>remain hidden until the discussions start on USEPRO, and implementations start
>>to be written.  Raising a significant formal objection now is going to be pretty 
>>difficult, since USEFOR is a document format, not a protocol. Risk of harm only 
>>arises through activity, not format specifications alone.
> 
> 
> Then your proper course of action is to recommend to the IESG that they
> decline to publish it until they see USEPRO (that is also my own view, but
> I accept that the consensus was against me).
> 
> But you have given no cogent reason for absolute rejection of the
> document.
> 

It was the third way I was searching for.  Discuss the process.  Discuss how 
USEFOR came to be submitted for last call, and if that was proper.  Discuss how 
soon the clean up to USEFOR (that USEPRO will cause) will happen.

I agree that "Perfect draft" is unreasonable.  But there is a continuum of
imperfection. We have a disagreement in the WG about how ready the document is.
That disagreement was NOT apparent or highlighted by the submission from Alexey.

The IESG gives no more weight to the USEPRO editor's view than others, which
is weird, considering how USEFOR came to be a piece split off from a larger
work, and the significant interdependencies between them.  If USEFOR were a 
strict documentation of existing practice, my opinion would be different.

So, Charles is correct that I have given no reason for absolute rejection of the 
document.  I don't think it should be absolutely rejected.  I agree it is an 
improvement over those parts of previous standards.  And that is what the IESG 
is looking for: some improvement.  That's a pretty low bar.  If "minimal 
improvement over 1036" was the bar of acceptance, then we could have submitted 
long, long, long ago. We could have used Son-Of-1036. But that was NOT the charter.

If that is the bar, then no Format standard that proposes new features can be 
appealed.  Is that what the IESG rules intend?  If one were to try to appeal to 
the IESG to reject USEFOR now, most likely it would be based on something that 
USEPRO draft says now.  (As I said, activities create risk, not mere format 
specifications.)  But an appeal on that basis would be dismissed by saying 
"Well, USEPRO is just a draft, we can fix it in USEPRO."  Saying that it is 
fixable in USEPRO is pure hubris, (some format flaws cannot be overcome by 
protocol.) Saying that USEPRO will be fixed in any particular time frame is not 
supported by the track record of this WG.

Isn't there a third way?  Apparently not.

I predict the end result of all this will be is a confusing set of conflicting 
or incomplete standards issued from a single WG, and no one left interested in 
cleaning it up.  The people who can act to prevent that are the chair and the AD.

To: [email-masked]
Xref: clerew local.usefor:23663
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: USEFOR last call, point of order
Date: Wed, 4 Oct 2006 10:40:29 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:

>I really appreciate your detailed response.

>> My suggestion, however, is that the better course of action given that the last
>> call has begun is to comment on technical issues in the document itself rather
>> than the process that has gotten us to this point.

>1. It is my opinion that most of the technical issues in USEFOR are going to 
>remain hidden until the discussions start on USEPRO, and implementations start
>to be written.  Raising a significant formal objection now is going to be pretty 
>difficult, since USEFOR is a document format, not a protocol. Risk of harm only 
>arises through activity, not format specifications alone.

Then your proper course of action is to recommend to the IESG that they
decline to publish it until they see USEPRO (that is also my own view, but
I accept that the consensus was against me).

But you have given no cogent reason for absolute rejection of the
document.

-- 
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

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: USEFOR last call, point of order
Date: Tue, 3 Oct 2006 09:17:09 -0700
To: Ralph Babel <[email-masked]>
Sender: [email-masked]

--Apple-Mail-31--951080653
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Thanks for your input on the suitability of this draft for  
publication -- IETF last call is a fine time for this input, as Ned  
explained.  However, note that at this point I'm most interested in  
seeing justified arguments that the document in last-call now is  
*worse* than what it is replacing.  If the usefor-usefor draft is a  
higher-quality document, even if it's not perfect, the low WG size/ 
energy suggests to me that it should replace the older document  
rather than continue getting slowly and contentiously polished.

By the way, I found this to be a well-written doc when I did my own  
read last week. Without being a netnews implementor I can't  
necessarily find all inconsistencies but I did find the text  
generally clear and well-organized.  I have thought about some of the  
reported unaddressed inconsistencies brought up on this list, and did  
not identify any as being big/bad enough to adversely affect  
interoperability.  I have been reading everything that goes by on the  
list (though I haven't consulted the tracking system) since March of  
this year.

The publication of a new Proposed Standard document on the Netnews  
article format should not be considered the last word ever on the  
topic.  If somebody found the energy to revise the document further  
some day, and found support for that work, it could happen.   
Improving a standard is generally possible; perfecting it is not.

Lisa

On Oct 2, 2006, at 12:41 PM, Ralph Babel wrote:

>
> Forrest J. Cavalier III wrote:
>
>> But the chair should be impartial when complying with
>> release procedures. Good executive decisions at the
>> level of the IESG can only be made based on accurate
>> assessments, and "spin" is not acceptable.
>
> Just for the record: I'm with Forrest.
>
> Too many contributors have left the WG; nonetheless, the
> number of reported inconsistencies in the draft remains
> constant. This "last call" looks more like the chair being
> tired of the lack of progress (and the draft _is_ far from
> acceptable), but not feeling like shutting down the WG as
> announced originally as part of the milestone schedule.
>

--Apple-Mail-31--951080653
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; min-height: 14px; "><FONT =
class=3D"Apple-style-span" color=3D"#000000"><BR></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT class=3D"Apple-style-span" =
color=3D"#000000">Thanks for your input on the suitability of this draft =
for publication -- IETF last call is a fine time for this input, as Ned =
explained.=A0 However, note that at this point I'm most interested in =
seeing justified arguments that the document in last-call now is *worse* =
than what it is replacing.=A0 If the usefor-usefor draft is a =
higher-quality document, even if it's not perfect, the low WG =
size/energy suggests to me that it should replace the older document =
rather than continue getting slowly and contentiously =
polished.=A0=A0</FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; min-height: 14px; "><FONT =
class=3D"Apple-style-span" color=3D"#000000"><BR></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT class=3D"Apple-style-span" color=3D"#000000">By =
the way, I found this to be a well-written doc when I did my own read =
last week. Without being a netnews implementor I can't necessarily find =
all inconsistencies but I did find the text generally clear and =
well-organized.=A0 I have thought about some of the reported unaddressed =
inconsistencies brought up on this list, and did not identify any as =
being big/bad enough to adversely affect interoperability.=A0 I have =
been reading everything that goes by on the list (though I haven't =
consulted the tracking system) since March of this =
year.</FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; min-height: 14px; "><FONT =
class=3D"Apple-style-span" color=3D"#000000"><BR></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT class=3D"Apple-style-span" color=3D"#000000">The=
 publication of a new Proposed Standard document on the Netnews article =
format should not be considered the last word ever on the topic.=A0 If =
somebody found the energy to revise the document further some day, and =
found support for that work, it could happen.=A0 Improving a standard is =
generally possible; perfecting it is not.</FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><BR class=3D"khtml-block-placeholder"></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Lisa</DIV><BR><DIV><DIV>On Oct 2, 2006, at 12:41 PM, =
Ralph Babel wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Forrest =
J. Cavalier III wrote:</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV> <BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">But the chair =
should be impartial when complying with</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">release =
procedures. Good executive decisions at the</DIV><DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">level =
of the IESG can only be made based on accurate</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">assessments, and "spin" is not acceptable.</DIV> =
</BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Just for the record: I'm with Forrest.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Too many =
contributors have left the WG; nonetheless, the</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">number of reported inconsistencies in the draft =
remains</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">constant. This "last call" looks =
more like the chair being</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">tired of the =
lack of progress (and the draft _is_ far from</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">acceptable), but not feeling like shutting down the =
WG as</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">announced originally as part of =
the milestone schedule.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV> </BLOCKQUOTE></DIV><BR></BODY></HTML>=

--Apple-Mail-31--951080653--

From: Russ Allbery <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: USEFOR last call, point of order
Organization: The Eyrie
Date: Mon, 02 Oct 2006 21:23:10 -0700
Sender: [email-masked]

Forrest J Cavalier <[email-masked]> writes:

> 4. It seems process is not a grounds for appeal, and a discussion about
> process is off-topic. If everyone thinks this WG is working well, then
> carry on.  The rest of the software development world has discovered
> that process explains results.

I don't think the WG is working well.  I do, however, think that the
current USEFOR draft is superior to RFC 1036 as guidance for implementors
on Usenet today, and I think it's silly to have a superior document be
left in semi-permanent limbo the way that Son-of was.  So when weighing
the decision of whether to publish or not publish USEFOR, separate from
the questions of whether or not we're likely to accomplish all of our
goals, it seems to me that it's better for the general community to
publish it.

As for continued work, well, I'm willing to keep working provided that
people are still reviewing and we seem to be converging on something
useful.  I think we mostly did that with USEFOR.  Whether we can do that
with USEPRO is very iffy, but we haven't really tried yet, and I don't
want to give up without even trying.

It's worth pointing out that the NNTP working group also went on for many
years past its deadlines and only finally made progress when the WG was
down to about five active members, and yet I'm extremely pleased with the
documents we produced and which are about to become RFCs.

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

Date: Mon, 02 Oct 2006 23:44:20 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: Usefor Mailing List <[email-masked]>
CC: Ned Freed <[email-masked]>, Forrest J Cavalier III <[email-masked]>, Harald Tveit Alvestrand <[email-masked]>
Subject: Re: USEFOR last call, point of order
Sender: [email-masked]

I really appreciate your detailed response.

> My suggestion, however, is that the better course of action given that the last
> call has begun is to comment on technical issues in the document itself rather
> than the process that has gotten us to this point.

1. It is my opinion that most of the technical issues in USEFOR are going to 
remain hidden until the discussions start on USEPRO, and implementations start
to be written.  Raising a significant formal objection now is going to be pretty 
difficult, since USEFOR is a document format, not a protocol. Risk of harm only 
arises through activity, not format specifications alone.

2. If this were the last and final WG document out the door, rather than the 
simplest and least contentious of 3 proposed documents, then I would agree that 
process discussions would be pointless: everything would be done. But we have 
90% of the work left to do.

3. It seems that missing a milestone by a year or many years is not rare in WGs.
But missing this prediction by a year, something like 5 times as many months as 
Harald first predicted, and then predicting that the next and more complicated 
work product will be complete in a year using the same process does not inspire 
confidence and trust.

4. It seems process is not a grounds for appeal, and a discussion about process 
is off-topic. If everyone thinks this WG is working well, then carry on.  The 
rest of the software development world has discovered that process explains results.

Thank you again, Ned and Harald, for replying.

Forrest

Date: Mon, 2 Oct 2006 17:08:29 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: Re: USEFOR last call, point of order
Sender: [email-masked]

Forrest J. Cavalier III wrote:

>I think your submission to the IESG requesting last call
>was biased.  Can you explain?

I felt the same when I read it. It is interesting to see in writing that 
nobody who dished personal insults my way got censured, despite my being 
told otherwise while it was happening.

Harald Alvestrand <harald@xxxxxxxxxxxxx>:

>If the group is closed, the biggest contributing factor I see for making 
>such a decision is lack of interest. Why do you assume that it has to be 
>caused by lack of interest?

You are the one assuming a lack of interest. People do not always leave 
this group because they lack interest in the outcome. I'd say that one 
very good reason is when they've seen a draft that they've worked very 
hard to get to say one thing go away because the editor decided he didn't 
like what it said.

>Nobody's threatened to appeal in any message I've seen on the list.

I recall having seen several such messages appear in the list in the past. 
I don't recall whether I said it explicitely myself, but I know I made my 
position clear about the process of discussing changes outside the list on 
a web system that cannot be accessed by anyone who refuses to accept bogus 
SSL certs.

I also recall at least one and perhaps more people saying "it doesn't 
matter anymore, I'll just appeal it when it gets to IETF." Expecting
them to stay around for half a decade just to say it again during this 
last-last-last-last call is silly.

Of course, you just might not have seen them. I think a statement such as 
"nobody has threatened to appeal" implies that you actually looked to see 
if they had.

Cc: Harald Tveit Alvestrand <[email-masked]>, Usefor Mailing List <[email-masked]>
To: Forrest J Cavalier III <[email-masked]>
Date: Mon, 02 Oct 2006 15:54:17 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: USEFOR last call, point of order
Sender: [email-masked]

> I expect a chair to be somewhat of a cheerleader and
> have an interest in moving things forward.

> But the chair should be impartial when complying with
> release procedures.  Good executive decisions at the level
> of the IESG can only be made based on accurate assessments,
> and "spin" is not acceptable.

> I think your submission to the IESG requesting last call
> was biased.  Can you explain?

I would suggest you familiarize yourself with IETF processes a bit more before
making comments of this sort. Just as one point, the last call process is
started by the relevant area director (in this case Lisa Dusseault), not by the
WG chair. The fact that the process has begun means the relevant area director
is comfortable that the necessary procedures have been followed.

This doesn't mean the document is ready to become an RFC. That's what the last
call is for: To determine whether or not it is ready.

> 1. I disagree with the idea that it should be published in the event the
> WG closes.  If a WG closes, it is because procedures were not
> being followed.

I'm actually having a hard time coming up with a case where a WG was shut down
due to procedures not being followed. Since the chair is responsible for
procedural issues the usual remedy in such cases is to replace the chair.

The usual reason for shutting down WGs is when they are completely out in the
weeds or there's clearly no chance of the group reaching closure.

It is also worth noting that approval of a WG changes document handling
somewhat but has never been a publication requirement in the IETF. There have
been plenty of cases where a WG failed but some of the WG products made it to
some form of RFC. There have also been a huge number of cases where non-WG
documents became RFCs.

> Why is it reasonable to assume work products that
> resulted from a flawed process should be accepted?

But why would it be unreasonable? Given that the members of WGs are human,
there are almost always minor process flaws if you look hard enough.

Specifications should succeed or fail on their own merits. Of course there are
some sorts of egregious process failures that would merit an objection during
last call or even an appeal, but failures to dot i's or cross t's do not rise
to this level. IMO nothing you have pointed out rises to the necessary level.

In any case, while procedural issues are in order, you are far more likely  to
get traction by making cogent technical arguments at this point.

>  I would think an explicit justification should be presented.

I know of no basis for calling for such a thing.

> 2. There have to be interoperating implementations before it can be
> standardized, and it should be clearer that there aren't even experimental
> implementations for some of it.

I'm sorry, but this is simply not the case. Interoperability requirements apply
to the move from proposed to draft, not the move to proposed. (There are some
exceptions to this for things like routing protocols but none that apply here.)

>  I am not sure that even bare requirements
> for submitting for last call are met here.  That was not clear in your
> submission.

The bare requirements for last call are just that: Pretty bare.

> 3. I think the "nobody threatened to appeal" is a hope, not a statement
> of the risk that someone appeals.  You never asked in the group.  Did you
> ask anyone else?  Especially when so many good reviewers left the group?

And the main reason why we have an IETF-wide last call is so the document can
receive wider review. I find it more than a little curious that you would
object to an action whose main goal is wider review by claiming that the
capacity for good review no longer exists in the group. If anything this is an
argument for a last call, not against one. 

> 4. You claimed "rough consensus."  Is there a reason that the actual poll
> results 6/10 were not made clear?   There is a 2/7 reject/reviewer ratio
> discernable in the last paragraph, but not stated as a ratio.  Are
> IESG executives aware of the controversies and opinions?  Are they aware
> there are so few participants in the poll and that the chairs and editors
> were part of those counted?

Only the AD can answer this, but having been an AD myself I'd be enormously
surprised if she isn't aware in detail of what has gone on.

> 5. I think the IESG should be made aware that the USEPRO editor is
> on record as saying that USEFOR is not ready until USEPRO is, and
> that USEPRO is not close.  The IESG should be aware of your previous
> predictions of schedule and milestones.  (See my previous e-mail.)
> And what that means for a range of when USEPRO can be expected to be
> completed, and with how many participants.

WGs that are way past their milestone dates are never in short supply in the
IETF. Just picking another group at random, I note that all open OPENPGP
milestones have dates in 2001. I recall noting one group some time back that
was almost seven years past any of their dates. In any case, if all WGs that
have missed milestones were shut down there wouldn't be very many groups left.

Harald is actually more of a stickler for milestones and whatnot than most, so
I'm a bit surprised USEFOR dates have not been updated. I personally think the
utility of these tools in a volunteer organization like the IETF is marginal at
best.

> I am not that involved with the IETF standards process, so I don't
> know which of the above warrant comment to higher levels.

Unless things have changed dramatically since my time on the IESG the relevant
AD reads this list, so your comments have probably been seen. Nevertheless, you
can and should send comments directly to the ADs, the IESG, or to the main IETF
list.

My suggestion, however, is that the better course of action given that the last
call has begun is to comment on technical issues in the document itself rather
than the process that has gotten us to this point.

				Ned

From: [email-masked] (Ralph Babel)
To: [email-masked]
Subject: Re: USEFOR last call, point of order
Date: Mon,  2 Oct 2006 21:41:13 +0200 (CEST)
Sender: [email-masked]

Forrest J. Cavalier III wrote:

> But the chair should be impartial when complying with
> release procedures. Good executive decisions at the
> level of the IESG can only be made based on accurate
> assessments, and "spin" is not acceptable.

Just for the record: I'm with Forrest.

Too many contributors have left the WG; nonetheless, the
number of reported inconsistencies in the draft remains
constant. This "last call" looks more like the chair being
tired of the lack of progress (and the draft _is_ far from
acceptable), but not feeling like shutting down the WG as
announced originally as part of the milestone schedule.

Date: Mon, 02 Oct 2006 21:36:17 +0200
From: Harald Alvestrand <[email-masked]>
To: "Forrest J. Cavalier III" <[email-masked]>
Cc: Usefor Mailing List <[email-masked]>
Subject: Re: USEFOR last call, point of order
Sender: [email-masked]

Forrest J. Cavalier III wrote:
> Harald,
>
> I expect a chair to be somewhat of a cheerleader and
> have an interest in moving things forward.
>
> But the chair should be impartial when complying with
> release procedures.  Good executive decisions at the level
> of the IESG can only be made based on accurate assessments,
> and "spin" is not acceptable.
>
> I think your submission to the IESG requesting last call
> was biased.  Can you explain?
>
> 1. I disagree with the idea that it should be published in the event the
> WG closes.  If a WG closes, it is because procedures were not
> being followed.  Why is it reasonable to assume work products that
> resulted from a flawed process should be accepted?  I would think an
> explicit justification should be presented.
If the group is closed, the biggest contributing factor I see for making 
such a decision is lack of interest. Why do you assume that it has to be 
caused by lack of interest?
>
> 2. There have to be interoperating implementations before it can be 
> standardized, and it should be clearer that there aren't even 
> experimental implementations for some of it.  I am not sure that even 
> bare requirements
> for submitting for last call are met here.  That was not clear in your
> submission.
There has to be interoperating implementations before it can be advanced 
to Draft Standard. This call is for Proposed Standard. Your 
interpretation of the IETF standards track is erroneous.
>
> 3. I think the "nobody threatened to appeal" is a hope, not a statement
> of the risk that someone appeals.  You never asked in the group.  Did you
> ask anyone else?  Especially when so many good reviewers left the group?
Nobody's threatened to appeal in any message I've seen on the list.
I trust that people who want to appeal are capable of making their own 
threats.
>
> 4. You claimed "rough consensus."  Is there a reason that the actual 
> poll results 6/10 were not made clear?   There is a 2/7 
> reject/reviewer ratio discernable in the last paragraph, but not 
> stated as a ratio.  Are
> IESG executives aware of the controversies and opinions?  Are they aware
> there are so few participants in the poll and that the chairs and editors
> were part of those counted?
The writeup should make it quite clear that there are very few people 
left in the group. I do not agree that 6/10 is a correct counting.
>
> 5. I think the IESG should be made aware that the USEPRO editor is
> on record as saying that USEFOR is not ready until USEPRO is, and
> that USEPRO is not close.  The IESG should be aware of your previous
> predictions of schedule and milestones.  (See my previous e-mail.)
> And what that means for a range of when USEPRO can be expected to be
> completed, and with how many participants.
The IESG is quite capable of noticing that the group's spent nine years 
without producing anything, and that I've taken at least one year longer 
than I first expected to get the first document out the door. That's a 
cause for pessimism for the next document, and the ADs are aware of this.
WRT the USEFOR/USEPRO linkage, the group consensus was not to hold it 
back; the IETF rules give no special weight to the opinion of an editor 
of another document.
>
> I am not that involved with the IETF standards process, so I don't
> know which of the above warrant comment to higher levels.
In my opinion: None.
Your mileage may vary; the IETF process allows anyone to state any 
opinion to anyone.

                               Harald

Date: Mon, 02 Oct 2006 15:19:38 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: Harald Tveit Alvestrand <[email-masked]>
CC: Usefor Mailing List <[email-masked]>
Subject: USEFOR last call, point of order
Sender: [email-masked]

Harald,

I expect a chair to be somewhat of a cheerleader and
have an interest in moving things forward.

But the chair should be impartial when complying with
release procedures.  Good executive decisions at the level
of the IESG can only be made based on accurate assessments,
and "spin" is not acceptable.

I think your submission to the IESG requesting last call
was biased.  Can you explain?

1. I disagree with the idea that it should be published in the event the
WG closes.  If a WG closes, it is because procedures were not
being followed.  Why is it reasonable to assume work products that
resulted from a flawed process should be accepted?  I would think an
explicit justification should be presented.

2. There have to be interoperating implementations before it can be 
standardized, and it should be clearer that there aren't even experimental 
implementations for some of it.  I am not sure that even bare requirements
for submitting for last call are met here.  That was not clear in your
submission.

3. I think the "nobody threatened to appeal" is a hope, not a statement
of the risk that someone appeals.  You never asked in the group.  Did you
ask anyone else?  Especially when so many good reviewers left the group?

4. You claimed "rough consensus."  Is there a reason that the actual poll 
results 6/10 were not made clear?   There is a 2/7 reject/reviewer ratio 
discernable in the last paragraph, but not stated as a ratio.  Are
IESG executives aware of the controversies and opinions?  Are they aware
there are so few participants in the poll and that the chairs and editors
were part of those counted?

5. I think the IESG should be made aware that the USEPRO editor is
on record as saying that USEFOR is not ready until USEPRO is, and
that USEPRO is not close.  The IESG should be aware of your previous
predictions of schedule and milestones.  (See my previous e-mail.)
And what that means for a range of when USEPRO can be expected to be
completed, and with how many participants.

I am not that involved with the IETF standards process, so I don't
know which of the above warrant comment to higher levels.

Thank you.

Forrest