Subject: Progressing I-Ds Immediately Before Meetings

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 18 Jul 2008 16:43:06 +0100

Hi,

The cut-off period before IETF meetings has (IMHO) some value to help people 
read an digest stable documents that will be discussed face-to-face.

However, some I-Ds are beyond WG last call and are going through other 
review cycles. Why should updates to these be barred?

For example, I have an I-D that has just completed IESG review. The updates 
are relatively simple and I would like to submit them and get the IESG to 
clear their Discusses. Apparently I cannot do this until July 27th. can 
anyone see a reason why this should be the case?

Cheers,
Adrian 

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Jul 2008 14:19:04 -0400

Adrian:

This has been discussed many times, and there is no easy way for the 
Secretariat to distinguish these document from others.  With the 
on-line Internet-Draft Submission Tool (IDST), it might be possible 
to search the database for such documents and let them 
through.  However, we're trying to get the existing functionality 
working first.  Frankly, we'd need a volunteer to write the code for 
this to be done anytime soon.

Russ

At 11:43 AM 7/18/2008, Adrian Farrel wrote:
>Hi,
>
>The cut-off period before IETF meetings has (IMHO) some value to 
>help people read an digest stable documents that will be discussed 
>face-to-face.
>
>However, some I-Ds are beyond WG last call and are going through 
>other review cycles. Why should updates to these be barred?
>
>For example, I have an I-D that has just completed IESG review. The 
>updates are relatively simple and I would like to submit them and 
>get the IESG to clear their Discusses. Apparently I cannot do this 
>until July 27th. can anyone see a reason why this should be the case?
>
>Cheers,
>Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 18 Jul 2008 23:20:43 +0100

Soooo,

How come I-Ds don't expire after publication has been requested? Could this 
be a field in the data base that could be accessed to allow continued 
submission of revisions regardless of cut-off dates?

Well, if it is too hard or needs many hours of volunteer time, the answer is 
obvious.

Adrian

----- Original Message ----- 
From: "Russ Housley" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 18, 2008 7:19 PM
Subject: Re: Progressing I-Ds Immediately Before Meetings

> Secretariat to distinguish these document from others.  With the on-line 
> Internet-Draft Submission Tool (IDST), it might be possible to search the 
> database for such documents and let them through.  However, we're trying 
> to get the existing functionality working first.  Frankly, we'd need a 
> volunteer to write the code for this to be done anytime soon.
>
> Russ
>
>>The cut-off period before IETF meetings has (IMHO) some value to help 
>>people read an digest stable documents that will be discussed 
>>face-to-face.
>>
>>updates are relatively simple and I would like to submit them and get the 
>>IESG to clear their Discusses. Apparently I cannot do this until July 
>>27th. can anyone see a reason why this should be the case?
>>
>>Cheers,
>>Adrian
>
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 18 Jul 2008 17:30:57 -0500

This could be WG chair approved too, i.e., WG chairs provide a list 
of IDs that are permitted to be submitted that are involved in the 
IESG process (but only ones that have gone through their first IESG meeting).

Not that many per WG should be in this state during any one (normal 
blackout) period.

Just a thought

James

At 05:20 PM 7/18/2008, Adrian Farrel wrote:
>Soooo,
>
>How come I-Ds don't expire after publication has been requested? 
>Could this be a field in the data base that could be accessed to 
>allow continued submission of revisions regardless of cut-off dates?
>
>Well, if it is too hard or needs many hours of volunteer time, the 
>answer is obvious.
>
>Adrian
>
>----- Original Message ----- From: "Russ Housley" <[email-masked]>
>>This has been discussed many times, and there is no easy way for 
>>the Secretariat to distinguish these document from others.  With 
>>the on-line Internet-Draft Submission Tool (IDST), it might be 
>>possible to search the database for such documents and let them 
>>working first.  Frankly, we'd need a volunteer to write the code 
>>for this to be done anytime soon.
>>
>>Russ
>>
>>>For example, I have an I-D that has just completed IESG review. 
>>>The updates are relatively simple and I would like to submit them 
>>>and get the IESG to clear their Discusses. Apparently I cannot do 
>>>this until July 27th. can anyone see a reason why this should be the case?
>>>
>>>Cheers,
>>>Adrian
>>
>
>

---

From: Jari Arkko <[email-masked]>
Date: Sat, 19 Jul 2008 14:28:53 +0300

I am in favor of relaxations in this area. I realize that new code would 
be needed in the submissions tool, but I don't think it would be too 
hard either. We already treat expirations differently depending on the 
tracker state. I have not looked at the submission tool code, but I 
would be surprised if it cannot access drafts database and tracker contents.

I currently have several drafts in a state where the IESG, authors, and 
the WG are talking about the changes needed to approve the document. In 
one case we have a very long list of RFC Editor notes that appear 
satisfactory. In theory we could approve the draft with those, but I 
would like to use RFC Editor notes for minor corrections, and this one 
is not... so a new draft would be preferred. Yet it cannot be posted at 
this time. Having the new draft would also make it easier to have a 
discussion with the WG, because then the usual tools diffs etc would be 
available.

So, my suggestion would be to add a change to our long list of tool 
development tasks. In its simplest form, submissions should be allowed 
even after the deadline has passed if tracker state > pubrequest. Other, 
more complex policies might also be possible, but they would need more 
discussion. For instance, chair decision, allowing updates of drafts 
that have already been updated shortly before, etc.

Jari

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 19 Jul 2008 06:56:41 -0500

Hi, Jari,

I had replied to Russ offlist, but since you're also thinking about ways to 
relax this restriction...

You do need new code if you want to enforce everything automatically.

Alternatively, we could assume that anyone with a draft they want to
"pseudo-submit" is posting it on some random website and posting a link to 
the
working group mailing list anyway ...

