![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
--On Sunday, July 20, 2008 2:07 PM -0400 Russ Housley <housley at vigilsec.com> wrote:
People seem to be forgetting that all I-D submissions used to be processed an a person. The automated tool is very new. When the I-D were processed by hand, the cut-off was necessary for the Secretariat to handle the spike of submissions just prior to the meeting. Look at the statistics report by IETF chair in their plenary presentations for the last few years -- the meetings cause a huge spike in I-D submissions. Remember back when the I-D submissions were handled by hand, it could be days after the submission that the document actually appeared in the repository. Now that we have the tool, it is a reasonable time to see if we still need this cut-off rule. I have put the topic on the agenda for the IESG discussions in Dublin.
Russ, Thanks.FWIW, it appears from various notes on this thread that we actually have two separate cutoff rules, with one having effectively hidden the other. One of those rules is the two and three week hard cutoff originally imposed to protect the Secretariat, as you have described above. That rule came with a "AD exception" procedure, which seems to have gotten lost over the years ("lost" == "current ADs didn't know about it"). Whether that exception model was a good idea or not relative to other things ADs could do with their time is a separate question -- it did exist and, for better or worse, it was _very_ rarely used.
The other rule is an RFC 2418 rule that says "should ... two weeks..." (note lower-case "should"). It carries with it provision for exceptions by WG chairs and some guidance as to whether those exceptions should be granted.
Many of the recent comments in this thread (including, I fear, mine) have confused the two. It appears to me that most of the suggestions could be accommodated by looking at the first set of rules (the posting cutoffs) only, either eliminating them entirely or cutting them to the point needed to assure a level playing field for those who are forced into manual posting by deficiencies in the automatic posting tool.
I see this an opportunity for evolution and incremental improvement.
Indeed. And a very welcome and much appreciated one. john _______________________________________________ Ietf mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf rg Errors-To: ietf-bounces at ietf.org--On Sunday, July 20, 2008 2:07 PM -0400 Russ Housley <housley at vigilsec.com> wrote:
People seem to be forgetting that all I-D submissions used to be processed an a person. The automated tool is very new. When the I-D were processed by hand, the cut-off was necessary for the Secretariat to handle the spike of submissions just prior to the meeting. Look at the statistics report by IETF chair in their plenary presentations for the last few years -- the meetings cause a huge spike in I-D submissions. Remember back when the I-D submissions were handled by hand, it could be days after the submission that the document actually appeared in the repository. Now that we have the tool, it is a reasonable time to see if we still need this cut-off rule. I have put the topic on the agenda for the IESG discussions in Dublin.
Russ, Thanks.FWIW, it appears from various notes on this thread that we actually have two separate cutoff rules, with one having effectively hidden the other. One of those rules is the two and three week hard cutoff originally imposed to protect the Secretariat, as you have described above. That rule came with a "AD exception" procedure, which seems to have gotten lost over the years ("lost" == "current ADs didn't know about it"). Whether that exception model was a good idea or not relative to other things ADs could do with their time is a separate question -- it did exist and, for better or worse, it was _very_ rarely used.
The other rule is an RFC 2418 rule that says "should ... two weeks..." (note lower-case "should"). It carries with it provision for exceptions by WG chairs and some guidance as to whether those exceptions should be granted.
Many of the recent comments in this thread (including, I fear, mine) have confused the two. It appears to me that most of the suggestions could be accommodated by looking at the first set of rules (the posting cutoffs) only, either eliminating them entirely or cutting them to the point needed to assure a level playing field for those who are forced into manual posting by deficiencies in the automatic posting tool.
I see this an opportunity for evolution and incremental improvement.
Indeed. And a very welcome and much appreciated one. john _______________________________________________ Ietf mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.