ISSUE: Document subseries name for IETF Administration

[John C Klensin]

--On Monday, 16 June, 2003 21:11 +0200 Harald Tveit Alvestrand 
<harald at alvestrand.no> wrote:

> --On mandag, juni 16, 2003 16:56:23 +0200 Brian E Carpenter
> <brian at hursley.ibm.com> wrote:
>
>> 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
>>
>
> 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....

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