(am I the only person who sees "until this draft is announced, it's 
available here" postings?)

... so the only drafts we're throttling are the ones that we need to REALLY 
submit, so we can progress them toward publication ...

... so we might just decide that this is just as bogus as "drafts disappear
after six months", for the same reasons, and remove the block completely, 
and trust WG chairs to ensure that drafts discussed in the meetings WERE 
announced early enough for participants to read them.

Thanks,

Spencer

>I am in favor of relaxations in this area. I realize that new code would be 
>needed in the submissions tool, but I don't think it would be too hard 
>either. We already treat expirations differently depending on the tracker 
>state. I have not looked at the submission tool code, but I would be 
>surprised if it cannot access drafts database and tracker contents.
>
> satisfactory. In theory we could approve the draft with those, but I would 
> like to use RFC Editor notes for minor corrections, and this one is not... 
> so a new draft would be preferred. Yet it cannot be posted at this time. 
> Having the new draft would also make it easier to have a discussion with 
> the WG, because then the usual tools diffs etc would be available.
>
> discussion. For instance, chair decision, allowing updates of drafts that 
> have already been updated shortly before, etc.
>
> Jari
>

---

From: Scott Brim <[email-masked]>
Date: Sat, 19 Jul 2008 08:47:22 -0400

> that have already been updated shortly before, etc.

... and the WG can always decide which ones to actually discuss.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 19 Jul 2008 09:07:09 -0400

Dear Jari;

On Jul 19, 2008, at 7:28 AM, Jari Arkko wrote:

> I am in favor of relaxations in this area. I realize that new code  
> would be needed in the submissions tool, but I don't think it would  
> be too hard either. We already treat expirations differently  
> depending on the tracker state. I have not looked at the submission  
> tool code, but I would be surprised if it cannot access drafts  
> database and tracker contents.
>
> I currently have several drafts in a state where the IESG, authors,  
> and the WG are talking about the changes needed to approve the  
> document. In one case we have a very long list of RFC Editor notes  
> that appear satisfactory. In theory we could approve the draft with  
> those, but I would like to use RFC Editor notes for minor  
> corrections, and this one is not... so a new draft would be  
> preferred. Yet it cannot be posted at this time. Having the new  
> draft would also make it easier to have a discussion with the WG,  
> because then the usual tools diffs etc would be available.
>

Wouldn't it be a lot simpler just to give the ADs the ability to  
advance a draft during the block-out period, maybe through an email to  
the Secretariat ?

They, of course, have to know about a draft getting upgraded in any of  
the above situations, this would not require a tool change, and of  
course if this were misused they are the ones who would have to face  
the wrath of the IESG.

Regards
Marshall

> development tasks. In its simplest form, submissions should be  
> allowed even after the deadline has passed if tracker state >  
> pubrequest. Other, more complex policies might also be possible, but  
> they would need more discussion. For instance, chair decision,  
> allowing updates of drafts that have already been updated shortly  
> before, etc.
>
> Jari
>

---

From: John C Klensin <[email-masked]>
Date: Sat, 19 Jul 2008 10:36:43 -0400

--On Saturday, 19 July, 2008 09:07 -0400 Marshall Eubanks
<[email-masked]> wrote:

>> I currently have several drafts in a state where the IESG,
>> authors,   and the WG are talking about the changes needed to
>> approve the   document. In one case we have a very long list
>> of RFC Editor notes   that appear satisfactory. In theory we
>> could approve the draft with   those, but I would like to use
>> RFC Editor notes for minor   corrections, and this one is
>> not... so a new draft would be   preferred. Yet it cannot be
>> posted at this time. Having the new   draft would also make
>> it easier to have a discussion with the WG,   because then
>> the usual tools diffs etc would be available.
>> 
> 
> Wouldn't it be a lot simpler just to give the ADs the ability
> to advance a draft during the block-out period, maybe through
> an email to the Secretariat ?
> 
> They, of course, have to know about a draft getting upgraded
> in any of the above situations, this would not require a tool
> change, and of course if this were misused they are the ones
> who would have to face the wrath of the IESG.

At the risk of seeing this as just another variation on a theme,
when the posting cutoff rules were first instituted (and, since
I was involved in the discussion, I think they go back to my
terms on the IESG, which is a very long time ago), it was
clearly understood that an AD could waive the deadline for a
particular document if, in his or her judgment, the advantages
of doing so outweighed the disadvantages.  My recollection is
that documents were posted after the deadline on such waivers
several times.   I don't think we ever wrote down that there was
an exception mechanism, mostly because it seemed obvious and
possibly because we didn't especially want to encourage a stream
of requests.  The assumption of obviousness was conditioned on a
general assumption that any procedural rule that IESG could
specify to make things go more smoothly was a rule that the IESG
(or individual ADs in their own areas) could waive for an
exceptional case in which something else would be more
productive.  As Marshall suggests, an AD who abused that [rather
small bit of] discretionary authority would face the wrath of
the IESG (and the wrath of WGs in the area) and an IESG that
abused it would face the wrath of the community for being
arbitrary.

But that, IMO perfectly sensible, combination of formal posting
cutoffs (whether to protect the Secretariat or to make sure
documents were available when they needed to be) with informal
provision for waivers, gradually morphed into a firm,
chiseled-in-stone rule with no exceptions and that no one could
really question, even a sitting AD trying to move a document
forward.  I suggest that has become a pattern, but let me focus
on this particular case.

So, Jari, let me make a suggestion.  Get the relevant draft
together, send it to the Secretariat, and ask (or tell) them to
manually post it and to do so RSN.  If they won't do it, you,
the IESG, and Ray need to have a discussion, but I can't imagine
that being necessary.  Especially because it has been some years
since this sort of exception was made, send a note to the WG,
copying the IETF list, indicating that you decided to apply good
sense and get the document posted in order to facilitate
discussions in Dublin and to avoid unnecessary delay in getting
a document wrapped up and published on which substantial
consensus already existed. 

I want to stress that I'm not recommending modifying the
non-document that defines the posting deadlines to try to
enumerate the exception cases, much less building a lot of extra
facilities into a future version of the posting tool.   I'm
suggesting that you have the authority (and, actually, the
responsibility) to get the document posted simply by the
application and assertion of good sense and that nothing more is
either necessary or desirable.

I imagine the WG would applaud.   Many of us, especially those
who have been increasingly concerned that the formation and
application of rules is replacing the application of good sense,
would also applaud.  I don't see any downsides other than
breaching the sanctity of The Rules, and I don't believe we
actually have Sacred Rules around here.

This situation gives you an opportunity to show the community
that the discretion given to ADs and the IESG --discretion that
is latent in our fundamental procedures-- can actually be used
to expedite moving documents forward efficiently, not just to
slow them down with quibbles, procedural rituals, nit-picking,
and personal preferences.   The ability to use discretion that
way is, IMO, the strongest argument for retaining that
discretion, rather than having the IESG spend time to fight off
real or perceived community efforts to restrict or abolish it
because of a perception that it is regularly misused.   

Go for it! 

     john

---

From: [email-masked]
Date: Sat, 19 Jul 2008 07:45:54 -0700 (PDT)

(reposting the substance of an earlier remark which appears to have
gotten lost)

> ...

> consensus already existed.

I have a more radical suggestion: Let's do away with the cutoff thing entirely,
replacing it if necessary with per-WG policies about what sort of advance
notice needs to be given for a document revision to receive consideration.

The reality is simply this: A given document is either stable or unstable. And
if it isn't stable, preventing people from posting a revision for a brief
period isn't going to magically make it stable. Really, all it does is insure
our repository contains stale data.

In many cases it doesn't even prevent consideration of a revised version by a
group. Over the years I've seen many postings along the lines of "revision
missed the cutoff so it isn't in the archive, you can find a copy of here" to
some list or other. And frankly this is preferable to the alternative of
having a bunch of slideware saying "this issue fixed in the revision that's
not posted yet".

Although to be fair, now that the gate opens once the week starts the
"revision by slideware" problem has become less common. What we see now
is revisions being posted the minute the gate opens and those revisions
being discussed during meetings. I guess this affords some "stability
protection" to the monday morning slot, but not much beyond that.

The rules we have now were designed for situation that no longer exists: One
where all drafts were processed manually, it was more difficult to find
alternate posting venues, and where the revision cycle was generally more
costly and as a result revisions occurred less often and were more substantial.
All of this has changed and we're saddled with a process that no longer makes
sense. It should be replaced by the application of common sense in the working
groups themselves.

> either necessary or desirable.

Well, we agree insofar as I think additional process rules for this are a
terrible idea. But while i applaud the general notion that the application of
common sense can take the place of all that, in this case the cost is going to
be pretty high: This sort of exception handling is going to take WG chair or AD
time, plus the mechanics of handling the exception will likely take secretariat
time. So I think the first application of common sense needs to be whether or
not any of this is necessary and whether the benefits of the draft cutoff are
worth the cost.

> actually have Sacred Rules around here.

I'd much rather breach the sanctity of the rules by getting rid of some of them
entirely.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sat, 19 Jul 2008 11:27:11 -0400

--On Saturday, 19 July, 2008 06:56 -0500 Spencer Dawkins
<[email-masked]> wrote:

> after six months", for the same reasons, and remove the block
> completely, and trust WG chairs to ensure that drafts
> discussed in the meetings WERE announced early enough for
> participants to read them

Spencer and others,

I wish this would work, but we've tried it --it describes the
situation we had before we had any posting limits.  Back then,
one could submit a document through the Friday before the
meeting and then start praying that the Secretariat would get it
up before, e.g., the following Thursday.   

But, more important, it does several things to us, all of which
are bad (although to different degrees):

	* WG agendas may not be able to be nailed down until
	much too close to the meeting.   Since those agendas are
	often used by people to make plans about which sessions
	to attend, rules about them being posted well in advance
	(even if sometimes not obeyed) help all of us.  Late I-D
	submissions prevent those agendas from firming up unless
	the WG Chair takes a firm "once I post the agenda, no
	new documents count" position.  But, where the new
	document is actually a revision, that creates silly
	states, since part of the WG will have prepared on the
	basis of version N and the rest will be working from
	version N-1.   Not an impossible situation, but it makes
	it harder to run effective meetings.
	
	* If people come into the WG session having studied
	document version N-1 but the discussion occurs using a
	late-posted version N, they have ample grounds for
	appealing any conclusions, or even the fact that the
	discussion was held, on the grounds that their inability
	to prepare was discriminatory.  We don't need that.
	
	* If a WG chair starts making "this one is important
	enough to consider despite late posting but that one
	isn't" decisions (which are, IMO, inevitable), it opens
	things up to a new range of opportunities for claims of
	discriminatory behavior. 

	* We have enough trouble getting people to read drafts
	in advance of meetings that doing something that
	encourages people to sit in a WG session, reading and
	trying to catch up, is just unwise. 

If it were important enough, we could, IMO, work around all of
those issues except possibly the last.  But, for the
overwhelming number of cases, submission cutoffs are a better
idea.   Now, the particular deadlines we have now were set
because of Secretariat manual-handling limitations in order to
guarantee documents would be posted before the meeting started
and, hence, IMO, should be reviewed in the light of changed
circumstances.  We almost certainly do not need three weeks for
new drafts.  Maybe we could even manage a one-week (or a bit
more) cutoff for everything.   But I suggest that we should keep
some cutoff to protect ourselves from worse nonsense and then,
as discussed in an earlier note, make exceptions when they are
obviously justified by good sense.

     john

---

From: Scott Brim <[email-masked]>
Date: Sat, 19 Jul 2008 12:20:57 -0400

> because of a perception that it is regularly misused.   

Good.  One generation's rule of thumb becomes the next generation's 
dogma.  The IETF should sit up and really think when someone suggests 
that a process has become dogma.

See you soon ... Scott

---

From: John C Klensin <[email-masked]>
Date: Sat, 19 Jul 2008 13:43:24 -0400

Ned,

While it seems otherwise, I don't think our suggestions are
really inconsistent.   Let me summarize a way to combine the
radical and the more radical:

	(1) Assume, right now and restoring an historical
	principle, that an AD has the right and obligation to
	waive the cutoff in situations that AD considers that it
	is important enough to the process to just get a draft
	posted to do so.  I think we are agreed about that.
	
	(2) As soon as convenient, initiate a discussion about
	updating the posting cutoff rules so that they are
	consistent with today's realities.  I hope that the IESG
	can lead that discussion, or find someone to lead it,
	and that we can have a new plan in place well before
	Minneapolis (it is too late to implement anything for
	Dublin anyway).  It would be a shame to have to initiate
	a formal process experiment for this, but that option is
	available too if the IESG doesn't feel like it wants to
	take the lead but is receptive to a proposal for change.
	I think it makes less difference whether I'm right and
	_some_ sort of nominal cutoff is a good idea or you (and
	maybe Spencer) are and we should just do away with the
	cutoff than that, to paraphrase Scott Brim, we don't
	[continue] to treat decade-old rules that have been
	overtaken by events as dogma or Received Wisdom.

I do note that neither my "AD waiver" model nor completely doing
away with the cutoff require any substantive changes to existing
tools.  It seems to me that is an advantages for one of those
models over anything more complex.

So, my suggestion to Jari that he just go ahead and get the
relevant draft posted still stands.  

And I would like to not be having this discussion in late
October or early November.  Put differently, I would take the
need for such a discussion at that time as a sign that our
process mechanisms are suffering from rather severe
constipation. 

     john

--On Saturday, 19 July, 2008 07:45 -0700 Ned Freed
<[email-masked]> wrote:

> (reposting the substance of an earlier remark which appears to
> have gotten lost)
> 
>> ...
> 
>> together, send it to the Secretariat, and ask (or tell) them
>> to manually post it and to do so RSN.  If they won't do it,
>...
> I have a more radical suggestion: Let's do away with the
> cutoff thing entirely, replacing it if necessary with per-WG
> policies about what sort of advance notice needs to be given
> for a document revision to receive consideration.
>...

---

From: Russ Housley <[email-masked]>
Date: Sat, 19 Jul 2008 15:12:07 -0400

>>forward.  I suggest that has become a pattern, but let me focus

I do not see it this way.  In fact, the document started this thread 
has already been posted.

When all of the Internet-Drafts were processed by Secretariat staff, 
there was a huge workload concern.  Now that the Internet-Draft 
Submission Tool (IDST) is taking the bulk of the load, there are 
resources to deal with these exceptions, as was just demonstrated.

We're going to look into a way to automate the handling of documents 
that are in IESG Evaluation.  In many instances, there is a need to 
post an update to resolve a DISCUSS position.  We will probably need 
a volunteer to update the code to detect this situation once the 
automated rule(s) are understood.

I also agree that an AD should be able to get an I-D posted after the 
cut-off date if it is "the right thing."  As demonstrated, this can 
already be done.  I do not see this being part of the ISDT.  I see it 
using the manual bypass via email.

Russ

---

From: Jari Arkko <[email-masked]>
Date: Sun, 20 Jul 2008 00:01:31 +0300

John,

> manually post it and to do so RSN. 
This seems reasonable. I will do that. Thanks.

Jari

---

From: Dave Crocker <[email-masked]>
Date: Sat, 19 Jul 2008 15:42:08 -0700

Russ Housley wrote:
> there was a huge workload concern.  
,,,
> cut-off date if it is "the right thing."  

Russ,

I'm missing some bit of logic that I hope you can clarify:

    1. The cut-off was put into place due to workload on the 
Secretariat.  The automated I-D has eliminated that bottleneck problem.

    2. Working groups manage their own load.  The Secretariat is not a 
factor nor is the cognizant AD for any other on-going working group work.

So I'm not understanding why there is still a need for a cut-off and for 
the ability to have an AD do "the right thing".

It would seem that the right thing is to remove the cutoff and let each 
working group decide on what drafts will be worked on.

What am I missing, that explains retaining the cut-off?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Sat, 19 Jul 2008 18:56:40 -0400

--On Saturday, July 19, 2008 3:42 PM -0700 Dave Crocker 
<[email-masked]> wrote:

> Russ Housley wrote:
>> When all of the Internet-Drafts were processed by Secretariat
>> staff,  there was a huge workload concern.
> ,,,
>> I also agree that an AD should be able to get an I-D posted
>> after the  cut-off date if it is "the right thing."
>
>
> Russ,
>
>     2. Working groups manage their own load.  The Secretariat
> is not a factor nor is the cognizant AD for any other on-going
> working group work.
>
> So I'm not understanding why there is still a need for a
> cut-off and for the ability to have an AD do "the right thing".
>
> It would seem that the right thing is to remove the cutoff and
> let each working group decide on what drafts will be worked on.
>

Dave,

I'm (I trust obviously) not speaking for Russ, but there are 
several advantages to having a well-defined point at which one 
can know that (modulo exception cases) all of the drafts that 
one should read before an IETF meeting starts are posted.  They 
include getting things ready for "airplane reading", evaluating 
agendas, etc., as well as whatever decisions a WG might make 
about what to consider.  I discussed some of them in an earlier 
note today.  There are other issues and tradeoffs, of course, 
but I think it is a little simplistic to translate "Secretariat 
is no longer the bottleneck" into "no cutoff needed" (I do 
believe that it can be translated into "the current cutoffs may 
be too early", but I discussed that issue in my earlier note too.

    john

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 19 Jul 2008 18:59:31 -0400

On Sat, 19 Jul 2008 15:42:08 -0700
Dave Crocker <[email-masked]> wrote:

> > I also agree that an AD should be able to get an I-D posted after
> > the cut-off date if it is "the right thing."  
> 
> 
> Russ,
> 
No, that's not the primary reason -- the reason was to give wg members a
chance to actually read the documents before the meeting.  Only a small
part of the interval was for the benefit of the secretariat.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John Leslie <[email-masked]>
Date: Sat, 19 Jul 2008 19:19:03 -0400

> What am I missing, that explains retaining the cut-off?

   You're missing the nature of consensus process.

   In consensus process, we work towards a situation that everyone can
agree to live with. We don't attempt to get everyone's view on record.

   Once you reach consensus, you expect it to represent stability,
because people don't want to go through all that trouble again. People
adapt to the consensus.

   It is quite right to ask whether the (old) consensus is still a
reasonable choice; it is not, however, your right to expect everyone
to answer. Least of all is it your right to demand a change to the
process just because people don't answer your question.

   Removing the automated cutoff would require changes in the way
various things are done. Several folks have raised perfectly valid
questions about the likely outcome of such a change.

   The truth is, we've been over much of this ground before -- quite
a few times, in fact. I suspect that the old consensus remains; and
folks believe that only "the last minute" will get drafts submitted.
(There's ample evidence that the majority of draft submissions are
strongly influenced by the cutoff deadline.)

   But it really doesn't matter what I suspect the consensus is: it's
not my job to judge IETF consensus, any more than it's yours.

   I suggest that those among us who see harm in the cutoff bring
our concerns to an IESG member. For myself, I won't devote a lot of
mental effort to this issue until I see exceptions to the cutoff
happening a lot more frequently.

   (Fine-tuning the length of the blackout period, OTOH, is probably
appropriate without re-opening the question of whether there should
be a cutoff at all. I'd welcome a proposal in that direction from
the IESG.)

--
John Leslie <[email-masked]>
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: [email-masked]
Date: Sat, 19 Jul 2008 16:09:16 -0700 (PDT)

> Secretariat.  The automated I-D has eliminated that bottleneck problem.

FWIW, my recollection is that this wasn't the main reason. The main reason was
an (IMO misguided and ultimately couterproductive) attempt to have all the
documents available for review before the meeting.

Regardless, the reason for the rule was put in place is really irrelevant at
this  point.

> factor nor is the cognizant AD for any other on-going working group work.

This point is key. A large, busy WG dealing with lots of complex and
contentious documents may want to have a very rigid policy about what drafts
get considered at a meeting, when and how they can be revised, etc. And they
should be allowed to do just that.

But by the same token, a small group with a few well-agreed on documents has no
need for any of this. Such groups are only inconvenienced by such rules.

> working group decide on what drafts will be worked on.

And when it is or isn't appropriate to allow revisions.

> What am I missing, that explains retaining the cut-off?

Frankly, I think it is more about trusting groups to be able to manage
themselves than anything else.

				Ned

---

From: [email-masked]
Date: Sat, 19 Jul 2008 13:22:19 -0700 (PDT)

> 	posted to do so.  I think we are agreed about that.
	
To the extent it relaxes the rules and helps as an interim measure, sure. But
we need to keep in mind that every cycle we take away from ADs to do this sort
of thing is time that could better be spent on something that's actually
useful.

> 	overtaken by events as dogma or Received Wisdom.

Yes, on this we agree.

				Ned

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 20 Jul 2008 12:56:27 +1200

Ned,

...
> themselves than anything else.

I don't think that's quite fair. If you think about a participant
who is tracking several WGs and/or topics that cut across many WGs,
that person needs to be able to read everything relevant before
arriving. A cutoff about two weeks in advance does make that feasible.
(Let's see - I still have about 12 drafts to read - is that unusual
with one week to go?) I would much rather have that situation, so
that I can prioritize the drafts, than have them arriving until
after I'm already in the air, which would be the inevitable result
of relaxing the cutoff rules.

That said, exceptions should definitely be possible, and I would
delegate that to WG Chair level.

    Brian

---

From: [email-masked]
Date: Sat, 19 Jul 2008 18:01:28 -0700 (PDT)

> that person needs to be able to read everything relevant before > arriving.

Really? The vast majority of document revisions I see don't make significant
changes, so even when I'm tracking a bunch of groups it is exceptionally rare
for me to have to read more than a few entirely new or substantially revised
documents. The rest I just check to see what's changed, which takes very little
time. (It also highlights another thing that's changed for us - the ready
availability of tools that compare document revisions.)

Again, you appear to assume that all groups have similar document loads and
similar work patterns. This is simply not true.

> A cutoff about two weeks in advance does make that feasible.

It does nothing of the sort. Again, it is pretty common for documents that miss
the deadline to be made available through other means.

Whether you want to admit it or not, the fact is that individuals see this rule
as damaging and are routing around it.

> delegate that to WG Chair level.

Well, that's a step forward, but instead of delgating an exception process
why not delegate the authority to decide on an appropriate draft handling
policy?

				Ned

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 20 Jul 2008 13:36:12 +1200

> similar work patterns. This is simply not true.

No, I' not assuming that. I'm talking (selfishly) about the inflow of drafts
that one participant may need to read regardless of source, and I (selfishly)
want that inflow to stop a couple of weeks in advance.

> the deadline to be made available through other means.

Yes, and it's also permissible and does happen for people in the WG
session to object to drafts being discussed that have arrived too
late to be read.

> as damaging and are routing around it.

True, but other individuals disagree.

> why not delegate the authority to decide on an appropriate draft handling

Because I fear that the resulting temptation for each WG to consider
only its own needs, plus the human tendency to work to deadlines,
would result in ~300 drafts arriving on the Friday before the IETF
starts.

    Brian

---

From: [email-masked]
Date: Sat, 19 Jul 2008 18:42:04 -0700 (PDT)

> want that inflow to stop a couple of weeks in advance.

But that's exactly the problem - the documents keep changing, you're just
walling yourself off from the current versions.

> session to object to drafts being discussed that have arrived too

Never seen it happen myself.

> True, but other individuals disagree.

Disagree as to the facts? This was happened. I can dig up the postings to lists
if necessary to prove it.

> would result in ~300 drafts arriving on the Friday before the IETF

And what's your evidence supporting such a thing being likely to happen? Given
that the gate opens at the start of the week, a strong tendencdy towards an
onslaught of premetting drafts would surely have already translated into a
bunch  being posted on Monday. AFAIK that has not happened.

I thknk we have enough real and pressing concerns to worry about without
manufacturing unlikely scenarios like this.

And more to the point, nothing prevents us from dealing with that problem in
the unlikely event it actually arises.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sat, 19 Jul 2008 19:27:57 -0700

> why not delegate the authority to decide on an appropriate draft handling

Oddly, I think it really doesn't.  By keeping the view that it is an 
"exception", it enforces a cumbersome, IETF-wide, Procrustean model with 
an exception, rather than a simple model with no need for exceptions.

Either working groups know how to run themselves on a daily basis -- 
that is, excepting real crises -- or they don't.

If they do. then we do not need one-size-fits-all-except-when-it-doesn't 
rules.  If they don't, then we need to be much, much better about 
writing and enforcing rules. (And all the evidence says that we won't be.)

As of now, we fail to enforce rules that exist and we have enforcement 
of rules that don't.  The underlying problem is that folks who are 
active in the IETF are not really all that fond of following strict rules.

Personally, I think that's a Very Good Thing.  However the persistent 
Bad Thing is that we keep pretending that we need lots of rules.

What we really need to be is reasonable, open and accountable, with 
"local" control for local activities.

Fewer rules, more working group self-management.

Oversight should be just that.  And that's quite different from 
micro-management.

d/

-- 

   Dave Crocker

---

From: [email-masked]
Date: Sat, 19 Jul 2008 20:34:51 -0700 (PDT)

> an exception, rather than a simple model with no need for exceptions.

Sigh. Point taken. I retract my previous assessment that this would be a real
step forward.

> that is, excepting real crises -- or they don't.

Yep.

> writing and enforcing rules. (And all the evidence says that we won't be.)

Indeed. Past efforts to drag groups out of the weeds have not been all that
successful, have they?

> Fewer rules, more working group self-management.

Exactly.

				Ned

P.S. It really isn't fair that you used the term "Procrustean" - one of my
favorites - to blow away my argument ;-)
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Sat, 19 Jul 2008 21:05:39 -0700

> favorites - to blow away my argument ;-)

well, ummm, it's not as if I had to change anything to make it... fit.

d/

-- 

   Dave Crocker

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 20 Jul 2008 08:11:40 -0500

I guess I have a tendency to local-optimize when I post here, so the 
conversation has broadened enough that it's worth sending a clarifying 
note...

Where I chimed in, in this thread, was on a specific problem - want to have 
exceptions for drafts that would be advanced - not discussed in the 
meeting - if we could submit them, but we couldn't submit them, and it would 
require tools development to automate exception handling.

My local optimization was to stop enforcing a rule that seemed to be 
leaking, and required AD intervention for exceptions. I've spent almost 
every Thursday for more than two years listening to ADs do AD work on 
telechats. They seem busy.

I don't actually mind a two-week cutoff (it's in 2418). The relevant text in 
2418 says

