--On Wednesday, August 19, 2009 22:26 +0300 Jari Arkko
<jari(_dot_)arkko(_at_)piuha(_dot_)net> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf