ietf-mxcomp
[Top] [All Lists]

Planning ahead: RFC schedule

2004-06-07 14:57:49



I've been poking around RFC2026 (Internet Standards Process) and the
MARID charter, RFC2418 (IETF Working Group Guidelines and Procedures)
and I've been trying to figure out when stuff has get done.  I guess
I'm not real sure, so if someone knows the details, could you please
let me know?


The MARID charter says:

Jun 04          Final selection of syntax and document review of
                selected proposal
Jul 04          Working group last call
Aug 04          Submit working group document on MTA Authorization
                Record in DNS to PS
Aug 04          Enter FIN_WAIT


According to RFC2026, there is a last-call period of a minimum of 2
weeks before an I-D can advance to being a Proposed Standard.  Before
the last call, the final draft of the I-D must be published for at
least 2 weeks.

The next IETF meeting (60th - San Diego) is Aug 1-6.

RFC2418 also talks about a working group last call, but gives no time
periods. 


So, is the IETF meeting relevant to the RFC process of this working
group?  Do we need to have stuff done before then?  If so, how much
before then?

If we need to get through the two 2-week waiting periods outlined in
RFC2026 before the IETF meeting, we would need to be pretty much
wrapped up by the end of this month.  If the IETF meeting has nothing
to do with our progress, then it looks like we have until the end of
August to get things done.


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.


-wayne


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