[rfc-i] draft-iab-styleguide-02 on referencing STDs

Heather Flanagan (RFC Series Editor) rse at rfc-editor.org
Mon Apr 14 09:28:53 PDT 2014

On 4/11/14, 1:28 PM, Brian E Carpenter wrote:
> This is indeed all very problematic.
> On 11/04/2014 18:57, Julian Reschke wrote:
>> This text is new, and I think it has lots or problems:
>>> Referencing STDs and BCPs
>>>    Standards (STDs) and Best Current Practices (BCPs) may consist of a
>>>    single RFC or multiple RFCs.  When an STD or BCP that contains
>>>    multiple RFCs is referenced, the reference entry should include ALL
>>>    of the RFCs comprising that subseries.  The authors should refer to
>> Does that imply that the reference by STD number is *mandatory*?

No.  When someone refers to an STD or BCP, then the reference format
should contain all the RFCs contained in that sub-series.  If someone
references a single RFC, which happens to be part of an STD, then
regular RFC reference rules apply.

> I don't think that is something that can be decided except by the
> IETF, and as far as I know it hasn't been discussed by the IETF.
> It would be a *major* change to current practice, and it's also
> broken:
>>>    specific RFC numbers as part of the text (not as citations) and cite
> That's not OK. It's actually worse than not OK. It's *wrong*. A normative
> reference must be to a specific version of the cited standard, and
> the rather broken STD designation doesn't support versioning.

The RFC Editor has heard two use cases here - in one instance, authors
want to capture the STD as it was at the time the RFC referring to it
was published, in other cases, they want to point to whatever the
current standard is.  I don't think the RFC Editor should be the entity
requiring one path or the other.

>>>    the subseries number.  Inclusion of the URI to the STD or BCP info
>>>    page is now recommended.  The text should appear as follows:
>>>       See RFC 1034 [STD13].
> No. Because if subsequently RFC 1034 is obsoleted by RFC 10034, the
> meaning of the citation changes and the technical details would
> no longer be correct. STDs are not immutable. RFCs are immutable,
> which is why they are the "atom" of normative citations.
> Just to complicate it, RFC 1034 is updated by RFC 5936, which
> is Proposed Standard. Is that part of STD13? No. Does it modify
> the meaning of RFC 1034? Yes.
> Look, this is a mess in the standards process, which people
> tried to fix 10 years ago without success:
> http://tools.ietf.org/html/draft-bradner-stdproc-isd-01 .
> Also see http://tools.ietf.org/html/draft-klensin-std-numbers-01 .
> This is not a topic for the Style Guide. It's an IETF process
> discussion. The change needs to be backed out.

It is partly an IETF process problem, and it is one that is not getting
resolved.  I don't think what we have documented in the new Style Guide
introduces any additional complexity to the problem, and in some cases
makes it easier to capture what the authors intended.


More information about the rfc-interest mailing list