Revising RFC 1264

[Alex Zinin <zinin@psg.com>]

I've started looking at revising the RFC1264, defining the
requirements for routing protocols going to standards track.

There are many reasons for the revision, including fixing outdated
process references coming from the times when IAB was approving the
RFCs, clarifying the reqs for new protocols and extensions to them,
etc.

>From my conversation with Bob Hinden, the author of the document, and
the RTG AD at that time, this was basically an INFO doc informing the
community about the policies the IESG is going to use while
considering routing protocol specifications. Bob could not remember if
the doc was IETF last-called or not. My understanding is that as long
as the requirements are within the framework described in 2026, it is
an IESG-internal matter (though input from the community is, of
course, important.)

Here's the draft list of changes/issues that I'd consider:

1. Number of interoperable implementations.
   The doc currently says:
     PS : 1 or more
     DS : 2 or more, at least 2 independent
     STD: 3 or more, at least 2 independent

   I'd like to raise this req to 2 for PS, because this is the only
   real way to check that the specification gives enough information
   for an independent implementors to interoperate.

   The same reqs should be for new protocols and for extensions.

2. MIBs. The document introduces a dependency between the MIB
   and the protocol specs:
    PS : MIB written in an I-D
    DS : MIB is at PS level
    STD: MIB goes together with the spec

   The first thing would be to make the MIB optional for extensions
   and use common sense to make sure the charter includes the MIB work
   if needed.

   For base protocol specs, the meta question is whether we really
   want to sync these two so much. Are we doing this for other specs?
   If not, maybe we shouldn't for routing either, and just use common
   sense too. (Data point: 2026 does not require this)

3. Reports.
   The text currently requires two reports submitted to the IESG
   along with the specs, the reports generally summarize the protocol
   scalability characteristics, experience in deployment of it,
   etc. These usually become separate RFCs.

   The de facto practice we have now is to not require those for
   extensions. I'd like the text to ask for only an implementation
   report (to ensure 2 interop implementations) submitted to the ADs.

Add the following:
   
4. Provide guidelines about what sort of details should
   be described in a specification, i.e., only bits
   on the wire vs including node-local decisions, FSMs,
   etc.

5. Spell out what is expected in the security section for
   new protocols, i.e., threat analysis and authentication;
   and for extensions: changes to the set of possible attacks
   and to the protocols security mechanisms.

6. For features--the spec should also include the "Backwards
   compatibility" section, that describes how the new feature
   interoperates with routers not implementing it, if protocol
   dynamics are changed, how they affect scalability, stability,
   robustness of the protocol.

7. For features--note that if the IETF owns the base proto 
   specification, the maturity level for an extension cannot
   exceed the base spec's one, per 2026 because it is a normative
   ref.

Plus fix the outdated procedural facts.

Comments are welcome.

Alex