7.1. Session documents

   All relevant documents to be discussed at a session should be
   published and available as Internet-Drafts at least two weeks before
   a session starts.  Any document which does not meet this publication
   deadline can only be discussed in a working group session with the
   specific approval of the working group chair(s).  Since it is
   important that working group members have adequate time to review all
   documents, granting such an exception should only be done under
   unusual conditions.  The final session agenda should be posted to the
   working group mailing list at least two weeks before the session and
   sent at that time to [email-masked] for publication on the IETF web
   site.

So I don't know where the "must have AD approval for exceptions" thing came 
from, unless it's a misplaced need to have ADs approve everything.

If ADs do discover copious and uncharted spare time, I would MUCH prefer 
that they spend it steering their working groups, and specifically noticing 
milestone offsets so we can move away from the current situation, where many 
so many milestones are expressed in terms of ID cutoffs for the next 
meeting, more than half the updates are posted within two weeks of the ID 
cutoff, and we're floundering through the drafts getting ready for the 
meetings.

I am particularly irritated when I see a draft that I submitted comments on 
immediately after the last IETF meeting (which was a long time ago), updated 
for the first time within a week of the ID cutoff for the next meeting. This 
does not give us timely publication - we can't even remember what we were 
talking about, in some cases.

I do, of course, appreciate working group chairs that do stagger their 
milestones, and I do, of course, wish that Eric and I thought about this 
more often in mediactrl.

