Subject: advice on role of a WG Chair

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Jun 2006 15:09:19 -0700

Hi,

Without going into specifics (I know this is probably written
down in a process document, if only I read those ;-)

Q: Is it the job of a WG Chair to produce a document that
    the WG wants, or is it to produce a document that s/he thinks
    the IESG will approve?

thanks,
Andy

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 22 Jun 2006 17:12:37 -0500

IMO:
The chair should be working in the interest of the WG and to produce a
document that has consensus and WG members believe is needed without having
to worry about whether the IESG will approve it.

-Raj

---

From: Brian Pawlowski <[email-masked]>
Date: Thu, 22 Jun 2006 15:15:56 -0700 (PDT)

Well, yeah, except the working group chair should also be working within
the context of the IETF and address issues of security and dependencies
and IP (patent) implications - that's pretty global to all documents
produced.

The WG represents the technical area expertise and I assume within the above
constraints they are producing a useful protocol etc. specification that
is put forward to the IETF/IESG.

Maybe the specifics would help:-)

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Jun 2006 15:22:03 -0700

> to worry about whether the IESG will approve it.

Well, obviously "both interests" is the ideal answer.
This is fine if you have all the time in the world,
and don't mind waiting until the IESG review to
make significant changes to the document.

I guess all a WG Chair can do is point out that there is
precedence for the IESG taking issue with specific
design choices (or omissions) and there is a chance
the document won't get approved.

As a Doc Shepherd, when I'm asked the survey question,
"Do you know of any issues...", I just write it down
and let the IESG eventually send the draft back to the WG.

Not exactly an optimal process.

Andy

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Jun 2006 18:55:15 -0400

>>>>> "Andy" == Andy Bierman <[email-masked]> writes:

    Andy> I guess all a WG Chair can do is point out that there is
    Andy> precedence for the IESG taking issue with specific design
    Andy> choices (or omissions) and there is a chance the document
    Andy> won't get approved.

No.  There are other things you could do.  You can ask your AD to get
involved.  If you know now that your AD will not accept the document
(or would rather not accept the document) you can apply significant
back-pressure on the WG.  Your AD can help a lot with this process.

--Sam

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Jun 2006 16:06:47 -0700

> back-pressure on the WG.  Your AD can help a lot with this process.

So you are saying the WG Chair/Doc Shepherd needs to be able
to answer "yes" to question (1a).  This is still a theoretical
issue (this time), as to whether the final document will contain
or not contain text that is likely to cause it to be returned
to the WG.

It's possible that the WG Chair/Doc Shep and AD don't agree
on the specific issue either, which could cause the
Doc Shep to answer "no" to (1a), and still have WG and AD consensus.

Andy

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Jun 2006 19:12:38 -0400

Sure.  And if it is important you can always ask the IESG or the IETF
about an issue.  If we know we need early review we can probably get
it.

And don't forget the IAB is there to help.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Jun 2006 18:52:22 -0400

>>>>> "Andy" == Andy Bierman <[email-masked]> writes:

    Andy> Hi, Without going into specifics (I know this is probably
    Andy> written down in a process document, if only I read those ;-)

    Andy> Q: Is it the job of a WG Chair to produce a document that
    Andy> the WG wants, or is it to produce a document that s/he
    Andy> thinks the IESG will approve?

I cannot directly answer your question.
However one question you need to answer when submitting a document to an AD for publication is :

   1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
              to forward to the IESG for publication?  

I can tell you that if a chair forwards a document to me and answers
that question "no," then we're going to be talking.  Perhaps the chair
wants me to be bad cop; perhaps the chair wants to discuss whether the
document actually is ready.  

--Sam

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Jun 2006 19:27:50 -0700

>   the WG wants, or is it to produce a document that s/he thinks

To produce a document the IETF community wants.  Publication
of the document as an RFC needs to be supported by a consensus
of the IETF.  -- Kurt

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Jun 2006 08:45:34 +0200

> of the document as an RFC needs to be supported by a consensus

I think the answer is the union of these.

There has to be WG rough consensus,
and there has to be IETF rough consensus,
and the IESG has to approve it, which in practice means finding no
serious residual problems.

This is clear enough in RFC 2026, and the IESG's current view of what
amounts to a serious residual problem is given at
http://www.ietf.org/u/ietfchair/discuss-criteria.html
(for standards track and BCP documents). Please note
the "non-criteria" in that document too.

