[rfc-i] Titles for divided reference sections in non-standards track documents
Brian E Carpenter
brian.e.carpenter at gmail.com
Sat May 31 20:26:35 PDT 2014
On 01/06/2014 10:02, Barry Leiba wrote:
>> So, if the text says "...MUST support avian carriers [RFC1149]"
>> it's entirely reasonable to expect the references to be
>> separated. But if it says "...might be useful to consider
>> avian carriers [RFC1149]", not so much.
> That's not the sort of thing I was thinking about, though. I'm
> thinking about, say, an Informational document that tells you how to
> achieve a certain result with pseudowires when you use the Farble
That sounds like a document that's trying to be an Applicability
Statement [RFC2026] when it grows up, a much-underused category
> Now, you won't get a thing out of this document if you don't
> understand pseudowires in general, and the Farble feature in
> particular. At least one base PW RFC is normative here, and the RFC
> that describes the Farble feature is as well.
> That's the kind of thing I'm talking about, and we do it all the time.
True, and one of the puzzles is why we don't do them as standards
track Applicability Statements. They certainly meet my idea of an
Informational document that is really a specification.
> If we have a problem statement document for xyz, and then we do a
> requirements document, the problem statement is probably a normative
> reference for the requirements doc, whether or not the requirements
> doc has 2119 key words in it.
Well, it's essential reading. If we'd called them "Essential References"
from the start, we'd be fine. (On the other hand, is the reader silly
enough not to check the problem statement when s/he reads "This
document identifies the requirements for a solution to the problem
described in [I-D.ietf-foobar-problem-statement]"?)
>> But I don't think that legislating for this is going to help,
>> since it surely remains a judgment call anyway.
> Guidance. We're talking about guidance here.
> No legislation. We're
> talking about making sure that people understand what we want
> normative references to mean, and that they think about it when they
> separate their references. We're talking about making sure that
> people understand that the fact that a document is Informational
> doesn't mean it won't have normative references. We're talking about
> giving people guidance about what to do. Of course judgment is
> involved, as it always should be.
More information about the rfc-interest