document classifications

[Steve Bellovin <smb@research.att.com>]

At the Retreat, I was charged with making suggestions about new 
document classifications.  When poking at Barbara's new IESG page 
layout, I stumbled on info-experimental.txt, which I should have 
remembered.  For Informational vs. Experimental, I'm mostly happy with 
it, though I think there's an important case missing:  a deployed I?TF 
protocol that isn't a standard, and isn't going to become one, but 
exists.  (MSDP is the current case on the table.)  My take is that it's 
Informational -- it's like a vendor protocol, for some value of 
"vendor".  In general, I'd rather have Experimental more focused on 
4.2.1 of that document (which I do think should be published as an RFC, 
since it clarifies 2026), and on the second two examples in Section 3.

Where I'd like to diverge from current practice is in how we treat 
architectures, requirements, and framework documents.  To me, an 
architecture is quite clearly something very much like Proposed -- such 
documents often appear on the same ballot as the Protocol.  What drove 
this home to me was an interaction on an IPSP ballot.  Bert had a 
DISCUSS on one document of three in the ballot, a document that was 
intended for Informational.  He suggested that we split the ballot, 
allowing the other two documents to progress.  Fine, no problem -- but 
the remaining document, being Informational, is no longer formally 
ballotted.  But it has a DISCUSS!  That strikes me as wrong.

I suggest that we treat architectures and frameworks -- the kinds of 
documents that implementors need to understand in order to build 
reasonable systems --as standards track documents.  If people don't 
like the phrase "Proposed Standard" for an architecture, I'm perfectly 
happy with "Proposed Architectural Standard", but to me that's needless 
complexity.  On the other hand, requirements documents that were 
written to guide the WG in its further work are, and should remain, 
Informational -- they're the archival record of how we got where we are.

I'd also like to split BCP.  Right now, we use it for two very 
different things -- the best technical way to do certain things -- 
i.e., 3481, 3470, and 3449, to name the most recent three.  But we also 
use it for describing IETF procedures, i.e., 3427, 2418, 2026.  I'd 
like to call those latter "PROC" documents -- Procedural.  But I care 
less about that, since I think that there's rarely any confusion there.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)