I hope this is clearer than what I posted, as a local optimization, earlier. 
I'm not opposed to global optimization.

Thanks,

Spencer

> rules.  If they don't, then we need to be much, much better about writing 
> and enforcing rules. (And all the evidence says that we won't be.)
>
> As of now, we fail to enforce rules that exist and we have enforcement of 
> rules that don't.  The underlying problem is that folks who are active in 
> the IETF are not really all that fond of following strict rules.
>
> Personally, I think that's a Very Good Thing.  However the persistent Bad 
> Thing is that we keep pretending that we need lots of rules.
>

---

From: [email-masked]
Date: Sun, 20 Jul 2008 07:50:10 -0700 (PDT)

>    sent at that time to [email-masked] for publication on the IETF web

Funny, I myself don't see anything in here at all about an I-D cutoff. What I
do see is a fairly reasonable rule (I think two weeks is a bit too long, but
that's a quibble) about having stuff available for review sufficiently early.

The I-D cutoff is at best a clumsy attempt to enforce this rule mechanically.

> from, unless it's a misplaced need to have ADs approve everything.

You're confusing a rule with a procedure which has as one purpose to try and
enforce that rule. Since the procedure is something implemented by the
Secretariat, the question is what whose authority would they accept to make an
exception. Maybe they'd accept a request from a WG chair. Or maybe not.

But let's suppose we can get ADs out of the exception process. As Dave pointed
out last night, the real problem is having to make such exceptions, and this
still doesn't fix that.

> cutoff, and we're floundering through the drafts getting ready for the

This is a consequence of the RFC 2418 rule and more generally of the way our
process revolves around our meetings. And while I share your dislike here, I
don't think making exceptions to the cutoff or getting rid of it entirely will
change this in any significant way. We're all busy, IETF work is not the
primary thing most of us do, and it is simple human nature to wait until the
last minute to do stuff.

> talking about, in some cases.

An argument for doing less work at meetings and more work on mailing lists,
perhaps, but again I don't see how any sort of change to the cutoff rule  can
fix this.

> milestones,

Youi know, it is interesting you should say that, because if it is true
it highlights how different parts of the IETF work quite diferently.

In most of the groups I participate in nobody pays any attention at all to
milestone dates. When a group meets it considers the documents that are ready
to be considered, not the ones that the schedule says must be considered.
Prodding by charis to meet milestone dates is practically unheard of. And lots
of these groups have milestone lists with missed dates. (In fact I believe
there have been cases of milestones seven years or more out of date.)

				Ned

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 20 Jul 2008 12:05:14 -0500

Hi, Ned,

> Funny, I myself don't see anything in here at all about an I-D cutoff. 

Agreed.

> that's a quibble) about having stuff available for review sufficiently 

Agreed with "fairly reasonable".

> The I-D cutoff is at best a clumsy attempt to enforce this rule 

I'm sure.

> enforce that rule.

Probably. I've been confused about this before.

> Since the procedure is something implemented by the

I probably wasn't being clear enough - I don't disagree with Dave here, what 
I was saying was that we were arguing about (please tell me if I'm doing a 
better job of saying this) a procedure that was intended to enforce a fairly 
reasonable rule mechanically), and the conversation seemed to assume that AD 
approval would be required for exceptions, which wasn't required by the rule 
that the mechanical procedure was intended to enforce.

I am sympathetic to the idea that the rule is more Procrustean than it needs 
to be, in addition to the procedure requiring something that the rule 
doesn't require (please tell me if you think I'm agreeing with you, because 
I think I am).

