My position is the exact opposite. Full and complete review of drafts it of
paramount importance and anything thqt interferes with that is unacceptable.
And as I have pointed out, we have "running code" demonstrating that these
things are at best distracting and at worst actively interfere with proper
review.
What's appropriate to appear in the final RFC is up to the RFC Editor.
That's
what the word "editor" implies. If the RFC Editor deems it appropriate to
remove null sections that's fine, if they feel they should be retained
that's
fine too. Someone reading an RFC to learn how to implement something has a
definite goal in mind and isn't going to be (or at least shouldn't be)
distracted by boilerplate in the same way a reviewer looking for issues - a
far
more nebulous proposition - can be.
Well, I guess we do disagree here to some extent. For me, every
sentence of a document that doesn't contribute to the technical
knowledge that needs to be conferred, interferes with readability, and
ultimately, interoperability.
I think this is absolutely true of drafts - the target audience is composed of
people with substantial expertise in networking and who are tasked with finding
any potential problems that cound arise, including obscure ones.
In the case of RFCs things aren't so simple. The RFC Editor has to balance a
wide variety of competing and sometimes conflicting goals, including but not
limited to keeping the publication series as a whole consistent, making sure
intellectual property concerns are addressed, seeing that neophytes aren't
misled and insuring the material is laid out sensibly. A substantial amount of
both expertise and perspective is required - something individual authors
cannot be relied on to have.
The IETF has a whole has an unfortunate tendency to want to second guess the
RFC Editor in a lot of this. IMO this tendency is something we need to resist.
That applies to the copyright
boilerplate, that applies to checkoff sections that are just there to
get approval, it applies to information that is needed only by IANA.
And I wasn't aware that our processes allowed the RFC Editor to delete,
say, a meaningless IANA considerations section. (I've never checked to
see whether has happened.)
My undestanding is that it happens all the time. (I cannot speak from personal
experience because of late all of the documents I've dealt with have had
non-null IANA considerations.)
However I don't have a problem with IESG wanting additional supporting
information to help it decide whether to approve documents and to decide
what additional processing is needed. If the best place to put such
information is in the I-D, fine; if the best place to put that
information is in a separate form, that's also fine with me. (And I'd
far prefer that we not impose unnecessary burdens on authors of early
I-Ds - the fewer hoops they have to jump through, the better.)
This is the heart of the issue. I think having IANA considerations on
a separate checklist is an excellent idea, with two possible
answers: (1) The document has IANA considerations and they are
described in an IANA considerations section and (2) The document has
been checked and found not to have any IANA considerations.
The key difference here is _when_ this information is provided. A submission
form isn't going to be filled out in advance so there's a good chance it will
relect the current state of the document. A null IANA considerations section
that's in the document will likely as not be there from the start, and if it
doesn't get updated it becomes an active source of confusion.
In general, I think that I-Ds and RFCs really serve very different
purposes, and trying to make them be (almost) the same causes us to make
less readable end product.
Agreed, although I really don't know what can be done about it that we're not
already doing.
I'd like to see more use of "NOTEs IN DRAFT"
and similar devices to separate supporting material from material that
belongs in the final publication.
Having a single section of this sort is fine and something I and lots of others
do fairly routinely, if for no other reason than to keep track of changes to
the draft. But beyond that I think there are dragons lurking - having such
notes scattered throughout the document is bound to cause confusion about
what's supposed to be in the published RFC.
I will also say that while having crisp technical content is of paramount
importance, RFCs are used for lots of purposes and our aversion to providing
more than a bare minimum of contextual information is in many cases quite
counterproductive. A lot of our documents would be improved tremendously by
having nonnormative "how we got to this point" appendices in the published
version.
I'm concerned about readability
throughout the document cycle, but am especially concerned about
readability of our published documents - as many more people read them
at this stage and those people have less context to aid them in sorting
through the crap.
Well, in the abstract sense of course I'm more concerned about the published
document. But IMO a significant fraction of the responsibility for that has to
be - and in practice is - borne by the RFC Editor. It is therefore appropriate
for authors to focus on making their drafts maximmally suitable for the part of
the process the IETF is responsible for - getting the technical content right.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf