[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-rfc-editor-rfc2223bis-04.txt
Hi.
Since everyone relevant seems to be copied on this except
Scott Bradner, I'm adding him to this response (if I remember).
Many of the points below, and in my original comments, are
really about procedures that go well beyond the RFC Editor.
Some are being discussed in the context of the IESG Charter,
others in the context of various IPR and problem-statement
documents, and a few are issues I thought had been put to rest
early in my term as IAB Chair. I don't think the RFC Editor is
to blame for any of these issues, and suggest that we should
figure out a way to move this document forward without getting
excessively entangled in them. That leads to my first
suggestion:
** Move toward having two documents, one of which covers
editorial and submission matters in the "what is in the
document and what does it look like" sense, but only
insofar as those are RFC Editor requirements. Policies
about submission and review practices, and IESG-imposed
requirements on RFCs, should be elsewhere, only partially
because it is unreasonable to try to put them definitively
together when we have several WGs and efforts working on
parts of those problems.**
Second, I'm quite fond of the "looks like a duck..." model for
object recognition. But I would point out that even it is
multifaceted: "has feathers" is insufficient to classify an
animal as a duck. Similarly, "is a candidate for publication
as an RFC" is insufficient for everything to be treated as a
standards-track document. That leads to the second suggestion:
** While some IESG and other actions in the last few years
have repeatedly blurred the boundaries, there should be,
and arguably have been for some years, three separate
types of documents that ultimately end up in the RFC
Editor's hands, and we need to be willing to treat them
differently when that is appropriate. They are:
(1) Documents emerging from the IETF, standards-track or
otherwise. These are the purvey of the IESG and the IESG
should make up, and enforce, whatever rules are needed to
protect the standards process.
(2) Documents generated by the IAB, or submitted to the
IAB. I would assume that the IAB could, if it wanted to,
accept and endore IRTF documents under this provision.
That seems proper and appropriate. I would assume that
the IAB would not accept documents off the street without
doing considerable review and tuning work on them, but
that should, IMO, be left up to the IAB. Such documents
should be sent to the IESG for review and comment as a
courtesy, and one assumes that the IAB would pay careful
attention to such documents as a matter of further
courtesy (if nothing else), but the IESG authority to
modify or delay them over IAB objections should be _very_
limited.
(3) Documents prepared as "individual submissions" and
submitted to the RFC Editor. The decision as to whether
to publish these documents, with or without modifications
suggested by other groups, is up to the RFC Editor.
Review as specified in 2026 --for end-runs or potential
harm to the Interet-- is required, but IESG review or
comment on other matters is just input to the authors and
the RFC Editor. **
The "release of rights" requirements at the time the documents
are produced, and again when they are submitted, may differ for
the three cases. For the first case in particular, the IESG
can, and should, demand that sufficient rights be granted to
the IETF to permit extraction and derivation of materials for
use in ongoing standards work. By contrast, the rules and
requirements developed for the third category should preserve
the rights of an author to publish a document elsewhere if it
is not accepted as an RFC and, in particular, the "not
previously published elsewhere" requirement that is typical of
many journals.
Third, I continue to be a firm believer in the concepts of
individual submissions and an independent RFC Editor. Like
some of those who believe it has outlived its usefulness, I no
longer see the RFC series as an appropriate publication forum
for any materials vaguely related to networking. But the
judgment as to which articles that fall within that very broad
category should be accepted has always been under RFC Editor
discretion. Few of them have actually been published, and I
think it is reasonable to leave decisions about the boundaries
in the RFC Editor's hands until and unless it is shown that we
really have a problem. By contrast, the potential ability for
an individual to get a document published in the RFC series
that provides, and justifies, the opinion that some IETF
standard is harmful or dangerous, or explaining perspectives on
its use, is an important and useful check on hints of abuses in
the standards process. Such documents should clearly indicate
that they are dissenting, perhaps personal, opinions that are
not (or may not be) supported by IETF consensus. In some
sense, the IESG review provisions of 2026 are just a safety
check to make sure that sort of language is present and clear
enough. So...
** Whatever procedures are adopted should create a clear,
well-defined, and efficient path for consideration and
publication of relevant documents that do not originate in
the IETF standards process. **
Now to the details ("accepted" comments deleted to save space
except where I had further comments)...
--On Tuesday, May 20, 2003 15:37 -0700 Bob Braden
<braden@ISI.EDU> wrote:
>...
> While it comes as a slight surprise to us that people perceive
> an actual conflict between this document and COPs, we
> certainly agree that this must be fixed.
Good. As suggested above, I think the first step is to try to
separate "submission policies and document processing steps"
from "editorial and format requirements in submission", and
then defer the first until the waters settle a bit.
> *> (2) Section 1.3.1, second paragraph, "The Internet Draft
> must *> include boilerplate that allows...". The
> boilerplate required *> is, I believe, an open issue as we
> rework ipr-submission. I've *> raised the argument there
> that, especially for individual *> submissions, it should
> be possible to prohibit any tampering *> with I-Ds (and to
> require strict interpretation of the "six *> month
> expiration" rule) while granting all of the needed *>
> permissions for RFC publication. The reference to
>
> We don't understand what you want us to do about this. As we
> understand it, the sentence in question is correct.
This is intimately related to the comments and second principle
above. For an individual submission, it should be permissible
for the author to retain full control over the copyright,
derived works, etc., until and unless the document is accepted
for publication as an RFC. This is consistent with the
practices of most journals, and is vital if the author might
want to submit the materials elsewhere if the RFC Editor
decides to not publish the document. This suggests that an
alternative to boilerplate that may be more appropriate to
standards-track, standards-derived, or standards-influencing
documents would be an explicit agreement to grant specific
rights to the RFC Editor if the document is accepted.
> *> 1id-guidelines is also problematic, since it is an
> extremely *> normative reference (see immediately below) to
> a document that, *> in practice, changes (or not) at the
> whim of the secretariat and *> for which there are no
> established change control procedures or *> tracking
> mechanisms.
> *>
> *> (3) Under the definitions of 2.7, the reference to
> *> 1id-guidelines is normative in the extreme: this document
> sets
>
> Sorry, but we fail to understand what you mean by "normative
> in the extreme." In any case, what you say about it makes no
> sense to us. On the contrary, it should be clear that this
> document is self-standing. The reputed fact that I-D
> formatting has deliberately been defined to be consistent with
> RFCs (a statement that was becoming true over the past few
> years, although this tide may have turned recently) does not
> in any way make 1id-guidelines a prerequisite for RFC 2223bis.
> (In fact, the reference is informative.)
Ok. I read it as requiring that the document be formatted
according to 1id-guidelines. That would be normative and
somewhat circular. But, of course, text that requires that
RFCs start as I-Ds that the IETF has been willing to post under
the 1id-guidelines provisions takes us fairly far in this
direction. In any event, the complaint is not with the RFC
Editor but with IESG and Secretariat procedures: if
1id-guidelines are to specify the gating content, boilerplate,
and format for documents, then that document, and changes to
it, needs to be controlled by a considerably more open --and
review-able by the community-- process than "whim of the
Secretariat". The latter appears to be the current model.
> *> up a requirement about text that must be included, then
> refers *> to 1id-guidelines for the rules about that text.
> Hence, it is *> impossible to meet the requirements of this
> document without *> reading, understanding, and following
> that one. This points *> out a problem with the
> normative/non-normative distinction that *> I've seen a few
> times lately (and IESG may be seeing more *> often):
> authors and editors are classifying marginal (or even *>
> very clear, as in this case) materials as non-normative in
> order *> to bypass the somewhat more strict checking rules
> for normative *> documents. That serves us even less well
> than having the two
>
> "Points out" implies that the RFC Editor deliberately tried to
> deceive you in this case. It should be clear that there is no
> substance in this.
Nor was it at all my intent. I did intend to suggest efforts
at deliberate deception, but the deceivers were the "authors
and editors", not the RFC Editor. To be more explicit... if I
am a document author, I know that the RFC Editor will hold up
publication of my document if there are any normative
references to unpublished documents or, if my document is
intended to be standards-track, documents at a lower
standards-track maturity level. That is the RFC Editor's job.
But, if I need to reference such a document, and can convince
(or even "deceive") the IESG and the RFC Editor into believing
that it is not normative, I may be able to get my document
published without waiting. That is an incentive, sometimes a
powerful one, for such deceptive tactics.
> *> lumped together. If we can't figure out how to stop it,
> I would *> encourage the IESG and the RFC Editor to
> reconsider the *> distinction.
>
> That seems like an over-reaction to a less-than-perfect
> world.
Perhaps, but permit me to explain the comment in the light of
what I intended to say in the prior sentences (and explain, I
hope adequately, above). If I recall, the reason
the normative/non-normative distinction was proposed and
adopted was to make it easier for the RFC Editor to check for
references that required queuing the document. If authors are
trying to "game" that process (and I've seen several cases
where they pretty clearly are), then we have substituted
"someone needs to check whether the references are correctly
classified" for "the RFC Editor has to figure out which
references are actually normative". That may still be an
improvement, but it isn't as much of an improvement as had been
hoped for.
For standards-track documents, it might be reasonable to make
the IESG responsible for that checking, to encourage people to
comment on misclassified references in Last Call, etc. For
informational or experimental documents, especially individual
submissions, it is less clear who should be responsible for the
checking, but the distinction is also less important in those
cases.
> *> (4) Section 1.3.1, third paragraph. The last I heard,
> *> submissions from the IAB, or under IAB management (e.g.,
> IRTF *> documents approved for publication by the IAB) were
> handled *> differently from either "individual submissions"
> or "IETF *> documents" (processed first by the IESG). That
> distinction, *> which was rather carefully worked out,
> seems to have gotten lost *> in this draft.
>
> Accepted. We have been fuzzy about this, in part because IAB
> documents are not very numerous. However, as someone else
> noted, our flow chart DOES show the IAB, so we ought to
> mention that case.
>
> IRTF documents we have been treating as individual
> submissions, and that generally seems to fit. In fact, I have
> been told in the past that the IESG treats IRTF documents as
> individual submissions.
See discussion above. This ought to be worked out between the
IAB and IESG, but I believe that, since the IRTF is responsible
to the IAB and under its general supervision, it should be
possible for the IAB to review an IRTF document and request its
publication. This may become important if the distinction
between "study the IAB undertakes through an IAB workshop" and
"study the IAB passes off to a RG" continues to blur, as I
think it has been doing.
> *>
> *> (5) Section 1.3.1, first bullet, first paragraph.
> Several of us *> have worked very hard to eliminate the
> ambiguities that have *> permitted individual submissions
> of informational document to go *> directly to the IESG,
> bypassing the documented processes, *> getting extra
> priority as a result, and creating priority *> problems
> within the IESG. The text "however the IESG may *>
> occasionally accept..." opens that problem back up again. I
> *> believe the text should either explicitly identify this
> *> statement as applying to standards-track non-WG documents
> or *> should point to the place where the
> occasional/exceptional *> procedure is documented. See
> also (7), below.
>
> Accepted. We will strike the sentence, although the
> "occasionally" seems to us sufficient, and we see no
> particular reason to tie the IESGs hand from ever submitting
> non-WG Informational documents to us.
This is almost certainly better worked out in the context of
the IESG Charter and procedures than in an RFC Editor document.
> *> (6) Section 1.3.1, first bullet, second paragraph. "TYI"
> should *> probably be "FYI". But the IESG should consider
> whether, with *> the User Services area closed, FYI
> documents are largely an *> historical artifact. Certainly
> a number of documents on the FYI *> list are ripe
> candidates for reclassification to "Historical". *>
> *> (7) It is not clear to me that the RFC Editor should be
> *> obligated to publish anything the IESG signs off on
> ("submits"). *> Clearly, standards-track documents must be
> published. But I'm *> less sure of WG-produced
> informational or experimental ones, and *> much less sure
> about individual informational submissions that *> have
> somehow gotten IESG endorsement. On those, it seems to me
> *> that the very essence of an independent RFC Editor is that
> they *> should be able to push back if they believe a
> document is *> inappropriate. I wouldn't expect they would
> do that very often, *> and it would presumably create a
> crisis if they did, but that is *> another matter.
>
> Well, in fact we have pushed back exactly once (the MPLS
> paordy), and yes, it did create a crisis. In any case, we
> thought that "reserves the right to discuss" was sufficient.
Ok. Clarifying the distinctions among types of submissions may
also help here.
> *> (9) Section 1.3.1, second bullet, paragraph five. We
> have had *> problems with the notion of RFC Editor review
> of individual *> submissions ever since we changed the
> procedures to require that
>
> I would change yhour "require" to "request", as more nearly
> reflecting what has happened -- or drop "require" altogether,
> as too anal ;-)
>
> We are not aware of "problems with the notion" -- the IESG
> asked for us to do it, and we were under the impression that
> the IESG was generally grateful for the results (if they
> aren't, they should be!)
My recollection of the history is a bit different, and my
explain the difference in perspective. My recollection is
that the suggestion/ request originated in an RFC Editor lunch,
in the midst of one of those discussions about additional
things the RFC Editor could do to increase value and justify
more funding. That conversation slid into a discussion of
which tasks were done by the RFC Editor and which ones by the
IESG, and whether there were useful ways to shift the balance.
I remember making the observation (which I also made at other
times) that we understood how to add more resources to the RFC
Editor (more money and the hope that ISI could identify and
hire or reallocate appropriate people) while we had no
realistic mechanisms for adding more resources or cycles to the
IESG.
At some point in that conversation, either Scott or I (neither
participating as an IESG member) suggested that it would be
useful for the RFC Editor to perform a sufficient preliminary
review to determine (i) whether the content of the document was
such that you would be willing to publish a (potentially-
revised) version and (ii) whether you believed it could be
edited into acceptable form with an acceptable amount of
effort. The intent was that, if a document failed either of
those tests, you would bounce it back to the author with a "no
sale" or "please rewrite into coherent English meeting the
guidelines of RFC 2223 and then try again if you want to" note.
I.e., if you didn't find the document acceptable from a content
or editorial standpoint, the IESG would not be forced to look
at it all all.
It is not clear to me whether the IESG ever formally reviewed
that suggestion, much less "asked for" it. My reading of 2026
and its predecessors was, and is, that there is not requirement
for the RFC Editor to pass everything you receive on to the
IESG for review, but only those documents you are contemplating
publishing.
We then had what, from my perspective, was a disconnect (and,
hence, "problems with the notion", above). Rather than
making a determination as to whether the document could be
edited into acceptable form with an acceptable resource
commitment, the RFC Editor decided that a document needed to be
in final edited form -- substantially ready for a 48 hour
author's last call -- before sending it to the IESG. That, to
me, causes two problems. First, there is often an unreasonable
amount of time before the author knows whether the document
will be published at all. And, second, if the IESG comes back
and says "this document is a problem, and we don't think it
should be published unless the author fixes the following...",
a good deal of time has been wasted. If the author decides to
drop the publication request, all of the time spent in editing
is lost. If the author provides a major revision, at least
some of the editing time is lost. This is just not efficient.
Of course, if the IESG receives a document that is editorially
rough and decides to fix it editorially by nit-picking the
structure of
individual sentences and paragraphs, the cost equations change.
But they are not authorize (perhaps even prohibited) from doing
that sort of editing work by 2026. And their being given a
document that was much rougher from an editorial standpoint
might actually reinforce the desirability of their not spending
time and resources in that particular way.
> *> review before the document went to the IESG. As one of
> the *> people who was at least partially responsible for
> the change *> (Scott and I can't remember who proposed the
> idea), the notion *> was to reduce load on the IESG by
> eliminating any document that, *> on the basis of relevance
> and appropriateness, the RFC Editor *> was not going to
> publish even if the IESG found that it was not
>
> And to raise the editorial quality before the IESG had to read
> it.
That wasn't asked for, at least while I was around, and may not
be, on balance, desirable. See above.
The RFC Editor should be able to determine whether the content
is appropriate, and whether or not you are likely to be able to
edit it into reasonable shape with reasonable resources, from a
very rough draft. The IESG ought to be able to determine
whether something is an end-run, or harmful, from a very rough
draft. I would assume that, if the IESG responded to a
particular document with "this is so incoherent editorially
that we can't determine whether it is a problem or not", the
RFC Editor might reasonably respond by doing some editing or,
probably better, reconsidering whether it could be edited with
a reasonable level of effort and bouncing it to the author.
> *> harmful or an end run. If the review was conducted the
> way we *> anticipated (and I thought we had consensus at
> the time), it *> would also reduce overall load on the RFC
> Editor by preventing *> having to do anything twice and
> some things even once. The *> model was that
> *>
> *> (i) The document would go to the RFC Editor, as provided
> *> in 2026.
> *>
> *> (ii) The RFC Editor would perform a preliminary review,
> *> focusing on relevancy and appropriateness and the
> *> general question of whether it appeared possible to edit
> *> it into an acceptable form (after a reasonable number of
> *> iterations with an author who was reasonable and
> *> cooperative). If the answer to any of those review
> *> questions was "no", the document would be returned to
> *> the author with appropriate instructions.
> *>
> *> (iii) If the answer to those three review questions was
> *> "yes", the document would be sent to the IESG --without
> *> further editing-- for review on the questions of
>
> This is not the practice we have been following, or what we
> think we were asked to do. It makes most sense to us to get
> the editorial work largely out of the way first, and it seems
> more efficient that way.
To the extent to which I (or that lunch) did the asking, it is
precisely what you were asked to do. With regard to getting
the editorial work out of the way first, see above.
> *> end-runs and possible harm to the network. Those two
> *> conditions are the only ones for which 2026 gives the
> *> IESG authority to review a document or ask for changes:
> *> "ensur[ing] its technical quality", as suggested by this
> *> document, is not on the list. IESG members may, of
> *> course, comment to the author on technical quality, or
> *> may offer opinions to the RFC Editor on whether it
> *> should be published, but so can any other member of the
> *> IETF community. They have no special standing as the
> *> IESG in that regard, and any sort of "change the
> *> document to make AD XX happy, or it isn't going
> *> anywhere" interactions are process violations.
>
> But, of course, we all recognize that the IESG definitely DOES
> review individual submissions for what they perceive to be
> technical quality. A few individual submissions have been
> inappropriately killed by the IESG when individual ADs had
> different technical ideas, in our opinion. But it is an
> imperfect world, and we muddle along.
To the extent to which the relevant BCPs specify the
requirements and limits of IESG responsibility and authority,
rather than the whims of IESG members doing so, having
documents killed by the IESG because individual ADs had
different technical ideas is technically known as "abuse of
authority". Those sorts of abuses are one of the things that
led to the current "problem-statement" effort. And I believe
that, to the degree to which the RFC Editor believes that IESG
authority is being inappropriately used in these ways, you
should be raising the issue with the IAB (through a formal
appeal if necessary).
> *> (iv) Only when the IESG acknowledges (by default if
> *> necessary) that the document does not constitute an end
> *> run and isn't proposing something that would cause
> *> serious harm does document editing and formatting begin.
>
> "Serious harm" is subject to a wide interpretation. The IESG
> is very properly protective of the Internet technology, and
> they may at times, with all good intent, over-state the risks.
> Remember Mohsen Banen?
Sure. But, in the last analysis, the IESG can only say "ok" or
"please don't publish, because", or "please don't publish
unless the following disclaimer is attached". Any of those
are appropriate inputs into the editorial process, but there is
little relative benefit to you (or the author) getting those
inputs after you have completed the editing and formatting
process as compared to before that process begins.
If one wanted to be extreme about this, the only things that
occurred in 1992 (and that were embodied in 2026 and other
documents) was the transfer to the IESG of any authority and
responsibility for standards management and standards review
and approval that it didn't have earlier. It is appropriate
that they offer nearly-binding organizational opinions on
whether publication of something would interfere with the
standards process. They should certainly also provide advice
to you if they believe that the ideas proposed would cause
serious harm to the infrastructure, and I hope you take those
comments seriously. But, with regard to a general overview, or
protection, of the Internet technology, IESG members may have
opinions as senior, skilled, and respected members of the
community. I assume, and hope, that the RFC Editor would take
those opinions into account in your decisions as to whether or
not to publish a document (and under what conditions) on the
same basis as any opinions from any other community member with
appropriate experience, knowledge, or qualifications. But, for
the IESG to assert special or binding authority in this area is
an abuse of authority and will remain an abuse of authority
until and unless the community agrees to a change in the rules.
In the interim, if you want an organizational opinion about
appropriateness of the document given overall technology
considerations, I think you need to ask the IAB (as I
understand the IAB has been asked on and off for the last 30
years).
> *> This permits any edits that are required as the result
> *> of IESG-requested changes to be incorporated into the
> *> first editing pass. If the IESG generates as "please do
>
> This would put the IESG in the position of being document
> editor, a task that I don't think they really (should) want to
> perform any more than they have to already.
No. It requires them to take a high-level view of the content,
rather than being concerned about editorial issues at all. If
they get involved with editing the document --whether you give
it to them in raw or in "about ready to publish" form-- they
are wasting everyone's time (espeicially their own) and
violating the formally-approved procedures.
> *> not publish" and the RFC Editor agrees, the document
> *> disappears without any editing time being spent. By
> *> contrast, the procedure outlined in the subject
> *> paragraph requires that they document be completely
> *> edited and formatted, sent to the IESG, and then
>
> No, we do not insist on strict formatting, as long as the
> document is reasonably readable. During the final publication
> process we expect additional editorial issues to arise and be
> corrected. But we do expect that a document submitted as an
> RFC should already generally follow the defined RFC format and
> be clearly organized and formatted with at least a bit of
> care, and we think that the IESG should expect no less in an
> individual submission that we send to them. It is sad how few
> individual submissions are even close.
But your practice, based on my experience, had been to edit the
document into final (or very nearly final) form before handing
it off to the IESG for review. It is that to which I'm
objecting. Individual submission documents that are "not even
close" should, IMO, be bounced back to the author, with no more
than a pointer to a coherent, and clear, document that
specifies what you are looking for and require. Note that
"generally follow the defined RFC format and be clearly
organized and formatted with at least a bit of care" does not
meet that criterion, since almost every word in it is extremely
subjective. And I would encourage you to set those criteria
in a form that does not require the use of specific
format-preparation software (such as a processor capable of
generating tables of contents with correct page numbers,
running headers and footers, etc.). I agree, incidentally,
that documents should be in acceptable minimum shape by the
time you send them to the IESG. I also believe that the IESG
should be bouncing IETF documents back to WGs that are not in
minimum acceptable shape. But I don't believe that either you
or the IESG should be spending time getting documents into that
shape, at least before a final decision to publish is made.
And, if your requirements for an input document are different
from the requirements for posting an I-D (and that might
reasonably be the case), those differences need to be made very
clear indeed. That is, of course, another part of my concern
about your reference to the I-D guidelines and vice versa.
> *> potentially discarded or extensively re-edited and
> *> reformatted. That doesn't benefit any of the IETF, the
> *> IESG, the authors, people waiting for publication of
> *> other documents, or whomever is paying the bills.
>
> We believe this is not a correct reading of the situation.
>
> BTW, you missed "the the". ;-)
Thanks.
> *> (10) Section 1.3.1, second bullet, paragraph six. This
> *> explanation of what happens when the IESG is unhappy with
> a *> document does not reflect actual practice, at least as
> I *> remember it. The IESG can either request that the
> document not *> be published or that a disclaimer be
> attached to it. Those are *> two separate types of
> requests: "DNP or at least attach a *> disclaimer" is a
> third possibility, but less common. When the *> RFC Editor
> gets _any_ of those inputs, they may: *>
> *> (i) Reject the document, even if the IESG only requested
> *> a disclaimer.
> *>
> *> (ii) Attach a disclaimer and publish. If the IESG
> *> requested non-publication, this presumably requires
> *> going back to the IESG and negotiating a disclaimer.
> *>
> *> (iii) In theory, publish the document as submitted
> *> (without a disclaimer), indicating to the IESG that they
> *> are welcome to submit a dissenting RFC.
> *>
>
> We do not believe in (iii). We believe that if the IESG wants
> a disclaimer, the IESG should have a disclaimer. Far better to
> publish with baggage than not to publish at all, in our view.
> Let the reader decide.
As a matter of practice, I agree. But I don't believe that the
option of publishing regardless should be taken away from the
RFC Editor, especially if you conclude that what the IESG is
requesting is not a disclaimer but a full-length explanation or
justification that might better be published as a separate RFC.
You will note that I tried to distinguish between the common
cases/ practice and this option by use of the words "in
theory". I would not expect this case to arise often.
> We do not understand your point here. The words we have
> written seem to correctly state the alternatives.
See above.
> *> I believe that the RFC Editor's doing something contrary
> to IESG *> wishes in these matters should be a rare
> situation indeed. But,
>
> We don't disagree with this.
Then I don't quite understand why you are taking exception to
my "in theory" observation about the potential.
> *> (16) Section 2.11. To the extent that this document
> should *> address the "update" and "obsolete" relationships
> for *> standards-track materials, it is important, IMO, to
> clarify *> whether a document at Proposed can obsolete, or
> even update, one *> at Standard. If the answer is "yes in
> some cases", I believe *> that decision should explicitly
> involve the IESG, rather than *> being an exclusively RFC
> Editor decision.
>
> This issue needs more discussion and clarification.
Indeed it does. And it seems to me that discussion and
clarification is an IESG responsibility, one that should not
fall on the RFC Editor by some sort of default.
> *> (17) Section 2.13. I believe that "satire" in the first
> *> sentence should be "satirical". The RFC Editor is to be
> *> congratulated on having this subsection appear as number
> 13.
>
> You noticed! ;-)
I did try to read the document carefully :-)
> *> (18) Section 3.1(2), second paragraph. I think this
> should be *> "protocol conventions require" or some other
> variant. The *> present text does not parse well.
>
> Maybe...
Editor's choice.
> *> (19) Section 3.1 and 3.3 generally. As highlighted by a
> recent *> set of discussions on the IETF
> "problem-statement" list, it is *> important for the RFC
> Editor (and, where appropriate, this *> document) to
> distinguish between the format(s) that are expected *> as
> input and those that characterize a finished RFC. For the
> *> former, the goal should be to maximize the efficiency of
> both *> authors and the RFC Editor. IMO, formatting
> details --including *> pagination, headers and footers, and
> table of contents page *> references that depend on them--
> that the RFC Editor will just *> need to remove before
> inserting their own as part of the nroff *> conversion
> process should not be required and might *> appropriately
> be actively discouraged.
>
> Not sure about this one. If you send us an exactly formatted
> RFC, we can feed it to a script that will deduce and add the
> correct nroff directives to reproduce that RFC. And, it seems
> that it is less work for us when the RFC you submit is ALMOST
> correctly formatted. But, if there were a clear advantage to
> submitting totally unformatted RFCs, I guess we could format
> them.
>
> The implications would need to be further explored, but the
> idea of avoiding page formatting in I-Ds and adding it to
> published RFCs does seem reasonable, as one alternative
> procedure.
I am specifically concerned about two cases, there may be
others. I would like to preserve the option of building I-Ds as
plain ASCII text, in text editors (emacs, vi, or even stupid
things like ed and notepad), which includes the option of
pulling a set of paragraphs expressing an idea out of some
other context, such as a mailing list. I think this is
important to our being able to get rough ideas out their
quickly, which is an important criterion for I-Ds. So, in
particular...
* There should be no requirement on I-Ds for pagination or
for running headers and footers (especially since you have
to replace the latter anyway, since RFC headers are not
permitted in I-Ds).
* There should be no requirement for page numbers on TOCs
or any indices that might appear. If it is useful for you
to specify the lines that are intended to appear in a TOC
or terms in an index, that is probably reasonable.
Now, if you need a higher standard than that -- and you may --
then 2223bis should be more strongly differentiated from
1id-guidelines so that we have
* I-D format (as permissive as we can make it consistent
with legal requirements and the requirements of document
handling). Remember that most I-Ds never get near the RFC
process.
* RFC submission format. Whatever you need; presumably
more restrictive than the I-D format. If you find it
helpful to say "if you put it into the final RFC format,
your document may make it through the works more quickly",
please do so and make sure that final format is clear.
* Published RFC format, which is really your issue and
only informational for the community.
Many of my formatting issues are related to the collapsing of
the first and second of these.
> *> (21) Section 4 (introduction) and 4.7. I have run into a
> few *> documents of late (more at the I-D stage than after
> RFC *> publication) that are so abbreviation-laden, and
> sufficiently *> long, as to be essentially unreadable. For
> those documents, it *> may be time to start requiring
> either a glossary or an index of *> special terms. I think
> the document should explicitly call out *> that possibility.
>
> The IESG sometimes asks for glossaries and we could do so too
> for individual submissions.
>
> However, recently we have noted a frightening increase in the
> following editorial abomination: a content-free Introduction
> section followed by a Glossary section with terms in
> alphabetical order, all intertwined in some complex way. You
> have to be a computer to parse the thing and figure out what
> the Hell the document is trying to say. Then sometime later
> there may be, in section 2 or 3 or 4, the introductory
> explanation that you needed before you got to the glossary.
> You end up rereading the glossary 30 times, trying to thread
> through the intertwined definitions. I don't know where
> people picked up this abominable format, but I suspect it is
> from other standards bodies. Jon left us with a legacy of a
> large corpus of technical documents written with grace and
> clarity. We are losing it, fast.
I believe that the RFC Editor would be performing a
considerable service for the community if you adopted the
principle that, when confronted with an abomination, you
identified it with that term, summarized why you found it
abominable, and returned it to the author -- regardless of
whether the author was an individual, and IETF WG, or the IAB
or IESG themselves. As our community and readership shifts to
include larger proportions of people who are not native
speakers and readers of English, especially poor English,
pushback of this sort becomes even more important.
> If we had our way, we would REQUIRE that glossaries come at the
> END of a document, forcing a proper introduction. A glossary
> should be for REFERENCE, not to make a document that only a
> computer could love.
I suggest that there is no reason you should not have your way
about this. Say it in 2223bis, and then enforce it. "The RFC
Editor will not attempt to edit, or otherwise process,
abominations" seems to me to be a very useful principle.
Speaking personally, and from the perspective of working
concurrently with a very good professional editor on a very
difficult document, you should be fairly careful about the way
you state the rule. That particular document contains a good
deal of specialized, and sometimes confusing, terminology. We
have made many changes to reduce the confusion level, but the
specialization remains. The solution, at present, is to have
an introduction that contains almost none of that terminology
and a a subsequent terminology section that introduces the terms
in a
coherent (not alphabetical) order. Our current thinking is to
create an index of special terms that appears in alphabetical
order at the end of the document, rather than a glossary,
because the latter would be textually redundant. But your
guidance on the latter would be welcome (and accepted without
question) and some discussion of this subject may belong in
2223bis.
> *> (22) Section 4.12 on reference formats. As discussed in
> another *> context some months ago, the [nn] style of
> references, as used *> and therefore implicitly recommended
> in this document, is *> somewhat problematic when used with
> a split (normative/ *> non-normative) references section.
> Part of the problem is *> illustrated on pages 33 and 34
> (see (26) below), where the *> numbers appear in a
> somewhat-odd order. It would be very *> helpful if the RFC
> Editor were extremely clear about what it *> expects (and
> would permit) in these cases, perhaps noting that *> most
> style manuals that recommend the [nn] form insist that the
> *> references be numbered strictly in the order in which the
> *> targets appear (which pages 33-34 violate).
>
> We just recently realized that we confused people about what we
> mean by "reference"; many people are taking it to mean
> "citation". We agree that numbered citations cause confusion
> with the Normative/ Informative split, and we should set the
> right example.
>
> Accepted, mostly.
Anything that can be done to clarify this situation would be
quite welcome. FWIW, I have had a recent exchange with
Marshall Rose about the possibility of getting the XML tools to
generate references/citations of the form of [Nxx] and [Ixx] so
that the result would be
Normative References
[N1] ....
[N2] ....
Non-normative (informative) references
[I1] ...
[I2] ...
Which would alleviate part of the problem. But this is
ultimately your decision: please provide guidance.
> Another issue that is bothering us these days is whether
> non-standards-track documents can EVER have Normative
> references. We suspect that only standards-track documents
> should make the N/I distinction in its references.
That change would make a good deal of sense to me.
> *> (23) Section 4.12 on I-Ds and URLs. While I completely
> agree *> on the importance of citing I-Ds only
> non-normatively (and with *> "normative" carefully and
> accurately interpreted, see (3) above) *> and as "work in
> progress", I think we do a disservice to the *> reader by
> not explicitly identifying these as I-Ds and giving a *>
> date. Someone who wants to find those "works in progress" is
> *> entitled to hints as to how to try to find them and which
> one *> was referred to in constructing the RFC. Otherwise,
> they aren't *> references at all, just a rather vague form
> of handwaving.
>
> This is problematic. Once you say a date, you are implying a
> particular version of the I-D, but since all versions are (or,
> should be, we strongly believe) ephemeral, this seems
> undesirable.
I agree that it is problematic. The question, to me, is
whether there is any expectation of the reader being able to
track down and read (or get more information about/from) the
citation. If that is answered in the affirmative, then,
however epheremal the document may be, a date or version number
(or both) are a requirement: after all, the material being
cited may not be present in an earlier or later version. I
note that, in most scholarly literature,
Braden, Bob, personal communication, 26 May 2003.
is preferred to
Braden, Bob, personal communication.
because there is slightly more chance that you might remember
what we talked about, or even if the conversation occurred at
all, if someone comes back and asks if, e.g., that was really
your position.
> *> (24) Appendix B: The discussion of Microsoft Word should
> *> reiterate that RFC 3285 and its template have been tested
> only *> on fairly simple documents and may not be suitable
> for more *> complex ones.
>
> Accepted. Maybe this should not even BE in this document, but
> only on the web page.
The RFC Editor has seen some additional notes that suggest the
possibility of a radical change in Word handling over the next
year or so. That further suggests web pages, I think. (For
the curious reader, the "2003" version of Word can produce some
semblance of XML output. We are exploring whether the right
path, especially for more complex documents is "Word produces
XML, which is then processed into RFC format" rather than "Word
produces RFCs". If workable, there are many advantages to that
approach.)
> *> (25) Appendix C, topic A.7 (and maybe C.1): We forbid
> categories *> from appearing in I-Ds. This seems to imply
> that the RFC Editor *> requires that the category be filled
> in correctly before the *> document reaches them. But, in
> theory, the only way in which a *> document reaches them is
> as an I-D. There is a bit of a problem *> with this (and
> elsewhere).
> Yes. Presumably the category is passed out-of-band, in the
> IESG's message to the RFC Editor.
Again, whether in-band or out of it, another way in which the
format of "ordinary I-D" differs from the format and content
for "submission to the RFC Editor"
> *> equivalent. The list of sections in section 4 of this
> document *> appears to follow that model, the document
> itself does not, *> resulting in unnumbered appendices and
> subsequent materials.
>
> The Appendices are not "unnumbered"; they are designated by a
> letter. This is in accord with publication convention as we
> know it. Since the unnumbered/unlettered sections are all
> conventionally required and named, there is no problem
> referencing them without page numbers.
>
> We don't see a problem here.
Except that we keep adding them, some of them are not required,
and some of them contain text that might be cross-referenced
and have fairly long titles. Note that "Acknowledgements",
"Contributors" and "IANA Considerations", at least, are
optional, and "References" might be, and that there is no firm
specification of the order in which these sections must appear.
"IANA Considerations" and "Security Considerations" may be
quite long, and those two sections are really part of running
text --they have just been singled out for special treatment
and placement. We no longer even have a conventionally-named
and required "References" section, but a choice between that
and "Normative References" and "Non-normative References
(either or both of which may not appear) -- that is the reason
I suggested, some months ago, having "References" with
"Normative" and "Non-normative" as subsections if needed.
Especially if there is no TOC with page numbers (still
apparently optional, and unlikely in I-Ds), "see the IANA
Considerations in section #" is likely to be quite useful in
leafing through the document and finding the thing.
Also, much of this objection would disappear if RFCs were
presented in a multiple-font style that permitted easy scanning
for section headings. With the ASCII format, those numbers at
the left margin are the strongest hint we have. And
appendices, by the way, don't even get the hint, since the
section heading is normally "Appendix A" rather than "A.
Appendix" and the RFC Editor has traditionally permitted
letters in outline levels to appear left-justified.
> *> While I believe the latter is less desirable (and
> inconsistent *> with many recent RFCs), I believe even more
> strongly that we *> should settle this issue once and for
> all, establish a norm for *> it, and get it into this
> document. Granted "appendices before *> acknowledgements"
> make numbering look a little strange, but, *> from both a
> formatting and "finding things in the text" *> standpoint,
> having security and IANA considerations, etc., *>
> unnumbered makes them hard to spot. I believe, fwiw, this is
> *> one of the reasons why ISO adopted the term "annex" in
> *> preference to "appendix" -- they put them where logic
> dictates *> and then just number them as sections (I don't
> recall whether *> their style manual calls for
> *>
> *> 85. Text section
> *> 86. Annex 1
> *> 87. Annex 2
> *> 88. More text
> *> or for
> *> 85. Text section
> *> 86. Annexes
> *> 86.1. Annex 1
> *> 86.2. Annex 2
> *> 87. More text
> *> but can look it up if that would be useful.
> Interesting observation. We have been struggling with
> specifying the order; people keep asking for more and more
> specificity, but, following the Internet Way, we want to
> specify the minimum necessary rules.
>
> Many authors like to put Appendices at the end, but that often
> makes it really hard to find the references, so we prefer the
> references near the end.
Yep. Of course, numbering everything in a consistent way would
also help with this :-)
> We are happy to consider the Acknowledgments and Security
> Considerations sections to be part of the body, and hence
> (normally) numbered. Here is where your Annex idea does seem
> to work better. We need to think more about this.
Let me know if I can be of any help.
regards,
john