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

bmanning@isi.edu Wed, 04 January 1995 00:01 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10187; 3 Jan 95 19:01 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10183; 3 Jan 95 19:01 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa23749; 3 Jan 95 19:01 EST
Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id <AA02249>; Tue, 3 Jan 1995 15:36:09 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: bmanning@isi.edu
Posted-Date: Tue, 3 Jan 1995 15:35:52 -0800 (PST)
Message-Id: <199501032335.AA09108@zed.isi.edu>
Received: by zed.isi.edu (5.65c/4.0.3-4) id <AA09108>; Tue, 3 Jan 1995 15:35:52 -0800
Subject: Re: ftp://ftp.cisco.com/fred/rreq-03.txt
To: Fred Baker <fred@cisco.com>
Date: Tue, 3 Jan 1995 15:35:52 -0800 (PST)
Cc: bmanning@isi.edu, rreq@isi.edu
In-Reply-To: <v02110107ab2f7901462f@[198.92.24.2]> from "Fred Baker" at Jan 3, 95 02:36:03 pm
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1833

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

Actually, the document should reflect router requirements for IPv4.
Any other version of IP may have different world views.

> 
> >        - Routing System Security? - Add references only if protocol supports
> >                                security options
> >        - Routing Protocol Security? - same as above
> 
> I think this would refer to RIP V2 and OSPF's security support.

	Yes.  You should also mention the single authentication bit in BGP
	and that IDRP has such capability defined (there are two IDRP 
	implementations... )

	Places where the document calls out specific protocols, some verbage on
	specific security features should be noted.  Routing in the presence
	of security features (encryption of portions of the data field anyone?)
	might be mentioned.

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


	This should be sufficent.  We had talked briefly about these topics
	in the context of MTU and Router Discovery.
 
> >        - Congestion Control    - Allison M. will provide docs
> 
> not here yet. I have independently added some documents to the bibliography.

Allison actually told me that she would revive her thoughts on this and
forward them to you.

> >        - DNS resolver          - Add as comments to documentation
> 

	"A router MAY implement DNS resolver code as an aid to management."



Thanks for your excellent work.  

-- 
--bill