ietf-mxcomp
[Top] [All Lists]

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

2004-08-19 21:15:43

In 
<C6DDA43B91BFDA49AA2F1E473732113E010BEA8B(_at_)mou1wnexm05(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
 "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:

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.

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.


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


<Prev in Thread] Current Thread [Next in Thread>