The WG Chair(s), under the PROTO process, are supposd to shepherd the
document through all three stages (i.e. their job includes facilitating
the resolution of IETF Last Call comments and IESG DISCUSS comments).
Also, note that substantive changes after IETF Last Call or IESG review
should be checked with the WG.

Many people believe that this whole process will go much more
smoothly for drafts that have had early cross-area review from
people outside the WG, before they get to the stage of WG Last
Call. That is in the WG Chairs' hands too.

    Brian

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 23 Jun 2006 17:43:41 -0700

You have asked a hard questions. The WG Chairs job has many things  
they have to do and I think those are just two of the things that  
need to happen. When I am acting as a chair one of the thing I try to  
think about is that there are many hurtles a good standard should  
meet and the WG chair needs to help them meet all of these. Some of  
them are

1) the WG has rough consensus on the document
2) the IETF community as a whole agrees it is acceptable
3) the IESG does not see some harm caused by it
4) implementers are willing to implement it
5) user and operators are willing to use and deploy it
... and about a million more ....

Is 1 more important than 3? who knows, who cares, both need to be  
dealt with. If my WG was doing something I thought the IESG would  
barf on, I would tell the WG that I suspected the IESG would barf on  
that and I would even ask my AD for some help in claiming that I was  
not nuts. If the WG still wanted it and had consensus to forward it  
to IESG, I would think it was my responsibility to forward it up the  
the IESG and see what happened. If the WG really thought it was a  
good idea and could explain why, then the Chair is going to be one of  
the people that has to educate the IESG on what this makes sense. I  
think it is pretty hard to predict what the IESG or IAB opinion will  
be on any given topic. For some topics, like do we need more cookies,  
you might be able to predict the response but for any complex issues,  
these groups are made of a bunch of people with wide variety of  
opinions. I would certainly tell my AD if I felt there was an area to  
be concerned about from an IESG point of view.

I don't know that this answers helps much - perhaps a short answer  
would be I think of one of the key jobs of the chair is to facilitate  
the WG producing a good standard (or other document type)  that the  
WG wants and help the WG understand what the IESG would have problems  
with since that will impact the WG goal of producing a standard.  
Making consensus calls are one of the most important parts of this  
for the chair and the consensus call a chair makes is about WG  
participants - it is not a call about IESG consensus or IETF  
consensus as a whole.

Cullen

(my 2 cents as a chair)

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jun 2006 18:44:14 -0700

Cullen Jennings wrote:
> 
> You have asked a hard questions. The WG Chairs job has many things they 

The whole point of my email was to raise the question
"Who does the WG Chair really work for?"

I've been doing the WG Chair thing awhile now,
and so I am aware of many of the tools of the trade.

This is really just a thought experiment.
In reality I know the document in question isn't
going to leave the WG until the co-chairs and ADs
are happy with it.

Idealistically, a WG Chair is supposed to only serve the
best interests of the entire Internet Community.
In reality, the job is to get the highest quality document
approved by the IESG in the shortest amount of time.

#include <timeliness_quality_rant.h>

Andy

> have to do and I think those are just two of the things that need to 
> happen. When I am acting as a chair one of the thing I try to think 
> about is that there are many hurtles a good standard should meet and the 
> WG chair needs to help them meet all of these. Some of them are
> 
> Is 1 more important than 3? who knows, who cares, both need to be dealt 
> with. If my WG was doing something I thought the IESG would barf on, I 
> would tell the WG that I suspected the IESG would barf on that and I 
> would even ask my AD for some help in claiming that I was not nuts. If 
> the WG still wanted it and had consensus to forward it to IESG, I would 
> think it was my responsibility to forward it up the the IESG and see 
> what happened. If the WG really thought it was a good idea and could 
> explain why, then the Chair is going to be one of the people that has to 
> educate the IESG on what this makes sense. I think it is pretty hard to 
> predict what the IESG or IAB opinion will be on any given topic. For 
> some topics, like do we need more cookies, you might be able to predict 
> the response but for any complex issues, these groups are made of a 
> bunch of people with wide variety of opinions. I would certainly tell my 
> AD if I felt there was an area to be concerned about from an IESG point 
> of view.
> 
> I don't know that this answers helps much - perhaps a short answer would 
> be I think of one of the key jobs of the chair is to facilitate the WG 
> producing a good standard (or other document type)  that the WG wants 
> and help the WG understand what the IESG would have problems with since 
> that will impact the WG goal of producing a standard. Making consensus 
> calls are one of the most important parts of this for the chair and the 
> consensus call a chair makes is about WG participants - it is not a call 
> about IESG consensus or IETF consensus as a whole.
> 
> Cullen
> 
> (my 2 cents as a chair)
>

---

From: Blake Ramsdell <[email-masked]>
Date: Fri, 23 Jun 2006 21:08:24 -0700

> "Who does the WG Chair really work for?"

I have a short answer, and I'm sure Russ will like it ;) -- "The WG 
Chair serves at the pleasure the WG's AD".

"pleasure" is somewhat fuzzy here. Talk to your AD. But basically the AD 
decides if you live or die, so they're the one to keep happy.

But the bottom line is that the WG should perform in a way that is 
consistent with their charter, and the WG should progress through its 
milestones. The WG chair is the first buck-stopping-point of 
accountability for that.

If a WG isn't making this progress, then it ultimately becomes the AD's 
problem. The AD can solve that problem in a fairly drastic way by 
replacing the WG chair. Thus, I keep my AD happy (or at least I think 
he's happy).

As far as drafts go, I release what the WG wants, which I would hope is 
consistent with what the IESG wants. If these are out of sync, well, the 
IESG wins.

But if you're that far apart in what the WG has consensus on, and what 
the IESG wants, then that's an indicator of a larger problem it seems. 
I'm not going to pretend like I have any kind of meaningful perspective 
on the history of these kinds of issues. But I can pretend that I know 
what the outcome was (the IESG won).

Corrections welcome. I'm just speaking from my own understanding and the 
way I work as a WG chair, which could be completely misaligned with reality.

Blake
-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Jun 2006 11:46:49 +0200

> approved by the IESG in the shortest amount of time.

Idealistically, our process and procedures would make
those two statements equivalent.

> #include <timeliness_quality_rant.h>

#include <process_update_rant.h>

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Jun 2006 17:07:20 +0200

Incidentally, a possible revision to RFC 2418 will
be discussed during the General Area open meeting,
Friday morning in Montreal. If people feel that it's
short on guidance about the WG chair's role and
responsibilities, that would be very relevant.

See http://www3.ietf.org/proceedings/06jul/agenda/genarea.txt

While I'm typing - there are still lots of missing agendas.
They're due by Monday, i.e. *before* the US holiday.

     Brian

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 Jun 2006 10:28:25 -0700

> those two statements equivalent.

Yes it would.
IMO, there is a finite amount of "total human effort hours"
available to the IETF.  Hours spend on Process are not being
spent on Engineering.

For some of us, it's always been about the Technology.
The problem began with the IETF focusing more on the Document
than the Technology.  Now the IETF is focusing on the Process
for producing the Document, as well as the Document.  Whatever
hours are left over are for Technology I guess.

Andy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jun 2006 09:36:23 +0200

> available to the IETF.  Hours spend on Process are not being

Andy, objectively, and even for those of us whose job description
includes worrying about Process, I don't think the number of hours
spent on process is really all that large.

> For some of us, it's always been about the Technology.

That's why I came for sure.

> than the Technology.

Really? I don't quite understand that comment. Or let's say that
as the technical community got bigger and became world-scale,
there really wasn't any way to agree about the technology without
good documents.

> Now the IETF is focusing on the Process

I don't it as *the* focus, but we can't just let it slide
completely either.

> hours are left over are for Technology I guess.

I truly hope that for most participants, that is most of
their IETF hours.

>> #include <process_update_rant.h>

My rant is actually along the lines of let's make simple
incremental process improvements rather than complaining
about the state of the universe.

     Brian

---

From: Andy Bierman <[email-masked]>
Date: Tue, 27 Jun 2006 07:49:38 -0700

Brian E Carpenter wrote:

There is a perception (perhaps only mine) that the technology,
and the timely delivery of standards containing the technology,
is not given a high enough priority.

Of course we should strive to have a perfect process and
perfect documents, but Engineering is often about trade-offs,
and Good Engineering is often a matter of making the right ones.

IMO, WGs should be nuked if they don't finish on time.
That would wake a few people up.  The IESG does a good
job chartering WGs, but often WGs treat the charter and the
milestones as some sort of "wish list".  Force the WGs to make
tough choices, and make them quickly.  Force WGs to learn
how to complete finite work in finite time.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 27 Jun 2006 16:54:06 -0700

Juergen Schoenwaelder wrote:
> On Tue, Jun 27, 2006 at 09:36:23AM +0200, Brian E Carpenter wrote:
> 
> <soap>
>   The last individual -00 ID I submitted got rejected because I used
>   the usual abbreviation of my last name (which worked for ten years)
>   but the abbreviation does not appear in my current email address and
>   this violates a new rule that got introduced recently. So I
>   resubmitted the ID with another email address inside which complies
>   to the latest ID naming consistency rules and the ID finally showed
>   up after several days delay. Now, as explained in some other thread,
>   my subscription to this mailing list (and who knows what other
>   places) has been silently changed as a side effect of this ID
>   submission. I will surely update my email address again in a
>   subsequent update of the ID to see whether things magically change
>   back. (Note that I am using xml2rfc to bypass all the other hassles
>   with correctly formatting IDs and boilerplate texts.)
> </soap>

We have a documentation rule that the format of the I-D name has
to exactly match a certain section of the author's email address
or the draft is automatically rejected? (!)

QED ;-)

