Subject: [yam] Pre-evaluation documents

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 Jun 2010 14:59:07 +0100

Hi,
During IESG retreat 2 weeks ago several IESG members suggested that the 
WG publishes pre-evaluation documents as Informational RFCs using the 
standard IETF process. I think this is a reasonable request.

Opinions?

---

From: SM <[email-masked]>
Date: Tue, 08 Jun 2010 08:39:17 -0700

Hi Alexey,
At 06:59 08-06-10, Alexey Melnikov wrote:
>During IESG retreat 2 weeks ago several IESG members suggested that 
>the WG publishes pre-evaluation documents as Informational RFCs 
>using the standard IETF process. I think this is a reasonable request.

The pre-evaluation I-Ds already have Informational as the intended 
status.  The template used mentions that:

   "This Internet-Draft is not meant to be published as an RFC.  It is
    written to facilitate processing within the IESG."

If the I-Ds were to be published as RFCs, they would have to go 
through an IETF-wide Last Call and the IESG would not be able to 
process the documents as "Management Items".  If the above request 
was implemented, it would adds an additional two-weeks processing 
time.  It might also require a change in the YAM WG Charter as it is 
stated that the WG consensus is obtained and the WG consults with the 
IESG on the changes (and non-changes).  The -bis I-Ds have to go 
through an IETF-wide Last Call anyway and the IETF standards process 
is followed.

If a pre-evaluation I-D is published as an RFC, an IESG Statement 
would have to be included in the document to answer the questions in 
Section 2.7 (see draft-ietf-yam-pre-evaluation-template-02).  I don't 
think that it is a good idea for the IESG to get into all that as the 
YAM WG may have more ammunition if there is any strong disagreement.

Regards,
-sm

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 Jun 2010 16:43:30 +0100

SM wrote:

>> the WG publishes pre-evaluation documents as Informational RFCs using 
>> the standard IETF process. I think this is a reasonable request.
>
> through an IETF-wide Last Call

Yes.

> and the IESG would not be able to process the documents as "Management 
> Items".

Which I think is a good thing. "Management items" are second class 
citizens during IESG telechats.

> If the above request was implemented, it would adds an additional 
> two-weeks processing time.

Yes.

> It might also require a change in the YAM WG Charter as it is stated 
> that the WG consensus is obtained and the WG consults with the IESG on 
> the changes (and non-changes).

I don't think this follows. The WG charter doesn't prohibit IETF LC.

> The -bis I-Ds have to go through an IETF-wide Last Call anyway and the 
> IETF standards process is followed.
>
> Section 2.7 (see draft-ietf-yam-pre-evaluation-template-02).

Not necessarily. IESG can do both.

> I don't think that it is a good idea for the IESG to get into all that 
> as the YAM WG may have more ammunition if there is any strong 
> disagreement.

I am not sure I follow this, so please explain.

---

From: SM <[email-masked]>
Date: Tue, 08 Jun 2010 09:57:19 -0700

Hi Alexey,
>citizens during IESG telechats.

The IESG could revert to the procedure used for the first 
pre-evaluation I-D where DISCUSSes were filed.

>I don't think this follows. The WG charter doesn't prohibit IETF LC.

If I recall correctly, the two-step approach was to get IESG 
"buy-in".  I'll use some text from Section 2.4 of 
draft-ietf-yam-5321bis-smtp-pre-evaluation-05 as an example for an IETF LC:

   "The WG will consider whether those rewordings are appropriate."

Is this WG going to ask the IETF community whether it should or 
should not consider whether the rewordings are appropriate?  That's 
like revisiting the WG Charter to determine what work the WG should 
do.  By the way, the IETF community can still comment on the 
pre-evaluation document before it is processed by the IESG.

>Not necessarily. IESG can do both.

The IESG cannot have it both ways.  If it wants to formalize the 
process used for the experiment, it should go all the way.

>I am not sure I follow this, so please explain.

