--On Thursday, 24 January, 2002 11:23 -0800 Ed Gerck
<[EMAIL PROTECTED]> 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