>...
> /js

Andy

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jun 2006 12:07:26 +0200

> is not given a high enough priority.

I'm sure it's not only you, but I go by the facts - in the year up
to Dallas, the IESG approved ~390 drafts. I'm not sure how to count
the number of process related drafts, but from a quick
look at the tracker, there were 8 to 10 process related ones,
about 2.5%.

> how to complete finite work in finite time.

I certainly believe that milestones should be made to stick,
but this remains a volunteer community that tries to resolve
dissent instead of voting it down, and that has consequences.

     Brian

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Jun 2006 01:27:49 +0200

<soap>

While the story above has its entertainment value (especially if you
compare this with the way we did work ten years ago when I first got
involved into IETF efforts) and as an isolated example surely cannot
demonstrate anything in general (and does not even intend to do so), I
do share Andy's concerns that the focus has shifted too much from
Technology to Documents (and Process).

Good documents have always been desirable. Running code has been even
more valuable to achieve wide-spread deployment (especially if it is
in some form of open source).

I am waiting for a proof that the stringent documentation and process
rules the IETF has put in place over the last few years actually help
producing better documents and more running code and ultimately widely
deployed technology.

/js

-- 
Juergen Schoenwaelder		    International Uamavisd-new,
	port 10024)
	with ESMTP id 10617-10; Wed, 28 Jun 2006 01:27:51 +0200 (CEST)
Date: Wed, 28 Jun 2006 01:27:49 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Mail-Followup-To: Brian E Carpenter <[email-masked]>,
	Andy Bierman <[email-masked]>,
	Working Group Chairs <[email-masked]>
Cc: Working Group Chairs <[email-masked]>
Subject: Re: advice on role of a WG Chair
Reply-To: [email-masked]

<soap>

While the story above has its entertainment value (especially if you
compare this with the way we did work ten years ago when I first got
involved into IETF efforts) and as an isolated example surely cannot
demonstrate anything in general (and does not even intend to do so), I
do share Andy's concerns that the focus has shifted too much from
Technology to Documents (and Process).

Good documents have always been desirable. Running code has been even
more valuable to achieve wide-spread deployment (especially if it is
in some form of open source).

I am waiting for a proof that the stringent documentation and process
rules the IETF has put in place over the last few years actually help
producing better documents and more running code and ultimately widely
deployed technology.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

niversity Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jun 2006 15:23:38 +0200

I'll try to figure out what's going on here. Meanwhile, do please
consider the statistics we have to deal with:

Between Vancouver and Dallas:
531 new I-Ds (56% in last 4 weeks)
995 updated I-Ds (58% in last 4 weeks)

Inevitably, you will see more and more robotic processing
with this many drafts to handle. We just need to give the robots
the correct instructions.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jun 2006 15:31:04 +0200

Juergen,

> producing better documents and more running code and ultimately widely

Those are three questions. I'm sure the documents are better
(I mean, just look carefully at RFC 791) but the question is whether
that has produced more interoperable code. I don't know where
I'd go to answer that; I just feel it has to be true.

As for wide deployment, don't you think that if 10% of our standards
get wide deployment we should be happy?

    Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Jun 2006 17:47:33 +0100

> IMO, WGs should be nuked if they don't finish on time.

How many WG will be around after that?
(Most WGs I participate in are late, but making progress)

---

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Jun 2006 11:02:58 -0700

> (Most WGs I participate in are late, but making progress)

What I am suggesting is that WGs take a more project-oriented
view of their work.  The charter milestones seem almost irrelevant
to many WGs -- because the Chairs know they can keep getting
extension after extension.

If you know you have a 12 - 18 months to get done -- or else --
there would be more incentive to focus, keep it simple,
and get work done in useful increments.

This is too simple of course and won't work, because vendors
who don't want a standard at all will just filibuster until
the clock expires and the standard dies.

If we required running code + an I-D to start new protocol
work, instead of just an I-D, there would be less work,
but more than 10% of it would end up widely deployed.
(But that's a new rant ;-)

Andy

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 29 Jun 2006 14:55:42 -0400

Yes, Brian, I would like you to figure out what's going on. Has the IETF
lost control of the draft submission process?

I had a draft rejected yesterday (see attached message) with the claim
that part of the boilerplate text HAD to be on the last page and was
PROHIBITED from appearing on any other page (see attached message). Just
last week I successfully submitted
http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-00.txt
, which has this supposed "defect" with no problem. I can't find this
requirement in the ID guidelines and the idnits tool does not complain
about it. Is the actual requirement now, for all practical purposes,
that you have to prepare your draft with xml2rfc? I have changed and
resubmitted the rejected draft with a polite note but I am certainly
tempted to be a lot less polite here. We seem to have multiple
undocumented, bizarre, and unbelievably persnickety requirements being
sprung as surprises *during the ID submission cycle for a meeting*.

Maybe from the point of view of someone within the IESG/IAB like you
there has always been a lot of process so you don't see much change. And
maybe from the point of view of a technical contributor who just
participated in WG mail lists and/or speaks up at meetings there isn't
much change. But from the point of view of document editors and WG
chairs, the IETF, which used to be an informal organization, is now
burdened with ever more ridged and bureaucratic process. If you can't
see this, consider that your perspective may blind you to it.

Donald

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, June 28, 2006 9:24 AM
To: [email-masked]
Cc: Working Group Chairs
Subject: I-D woes [Re: advice on role of a WG Chair]

Inevitably, you will see more and more robotic processing with this many
drafts to handle. We just need to give the robots the correct
instructions.

    Brian

Juergen Schoenwaelder wrote:
>>>The problem began with the IETF focusing more on the Document than 
>>>the Technology.
>>
>>Really? I don't quite understand that comment. Or let's say that as 
>>the technical community got bigger and became world-scale, there 
>>really wasn't any way to agree about the technology without good 
>>documents.
> 
> 
> <soap>
>   with correctly formatting IDs and boilerplate texts.) </soap>
> 

> /js

Subject: Re: draft-ietf-dnsext-2929bis-03.txt
From: <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: <[email-masked]>, "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 28 Jun 2006 22:10:20 -0400

The Secretariat CANNOT process your Internet-Draft submission due to
following reason(s):

* All Internet-Drafts must include the following statement on the last
page: This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

* All Internet-Drafts must not include the following statement any other
page than the last page: This document and the information contained
herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Please correct and resumit.

> Hi,
>
> Attached is an updated draft in the DNSEXT working group. Its file name
> is
>
> 	draft-ietf-dnsext-2929bis-03.txt
>
> Please post,
>
> Thanks,
> Donald
>
>  =========================================================
>  Donald E. Eastlake III       [email-masked]
>  Motorola Laboratories              +1-508-786-7554 (work)
>  111 Locke Drive                    +1-508-333-2270 (cell)
>  Marlboro, MA 01752 USA
>

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 29 Jun 2006 15:05:29 -0400

Today I had a working group member have two documents bounced.
One was bounced because the Copyright date was 2005 instead of 2006
and the other was bounced because the draft version number was off
by one.

I should point out that both items were noticed by the document
author and second copies of the draft had been submitted as
replies to the I-D publication request acknowledgment several
hours later.

Upon receipt of the bounce messages this morning, the document
author once again submitted the corrected versions of the drafts
in reply to the bounce messages.

The document which was originally submitted with the wrong version
number was bounced a second time for the same reason.  Even though
the attached revised document did in fact have the correct version
number.