This is mere speculation.  There are some well-known participants in 
this WG who are highly familiar with the IETF Standards 
Process.  There are still some documents going into the hopper that 
could end up being controversial. If the two-step experiment is 
over-formalized, there is a risk that the disagreements might pave 
the way for appeals.  With the request, you have two determinations 
of IETF consensus (used loosely).  The first one doesn't pre-empt the 
second one.  But it could still be used in the arguments about 
changes/non-changes.

In simple terms, as far as I know I don't know what will happen.  But 
I do know that the current approach is working.

Regards,
-sm

---

From: Ned Freed <[email-masked]>
Date: Tue, 08 Jun 2010 13:20:59 -0700 (PDT)

> > using the standard IETF process. I think this is a reasonable request.

I disagree. These documents are essentially a collection of notes, nothing more.
They are poorly suited for archival use, and the effort needed to get them into
a state where they would be suitable would be better spent on other tasks.

> through an IETF-wide Last Call anyway and the IETF standards process

Agreed on all points.

				Ned

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 09 Jun 2010 01:01:16 +0200

On 6/8/2010 10:20 PM, Ned Freed wrote:
> I disagree. These documents are essentially a collection of notes, nothing
> more. They are poorly suited for archival use,

It had forgotten to consider the question of 'archive' use.  It's equally easy 
to forget that Internet-Drafts remain accessible, after they have time-out.  So 
historians will still be able to see the process that was used.

> and the effort needed to get
> them into a state where they would be suitable would be better spent on other
> tasks.

There is a common view -- particularly among ADs -- that producing an RFC can be 
made simple and cheap and quick.  While yes, it is theoretically possible, I 
haven't seen it happen in practice.  From an economics standpoint, the time of 
the editor and other wg participants is often treated as being free, when 
considering these additional tasks.  I'm not saying that to be harsh or petty, 
but as a comment on the way these requirements tend to develop.  They are 
generated by reasonable intentions, but a meaningful cost-benefit assessment is 
not done, or the cost side is overly optimistic.

Personally, I am frankly delighted that anyone on the IESG considers these 
worthy of archival status.  But realistically, that requirement has already been 
satisifed.  The question, then, is what incremental benefit will be obtained 
from the always-substantial effort to convert the draft to an RFC?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Tony Hansen <[email-masked]>
Date: Tue, 08 Jun 2010 22:41:05 -0400

Didn't we consider and reject this option when we were working on the 
charter. I don't think the situation has changed sufficiently to warrant 
changing our mechanisms.

     Tony Hansen
     yam co-chair

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Jun 2010 06:59:36 +0100

> Hi Alexey,

Hi SM,

> pre-evaluation I-D where DISCUSSes were filed.

And how is this different from the procedure used recently? IESG can 
still block (reject) pre-evaluation documents. The major difference is 
that there is no public record of which AD raised a particular blocking 
issue. With proper IESG review of pre-evaluation documents, datatracker 
can be used for permanently storing such comments.

> If I recall correctly, the two-step approach was to get IESG "buy-in".

Publication of the pre-evaluation documents as RFCs doesn't change this 
agreement in any way.

> I'll use some text from Section 2.4 of 
> Is this WG going to ask the IETF community whether it should or should 
> not consider whether the rewordings are appropriate?

One purpose of the IETF LC is to alert wider IETF community about 
certain agreements reached in the WG.

You seem to be implying that there are 3 parties here (YAM WG, IESG and 
the rest of IETF community) and that the third party doesn't need to be 
involved.

Besides, there would be IETF LC for the bis document itself. During such 
IETF LC any issues could be raised. Making sure there are no surprises 
there would be in the best interests of the WG.

> That's like revisiting the WG Charter to determine what work the WG 
> should do.  By the way, the IETF community can still comment on the 

In theory you should be right. But in practice it doesn't work like 
this. Some people don't follow the yam mailing list on daily basis and I 
don't blame them.

> The IESG cannot have it both ways.

I don't understand why you say that. IESG can send additional statements 
in addition to approving documents.
I don't see any conflict in this, or any proof that IESG wants to screw 
the WG.

