Frank,
On 2007-02-09 17:04, Frank Ellermann wrote:
Jari Arkko wrote:
I would be happy to sponsor a ternary bit draft, but only on
April 1 :-)
What I don't like in your draft is the (apparent) personal veto
right for the AD. Authors (hopefully) have an idea about their
topic, but they don't need to be procedural experts. They don't
need to know what an "area" is, if it has a catchall WG or not,
and who the area directors are if it has no such WG.
They decide when their memo is ready to be published as RFC,
No, that is not their decision. They decide that they would
*like* the document to be published as an RFC. And frankly if
someone's understanding of the IETF is such that they can't
even decide which Area is likely to be appropriate, I have to
wonder why they think they are ready to publish via the IETF.
and
what follows should be a simple procedure: Send a "publication
request" to the IESG (maybe to a public list), get a responsible
AD, work it out.
That doesn't actually work. Sending a message to a group of
very people is roughly like sending it to /dev/null. That's
exactly why we want to change this.
The IESG or AD could tell them that the memo
belongs to an existing WG, that it's not in a shape to waste the
time for an IESG evaluation with it, and maybe that it's anyway
hopeless.
It's okay if there are shortcuts for authors knowing precisely
which area and AD they want, but generally authors shouldn't need
to know this.
Disagree, see above.
If the IESG refuses to pick a responsible AD for a memo the author
should have a right to appeal.
Actually, the way we interpret RFC 2026, there is always a right
to appeal, whatever we write in this document.
With some chance authors would see
that their appeal will be decided by the same group who refused to
deal with their text in the first place, and don't try this.
That's why there is a 2nd level of appeal.
But
maybe they want this situation on public record, because then the
"community" can check what's going on - "oh, Leibniz didn't speak
Chinese and erroneously stated there are only 64 trigrams for six
bits" or whatever the problem might be.
Sure, a public record is good.
[catchall WGs in some areas]
the draft says relatively little about this, because there are
different situations. Some areas have a general purpose area
working group with chairs and an ability to produce documents
just like any other WG.
I certainly didn't know this before I read your I-D, it could be a
good idea. Or not, depending on the catchall WG, if they refuse
to consider anything NIH.
That's why we also have Independent Submission, I think.
What if they don't like it, but the authors still insist on
an evaluation ? Can they appeal then ? What if the AD
does not like it personally, but admits that it's not as
bad as the famous ternary bits ?
As with regular WG submissions, the document has to pass the
responsible AD's review. Otherwise it goes back to the WG or
the authors.
That's apparently a side effect of the "must vote YES" rule. One
part of it is clear, don't waste the time of the complete IESG if
the memo isn't in a shape for serious considerations. But it's
a bad rule if the AD "only" doesn't like the memo, while others
could think it's okay.
True, if the NomCom appoints bad ADs...
With your draft you'd introduce a third point of failure - before
potential post Last Call "RFC editor note" or "AUTH48" mutilations
of a draft - a single AD can veto and kill anything as it pleases
him or her.
No, the draft introduces nothing new at that stage - it's only
the very first step that is changed from what's been done for
many years.
Ask another AD ? Your draft tries to block that escape hatch.
Perhaps for ternary arithmetic, but not for something that
really belongs to another Area.
Try "independent" ? John's draft tries to block that too.
No
Last
solution, authors should start with "independent" if they're not
interested in arbitrary AD decisions. If they try "individual"
they'd be doomed if that fails.
No, in fact a common reply from an AD might be to recommend
independent submission if the work is interesting but really
outside IETF scope.
Brian
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf