--On Thursday, 24 January, 2002 11:23 -0800 Ed Gerck
<egerck(_at_)nma(_dot_)com> wrote:
Now, let me summarize Case 3 -- which I briefly
outlined
before:
Case 3. The IETF discusses and
provides a simple,
text-based, format for communications
sent to a
set of Non-Conformance Lists divided
in areas. All
NCL communications must have headers that match
the
predefined format, and are parsed/routed for their
purposes,
but no body text (where the
communication actually
resides, the rest is addressing and
structure) is
ever parsed. Communications that do not match the
format,
are rejected -- after all, they are
non-conforming.
Subscribers to each NCL will receive
the
respective postings, that may also be publicly
read
in web archives. Only subscribers to each NCL may
post. There
are no replies to NCL communications.
All
communications are the exclusive
responsibility of
the authors, with an IETF hosting content
disclaimer similar
to those used by webhosting services.
Communications expire in
one year, but may be freely renewed
after
expiration. Once posted, a communication
may be
deleted by request from the poster herself, by the
IETF or
when it expires. It may only be
deleted by the
IETF if it is clearly spam or if there is
a legal
order to do so. The hosting content disclaimer,
complete
absence of editorial control in
technical matters
and yielding to legal orders should
avoid the
liability issues, but legal counsel must be
consulted before
the service starts. The NCL should
be free for
mirroring elsewhere.
Since all NCL communications are under the
exclusive
responsability of their own authors, both to post
AND delete,
the authors are thereby encouraged to be
responsible ... or
else. For additional details, see the posting
below.
Comments?
Yes. Administering this would be an additional
burden on an
already-overextended IETF Secretariat and the
entities who have
to manage them (primarily the IETF Chair and the
IESG) and that
there would be little value-added in having the IETF
somehow
associated with the process. If there were
significant value
associated with IETF involvement, I'd think about it
differently, but, defined this way, you are
suggesting adding
additional responsibilities, however small, to a
Secretariat and
an IESG that some members of the community feel is
already
stretched too thin and holding things up too much.
Substituting
the IAB for the IESG in that oversight role wouldn't
change
much, the RFC Editor (another possible arrangement
for
maintaining the lists and archives) is stretched
pretty thin
too, and so on.
That doesn't make the _concept_ a bad one --I
personally find it
somewhat attractive although I remain skeptical
about
significnat impact for the reasons I outlined-- but
I would
encourage you to find someplace outside the IETF to
host and
manage it.
john