Personally I think that when a date is clearly incorrect due to
an oversight or the version number that [email-masked] staff should
simply make the corrections and publish the documents.  They can
send back a note indicating that the corrections were made.

Jeffrey Altman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 29 Jun 2006 16:19:54 -0400

> send back a note indicating that the corrections were made.

Folks, many of the items you're complaining about are the result of 
automated checks.  The checks happen because the volume of submitted I-D's 
is large, and the number of people available to deal with them is not.  The 
first two bounces Jeff describes were legitimate problems with the 
submitted documents, which were caught by an automated check without taking 
up any time of the people at the secretariat, all of whom have quite enough 
to do getting ready to run a meeting that starts, officially, 10 days from 
now.

My guess would be that the second bounce was the result of 
double-submitting the "corrected" version - one corrected submission was 
accepted, at which point the second one now had a duplicate version.  The 
answer to this is to not double-submit the correction.  I suggest also not 
submitting credit card payment forms more than once, as many of those have 
less stringent checks and will happily bill you twice.

The problems Don encountered sound like bugs.  Instead of ranting to the 
wg-chairs list about "requirements being sprung as surprises", consider the 
possibility that you encountered a bug, and report it.

It's also worth noting that the I-D submission cutoff was Monday, so your 
submission in fact did not fall during the I-D submission cycle for a 
meeting.

-- Jeff

---

From: "James Kempf" <[email-masked]>
Date: Thu, 29 Jun 2006 14:44:55 -0700

In April, I had two WG documents that the Secretariat never posted, even 
though I sent them in twice and had automated confirmations. Last Fri. I had 
the same thing happen, except this time, I didn't even get an automated 
reply. Now, of course, this means that the document missed the deadline. 
Since this document had gone through last call as was being sent to the 
IESG, it was very inconvenient.

            jak

----- Original Message ----- 
From: "Jeffrey Hutzelman" <[email-masked]>
To: "Jeffrey Altman" <[email-masked]>; "Working Group Chairs" 
<[email-masked]>
Sent: Thursday, June 29, 2006 1:19 PM
Subject: Re: I-D woes [Re: advice on role of a WG Chair]

> is large, and the number of people available to deal with them is not. 
> The first two bounces Jeff describes were legitimate problems with the 
> submitted documents, which were caught by an automated check without 
> taking up any time of the people at the secretariat, all of whom have 
> quite enough to do getting ready to run a meeting that starts, officially, 
> 10 days from now.
>
> wg-chairs list about "requirements being sprung as surprises", consider 
> the possibility that you encountered a bug, and report it.
>
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 29 Jun 2006 18:03:24 -0400

On Thursday, June 29, 2006 02:44:55 PM -0700 James Kempf 
<[email-masked]> wrote:

> though I sent them in twice and had automated confirmations. Last Fri. I
> had the same thing happen, except this time, I didn't even get an
> automated reply. Now, of course, this means that the document missed the
> deadline. Since this document had gone through last call as was being
> sent to the IESG, it was very inconvenient.

You never got a reply, or your spam filter ate it?
In either case, I suggest sending mail to ietf-action and asking after the 
case where you sent something in and never got an autoreply.  If nothing 
else, they will try to track down the problem so it doesn't happen in the 
future.  I would not be surprised if they also did something about 
publishing your I-D, given that it was submitted on time.

-- Jeff

---

From: "James Kempf" <[email-masked]>
Date: Thu, 29 Jun 2006 15:08:59 -0700

> You never got a reply, or your spam filter ate it?

I never got a reply. I checked my spam folder.

> publishing your I-D, given that it was submitted on time.

That's what  I did, except I sent email to the Secretariat. I'm not 
optimisitic, however, in April, I did not get any action even after sending 
the draft in twice, and numerous emails to the Secretariat, until finally I 
had one of the INT ADs look into the matter.

            jak

---

From: <[email-masked]>
Date: Fri, 30 Jun 2006 06:42:20 +0300

Hi all,

>Yes, Brian, I would like you to figure out what's going on. 
>Has the IETF lost control of the draft submission process?

Just to throw in my two cents - I had 1 wg draft bounced because of
wrong copyright data (2005) and an individual submission was bounced
because of capitalization.

Original:
Just to throw in my two sense 
"Hybrid on-path off-path approach for end-to end signalling accross NSIS
domains (HyPath)"
draft-cordeiro-nsis-HyPath-00

