Subject: ISSUE: Document subseries name for IETF Administration

From: John C Klensin <[email-masked]>
Date: Sun, 15 Jun 2003 01:32:31 -0400

Hi.

I've been studying the most recent draft of 2223bis
(draft-rfc-editor-rfc2223bis-05.txt) and it is becoming clear to
me that having a document with as much procedural impact as that
one published as "informational" is a distortion.  Similarly, it
seems to me that, despite a number of precedents to the
contrary, we should be reserving "BCP" for _network_ Best
Practices and not using it for IETF dministrative documents.

So...

Problem: there is no appropriate document series into which to
put IETF Administrative documents so that they can be
conveniently located and properly identified without creating
confusion with documents that describe, or specify best
practices for, the network.

And, while I'm at it, having IESG policy statements that have
great impact on how the IETF operates available only on a web
page that changes seems unsanitary and likely to get us into
trouble.  So...

Problem: IESG "statements" are not published archivally.  That
is undesirable, and some system of recording them, such as
rounding them up annually and publishing them (or the last
year's additions and modifications) as an RFC, would be helpful
and wise.

       john

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Jun 2003 16:56:23 +0200

John,

However, "there are too many document subseries and it's confusing
everybody" is not a problem we want to create. So while your
point is completely valid, I would like to see simplification
elsewehere to go with this complicattion.

   Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 16 Jun 2003 21:11:28 +0200

> elsewehere to go with this complicattion.

peeking over into solution space....

part of the problem may be that we're so used to using the RFC series for 
*everything* that needs to be permanently archived and identifiable.

That might not be an optimal strategy going forward....

---

From: John C Klensin <[email-masked]>
Date: Mon, 16 Jun 2003 15:44:42 -0400

--On Monday, 16 June, 2003 21:11 +0200 Harald Tveit Alvestrand 
<[email-masked]> wrote:

>> However, "there are too many document subseries and it's
>> confusing everybody" is not a problem we want to create. So
>> while your point is completely valid, I would like to see
>> simplification elsewehere to go with this complicattion.
>>
>>    Brian
>>
>
> part of the problem may be that we're so used to using the RFC
> series for *everything* that needs to be permanently archived
> and identifiable.
>

I wasn't thinking in terms of taking any of these things out of 
the RFC Series -- that is a separate topic, at best.   Instead, 
I was suggesting that we consider a subseries, parallel to BCP, 
for IETF-related administrative or procedural documents.  As 
Scott pointed out in a private note, this would require a change 
to 2026, both to create the new series and to remove IETF 
procedural documents from BCP.  And we would then presumably 
have a reclassify the old ones... probably not a big deal 
--there aren't _that_ many of them although this effort and the 
IPR WG seem likely to add several more.

Borrowing from my response to Scott...

The reason for separating them should be [...] obvious.   We
have had a long-standing tradition (predating the IETF, if I
recall) that the RFC Editor and IANA can issue documents that
normatively describe their processes and rules for accepting
submissions and requests. As long as "not a protocol standard"
implied "informational", it wasn't an issue -- everything was in
the same subseries.  But now we have two problems.  The first is
that people who are looking for "best practices" documents about
network protocols find clutter in the BCP series in the form of
IETF administrative procedures.  I note, fwiw, that no other SDO
I'm aware of merges/ confuses its internal operating procedure
documents with its [technical] standards... that just isn't
considered mature behavior.  The second is that the role and
position of IANA and the RFC Editor are significantly changed
because we are telling people that informational documents don't
count and BCPs do.  But BCPs are published only through a Last
Call and IESG approval procedure.  That doesn't seem right
for bodies that are responsible to the IAB and not to the IESG.
It is a separate issue whether such documents should require
IAB signoff, or IAB signoff with IESG approval, or they should
be able to do them on their own as they have in the past, but
that issue is impossible to sort out in the BCP context.

I don't know whether this is hugely important or not, but it is 
a "problem" or "issue".   If we are going to [re]open the kinds 
of document categories we have, such as to reduce the number of 
standards-track maturity levels, it makes sense to examine other 
categories of RFCs (or whatever) as well, and this one, IMO, 
belongs on that list of things to be examined.

And, of course, if we were to start publishing IESG-produced 
policy or processing rule statements to provide archival 
snapshots and a good referencing base at regular intervals (as 
we do STD1 and for the reasons), this possible series would be a 
good place to put those statements as well.

   john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 17 Jun 2003 08:54:11 -0700

HTA> part of the problem may be that we're so used to using the RFC series for
HTA> *everything* that needs to be permanently archived and identifiable.

In fact we should consider carefully what purposes there are in
retention, and should consider responding to them differentially.

Example purposes that might warrant different retention policies:

      -  scientific posterity
      -  use in current operational systems
      -  aid research on prior art
      -  use in legal challenges of IETF process
      -  general education of participants
      -  specific review of wg discussion and decision history

We currently have 3 retention policies:

     1. Permanaent / Ready access -- RFCs
     
     2. Officially short term / Actually maybe permanent / Obscure
     access -- I-Ds
     
     3. Random -- WG mailing lists

Gaining some agreement on our needs and then gaining some agreement on
the ways to satisfy them would seem to be quite helpful.

I have come to believe that we need two different sets of permanant
archives.  One for official publications, namely RFCs.  The other is for
use in the various research efforts, both legal and technical, that crop
up.  For these latter efforts, wg mailing lists, I-Ds, and the like
should be accessible, but lack any formal status.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 17 Jun 2003 09:42:09 -0700

-  scientific posterity

     

d/