Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 18 Aug 2004 14:58:55 -0700

> I suggest you look at RFC 2026, and tighten your terminology. 

Is this a deliberate troll or are the insults merely gratuious?

> A "draft" is
> what we have now. A "draft" is worked on, edited, and finally moves to
> "Proposed Standard". A "Proposed Standard" moves to "Draft 
> Standard".  It does not move to "draft" ordinarilly.

My statement was perfectly clear in context. The IETF process is
confusing but not that confusing.

There is no code required at all at this point. We have multiple
independent implementations that provide proof of concept. The
creation of compliant versions is dependent on progress to 
Proposed Standard.

> The multiple implementations and experience referred to in RFC 2026 is
> different from the concept of obtaining _some_ running code 
> to ensure that a draft is complete and workable. 

That is not a process requirement.

> The point of several people posting is that there are many different
> problems that need to be solved before this draft should be 
> considered for last call.  

They can raise them in the last call period, that is the purpose
of last call.

> _some_ testing and codebase should be available before a draft 
> is put to last call. Otherwise, we are dealing in hypotheticals.

There is considerably more experience of use of SPF today than
there is of application of the vast majority of Proposed standards
and more than a few Draft standard.

> Several days ago it was proposed that some testing be done before last
> call.  I thought there were many people in favor of that.  
> Indeed, I would
> have thought there was a consensus on that direction.  Is that not the
> case?  So what is the rush?  I'm still not understanding what 
> the rush is.

If you really don't know what the rush is then I don't think you 
understand the problem.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 19 Aug 2004 11:31:01 -0400 (EDT)

> Is this a deliberate troll or are the insults merely gratuious?

You used the wrong terms, as I very politely explained. If you take
correction is insult, that's not my problem. However, it was not
gratuitous.

> and more than a few Draft standard.

I'll stipulate there has been bad past practice, though I doubt as bad as
you say, but even so, bad past practice doesn't justify further bad
practice.  We are supposed to learn from our mistakes. It has already been
pointed out nearly all of the previous antispam measures has failed. They
failed largely because they went off half-cocked without sufficient
analysis.

> > call.  I thought there were many people in favor of that.  Indeed, I
> > would have thought there was a consensus on that direction.  Is that
> > not the case?  So what is the rush?  I'm still not understanding what
> > the rush is.
> 

I guess I don't then.  Because if the MTA authorization problem is
serious, then it is more imporantant to have a solution that works, than
one that doesn't work.  

I wonder if people are in a rush because they _know_ that if time is spent
on analysis and hostile testing, that their schemes just won't measure up.  

		--Dean

---

From: Andrew Newton <[email-masked]>
Date: Thu, 19 Aug 2004 12:06:29 -0400

> correction is insult, that's not my problem. However, it was not

Is it possible that this back-and-forth volley can end without a 
finding of fault on any party?

I'm sure there are valid points all the way around, but agreement to 
disagree seems to be the only way forward.

-andy

---

From: wayne <[email-masked]>
Date: Thu, 19 Aug 2004 22:27:54 -0500

> creation of compliant versions is dependent on progress to 

While working code is not always required, that doesn't mean the IESG
will not require it.  

I'm sure that many people have read RFC2026 at least once, but I
figured I'd snip out this section on what it takes to qualify for
an RFC starting on the standard-track.

4.1.1  Proposed Standard

   The entry-level maturity for the standards track is "Proposed
   Standard".  [...]

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

I think that MARID may well be considered to have a "significant
operational impact on the Internet", and thus the IESG may require
"implementation and/or operational experience".  At a minimum, our RFCs
will need to be "well-understood".  While we may not need a full-blown
implementation, I personally wouldn't consider an algorithm to be
"well-understood" if there at least some dry runs on real data from
multiple sources.

While there have been a couple of dry runs by both Andy Newton and
Mark Lentczner, they were both tiny (personal mail boxes).  They also
both showed that the PRA may well have a far greater error rate than
SPF-classic.

-wayne