> If it wants to formalize the process used for the experiment, it 
> should go all the way.

I am not sure what you are suggesting. Please explain.

---

From: SM <[email-masked]>
Date: Wed, 09 Jun 2010 02:19:46 -0700

Hi Alexey,
At 22:59 08-06-10, Alexey Melnikov wrote:
>still block (reject) pre-evaluation documents. The major difference 
>is that there is no public record of which AD raised a particular 
>blocking issue. With proper IESG review of pre-evaluation documents, 
>datatracker can be used for permanently storing such comments.

That's a reason to file a DISCUSS instead of taking the "Management 
Item" path.  Dave commented on the archival which provides a public 
record of the changes/non-changes considered by the WG even after the 
I-D expires.  As there wasn't any blocking issues for the latest 
pre-evaluation draft that was processed, I cannot tell what the 
record from the IESG end will be like.  I agree that the IESG can 
still block or reject a pre-evaluation document.

>Publication of the pre-evaluation documents as RFCs doesn't change 
>this agreement in any way.

Ned mentioned that these documents "are essentially a collection of 
notes, nothing more".  In Appendix B of 
draft-ietf-yam-5321bis-smtp-pre-evaluation-05, Barry provided a 
detailed list of issues.  There was an issue raised during the 
Gen-ART review was about the requirements for advancement to Internet 
Standard.  There are two questions here; the level of detail needed 
from outside the YAM WG to understand the issues that were identified 
and requirements for advancement.  I am not implying that the 
pre-evaluation documents are not up to the quality required for 
publication.  My point is that it would require more effort to polish 
each pre-evaluation document.

Referring to Tony's message, we would be changing the 
mechanism.  Whether this changes the agreement could be subject to 
discussion.  And the discussion can be a distraction from current work.

>certain agreements reached in the WG.

The only agreement the YAM WG has with the wider IETF community is 
the YAM charter.  Anything more than that can turn into a process discussion.

>You seem to be implying that there are 3 parties here (YAM WG, IESG 
>and the rest of IETF community) and that the third party doesn't 
>need to be involved.

I am saying that any agreement between the YAM WG and the IESG can be 
overturned through the IETF Standards Process.  The IETF community 
would only be a third party which is not involved if they were kept 
out of the picture.  That is not going to happen as there must be a Last Call.

>Besides, there would be IETF LC for the bis document itself. During 
>such IETF LC any issues could be raised. Making sure there are no 
>surprises there would be in the best interests of the WG.

There can always be an element of surprise which affects 
decision-making based on consensus.  It may be in the best interest 
of the WG to make sure that there are no surprises.  But that best 
interest cannot take precedence over the wishes of the IETF community.

In the Charter, there is:

  "If the WG cannot quickly reach consensus about further work
   on a document, it will drop the documents from its agenda
   without further comment or effort."

If the intent was to avoid surprises from the IETF community, it 
would have been mentioned in there.  I doubt that would fly.

>this. Some people don't follow the yam mailing list on daily basis 
>and I don't blame them.

Yes.

>I don't understand why you say that. IESG can send additional 
>statements in addition to approving documents.
>I don't see any conflict in this, or any proof that IESG wants to 
>screw the WG.

I do not believe that the IESG wants to screw the WG.  If we want to 
have a RFC for archival purposes, we might as well do it with a 
proper record of the decision-making, i.e. those are the issues 
agreed upon and this is what the IESG has to say.

>I am not sure what you are suggesting. Please explain.

See above.  This would like the IESG Note from BCP 92.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Wed, 09 Jun 2010 07:47:56 -0400

--On Wednesday, June 09, 2010 02:19 -0700 SM <[email-masked]>
wrote:

