--On Wednesday, August 19, 2009 22:26 +0300 Jari Arkko
<jari.arkko@xxxxxxxxx> wrote:
>...
> However, speaking personally, for some reason I'm not too
> enthusiastic about writing charters in drafts. Perhaps this is
> just resistance to a change, but I have found it personally
> easy to deal with the charters simply as text. Writing
> charters as drafts would in my opinion complicate the process.
> I couldn't write a proposed charter version NN for a BOF in
> the two weeks before an IETF meeting. And often the different
> versions are written by different people, e.g., original
> proponents, then selected BOF chairs, then ADs. Some of these
> people would probably take it longer to set up the necessary
> tools and submit the draft than it would take from them to
> send an e-mail with text. And not all versions of charter
> proposals represent actually agreed charters. Typically even a
> simple recharter event would go through 2-3 iterations.
Jari,
I'm not convinced that the I-D idea is a good one, only that it
was worth thinking about.
As I read through your comments above, I can see how to easily
work around them with a few tools and reminding ourselves that
the "real" requirements for format and content of I-Ds that are
not expected to evolve into RFCs are quite few. As a handy
example, the IESG could decide that documents named
"draft-charter-foo-..." were exempt from the posting deadline so
that there would be no backout period. That would presumably
require some programming in the submission tool, but, given that
it already contains code to differentiate between
"draft-ietf-..." documents and others and between "-00"
documents and others, I can't imagine it would be more than a
handful of lines or code.
That still doesn't make the idea a good one. Your note and the
other cases, definitely illustrates that my suggestion was just
that and not a fully-baked proposal (I already knew that).
At the same time, one of the elements of Spencer's note to which
I was reacting is that, with many versions of a charter floating
around, being able to look quickly at two or more of them and
determine quickly and accurately which one is "latest". So it
seems to me that it is important that whatever is done be
associated with an unambiguous version number or time stamp.
The sequence numbers on I-Ds accomplish that (and leave tracks)
but there are obviously many other ways to do it.
> But I do have an alternate proposal, if its important for the
> IETF community to understand the differences and rationales of
> charter changes better. Why don't we simply change the
> announcement format to include the three parts that I outlined
> above? My understanding is that the process is largely manual
> from the secretariat's point of view, so all it would take is
> for the AD to include three pieces of information instead of
> one when requesting a charter review to be sent out. In most
> cases this information exists already, its just a matter of
> sending it out to the public as well as the IESG.
It think it is important for the community to understand that.
Otherwise, posting charters that are being revised (as distinct
from new ones) is, in general, pretty useless, perhaps even a
demonstration of how easy it is to go through the forms of
community review without making that functional for anyone but
the most determined.
The expanded announcement you suggest would work for me. I
think Spencer and I were focused on a slightly earlier part of
the process, in which multiple drafts were circulating around in
the pre-BOF and immediate post-BOF stages. Those are drafts
that people closely involved with the group in formation need to
see and interact with (and that probably would benefit from
being a little more organized and easier to identify). Once the
time comes for a formal AD announcement of a charter draft to be
reviewed for the community, I think your suggestion would be
more than adequate.
The question of comparing a formally-proposed charter revision
with an existing charter is a somewhat different one. As I
write this, I even suspect that they may be two separate
problems that could be solved in different ways.
best,
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf