--On Wednesday, June 09, 2010 02:19 -0700 SM <[email protected]>
wrote:
> Hi Alexey,
> At 22:59 08-06-10, Alexey Melnikov 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
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
