Fred Baker <fred@cisco.com> Tue, 03 January 1995 23:09 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09316; 3 Jan 95 18:09 EST
Received: from [] by IETF.CNRI.Reston.VA.US id aa09312; 3 Jan 95 18:09 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa22447; 3 Jan 95 18:09 EST
Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-20) id <AA29353>; Tue, 3 Jan 1995 14:36:05 -0800
Received: from [] ([]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id OAA16179; Tue, 3 Jan 1995 14:34:06 -0800
X-Sender: fred@stilton.cisco.com
Message-Id: <v02110107ab2f7901462f@[]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 3 Jan 1995 14:36:03 -0800
To: bmanning@isi.edu
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <fred@cisco.com>
Subject: ftp://ftp.cisco.com/fred/rreq-03.txt
Cc: rreq@isi.edu

I have posted a new version of the document. I believe that it addresses
all comments to date, from Yakov (CIDR), Scott, and Charles. With any luck,
I've figured out the recipe on formatting - there were two lines


which somehow became


nroff died...

wrt the minutes:

>        In support of CIDR, we recommended that
>        RIPv1  (RFC 1058) be moved to historic status.

I started to simply remove EGP and RIP from the document. Rather than do
so, I moved the text concerning them to an appendix:

    Certain routing protocols are common in the Internet, but the authors of
    this document cannot in good conscience recommend their use. This is not
    because they do not work correctly, but because the characteristics of
    the Internet assumed in their design (simple routing, no policy, a
    single "core router" network under common administration, limited
    complexity, or limited network diameter) are not attributes of today's
    Internet. Those parts of the Internet that still use them are generally
    limited "fringe" domains with limited complexity.

    As a matter of good faith, collected wisdom concerning their
    implementation is recorded in this section.

>        Fred Baker touched briefly on his charge from the IESG to update
>        RFC 1716 to reflect:
>                -Section numbers to names on references to RFC 1122/1123
>                -CIDR Support
>                -Security
>                -New Topics
>                -Replace RFC1009

I believe that it has all the section references to RFC 112[23] changed
from numbers to names of sections. I also believe that it fully addresses

I have not done anything with Security.

I still need to go find all the MUSTs and think about them.

I still need to derive a checklist of MUST, SHOULD, MUST NOT, and SHOULD NOT.

>        - SNMPv2 & MIBs         - Add references in the New RFC

I have put a note to Bob Stewart, copying Marshall Rose and predictable
others, asking him to either tell me how to change the section or propose
text. Marshall comments that SNMP V2 should not at this point be reflected
in this document. I would appreciate further discussion on this point.

Another thought: there is a long list of MIBs in the document, with
statements of the form:

        "if you implement feature <foo>, you MUST implement the <foo> MIB,
         which is RFC <fubar>."

It occurs to me that this in some sense preempts the IAB Official Protocols
document, which is likely to be more current in its list. The entire
discussion and list of MIBs could be changed to:

        "If an implementation supports a feature for which there is an IETF
        SNMP MIB, the implementation MUST be SNMP Manageable using that MIB.
        Implementations SHOULD be based on the version of the MIB which the
        IAB Official Protocols document dictates is current."

Am I out of line here? Any arguments as to why I should *not* make that change?

>        - Mention IDPR          - Do -not- add, per AD

removed the one reference, which was in a "to do" element.

>        - Flesh out CIPSO       - Remove text from RFC

removed the one reference, which was in a "to do" element.

>        - IPv6 text?            - Save for next WG

There are a couple of points where it was incidentally relevant, such as
the fact that, if the version number is not 4, the protcol might be ST-II
*or* IPng.

>        - Routing System Security? - Add references only if protocol supports
>                                security options

I think this would refer to RIP V2 and OSPF's security support.

>        - Routing Protocol Security? - same as above

I think this would refer to RIP V2 and OSPF's security support.

>        - IPv4 issues           - Add references to RFC 1108

I have a question out to Ran Atkinson, copying Jeff Schiller. No answer yet.

>        - Route Caching Issues  - Frank K and Paul T will work on this

Frank K and Paul T decided that Route Caching is not appropriate for
standardization. At most, the document should say that routers that are so
benighted as to implement route caches should be externally
indistinguishable from routers that don't. My reading on that is that
routers which have route caches have the same requirements as those that do
not or have their caches disabled; since this is a list of requirements,
route caches are pointless to discuss. I simply removed the one reference,
which was in a "to do" element.

>        - Load Spliting & Fragmentation - On the list for discussion

I have done nothing with this. There is some current text, which indicates
that routers should generate no more fragments than absolutely necessary,
and discusses several algorithms and scenarios.

>        - CIDR detection        - Not for this document

and not there.

>        - Multi-LIS on same media - Andy M. is working w/ Fred on this

I have a question out to Andy Malis, copying Joel Halpern. We have not done
anything on this.

>        - Congestion Control    - Allison M. will provide docs

not here yet. I have independently added some documents to the bibliography.

>        - DNS resolver          - Add as comments to documentation

to whom should I talk?

>        - LinkLayer Reqs Doc.   - Not for this group

nothing done here.

>        All of these actions should be resolved before Fred publishes his
>        RFC in Jan'95.  We expect a brief meeting in Danvers and then
>        disband.

I shall await comments and/or closure of actions from various and sundry.

    It's hardest to find the real answer when you already know what it is