>> And how is this different from the procedure used recently?
>> IESG can  still block (reject) pre-evaluation documents. The
>> major difference  is that there is no public record of which
>> AD raised a particular  blocking issue. With proper IESG
>> review of pre-evaluation documents,  datatracker can be used
>> for permanently storing such comments.
> 
> That's a reason to file a DISCUSS instead of taking the
> "Management Item" path.  Dave commented on the archival which
> provides a public record of the changes/non-changes considered
> by the WG even after the I-D expires.  As there wasn't any
> blocking issues for the latest pre-evaluation draft that was
> processed, I cannot tell what the record from the IESG end
> will be like.  I agree that the IESG can still block or reject
> a pre-evaluation document.
>...

SM, Alexey,

FWIW, this whole discussion would make much more sense to me if
I-Ds actually expired (as 2026 says) and disappeared (as 2026
and other documents imply) after six months.  Given that they
are now being kept, and kept available, archivally, even though
they are still working documents, the historical record isn't
being lost.

Let me skip the conversation about procedures and agreements,
since others seem to be carrying that adequately.

Unless the WG is moving _really_ slowly --an issue that would
require attention regardless of whether these documents were
being published-- the processing times and holding window for
RFC publication should guarantee that any specific decisions
would be overtaken by events --and documented as appropriate in
change logs in the actual documents-- before the RFCs appeared.
So "notify the community about decisions about work in progress"
doesn't seem to me to be a practical reason for doing this.