The author was told to submit the draft again with a lower case file
name,
on page 1 of the draft.  Bouncing a draft because of this seems odd.

My overall concern is that we are focusing more energy on nits, making
it harder to get the real work done.

John

---

From: Jari Arkko <[email-masked]>
Date: Fri, 30 Jun 2006 07:44:55 +0300

Folks,

I feel your pain about the submission problems. The current situation
is indeed bad. I can not estimate how frequent the problem is, I think
we are still talking about isolated cases, but if you are hit with this
problem it typically happens at the worst time and can disrupt your
work.

Having said that, we do have real reasons why the boilerplate language
is there, and I do not see the requirement for it going away anytime soon.
We should not be sending drafts back for long lines etc, but I do think that
we need to check for the boilerplate. And there is no way we can do
that without tools. The problem is, the current tools are not all that
great, but as Henrik noted the secretariat is in the process of (a )moving
to a better tool and perhaps more importantly (b) implementing the
submission web tool, which makes it possible for the submitter to see
and correct the problems as he submits.

In addition to boilerplate issues, we also need to make sure that
the draft is suitable for the IETF's access tools to the drafts,
the tracker, etc. It sounds like John's filename capitalization problem
is related to that. Its likely that we need to check for a few other
things too, like length of file name, ability to find the author
contact information from the draft, etc. Again, the submission tool
should free you from late surprises in this regard.

Also, the secretariat has always been receptive to fixing these
problems even after the deadline. You should be able to resubmit
a fix.

Finally, there may also be other problems. James' problem sounds
like a re-run of the problem they had at netlmm had a few months ago.
At that time all we could determine was that the secretariat was not
receiving the e-mails from the submitters, but it was never
determined why this happened. I have now sent mail to the
secretariat and have gotten an automated response back, so I'm
hoping this case will be solved soon. In any case, I have started
my AD review on the document which was what you wanted to
happen anyway, so I hope we're not loosing too much time over
this.

In the meantime, its been my observation that if your draft is prepared
in XML, you use a recent version of XML2RFC, and you pass the idnits
web check, then you are far less likely to have problems than in other
cases.

If you encounter a problem that looks like a bug, complain to
[email-masked].

--Jari

---

From: <[email-masked]>
Date: Fri, 30 Jun 2006 08:02:38 +0300

Jari,

I have no problem about checking for nits (as some of the 
nits do have significant impact upon those people reading the
drafts) & the boilerplate is there for good reason.

I think the biggest take-away from this thread is that there
have been changes to the submission procedure which have
been unannounced & undocumented (perhaps known only by the
Tools team, IESG & Secretariat).

We all deal with software, so we understand that there will
always be bugs, especially in the initial deployment of the
sw.  Updating production software around critical deadlines
is never a good idea - but I don't know if this is the case.

In the future, it might be useful for the Secretariat to
announce changes, with a note of how to follow-up if there
are any problems.  Something along the lines of:

 We have updated our automated draft submission mechanism,
 corresponding to "insert appropriate reference here".  This
 will help us process drafts more efficiently.  If you have
 any concerns or comments, contact us at [email-masked].

Or something like that.  

When working group members or draft authors come to working group
chairs and ask us why their drafts were bounced, where is the
stated policy about the cause of the bounce action - it isn't
a good situation if the chair can just shrug our shoulders and
mumble "dunno."

thanks,
John