> change this in any significant way.

Agreed. My attempted point was that I could think of things that I'd prefer 
to see ADs doing, rather than worrying about "exceptions".

One of my earliest process memories at IETF was in Munich (IIRC), where an 
IAB member and primary document author had submitted a draft by e-mail 
several *minutes* after the I-D cutoff, and people seemed to think that 
missing the cutoff prevented the working group from discussing the draft. I 
was confused by that memory into thinking that exceptions weren't possible, 
for several years thereafter. I was wrong, but I wasn't the only person who 
thought that, at the time.

> We're all busy, IETF work is not the

Agreed. I am wondering why we all have to have the same "last minute", only 
once per IETF cycle, but if we're going to enforce rules mechanically 
through procedures that don't quite seem to match the rules, I guess we're 
getting what we deserve.

> perhaps, but again I don't see how any sort of change to the cutoff rule 

Agreed. I was still thinking of more consistent milestone steering, not that 
changes to the cutoff rule would affect how often drafts were updated. Sorry 
that I didn't make this clearer.

Interesting that you would go off to the land of "more work on mailing 
lists". That would be lovely. I remember Harald talking about the absence of 
working group mailing list traffic for months between IETFs, for working 
groups that met at both IETFs, as a not-terribly-healthy sign.

> there have been cases of milestones seven years or more out of date.)