In addition, because the RFC Editor has (and I hope will
continue to have) standards for editorial quality in
publications that far exceed those for I-Ds (or "collections of
notes"), a decision to publish the documents as RFCs implies RFC
Editor time, community time in Last Call, Author and AD time in
Last Call (and usually AUTH48), and so on.   At least in
principle, that energy could be spent on the documents
themselves... and might be better spent that way. Given that
time I expected to spend last weekend on 5321bis was preempted
by the need to sort out changes the RFC Editor had made to the
IDNAbis documents, I'm particularly sensitive right now to the
costs of the last stages of the publication process.

While I may be missing something, I don't see the value
proposition that justifies that extra work in this case.

On the other hand, if the IESG's real desire is to get community
review of the pre-eval documents by doing a carefully-designed
IETF Last Call, I think that should be discussed on its own
merits, independent of whether the result is published through
the RFC process.  I would hope that discussion would include an
evaluation of the advantages of more review versus the costs of
delay.  One might even carry out a mini-experiment: pick an
upcoming pre-eval document, put it through IETF Last Call, and
see if enough uaeful comments show up on issues not already
considered by the WG to justify the extra time.  If so, let's do
Last Calls; if not, let's not invest the extra time.   We don't
get statistical validity from an opportunistic sample of one
case, but if the Last Calls are really going to pick up
significant data, it should be obvious even from a single case.
If it picks up nothing, or only edge cases, perhaps effort is
better spent on the substantive documents themselves.

Just my opinion.

     john

---

From: John C Klensin <[email-masked]>
Date: Wed, 09 Jun 2010 08:17:03 -0400

--On Tuesday, June 08, 2010 22:41 -0400 Tony Hansen
<[email-masked]> wrote:

> Didn't we consider and reject this option when we were working
> on the charter. I don't think the situation has changed
> sufficiently to warrant changing our mechanisms.

Yep.  We did.  See my previous posting to the list, but I'd like
to see even a modicum of evidence that something important is
being missed or lost before adding more process and delays to a
WG that is already running --in part because of the slow
evaluation process on the pre-eval documents-- much more slowly
than anyone anticipated.

Frankly, there is a case to be made that the YAM idea of
advancing these documents quickly and with a minimum of pain has
already been proven a failure.  For example, if I had any idea
that the WG really wouldn't be ready for me to open 5321bis
before June 2010, I might have opposed the whole idea at the
beginning.  This much process is just not what I'm aware of
anyone signing up for.

    john

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 Jun 2010 09:21:02 -0600

On 6/9/10 5:47 AM, John C Klensin wrote:

> a decision to publish the documents as RFCs implies RFC
> themselves... and might be better spent that way. [...]
> 

I too don't see a great deal of benefit from spending more cycles at
this point in the standards process. It seems to me that the people who
care about progressing these documents are paying attention within this
WG, and that IETF-wide last call, shepherd reports, IESG review, IANA
input, and RFC Editor work will not appreciably improve the
pre-evaluation documents being produced here.

Merely my two cents.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 09 Jun 2010 19:47:24 +0200

On 09/Jun/10 13:47, John C Klensin wrote:
>> [publishing pre-evaluation documents as Informational RFCs]
>

+1. It would clutter the RFC series somewhat.

JM2C

---

From: Ned Freed <[email-masked]>
Date: Wed, 09 Jun 2010 14:07:38 -0700 (PDT)

> +1. It would clutter the RFC series somewhat.

Agreed, but to be blunt I'm far more worried about the extra work for authors.
A conservative estimate is that this will triple the amount of effort needed to
put together a pre-eval document. I'm already having trouble finding the time
to do this work.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Jun 2010 13:39:00 +0100

[Disclaimer: I haven't read all replies in this thread yet.]

Ned Freed wrote:

> Agreed,

I hear you.
I should have explained perceived advantages (at least from the IESG 
side) in more details. Hopefully in a separate message and hopefully soon.

> but to be blunt I'm far more worried about the extra work for authors.

If you are referring to your recent IESG experiences with being a 
document shepherd, I can tell you that different documents receive 
different level of reviews.
The current IESG is way less picky with Informational documents.

In general, the current IESG is quite good with not nitpicking a 
document to death if warned/asked in advance. I also haven't heard any 
suggested changes to the pre-evaluation document of 5321bis, so I don't 
think publishing them as RFCs would actually be much more work.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Jun 2010 13:51:12 +0100

SM wrote:

> pre-evaluation draft that was processed, I cannot tell what the record 
> from the IESG end will be like.

I am talking about IESG voting comments in datatracker.
I think it is important for the community to know how each AD voted and 
which comments (blocking and non-blocking) were made. At the moment I am 
the only person who has this information. Part of it is scattered in 
various internal emails from various ADs, part of it can be found in the 
recording of IESG telechats, etc.
If I step down from IESG my successor will not be able to reconstruct 
this information easily.

> I agree that the IESG can still block or reject a pre-evaluation 
> document.
>
> detailed list of issues.  There was an issue raised during the Gen-ART 
> review was about the requirements for advancement to Internet 

The last sentence: I doubt it would (see my reply to Ned), but of course 
I can't promise that.

> Referring to Tony's message, we would be changing the mechanism.  
> Whether this changes the agreement could be subject to discussion.  
> And the discussion can be a distraction from current work.

The whole YAM process and discussion about it is already a distraction 
from current work ;-).

---

From: Ned Freed <[email-masked]>
Date: Thu, 10 Jun 2010 15:39:21 -0700 (PDT)

> different level of reviews.

That's not at all what I'm referring to. I'm talking about the effort involved
in putting the document together, not sheparding and other managerial duties.

Maybe other people view this differently, but when I'm working a document
that's going to appear as a formal publication in a document series for a wide
audience with my name attached, I spend a lot of time on word and organization
choices. I also spend a lot of time getting people to review it, reading and
addressing all review comments, and last but not least, working with the RFC
Editor during AUTH48 on editorial issues.

I'm doing none of this stuff in the MIME pre-eval I'm working on now. I don't
need to - the audience for the document is limited to those who care enough to
review it during the YAM process. I could not care less if the wording choices
are ideal, the organization is spot on, or anything else. The only purpose
these documents serve is as a means of communicating our intent to the very
limited audience of people interested in the YAM process. As long as it
accomplishes that goal, nothing else matters. Really, the amount of effort
involved here is more comparable to writing an email message reviewing
something than it is to constructing something intended for RFC publication.

Again, my estimate is that you're triping the amount of work I have to do on
the document. If the benefits to me are worth these added costs, I for one sure
am not seeing it.

> The current IESG is way less picky with Informational documents.

And that's actually bad news from my perspective - less review from the IESG
means I have to pick up the slack and do even more review work myself.

I note in passing that aside from MIME, the informational RFCs I've written
have required the most effort.

> think publishing them as RFCs would actually be much more work.

You might want to ask the authors of that document if they would be happy
having it published in its current form before making such assumptions.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Thu, 10 Jun 2010 19:56:53 -0400

--On Thursday, June 10, 2010 15:39 -0700 Ned Freed
<[email-masked]> wrote:

>> In general, the current IESG is quite good with not
>> nitpicking a document to death if warned/asked in advance. I
>> also haven't heard any suggested changes to the
>> pre-evaluation document of 5321bis, so I don't think
>> publishing them as RFCs would actually be much more work.
> 

I think Ned's implied question is important so, as one of said
authors, let me try an answer in both short and longer form.

Short form:  ROFL!  And that isn't with happiness and joy.

Longer form:

As both of you know, the informal agreement was that Barry would
assemble the pre-eval document and I would concentrate my
efforts on 5321bis itself.  I've looked through the various
iterations on the pre-eval document, but I've concentrated on
the equivalents of the task list --what we are and are not going
to do.  I've paid about zero attention to the more descriptive
text and even less to how things were phrased, etc.  Barry
writes more than well enough for me to be very confident that
whatever he put in was good enough for the purpose.

But, if one turns the document into something that is going into
the RFC series with my name on it, I start behaving just about
the same way Ned describes himself as behaving.  I want it right
and I want it up to whatever I try to establish as a standard
for my permanent/ professional writing.  That means a complete
editing pass on the I-D, discussions with Barry about possible
changes, and probably another pass or two.  Then we get to
AUTH48.  Perhaps we would get lucky this time but, on almost
every RFC on which I've been an author or co-author, AUTH48
results in identifying some changes that I'm not happy about on
first reading.  Many of those lead to extended discussions about
stylistic issues, norms, and comprehensibility.  Sometimes ADs,
co-authors, WG Chairs, authors or editors of related documents,
and an occasional shepherd get into the act and we don't all
agree with each other, much less the RFC Editor, at least
initially.    Patches the RFC Editor wanted to make by changing
a few words turn into rewritten paragraphs that several people
want to go over.  Three to five iterations on a document after
the first AUTH48 are pretty common (and I've experienced larger
numbers).    We usually emerge with a much better document and I
almost always end up reflecting on the professionalism and good
tempers of the RFC Editor staff for not deciding I take far more
effort than my documents could possibly be worth, but that is
how it goes.  It is hugely time-consuming.

Alexey, you've been following the AUTH48 process on the IDNA2008
documents since they went into that state a week ago.  There are
some things about those documents that make them unique, but
maybe there are some things about every document that makes it
unique.  I'll spare the rest of you the details but... it is
taking a lot of everyone's time to make sure the published forms
are as clear, precise, and comprehensible as the future readers
deserve.

In addition, the effect on YAM of the extra time an RFC effort
for the pre-eval documents would cost is fairly clear for me and
probably others: the WG is only going to get so many cycles in a
given month and time spent doing editorial work on the pre-eval
docs is time that translates directly into slippage of the
schedule for getting the standards-track document finished, at a
ratio that is probably somewhat worse than one week per week.

best,
    john

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 13 Jun 2010 08:24:11 +0200

On 6/11/2010 12:39 AM, Ned Freed wrote:
>> If you are referring to your recent IESG experiences with being a document
>> shepherd, I can tell you that different documents receive different level
>> of reviews.
>
> That's not at all what I'm referring to. I'm talking about the effort
> involved in putting the document together, not sheparding and other
> managerial duties.
>
> that's going to appear as a formal publication in a document series for a
> wide audience with my name attached, I spend a lot of time on word and
> organization choices.

This serves as one more item in a list of reasons one needs to view any extra 
formal step as needing extra work, and that discounting the /amount/ of that 
work tends to lead to commiting to much higher overhead.

We all -- everyone in the IETF -- should be looking for ways to do things that 
require /less/ work, not more.

This latest proposal borders on a model that all interactions with the IESG must 
result in an RFC.  No, that's not what got stated, but it strikes me as a 
reasonably modest bit of logical extension.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 13 Jun 2010 08:30:34 +0200

On 6/10/2010 2:51 PM, Alexey Melnikov wrote:
> which comments (blocking and non-blocking) were made.

My desire for less formal work notwithstanding, I'd like to support your goal.

However I suggest that it needs to be cast in a framework that considers the 
full range of IETF management activities that should be available in archival 
format.  In other words, this should not be considered as an isolated 
requirement, and almost certainly not in terms of this wg.

With a coherent view of such things, we can work forward, to make sure that each 
bit really is available long term.  This will almost certainly not require 
changes in the formal, daily work of any IETF participant but will, rather, 
entail a set of back-end procedures for formal IETF archiving rules.

d/

-- 

   Dave Crocker

---

From: Pete Resnick <[email-masked]>
Date: Wed, 16 Jun 2010 22:52:19 -0500

On 6/10/10 7:51 AM, Alexey Melnikov wrote:

> I think it is important for the community to know how each AD voted 
> and which comments (blocking and non-blocking) were made. At the 
> moment I am the only person who has this information. Part of it is 
> scattered in various internal emails from various ADs, part of it can 
> be found in the recording of IESG telechats, etc.
>
Catching up a bit:

Alexey, I couldn't care less if the IESG wants to make believe that 
these things are going to be published as RFCs in order to track them in 
their tool because the tool doesn't understand anything that is not 
going to be published as an RFC. That makes the tool broken, but who 
cares? However:

- I think Last Calling these things is silly, though probably harmless. 
These are evaluations of whether items are on our charter, only in a 
more extensive way than most items hit a charter. This is an IESG 
decision, not a community decision. If the IESG needs community input 
into these decisions, that's fine, but I would think the IESG has the 
expertise to make these decisions for themselves.

- The IESG making believe that these are RFCs notwithstanding, I can 
assure you that my pre-eval document will *never* be published as an 
RFC. At least not with my name on it. It will sit in AUTH48 forever if 
the IESG wants to publish it and puts my name on it.

But like I said, I don't care if that's the way you want to treat it 
internally; that's the IESG's business. :-)

