[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC 2223bis publication
Hi Bob.
Thanks for your response. I'm only now responding as I wanted to go
and actually review the document, which I have now done.
> When the decision was originally made, we went back and forth on it
> with Harald. We sort of preferred the tradition of Informational, and
> frankly, I always thought that (mis-)using the BCP category for
> administrative documents is a bit peculiar. However, we agreed with
> Harald on the desirability of a Last Call, to ensure that people
> read and commented on it. Harald pointed out that it was a little
> unusual to Last Call an Informational document, so we agreed to go
> with a BCP Last Call.
I agree that a lot of the stuff in here is info material (e.g, the
detailed formatting rules). But there is also policy in the
document. For instance:
- numbers of authors
- the IPR stuff comes straight from IETF policy documents
- section 1.2 talks about IESG notes and review
I think that where the case for BCP comes in is on the policy
side. One aspect of a BCP is that it indicates a higher degree of
community buy-in to the result. In this time of community unrest, I
think it is generally a Good Thing to get explicit community buy-in
where possible.
> Well, we did that, it worked well, and we think the process was served.
> But since BCP *is* a little strange for the RFC Editor document,
see above
> and since it replaces an Informational document,
This is a bit of a Red Herring IMO. The first version of this document
preceded the BCP series, so of course the easy/default course would be
to leave the revisions as Informational. But there are other
considerations too.
> we decided that the best course would be to go ahead and publish it
> as Informational. We are frankly surprised that anyone cares. In
> fact, I think we ALL have more important issues to take care of...
We'll, I do think it the status of a document does send a signal to
the community. While I could live with this document going
informational, my preference would be BCP.
BTW, I've appended my specific review comments on the document below.
Thomas
> RFCs in the Standards Track category are published on behalf of
> the IESG. The IESG assigns a maturity level -- Proposed Standard,
> Draft Standard, or Standard -- to each Standards Track RFC. The
> current maturity levels of all Standards Track RFCs are specified
> in STD 1, "Official Internet Protocol Standards" [STD1] and in the
> RFC index; they are not specified on the RFCs themselves.
should this be the IETF rather than the IESG? I.e., the IETF does
this, via mechanisms documented in (say) 2026. Having it be "The IESG"
makes it sound a bit detached from the IETF. :-(
> o FYI document (For Your Information) -- Category is
> Informational [FYI90]
Do we still have these? (I guess there is no harm in leaving the
category...)
> completely as possible the reasons for rejection. The RFC
> Editor is always hopeful of a miracle -- that a bad document
> will re-emerge as a good document -- and occasionally it
> happens!
May be true, but reads it a bit unprofesional IMO. I.e, very negative
to those whose submissions have been rejected.
> o Individual Submission
Does the IESG not have the right to add an IESG note to individual
documents? The way this section is written, IESG notes can only be
added to "IETF documents" (i.e, those from the IETF). I thought we
could request an IESG note be added to any document.
> o Submission from the IRTF
>
> RFC submissions from IRTF members are treated as individual
> submissions.
Could be worded better. "from IRTF WGs" might be better...
> 1.2.2 RFC Publication
>
> A document that is submitted to the RFC Editor enters the
> RFC Editor's queue, which is publicly accessible at the RFC
> Editor Web site [RFCed]. The RFC remains in the queue until
> it is published or until the IESG or the author requests
> that it be removed.
could be worded better... Makes it sound like IESG can ask for removal
of any document prior to its publication, and we know that is not a
good summary of what the practice actually is...
> 2. General RFC Editorial Policies
>
> This section summarizes some general editorial and publication
> policies for RFCs. Individual policies may be modified or new
> policies added by the RFC Editor and the IESG, before the present
> document is revised. RFC authors should obtain the latest policy
> statements (see "News") from the RFC Editor web page [RFCed].
what sort of policies can the IESG add? I.e., the RFC editor has
traditionally been independent. But the above makes it sound like the
IESG can also set new policies. But things are not that simple. Do you
mean to say something like "in consultation with the IESG"?
> The ASCII plain text version (and its .txt.pdf facsimile) is
> always the official specification, and it must adequately and
> completely define the technical content. (A very few exceptions
> have been made over the 30 year history of RFCs, allowing a
> definitive PostScript (.ps) version with no .txt version.) The
> primacy of the ASCII version typically requires that the critical
> diagrams and packet formats be rendered as "ASCII art" in the .txt
> version.
This section doesn't seem to say what the naming convention is for pdf
files that are not the official version. I.e, if the author provides
ps/pdf for fancy graphics, how can one distinguish those from the
above .txt.pdf files?
> An RFC must include separate lists of normative and informative
> references (see Section 4.7f below.) The distinction between
this seems to apply to all RFCs; But we have been pretty lax (in IESG)
for verifying this in non-standards track documents.
> An RFC must include separate lists of normative and informative
> references (see Section 4.7f below.) The distinction between
> normative and informative references is often important. The IETF
> standards process and the RFC Editor publication process need to
> know whether a reference to a work in progress is normative. A
> standards-track RFC cannot be published until all of the documents
> that it lists as normative references have been published. In
> practice, this often results in the simultaneous publication of a
> group of interrelated RFCs.
But per above normative references to works-in-progress block/delay
publication only for standards track documents. This seems odd. Why
require separating the references, if normative references to
non-existant documents are allowed?
Please clarify.
> RFCs that include URLs as generic examples must be careful to use
> the particular example URLs defined in RFC 2606, "Reserved Top-
> Level DNS Names" [TLD99], to avoid accidental conflicts with real
> URLs.
Why restrict the above to URLs? Seems like it either should apply to
all DNS names, or not be a requirement at all.
> Note that in past years the RFC Editor has sometimes published
> serious documents with April 1 dates. Readers who cannot
> distinguish satire by reading the text may have a future in
> marketing.
Seems like an inappropriate comment for the RFC editor to make.
Somewhat surprised to see Section 2.14. But I can live with
it. However, the sentence:
> relationship; the normal lower-case words should be used. On the
> other hand, if the capitalized words are used in a document, they
> must be used consistently throughout the document.
will cause the RFC editor much grief if actually enforced. In my
experience, few documents do this. It's also not clear what
"consistent" usage means...
> The present rules for RFC copyrights are contained in RFC
> 2026 Sections 10.1, 10.2, 10.3 except 10.3.2 and 10.3.3, and
> 10.4(C). These rules call for the Copyright Notice and Full
> Copyright Statement sections in every RFC (see Sections 4.2
> and 4.9 below), granting the Internet Society non-exclusive
> copyright.
>
> The statement defining rights in contributions policy is
> under revision at this time. [IPS03].
This text should be removed and replaced with corresponding text from
the revised documents. Note that the there is already a normative
(blocking) reference to these revised documents elsewhere in this
document, e.g,:
> Normative References
>
> [IPR03] Bradner, S., "Intellectual Property Rights in IETF
> Technology", Work in Progress, June 2003. [[This will hold
> up publication of RFC2223bis]]
>
> [IPS03] Bradner, S., "IETF Rights in Submissions", Work in
> Progress, June 2003. [[This will hold up publication of
> RFC2223bis]]
>
Same comment applies to immediately following sub-section. All of
section 2.16 should arguably wait for the revised documents.
> Non-normative references to Internet-Drafts are allowed, but
> they must take the following restricted form: the author(s),
> the title, the phrase "Work in Progress", and the date; for
> example:
>
> [doe13] Doe, J., "The Deployment of IPv6",
> Work in Progress, May 2013.
I would strongly encourage the rfc editor to do the following:
make clear (if necessary) how the final reference will be shown in the
RFC (i.e., w/o an ID name).
At the same time, encourage (actually, _require_) any reference to an
ID in an ID (whether normative or non-normative) to include the ID
name. I think its important the ID names appear in all IDs becuase:
- with the requirement that all RFCs have split references, saying
"work in progress" in the citation is redundant.
- a reference to "work in progress" is darn near impossible to track
down, whereas having the ID name makes this generally
straightforward.
- I see many authors using "work in progress" in IDs and it frustrates
me (when reviewing) to not know what document is actually referred
to. Even _this_ document suffers from that... I hypothesize that
authors don't include the ID name because of they belive the RFC
editor has said use "work in progress"
- Having the ID name at hand would presumably simplify the editing
task for the rfc editor as well, as I suspect you sometimes also
have fun tracking down a reference to see whether it's actually
already out as an RFC...
> 4.9 Full Copyright Statement
update to point to 2026bis?
Thomas