Subject: For discussion: revising RFC1264

From: Alex Zinin <[email-masked]>
Date: Wed, 12 Mar 2003 20:48:55 -0800

Folks-

 We're going to discuss this topic at the RTG area meeting next week.
 Here's the background for the discussion.

 RFC1264 defines requirements for routing protocols going to standards
 track. It was published more than 10 years ago and there are several
 reasons why we would like to revisit those.

 The biggest issue with the document is that it does not spell out the
 requirements for protocol extensions, neither does it say that the
 requirements described in it are for base protocol specifications
 exclusively.

 Here's the draft list of changes/issues that I'd like to solicit your
 comments on:

 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

    Should we raise this req to 2 for PS for both base protocol and
    extensions?
    
    The reason being that this is the only real way to check that the
    specification gives enough information for independent
    implementations to interoperate. Plus, of course, it raises the
    quality bar.

    The downside would be that if for some reason we would like to
    encourage implementation of something by making this a proposed
    standard, we wouldn't be able to do this until we had at least
    two interoperable implementations.

 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. We don't have such rules written
    down for other protocols, maybe we shouldn't for routing either,
    and just use common sense too. (Data point: 2026 does not require
    this.) The downside of this would potentially be decreased thrust
    behind the MIB work.

    Another meta question is whether the MIBs have to be read/write
    or read-only, i.e., whether we should mandate that MIBs be written
    for configuration as well as for monitoring or for monitoring
    only. Recent discussions suggest that we should mandate monitoring
    and make configuration optional.

 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 think the text should ask for only an implementation
    report (to ensure 2 interop implementations) submitted to the ADs
    for features.

 Add the following:
   
 4. Provide guidelines about what sort of details should be described
    in a specification.

    There have been discussions recently about what sort of details
    should be described for routing protocols. i.e., only bits on the
    wire (message format only) vs including node-local decisions,
    FSMs, timing, etc.

    I fundamentally believe that node-local decisions, as well as
    timing are important for routing protocol specifications (this, in
    fact, is how currently used protocols are described), and think
    that the document should spell this out as a requirement.

 5. Spell out what routing-specific details are 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 specs should also talk about backwards
    compatibility, describing how the new feature interoperates with
    routers not implementing it, if protocol dynamics are changed, how
    they affect scalability, stability, and 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--those come from the times
 when IAB approved RFCs.

 Opinions are welcome.

-- 
Alex

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: "Tony Li" <[email-masked]>
Date: Fri, 21 Mar 2003 13:11:16 -0800

|    The BGP FSM is a poor example of this for complicated reasons.

Agreed.  This probably should have been described via some other
mechanism
such as pseudo-code.

Tony