pr

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Jun 2010 21:04:23 -0400

> Catching up a bit:

Yes, me too; sorry, but I've been away.

> These are evaluations of whether items are on our charter, only in a more
> extensive way than most items hit a charter. This is an IESG decision, not a
> community decision. If the IESG needs community input into these decisions,
> that's fine, but I would think the IESG has the expertise to make these
> decisions for themselves.

I think it's more than silly: it's harmful.  Repeating what others
have said, but more succinctly: it is VERY EXPENSIVE to ask the
community to review and give last-call comments to the pre-eval
documents, VERY EXPENSIVE to ask the RFC Editor to put them through
the process, VERY EXPENSIVE to publish them as RFCs and have
<strike>Alfred</strike> many folks pay attention to them as fully
fledged documents.

It strikes me that some people are underestimating the cost, probably
by mistakenly thinking that the time that goes into all this is free.
We know that the time spent by the IESG and the document authors is
not free.  Let's not forget that the community review time and the
other community attention are not free either.

For reasons already stated, the decision process can be recorded, the
documentation of the process and the decision can be archived, and the
IESG can get whatever advice it needs to supplement its own collective
expertise without going through the VERY EXPENSIVE process of making
these things RFCs.

Let's PLEASE save the RFCs for the actual documents, and NOT for the pre-evals.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 19 Jun 2010 13:51:23 +0100

Ok, I got plenty of opinions on publishing pre-evaluations documents as 
RFCs and I think the message I should take back to IESG is quite clear.

I will reply to the most important points people have raised later when 
I catch up with email and other IETF related work. I just want to let 
people know that I will be really slow on this, as I have plenty of more 
important IETF stuff to act on at the moment. So please be patient.

Best Regards,
Alexey, as the responsible Apps AD for the WG