ietf
[Top] [All Lists]

Comments regarding draft-iesg-rfced-documents-00.txt

2004-03-26 16:12:51
I have read draft-iesg-rfced-documents-00.txt and generally support
this change in the current practices.   In review of background BCPs,
in particular RFC 2026, I find this change can, and in my opinion,
should be returning to the procedures outlined in RFC 2026.  However,
I do have some concerns (see below) and some editorial suggestions
(which I will send separately to the I-D's authors).

General support:

It is my opinion that RFC 2026 did not intend for the IESG, nor the
RFC Editor for that matter, to undertake a "full scale" technical
review of the individual submission.

RFC 2026 described the IESG review propose "[t]o ensure that the
non-standards track Experimental and Informational designations are
not misused to circumvent the Internet Standards Process."

RFC 2026 described the RFC Editor's review purpose as ensuring
"editorial suitability" and subject to "editorial considerations".

While I support the RFC Editor continued right to "refuse to publish
a document which, in the expert opinion of the RFC Editor, is unrelated
to Internet activity or falls below the technical and/or editorial
standard for RFCs", we should continue the long standing tradition
of allowing publication of alternative ideas, alternative protocols,
and April Fool's RFCs.

Concerns:

I am concerned is the document by this Section 3 paragraph:
   Note that judging the technical merits of submissions,
   including considerations of possible harm to the Internet,
   will become solely the responsbility of the RFC Editor. The
   IESG assumes that the RFC Editor will create its own
   mechanisms for additional technical review.

I argue that the RFC Editor should not refuse publication of a work
because, in the opinion of the RFC Editor, that work would be harmful
to the Internet.  While I can see that cases where a document fails to
met the technical standards of RFCs, a document that causes harm to
the Internet does not necessarily below those technical standards.

Determining whether a document would cause harm requires more detailed
review than simply determining whether the document fails to met the
technical standards of RFCs.  Certainly the technical standard of RFCs
(including those produced by the IETF) is, at times, quite low.  Hence,
I recommend the phrase "including considerations of possible harm
to the Internet" be dropped or, better yet, this paragraph be replaced 
with language more consistent with that used in RFC 2026.

Also, as the kind of harm discussed in section 5 is about confusion
with standardization efforts, not about harm caused by technical
flaws in the technical specification itself (as discussed in Section 3),
the meaning of 'harmful' is confused in this document.  Deleting the
phrase as suggested above would remove that confusion and focus the
issue on proper standards coordination and not in-depth technical
review of the document.

Kurt