Agreed.

Thanks for your note, and for the opportunity to (once again attempt to) say 
what I was thinking more clearly. The communication problem may not be in 
your receiver, of course :-(

Spencer

---

From: Pete Resnick <[email-masked]>
Date: Sun, 20 Jul 2008 12:27:10 -0500

>You're missing the nature of consensus process.

Actually, John, I'm afraid it was you who missed the consensus. As 
Spencer writes:

>The relevant text in 2418 says
>
>7.1. Session documents
>
>So I don't know where the "must have AD approval for exceptions" 
>thing came from, unless it's a misplaced need to have ADs approve 
>everything.

The consensus was to have WG chairs make a two-week deadline with 
exceptions if needed. As Ned pointed out:

>Funny, I myself don't see anything in here at all about an I-D 
>cutoff. What I do see is a fairly reasonable rule [...] about having 
>stuff available for review sufficiently early.
>
>You're confusing a rule with a procedure which has as one purpose to 
>try and enforce that rule. Since the procedure is something 
>implemented by the Secretariat, the question is what whose authority 
>would they accept to make an exception. Maybe they'd accept a 
>request from a WG chair. Or maybe not.

The cutoff is an arbitrary procedure to try (poorly IMO) to enforce 
the 2418 rule. It is the procedure, and the resultant non-consensus 
rule ("No drafts within 2 weeks of an IETF meeting") which is 
garnering these complaints.

>because people don't want to go through all that trouble again. 
>People adapt to the consensus.

On this we agree.

>various things are done.

Well, it might require changes to how things are done. However, it 
would not require changes to the consensus, and (IMO) would not 
change the outcome. WG chairs would be expected to follow the 
consensus as laid out in 2418, two weeks would be given for review 
(as now), exceptions could be made (as now), and the ADs would not 
have to be in the loop (which was never required by the consensus).

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Russ Housley <[email-masked]>
Date: Sun, 20 Jul 2008 14:07:45 -0400

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.

I see this an opportunity for evolution and incremental improvement.

Russ

---

From: Dave Crocker <[email-masked]>
Date: Sun, 20 Jul 2008 11:47:50 -0700

Russ Housley wrote:
> need this cut-off rule.  I have put the topic on the agenda for the IESG 
> discussions in Dublin.
> 

Cool!  Thanks.

d/
-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Sun, 20 Jul 2008 15:00:07 -0400

--On Sunday, July 20, 2008 2:07 PM -0400 Russ Housley 
<[email-masked]> 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

Indeed.  And a very welcome and much appreciated one.

   john

---

From: [email-masked]
Date: Sun, 20 Jul 2008 12:28:15 -0700 (PDT)

> actually appeared in the repository.

There seems to be some disagreement as to why the cutoff was established. (My
recollection is that it had more to do with stability than with Secretariat
workload, but it was a long time ago and I freely admit my memory may be
faulty.) But how we got here is not the real issue, what to do now that we're
here is.

> need this cut-off rule.

+1

> I have put the topic on the agenda for the

Most excellent.

Exactly.

				Ned

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 20 Jul 2008 14:37:26 -0500

Hi, Russ,

The only statement in this thread I don't agree with is

>> be processed an a person.

I am still remembering that time all too clearly. I suspect that anyone who 
worked for the secretariat as that person remembers it even more vividly :-)

On everything else, I want to echo Dave's "cool", and John's "thanks".

Spencer

>> The automated tool is very new.
> 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.
>

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 21 Jul 2008 09:25:55 -0500

Ned,

	See below...

--
Eric Gray 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Sunday, July 20, 2008 10:50 AM
> To: Spencer Dawkins
> Cc: [email-masked]
> >    published and available as Internet-Drafts at least two weeks
> >    before a session starts.  Any document which does not meet this 
> >    publication deadline can only be discussed in a working group 
> >    session with the specific approval of the working group chair(s).
> >    Since it is important that working group members have adequate
> >    time to review all documents, granting such an exception should
> >    only be done under unusual conditions.  The final session agenda
> >    should be posted to the working group mailing list at least two
> >    weeks before the session and sent at that time to [email-masked]
> >    for publication on the IETF web site.
> 
> Funny, I myself don't see anything in here at all about an 
> I-D cutoff. What I do see is a fairly reasonable rule 
> (I think two weeks is a bit too long, but that's a quibble) 

Actually, 2 weeks is not too long as a general rule, and maybe
not even long enough in some cases (notably this case).

Many (most?) of us have other things we need to be doing (as
you note yourself below), and having a huge dump of IDs in the 
last few days before an IETF meeting will - for many people - 
mean we haven't even had a chance to see them, let alone down-
load and read them.  Which is an excellent segue to another 
point - i.e. - in case some people haven't noticed, it can be 
hard to download drafts in the last few days before a meeting 
because the ID repository server tends to be overwhelmed by 
such requests (and a later dead-line is not going to help).

Another thing that is a clearly observable fact is that people
tend to push the deadline, and moving it to some time slightly
before the meeting - or worse, eliminating it entirely - would
be an excellent way to ensure that very few of them get posted
with a reasonable lead time to allow reading.  Again, this is
something you've also commented on below.

Finally, one thing that is likely to get worse, with current 
cost of travel getting ready to sky-rocket, is that the number
of activities that people going to an IETF meeting are likely
to be expected to participate in will increase rather than
decrease.  Hence the number of drafts that each attendee will
be expected to have read is going to increase - hence this is
probably not a good time to talk about reducing the time that
may be available to read those drafts.

> about having stuff available for review sufficiently early.
> 

Yes, it is clumsy, and mechanical.  But mechanical is not
always bad.  People frequently reconize how useless it is
to argue with a mechanism (when was the last time you found
yourself yelling at a automated voice menu system?). With 
a mechanically enforced cut-off, people are likely to feel 
that there is little opportunity for argument, so they make
a little more effort to be on time.  And THAT is a good 
thing, especaily if you would like to consider the overhead 
of addressing these arguments to the probably already hard 
job of dealing with the occasional failures of the clumsy 
mechanical submission process.  I suspect the secretariat 
feels considerable angst at having to deal with each person 
who feels that their own ID submission is the only important 
thing the secretariat has to do with their time before a 
meeting.

Also, not having the late drafts actually available before
a meeting makes the WG chairs' job easier (at least for the
most part, I believe) because it makes agenda management a
bit easier if they don't have a lot of people arguing that 
their nearly-on-time draft should be included in the agenda.

> 
> > So I don't know where the "must have AD approval for 
> > exceptions" thing came from, unless it's a misplaced 
> > need to have ADs approve everything.
> 
> You're confusing a rule with a procedure which has as one 
> purpose to try and enforce that rule. Since the procedure 
> is something implemented by the Secretariat, the question
> is what whose authority would they accept to make an
> But let's suppose we can get ADs out of the exception 
> process. As Dave pointed out last night, the real problem
> is having to make such exceptions, and this still doesn't
> fix that.
> 
> > If ADs do discover copious and uncharted spare time, I 
> > would MUCH prefer that they spend it steering their
> > working groups, and specifically noticing milestone
> > offsets so we can move away from the current situation,
> > where many so many milestones are expressed in terms of
> > ID cutoffs for the next  meeting, more than half the
> > updates are posted within two weeks of the ID cutoff, 
> > and we're floundering through the drafts getting ready
> > for the meetings.
> 
> This is a consequence of the RFC 2418 rule and more generally 
> of the way our process revolves around our meetings. And while
> I share your dislike here, I don't think making exceptions to
> the cutoff or getting rid of it entirely will change this in
> any significant way. We're all busy, IETF work is not the
> primary thing most of us do, and it is simple human nature to 
> wait until the last minute to do stuff.

This confuses me.  Above, you say that 2 weeks is "a bit too
long" - yet here you're making a strong argument for having
as long a lead time as possible.  What do you really want?

> 
> > I am particularly irritated when I see a draft that I 
> > submitted comments on immediately after the last IETF 
> > meeting (which was a long time ago), updated for the 
> > first time within a week of the ID cutoff for the next
> > meeting. This does not give us timely publication - we
> > can't even remember what we were talking about, in some
> > cases.
> 
> An argument for doing less work at meetings and more work on 
> mailing lists, perhaps, but again I don't see how any sort
> of change to the cutoff rule can fix this.
> 
> > I do, of course, appreciate working group chairs that do 
> > stagger their milestones,
> 
> You know, it is interesting you should say that, because if 
> it is true it highlights how different parts of the IETF work
> quite differently.
> 
> In most of the groups I participate in nobody pays any 
> attention at all to milestone dates. When a group meets
> it considers the documents that are ready to be considered,
> not the ones that the schedule says must be considered.
> Prodding by chairs to meet milestone dates is practically 
> unheard of.  And lots of these groups have milestone lists
> with missed dates. (In fact I believe there have been cases
> of milestones seven years or more out of date.)

I think all that you say in the above two paragraphs is true 
in a lot of working groups, and this is something that many
people probably would like to see fixed - rather than used as
an excuse for continuing with the current bad behavior.

The IETF needs to work toward being slightly more predictable
in its deliverables, given the way that some IETF delays tend 
to be directly translated into delays in other sectors of the 
industry.

This is something we need to work on, if we want to drive the
Internet standards of the future.  Driving the process based
on "the documents that are ready" - without a conscious effort 
(and focus) to ensure that the right documents are the ones 
"that are ready" is a recipe for making the IETF a paper
outlet for quasi-interesting rumours about what a subset of
Internet products and services are doing already.

If the IETF continues to foster processes and behaviors leading 
to inaccurate reporting of de facto standards - instead of ways
to define those standards - it is headed for its own "historical" 
status.

---

From: [email-masked]
Date: Mon, 21 Jul 2008 08:01:50 -0700 (PDT)

> not even long enough in some cases (notably this case).

That may well be true sometimes, like when a massive and complex new
document is first introduced.

But by the same token, in lots of cases it is too long, such as when a
longstanding document receives a minor update. I think on average it is too
long, which is why I made the side remark I did. But in any case i'm not
proposing changing the two week limitt.

> such requests (and a later dead-line is not going to help).

You're confusing multiple things and are failing to acknowledge the reality of
the situation. Thow in a few straw men to boot and it is difficult to even
formulate a response to this.

The I-Ds are going to get written or revised whenever the authors want to do
so, and right now that's often right before a meeting. We have no control over
that.

The I-Ds are going to get posted somewhere if the authors so desire. Again, we
hwat no control over that.

We do have control over what's actually considered at a meeting, so if an
author brings up a documeent that missed the deadline we can refuse to consider
it. Apparently this happens in some groups, but while I've seen many cases
where documents that missed the deadlines were brought up, I cannot recall a
single case where the group refused to discuss it because of that. (FWIW, I"ve
also seen plenty of cases where a document could not be considered because
nobody had read it, but this includes quite a few documents posted months
before the deadline. So much for the other side of the "if it is there soon
enough we'll read it" contract.)

The bottom line is that the only things we have control over are are our
meeting agendas and the official repository. I'm arging that attempting to
control agendas with repository rules is a losing proposition. That's all.

In particular, I'm not saying that having a rule about material that's going to
be considered be available in advannce is a bad idea, and your apparently
making arguments against removing such a rule is nothing but a straw man.

> something you've also commented on below.

The fact that our work schedules revolve around our meeting dates is the root
cause of a number of serious problems, but fidding with that opens a huge can
of worms. While we may lament the effect it has, nobody is proposing any
changes in this area AFAIK.

Nor is anybody proposing a change to RFC 2418 rules. Again, this is a  strawman
of your own making.

> may be available to read those drafts.

Increased travel costs may impact us in a numbvr of ways, although I'm very
skeptical it will produce the results you claim it will. (A far more likely
outcome is that attendence drops dramatically while remote attendance
escalates, with all that implies.) It may in fact eventually force us to open
that aforementioned can of worms. But that's a separate discussion for a
different day.

> yourself yelling at a automated voice menu system?).

You know, that's an excellent example, because what happens in practice is that
if these sorts of automated systems are too cumbersome people simply route
around them just like they route around the cutoff now: They hit "0", forcing
costly manual intervention for routing purposes, they use some other means of
communication, or they may even game the system by dialing extensions or other
tricks. (Yes, I'm guilty of multiple counts of all three, and quite proud of my
serial offender status.)

As for yelling, its going to be at whoever they end up talking to. I would not
want to be the person actually taking orders at Herb's World of Junk (in
Moonsocket, Rhode Island), would you?

> With a mechanically enforced cut-off, people are likely to feel
> a little more effort to be on time.

Let's just say you have a much better opinion of human nature than I do.

> as long a lead time as possible.  What do you really want?

Again, AFAIK nobody is proposing changing the two week rule. But to answer your
question, the rule has to strike a balance - if the gap is too long too many
documents will miss and too many exceptions will have to be made in the groups
themselves. I happen to think two weeks is a bit too long on average.

> an excuse for continuing with the current bad behavior.

This is really off topic, but since you brought it up...

No doubt you'd like to see more rules added to try and get rid of what you see
as "bad behavior".

This is exactly what we should not be doing. What we should do instead is to
take a close look at why milestone dates are not being used in any meaningful
ways by a lot of groups and see what changes make sense to address that.
Perhaps more rules are indeed needed to force groups to use these dates, but I
think that's a very unlikely outcome.

I haven't given this any serious consideration, but the place where I'd look
for a solution to this particular problem would be to completely rethink the
relationship between groups, drafts, and milestones, in the process getting rid
of some update rules we currently have. In particular, for draft-related
milestones, tie the updating  to the draft itself, not the group's charter, and
give the author/editor the ability to update the milestones for their own
drafts. Maybe even make it automatic - when a revision is posted check to see
if there are related milestones and right then and there ask if this revision
addresses any of them.

Again, this is just off the top of my head. But I think fewer rules and more
automation are where the answer lies.

> to be directly translated into delays in other sectors of the

Agreed, but it is going to be extremely difficult to do in a volunteer
organization. And I don't think making more rules will help.

> to define those standards - it is headed for its own "historical"

And I see all the rules we have accreted as helping us along that path at an
ever-accelerating pace.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Jul 2008 12:21:40 -0400

--On Friday, 18 July, 2008 16:43 +0100 Adrian Farrel
<[email-masked]> wrote:

> Hi,
> 
> The cut-off period before IETF meetings has (IMHO) some value
> to help people read an digest stable documents that will be
> discussed face-to-face.
> 
> However, some I-Ds are beyond WG last call and are going
> through other review cycles. Why should updates to these be
> barred?
> 
> For example, I have an I-D that has just completed IESG
> review. The updates are relatively simple and I would like to
> submit them and get the IESG to clear their Discusses.
> Apparently I cannot do this until July 27th. can anyone see a
> reason why this should be the case?

The original reason for those cutoffs -- even more important
than giving people time to read drafts -- was that the
submissions were overwhelming the Secretariat.  Not only did
they have other things to do in the weeks before the meeting, it
was becoming unpredictable whether a draft submitted in advance
of the meeting would be posted early enough for the relevant WG
to look at it.  The split between "new" and "revised" drafts was
another attempt to protect the Secretariat -- notions of having
to formally approve WG drafts came later.

Of course, all of those original reasons vanished when the vast
majority of I-Ds started being posted by a tool that doesn't
require human intervention, leaving, as far as I can tell, three
reasons:

	(1) Assuming adequate lead time for discussions.  As you
	point out, that may not apply to all drafts.  It might
	also be outweighed by other considerations for other
	drafts.
	
	(2) Since the automated submission tool is not
	infallible and sometimes forces perfectly good documents
	into manual submission, we want to preserve a level
	playing field between those who can post drafts via the
	submission tool and those who cannot.
	
	(3) We just like our rules and, once something becomes a
	rule, it is too hard to review and change it.

I hope (3) isn't operating here, but I've seen some small amount
of evidence to the contrary.

    john

---

From: Ned Freed <[email-masked]>
Date: Fri, 18 Jul 2008 09:29:50 -0700 (PDT)

> read an digest stable documents that will be discussed face-to-face.

I'm afraid this is another case where we're trying to use processes to control
the uncontrollable.

A document is either stable or it isn't. If it isn't stable and is being
actively revised those changes are going to happen irrespective of whether or
not they get posted to some archive. All this rule does is insure that everyone
sees stale data in the archive in such cases.

And even if you think having groups consider stale data is a good thing, it
doesnt' even accomplish that. Over the years I've gotten many notices to the
effect of "revision didn't make the cutoff, please go do this other place for
the latest revision". Alternately, there's the slide listing the revisions that
have already been made.

In my experience the only useful thing the cutoff has done is to provide a neat
example Sieve script for RFC 5260.

> review cycles. Why should updates to these be barred?

And for that matter why have a cutoff for new drafts? If there's was ever a
problem with people creating new documents and bringing them to the attention
of the group during the meeting I sure wasn't aware of it. And since we now
reopon the gates during the week, the only meeting that's actually protected by
this is monday morning slot.

> anyone see a reason why this should be the case?

Almost certainly because enforcing the restriction on documents under
consideration by the group would require that the posting facility be aware of
document statuses at the group level. AFAIK that's not information that's
centrally tracked at this time.

IMO the draft cutoff does a lot more harm than good and should be absolished.
And if groups need to have rules about late changes or new documents why not
leave that to the groups themselves?

				Ned

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 21 Jul 2008 11:56:08 -0500

Ned,

	Just to be clear, my last response below was to the notion 
that it is okay for a working group to consider the drafts that 
are ready to be considered, as opposed to those that are nearing 
(or past) their milestones.  This was how you responded to part 
of Spencer's (I think) assertion that some WG chairs do try to 
create reasonable schedules (i.e - the reference to staggered 
milestones, which has been elided below).

	You seemed to be saying that such effort is wasted in your
experience.

	Also, I was not asserting that any existing rules are in
place to help with that, nor do I think automated rules would be 
likely to help.  But I do think that working group chairs and 
(where necessary) area directors should invest some effort in 
ensuring that the work is progressing to schedule and that one 
of the ways to do that is to create schedules that make sense.  

	Assuming the schedules do make sense, sticking to a schedule 
- it seems to me - would be easier if the working group were to 
work on things based on where they should be (from the schedule), 
as opposed to where they are.  And that would mean it would be a 
more productive use of a working group's time to spend it trying
to determine why a draft that should be at a certain point is not 
at that point than to spend an equivalent amount of time discussing 
work that just happens to be ready to discuss.

	There are issues with this, particularly in an all-volunteer
organization.  But let's face the fact that the IETF is a volunteer
organization - for the most part - in name only.  Most people don't
have to have their arms twisted to be a WG chair (or AD) in an IETF
WG (or Area) in which their employer has interest, and the people
who are doing the work in the working groups are - mostly - not
doing it for free either.  People are certainly not getting enough 
compensation for the work they're doing in the IETF, but I think it
unlikely that it would be impossible to get people to continue to
do it if there was the additional cost of doing it according to a
set of milestones, according to a plan they themselves helped to 
set up...

--
Eric Gray
Principal Engineer
Ericsson  

> From: Ned Freed [mailto:[email-masked]] 
> Sent: Monday, July 21, 2008 11:02 AM
> To: Eric Gray
> Cc: [email-masked]; Spencer Dawkins; [email-masked]
> Subject: RE: Progressing I-Ds Immediately Before Meetings
> Importance: High
>

---

From: [email-masked]
Date: Mon, 21 Jul 2008 15:14:56 -0700 (PDT)

> are ready to be considered,

That depends on what you mean by "ready". it is axiomatic that draft
availability is only the first step to something being "ready". Obviously
sufficient people have to have read the thing, or if they've already read it
familiarize themselves with whatever has changed.

> as opposed to those that are nearing
> (or past) their milestones.

I see no connection here at all. A draft is either ready for consideration or it
isn't. What the milestones say is almost completely irrelevant. (I suppose it
might be different if we consistently got things done before milestone dates
and some subset of the participants were scheduling reviews on the basis of
milestone dates and not WG agendas, but AFAIK the former is very rare and the
latter unheard of.)

> This was how you responded to part

> 	You seemed to be saying that such effort is wasted in your

I never said or even implied any such thing. For about the dozenth time, this
is about eliminating the mechanical cutoff date. Nothing else.

This endless stream of strawmen is starting to grate.

> of the ways to do that is to create schedules that make sense.

Sure, that's all motherhood and apple pie. But the trick is to try and find
actual incentives to make this happen. In my experience streamlining processes
and getting rid of unnecessary rules are pretty much the only incentives we
have available, whereas rules creating additional hoops to jump through, as you
seem to be suggesting, invariably act as strong disincentives.

> work that just happens to be ready to discuss.

I'm sorry but I just don't see it. Far and away the most common reason drafts
aren't ready is because someone in some important role didn't have enough time
to do something. In such cases brief consideration of whether a switch of
authorship, or reviewership, or whatever the draft is stuck on makes sense. And
if the draft is stuck because of substantive disagreement then that's obvious
something the group needs to spend time resolving.

But a massive "why are we not meeting milestones" introspection-fest would send
me, and I suspect a lot of other people, running out of the room, never to
return. I nave neither the time nor the patience to indulge in such nonsense.

> organization - for the most part - in name only.

Well, if you want facts, how about the *fact* that not only did I receive zero
compensation for most of the time I spent developing MIME, I paid to attend
most of the IETF meetings in those days out of my own pocket.

Even now Sun, my employer, mildly encourages my participation as long as it
doesn't cut into my getting my regular work done. But they certainly doesn't go
out of their way to have me do IETF stuff, let alone insist on it.

And I don't think I'm alone in this. Quite a few people participate for reasons
other than their employers push them to do it. Heck, some of the biggest
participants in some of the groups I'm in have never attended a meeting because
they have no sponsorship to do so. Their participation is entirly remote.

This probably varies a lot from one group to the next.

> Most people don't
> doing it for free either.

This may well be true in your neck of the woods. But it's yet another thing I'm
pretty sure doesn't generalize across the entire IETF.

>  People are certainly not getting enough

Impossible is exactly what it would be in quite a few cases I'm familiar with.

All of which argues once again that Procrustean rules are a bad idea. Maybe
strict adherence to milestones would help in some groups (I'm very skeptical,
but just as you seem entirely unaware of how things actually work in my neck of
the woods, I'm prepared to give you the benefit of the doubt in yours) but it
would be a terrible idea in others. The obvious solution is to give groups the
flexibility to do what works for them.

				Ned