>From: ext Jari Arkko [mailto:[email-masked]] 
>Sent: 30 June, 2006 07:45
>To: Loughney John (Nokia-NRC/Helsinki); 
>[email-masked]; James Kempf
>Cc: [email-masked]; IETF TOOLS discussion
>I feel your pain about the submission problems. The current 
>situation is indeed bad. I can not estimate how frequent the 
>problem is, I think we are still talking about isolated cases, 
>but if you are hit with this problem it typically happens at 
>the worst time and can disrupt your work.
>
>Having said that, we do have real reasons why the boilerplate 
>language is there, and I do not see the requirement for it 
>going away anytime soon.
>We should not be sending drafts back for long lines etc, but I 
>do think that we need to check for the boilerplate. And there 
>is no way we can do that without tools. The problem is, the 
>current tools are not all that great, but as Henrik noted the 
>secretariat is in the process of (a )moving to a better tool 
>and perhaps more importantly (b) implementing the submission 
>web tool, which makes it possible for the submitter to see and 
>correct the problems as he submits.
>
>In addition to boilerplate issues, we also need to make sure 
>that the draft is suitable for the IETF's access tools to the 
>drafts, the tracker, etc. It sounds like John's filename 
>capitalization problem is related to that. Its likely that we 
>need to check for a few other things too, like length of file 
>name, ability to find the author contact information from the 
>draft, etc. Again, the submission tool should free you from 
>late surprises in this regard.
>
>Also, the secretariat has always been receptive to fixing 
>these problems even after the deadline. You should be able to 
>resubmit a fix.
>
>Finally, there may also be other problems. James' problem 
>sounds like a re-run of the problem they had at netlmm had a 
>few months ago.
>At that time all we could determine was that the secretariat 
>was not receiving the e-mails from the submitters, but it was 
>never determined why this happened. I have now sent mail to 
>the secretariat and have gotten an automated response back, so 
>I'm hoping this case will be solved soon. In any case, I have 
>started my AD review on the document which was what you wanted 
>to happen anyway, so I hope we're not loosing too much time over this.
>
>In the meantime, its been my observation that if your draft is 
>prepared in XML, you use a recent version of XML2RFC, and you 
>pass the idnits web check, then you are far less likely to 
>have problems than in other cases.
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 30 Jun 2006 08:42:15 +0200

Hi,

  I want to respond primarily to one point below:

> Tools team, IESG & Secretariat).

Exclude the Tools Team here - if we'd received an indication of
changed procedures, I would have updated idnits to warn about
them.

>  any concerns or comments, contact us at [email-masked].

I very much agree.

> a good situation if the chair can just shrug our shoulders and

Again, I agree.  And of course, you can imagine that a similar
situation has happened a few times when people contact me as idnits
maintainer and wonder why a draft that passes idnits gets rejected -
I can only say that if I'd known, I'd have tried to update idnits
accordingly...

Regards,

	Henrik

---

From: <[email-masked]>
Date: Fri, 30 Jun 2006 09:45:19 +0300

Hi Henrik,

>> I have no problem about checking for nits (as some of the nits do
have 
>> significant impact upon those people reading the
>> I think the biggest take-away from this thread is that there have
been 
>> changes to the submission procedure which have been unannounced & 
>> undocumented (perhaps known only by the Tools team, IESG & 
>> Secretariat).
>
>Exclude the Tools Team here - if we'd received an indication 
>of changed procedures, I would have updated idnits to warn about them.

Just for the record, I'm not accusing anyone - hence the 'perhaps' in
my statement above.  I guess this just makes my point even stronger - 
when there are some changes to the submissions process, a small public 
note would be helpful.

thanks,
John

---

From: Jari Arkko <[email-masked]>
Date: Fri, 30 Jun 2006 09:47:04 +0300

>a good situation if the chair can just shrug our shoulders and
I can take it up with the secretariat to see if we actually could update
the I-D requirements to state what is really required today (like no
uppercase
in the filename). Beyond that, I think we should use our resources to go
to the new tool, rather than explaining what's wrong with the old one
or updating it...

--Jari

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 30 Jun 2006 09:45:42 +0200

Hi John,

> when there are some changes to the submissions process, a small public 

Oh, no problem, I didn't take it as accusatory -- I just wanted to
let you know that we didn't know about this either.

And I continue agreeing on your point regarding the announcement of
changes to the submission process :-)

Regards,

	Henrik

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jun 2006 17:28:33 +0200

> send back a note indicating that the corrections were made.

Honestly, that isn't going to happen, and it's certainly not going
to happen once we get the submission tool in place.

The other things you describe I can only put down to overload
and I will make sure the IAD is aware. It's his domain these days,
not mine.

    Brian

---

From: Jari Arkko <[email-masked]>
Date: Fri, 30 Jun 2006 20:05:33 +0300

FWIW, out the four reported problems, James' issue seems
like an e-mail problem (at someone's end) and John's filename
requirement is something that

    http://www.ietf.org/ietf/1id-guidelines.html

already talks about. The copyright template requirements
are also clear, and require the current year to be used.
These were announced here:

  http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01167.html

But I can't find the last page requirement
that Donald reported of from the guidelines.
Perhaps this is a bug.

Anyway, I do not believe we have a satisfactory solution
until there's real-time feedback that you can or can not
submit this draft because of <X>.

--Jari