Re: ftp://ftp.cisco.com/fred/rreq-03.txt

Frank Kastenholz <kasten@ftp.com> Wed, 04 January 1995 13:41 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01716; 4 Jan 95 8:41 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01712; 4 Jan 95 8:41 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa05760; 4 Jan 95 8:41 EST
Received: from ftp.com by venera.isi.edu (5.65c/5.61+local-20) id <AA27612>; Wed, 4 Jan 1995 05:24:07 -0800
Received: from ftp.com by ftp.com ; Wed, 4 Jan 1995 08:24:06 -0500
Received: from mailserv-D.ftp.com by ftp.com ; Wed, 4 Jan 1995 08:24:06 -0500
Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA03586; Wed, 4 Jan 95 08:23:08 EST
Date: Wed, 4 Jan 95 08:23:08 EST
Message-Id: <9501041323.AA03586@mailserv-D.ftp.com>
To: fred@cisco.com
Subject: Re: ftp://ftp.cisco.com/fred/rreq-03.txt
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Frank Kastenholz <kasten@ftp.com>
Reply-To: kasten@ftp.com
Cc: rreq@isi.edu
Content-Length: 2218


 > 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:
 > 
 >     .H1 "APPENDIX F: HISTORICAL ROUTING PROTOCOLS"

could do that, or possibly could simply refer to 1716(?) if the information
has not changed.


 > 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?

seems fine. the only concern would be if there are mibs which are not
a part of the standards track that we, as the r.r. wonks, wish to encourage
folks to use. i don't recall any such mibs right now, so we can ignore the
issue for now and, if it ever arises, the document can be revised.



 > >        - DNS resolver          - Add as comments to documentation
 > 
 > to whom should I talk?

rob austein of one of the dns w.g.s -- sra@epilogue.com. 

what is there to talk about? this was really in regard to the user-
interface stuff - to allow humans to type host/router-names on the
console rather than ip addresses (and to see names instead of
addresses in displays of data such as the routing tables...). how
about simply pointing to host requirements?

i'd say
	- a router MAY do dns resolution for the user-interface and if
	  implemented:
	  - MUST be disableable (to assist in network debugging!)
	  - MUST follow rules of h.r. section frotz

probably in chapter 10 -- o&m


--
Frank Kastenholz    "The dogmas of the quiet past are inadequate to the stormy
                     present... As our case is new, so we must think anew, and
                     act anew" - A. Lincoln