Subject: giveaway
From: "Shingumi Resources Pty Ltd ACN 080370092" <[email-masked]>
To: <[email-masked]>
Date: Sat, 28 Feb 1998 11:25:16 +1030

Dear Faculty,

This email address was listed at your school's home site. We, at Shingumi
Resources Pty Ltd, are suppliers of Japanese culture teaching resources. We
are currently offering a special on our Daily Life in Japan Unit.  This unit
consists of 50 pages divided up into 12 lessons. It includes a license to
photocopy a full class set. It is on sale for  $35.00. AS WELL AS
RFECREIVING ALL OF THE ABOVE YOU WILL RECEIVE AN ADDITIONAL 10% DISCOUNT IF
YOU ORDER WITRHIN 30 DAYS. Free offer! You are invited to order a sample
lesson from one of our units. Respond by email to order.

All you have to do is reply to this email with "remove" typed in the subject
line if you do not wish to receive further mail from us.

Sales Department
Shingumi Resources Pty Ltd

Date: Wed, 25 Feb 1998 09:46:27 -0500 (EST)
From: Ron da Silva <[email-masked]>
To: Masaki Hirabaru <[email-masked]>
cc: "Michael S. Briggs" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: next hop attribute in BGP multiprotocol packets 
Sender: [email-masked]

from a protocol standpoint, either can be introduced in an update msg
using a different type code.  bgp speakers that don't recognize the type  
code should drop the update.

different tcp connections would be implementation specific.  at least
that's the way i understood the rfc.

-ron

On Wed, 25 Feb 1998, Masaki Hirabaru wrote:

> Let me ask more basic question.
> Can't a BGP4 MP packet carry both IPv4 and IPv6 NRI?
> 
> Suppose that there are two MP (v4 and v6) routers peering,
> 1) they need to establish two TCP (v4 and v6) connections?
> 2) they share a TCP connection, interleaving IPv4 and v6 updates?
> 3) they may send both IPv4 and IPv6 NRIs in a MP update?
> 
> Thanks,
> Masaki
> 
> >> Date: Tue, 24 Feb 1998 14:39:36 -0500 (EST)
> >> From: "Michael S. Briggs" <[email-masked]>
> >> To: [email-masked]
> >> Cc: [email-masked], [email-masked]
> >> Subject: next hop attribute in BGP multiprotocol packets
> >> 
> >> 
> >> Has a decision been made on whether the v4 Next Hop attribute (attribute 
> >> type code 3) should be included in BGP MP packets? It appears thatThis 
> >> attribute is essentially useless in a BGP Multi-Protocol packet, 
> >> however, according to BGP4 it is a well-known mandatory attribute. 
> >> Nothing in the BGP MP draft says otherwise. So, should it be 
> >> included? It would be nice if the draft could be explicit about this. I 
> >> would appreciate any comments.
> >> 
> >> Thanks,
> >> Mike Briggs
> >> ------------------------------------------------------------
> >> Michael Briggs 			UNH InterOperability Lab
> >> [email-masked]            IP/Routing Consortium
> >> -------------------------------------------------------------

Date: Wed, 25 Feb 1998 09:46:27 -0500 (EST)
From: Ron da Silva <[email-masked]>
To: Masaki Hirabaru <[email-masked]>
cc: "Michael S. Briggs" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: next hop attribute in BGP multiprotocol packets 
Sender: [email-masked]

from a protocol standpoint, either can be introduced in an update msg
using a different type code.  bgp speakers that don't recognize the type  
code should drop the update.

different tcp connections would be implementation specific.  at least
that's the way i understood the rfc.

-ron

On Wed, 25 Feb 1998, Masaki Hirabaru wrote:

> Let me ask more basic question.
> Can't a BGP4 MP packet carry both IPv4 and IPv6 NRI?
> 
> Suppose that there are two MP (v4 and v6) routers peering,
> 1) they need to establish two TCP (v4 and v6) connections?
> 2) they share a TCP connection, interleaving IPv4 and v6 updates?
> 3) they may send both IPv4 and IPv6 NRIs in a MP update?
> 
> Thanks,
> Masaki
> 
> >> Date: Tue, 24 Feb 1998 14:39:36 -0500 (EST)
> >> From: "Michael S. Briggs" <[email-masked]>
> >> To: [email-masked]
> >> Cc: [email-masked], [email-masked]
> >> Subject: next hop attribute in BGP multiprotocol packets
> >> 
> >> 
> >> Has a decision been made on whether the v4 Next Hop attribute (attribute 
> >> type code 3) should be included in BGP MP packets? It appears thatThis 
> >> attribute is essentially useless in a BGP Multi-Protocol packet, 
> >> however, according to BGP4 it is a well-known mandatory attribute. 
> >> Nothing in the BGP MP draft says otherwise. So, should it be 
> >> included? It would be nice if the draft could be explicit about this. I 
> >> would appreciate any comments.
> >> 
> >> Thanks,
> >> Mike Briggs
> >> ------------------------------------------------------------
> >> Michael Briggs 			UNH InterOperability Lab
> >> [email-masked]            IP/Routing Consortium
> >> -------------------------------------------------------------

To: "Michael S. Briggs" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: next hop attribute in BGP multiprotocol packets 
Date: Wed, 25 Feb 1998 03:25:29 -0500
From: Masaki Hirabaru <[email-masked]>
Sender: [email-masked]

Let me ask more basic question.
Can't a BGP4 MP packet carry both IPv4 and IPv6 NRI?

Suppose that there are two MP (v4 and v6) routers peering,
1) they need to establish two TCP (v4 and v6) connections?
2) they share a TCP connection, interleaving IPv4 and v6 updates?
3) they may send both IPv4 and IPv6 NRIs in a MP update?

Thanks,
Masaki

>> Date: Tue, 24 Feb 1998 14:39:36 -0500 (EST)
>> From: "Michael S. Briggs" <[email-masked]>
>> To: [email-masked]
>> Cc: [email-masked], [email-masked]
>> Subject: next hop attribute in BGP multiprotocol packets
>> 
>> 
>> Has a decision been made on whether the v4 Next Hop attribute (attribute 
>> type code 3) should be included in BGP MP packets? It appears thatThis 
>> attribute is essentially useless in a BGP Multi-Protocol packet, 
>> however, according to BGP4 it is a well-known mandatory attribute. 
>> Nothing in the BGP MP draft says otherwise. So, should it be 
>> included? It would be nice if the draft could be explicit about this. I 
>> would appreciate any comments.
>> 
>> Thanks,
>> Mike Briggs
>> ------------------------------------------------------------
>> Michael Briggs 			UNH InterOperability Lab
>> [email-masked]            IP/Routing Consortium
>> -------------------------------------------------------------

To: "Michael S. Briggs" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: next hop attribute in BGP multiprotocol packets 
Date: Wed, 25 Feb 1998 03:25:29 -0500
From: Masaki Hirabaru <[email-masked]>
Sender: [email-masked]

Let me ask more basic question.
Can't a BGP4 MP packet carry both IPv4 and IPv6 NRI?

Suppose that there are two MP (v4 and v6) routers peering,
1) they need to establish two TCP (v4 and v6) connections?
2) they share a TCP connection, interleaving IPv4 and v6 updates?
3) they may send both IPv4 and IPv6 NRIs in a MP update?

Thanks,
Masaki

>> Date: Tue, 24 Feb 1998 14:39:36 -0500 (EST)
>> From: "Michael S. Briggs" <[email-masked]>
>> To: [email-masked]
>> Cc: [email-masked], [email-masked]
>> Subject: next hop attribute in BGP multiprotocol packets
>> 
>> 
>> Has a decision been made on whether the v4 Next Hop attribute (attribute 
>> type code 3) should be included in BGP MP packets? It appears thatThis 
>> attribute is essentially useless in a BGP Multi-Protocol packet, 
>> however, according to BGP4 it is a well-known mandatory attribute. 
>> Nothing in the BGP MP draft says otherwise. So, should it be 
>> included? It would be nice if the draft could be explicit about this. I 
>> would appreciate any comments.
>> 
>> Thanks,
>> Mike Briggs
>> ------------------------------------------------------------
>> Michael Briggs 			UNH InterOperability Lab
>> [email-masked]            IP/Routing Consortium
>> -------------------------------------------------------------

Date: Tue, 24 Feb 1998 14:39:36 -0500 (EST)
From: "Michael S. Briggs" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: next hop attribute in BGP multiprotocol packets
Sender: [email-masked]

Has a decision been made on whether the v4 Next Hop attribute (attribute 
type code 3) should be included in BGP MP packets? It appears thatThis 
attribute is essentially useless in a BGP Multi-Protocol packet, 
however, according to BGP4 it is a well-known mandatory attribute. 
Nothing in the BGP MP draft says otherwise. So, should it be 
included? It would be nice if the draft could be explicit about this. I 
would appreciate any comments.

Thanks,
Mike Briggs
------------------------------------------------------------
Michael Briggs 			UNH InterOperability Lab
[email-masked]            IP/Routing Consortium
-------------------------------------------------------------

Date: Tue, 24 Feb 1998 14:39:36 -0500 (EST)
From: "Michael S. Briggs" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: next hop attribute in BGP multiprotocol packets
Sender: [email-masked]

Has a decision been made on whether the v4 Next Hop attribute (attribute 
type code 3) should be included in BGP MP packets? It appears thatThis 
attribute is essentially useless in a BGP Multi-Protocol packet, 
however, according to BGP4 it is a well-known mandatory attribute. 
Nothing in the BGP MP draft says otherwise. So, should it be 
included? It would be nice if the draft could be explicit about this. I 
would appreciate any comments.

Thanks,
Mike Briggs
------------------------------------------------------------
Michael Briggs 			UNH InterOperability Lab
[email-masked]            IP/Routing Consortium
-------------------------------------------------------------

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-route-damp-02.txt,.ps
Date: Tue, 24 Feb 1998 10:55:28 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: BGP Route Flap Damping
	Author(s)	: C. Villamizar, R. Govindan, R. Chandra
	Filename	: draft-ietf-idr-route-damp-02.txt,.ps
	Pages		: 33
	Date		: 23-Feb-98
	
  A usage of the BGP routing protocol is described which is capable of
  reducing the routing traffic passed on to routing peers and therefore
  the load on these peers without adversely affecting route convergence
  time for relatively stable routes.  This technique has been
  implemented in commercial products supporting BGP. The technique is
  also applicable to IDRP.
 
  The overall goals are:
 
  o  to provide a mechanism capable of reducing router processing load
     caused by instability
 
  o  in doing so prevent sustained routing oscillations
 
  o  to do so without sacrificing route convergence time for generally
     well behaved routes.

  This must be accomplished keeping other goals of BGP in mind:
 
  o  pack changes into a small number of updates
 
  o  preserve consistent routing
 
  o  minimal addition space and computational overhead
  
  An excessive rate of update to the advertised reachability of a subset
  of Internet prefixes has been widespread in the Internet.  This
  observation was made in the early 1990s by many people involved in
  Internet operations and remains the case.  These excessive updates are
  not necessarily periodic so route oscillation would be a misleading
  term.  The informal term used to describe this effect is ``route
  flap''.  The techniques described here are now widely deployed and are
  commonly referred to as ``route flap damping''.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-route-damp-02.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-route-damp-02.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-idr-route-damp-02.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-route-damp-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-route-damp-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
cc: [email-masked]
Subject: IDR WG agenda topics
Date: Thu, 19 Feb 98 13:27:47 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

As you can see from the attached, we'll be meeting on 4/2 at 9:00.
Please send me or Sue Hares suggestions for the agenda items.
The deadline for suggestions is in 2 weeks (3/6/98).

Yakov.
------- Forwarded Message

Date: Thu, 19 Feb 1998 16:19:16 -0500
To: Yakov Rekhter <[email-masked]>
From: Marcia Beaulieu <[email-masked]>
Subject: 41st IETF-LOS ANGELES: IDR 
Cc: [email-masked], [email-masked]

This is to confirm one session for IDR as follows:

	Thursday, April 2 at 0900-1130 (opposite ipngwg, entmib, pkix, rtfm)

Please submit an agenda (to [email-masked]) for this meeting as soon as
possible.

Thanks,

Marcia

**********************************************************************
Marcia Beaulieu <[email-masked]>
Meeting Coordinator
Voice: 703-620-8990 ext. 210
Fax: 703-758-5913

------- End of Forwarded Message

From: [email-masked]
Date: Wed, 18 Feb 1998 17:08:00 -0500 (EST)
To: [email-masked]
Subject: Cluster-Lists and Originator-ids
Sender: [email-masked]

Hi,

I had a couple of queries on route reflection which I was hoping someone 
here could address.

[1] RFC 1966 says

   CLUSTER_LIST

   When a RR reflects a route from its Clients to a Non-Client peer, it
   must append the local CLUSTER_ID to the CLUSTER_LIST. If the
   CLUSTER_LIST is empty, it must create a new one. Using this attribute
   an RR can identify if the routing information is looped back to the
   same cluster due to mis-configuration. If the local CLUSTER_ID is
   found in the cluster-list, the advertisement will be ignored.

The RFC doesn't make a statement about attaching a cluster-id on reflecting
from a Non-Client/Client to a Client. Are there any known problems if 
the cluster-id is attached for the non-client/client to client reflections? 

[2] The use of Originator-ids is not completely clear to me - It seems that 
    they are primarily used in a bogus-update-sending-suppression capacity. 
    Is it ever the case that a misconfiguration leads to a receiving router
    discarding an update because its router-id matches the originator-id?

    On a related note, is it safe for a reflector to set the originator-id
    as follows :
    a) Don't overwrite originator-ids already attached to an update.
    b) Route from EBGP peer - set Originator id to my router-id before 
       sending it out. IBGP peers which do not understand this attribute 
       will ignore it.
    c) Route from IBGP peer - set Originator-id to the router-id of the 
       IBGP peer. Since the first reflector seeing an update knows the 
       router-id of the IBGP peer it can set this correctly.

(router-id is used to denote bgp-identifier.)

Thanks in advance for your comments.
--rohit.
#include <stdio.h>        /* Opinions mine alone ! */

Date: Wed, 18 Feb 1998 10:28:42 -0800
To: (Recipient list suppressed)
From: "[email-masked]" <[email-masked]>
Subject: Commercial delegate in Egypt
Sender: [email-masked]

Feb. 18th 1998. 

.                   

Dear Sirs,
     
I have the pleasure to enclose herewith a copy of my C.V. introducing myself
to you as a person of very good experience in Freight Forwarding &
International Transportation and in the different commercial services
related thereto; and proposing myself for representing your company in Egypt
and the Middle East as its own local resident COMMERCIAL DELEGATE looking
after your interests and projects in this area.
As a matter of fact, among lots of investors, many international freight
forwarding & transportation companies have started their own presence in
Egypt seizing the opportunity of the economic reformation achieved in this
area; as now is the right time for business starting in Egypt.
Starting with Commercial Delegation I foresee our final target, in case my
proposal meets your interest, is to develop that delegation into the full
operating company‘s branch in Egypt. That is to be achieved gradually by
time, but as quickly as possible, through building a good account of clients
and by selecting and training an efficient professional work team.
In addition to my  qualifications shown in my enclosed C.V., I am actually a
USA resident as per the Green Card I have got for lawful admission for
permanent residence in America (Employment Authorized). Such advantage is
considered as a good asset for a person appointed by an American company to
represent it as its own Commercial Delegate in the area where he was grown
up. Speaking their own language and understanding their mentality and the
way they think, such delegate can move among the company’s correspondents &
agents, its clients, the local official authorities, and any other concerned
parties to intervene, for his company’s favor, to avoid any probable
problems and to enhance the company’s achievements in this area.
For any further details and/or information, please feel free and do not
hesitate to contact me through any of the contact means listed among my
personal data in my C.V. attached hereto. You may also contact me, for the
time being and until Feb. 24th when I leave back to Egypt, through my
address in USA which is as follows:
915 Mount Olive Dr.  #3
Duarte,   CA 91010
Tel & Fax (626) 357 0243
E-mail: [email-masked]
Looking forward to getting the honor of working with your esteemed company,
I wish you all the best and remain
faithfully yours. 

 Isaac  Youssef

CURRICULUM VITAE
PERSONAL DATA:

Name:			   Isaac Youssef Atiya
Nationality; 		   Egyptian
Place and date of birth:    Cairo, On Oct. 5th 1951
Marital Status:		   Single
Education Degree:	   B.Sc. Cairo University
Contact Address:	   PO Box  #15
			   Al- Afdal Post Office
   Cairo-11627,  Egypt.

Tel:			   00202-235-3997
Fax:			   00202-236-7413
E-mail:                            [email-masked] 	 
 
JOB HISTORY & BUSINESS EXPERIENCE:

Jan. 1st. 94 - Currently:
PARTNER and MANAGER of CFT Int’1., CENTRE DU FRET ET DU TRANSPORT
INTERNATIONAL, which is actually an extension of GONDRAND Egypt     (A
former company mentioned below). As CFT Int’l., I represented the following
companies:
= SDV group, including SCAC, TTA, & ATT				France 
= TRANSCAP INTERNATIONAL					France
= GEFCO								France

Aug, 15th 91 - May 31st  94
The GENERAL MANAGER, and the only ACTIVE PARTNER of GONDRAND Egypt, one of
the most leading freight forwarding agents and the international transport
companies working in Egypt. As GONDRAND Egypt, I was the agent of many world
wide companies such as :
= S.F.T. GONDRAND FRERES					France
= MACH + 								France
= SAVING SHIPPING & FORWARDING 				Italy
= UTC, UNION TRANSPORT CORPORATION			USA
= UAT, UNION AIR TRANSPORT					Europe
= DSL, DISTRIBUTION SERVICES LTD				USA
= GEFCO								France
= TRUST FREIGHT							USA

Sep. 1st  88 - Aug. 14th 91:
During that period, besides managing an export- import group consisting of 3
sister companies, I worked in the following companies:
= DMC, the Egyptian daughter company of DOLLFUS MIEG ET CIE, one of the most
leading world wide French threads manufacturers, in which I worked as the
MATERIALS / INFORMATION FLOW & PURCHASING MANAGER. My duties included the
following:
1-  Supplying and furnishing both of the clients of the company and its
employees with whatever they needed of information, materials, services, and
/or products.
2-  Controlling the flow of all the materials imported or locally purchased.
3-  Supervising the import formalities and regulations with Banks, Customs
and Governmental authorities, Air and Maritime lines, and Freight Forwarding
agents.
4-  Supervising purchasing and maintenance of the company assets through
different contractors, suppliers, and services companies.
5-  Controlling the circulation of raw materials and products.
= AMECO, an Egyptian freight forwarder which, in the same time, represents
ships owners. In AMECO I had the position of the ASSISTANT MANAGER of Cairo
branch.    
= MEDTRANS, The Egyptian correspondent of a group of European and American
freight forwarding companies, such as the French company S.F.T. GONDRAND
FRERES, And the American company DANIEL F. YOUNG Inc.. In MEDTRANS I had the
position of the EXECUTIVE MANAGER.

Feb. 1st 80 - Aug. 31st 88 :
A SUPERVISOR and a DEPARTMENT HEAD in MFA - MISR FREIGHT AGENCIES - The
Egyptian branch of the world wide DANZAS company for international
transportation and freight forwarding - which had, at that time, 450 offices
distributed in 42 countries with the head office in Switzerland.
In MFA- DANZAS Egypt - I supervised the following departments:
1-  Sea Freight Dep. (Conventional and General Cargo, and Containerized
Shipments).
2-  Air Freight Dep.
3-  Projects Transport Dep.
4-  Transit Goods & Distribution Dep.
5-  Fairs & International Exhibitions Transport Dep.
6-  The Local Operations & Inland Road Transport Dep.
7-  Besides the above, I supervised some special inter-branches relations
between MFA and the other world wide branches of DANZAS group.
      
Before MFA was founded, I worked in the above capacities for the COMMERCIAL
DELEGATION OF DANZAS in Egypt.

Sept. 78 - Jan. 31st 80:
	The DIRECTOR ASSISTANT of CENTER FOR EGYPTIAN CIVILIZATION STUDIES, in
which I supervised the following:
1-  Planning & Execution of programs
2-  Administration
3-  Public Relations
4-  Correspondence
5-  Translation

OTHER QUALIFICATIONS:

= Courses in MANAGEMENT SKILLS FOR SUPERVISORS AND DEPARTMENT
HEADS organized by Monadonck International Limited - London, for
International Management Development.
=  A seminar and a long training course in PROJECTS TRANSPORT, SEA FREIGHT,
and INLAND ROAD TRANSPORT in  DANZAS  branch in Zurich city, and in  AIR
FREIGHT in its branch in Kloten airport of Zurich.
= Courses in BUSINESS ADMINISTRATION including FINANCE FOR NON- FINANCIAL
MANAGERS, AN INTRODUCTION TO COST ACCOUNTING, and BASIC PRINCIPLES OF
FEASIBILITY STUDIES. These courses were organized by The Egyptian-German
Association for Economical and Social Development of The Arab-German Chamber
of Commerce in Cairo, among the Business Administration Program in Egypt
sponsored by Konrad-Adenauer Foundation.
=  Write and Speak English language.
=  Some courses in French language, and still studying.
= Traveled in Business Trips to many  countries, such as Switzerland, UK,
France, Germany, Turkey, and USA.
=  Active, Head Working, Ambitious, and willing for constant movement &
traveling.
=  Fond of creating new businesses in Egypt.

    Signature 

Isaac Youssef

PS:
Besides the ordinary transport activities and the services related to the
freight forwarding business, I represent my clients in the various official
authorities, e.g. Customs Authority; Investment Authority, General
Organization for Fairs & International Exhibitions, Egyptian General
Petroleum Corporation, National Authority for Wire and Wireless
Communications, Traffic Administration, The Import Rationalization Committee
of the Ministry of Foreign Trade, Banks, Embassies, and Chambers of
Commerce……etc.. 

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing to Proposed Standard
Date: Wed, 18 Feb 1998 08:12:47 -0500
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing'
<draft-ietf-idr-bgp4-ipv6-01.txt> as a Proposed Standard.  This
document is the product of the Inter-Domain Routing Working Group.  The
IESG contact person is Joel Halpern.

Technical Summary
 
 This protocol specification defines the extensions to multi-protocol BGP-4
 required to support IPv6.  It thereby provides the mechanisms need to have an
 inter-domain routing protocol for IPv6, with all of the proerties of BGP-4.

Working Group Summary

 There was strong consensus in the working group in support of this document.
 Alternatives werediscussed, and this was agreed as the way forward.

Protocol Quality

 The document has been reviewed for the IESG by Joel M. Halpern, the Routing
 Area Director. Use of this protocol has begun in multiple implementations.

To: [email-masked]
cc: Tony Li <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Regarding draft-ietf-idr-bgp4-07.txt 
Date: Mon, 16 Feb 1998 20:12:47 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, [email-masked]
m writes:
> 
> I see a change here
> 
> The LOCAL_PREF  is changed to well known mandatory attribute from well
> known descretionary.
> and in the text some "SHALL" is changed to "MUST" (Page 24)
> 
> 1. Text says that A BGP speaker MUST NOT include this attribute in UPDATE
> message that it sends
> to external peers.
> 
> a. This is contradiction to the definition of "Well Known Mandatory
> attribute"( page 20).  The problem is
>      if external peer does not see this attribute, according to "BGP Error
> handling" (page 25), error subcode
>      is set to "missing well-known attribute" , notification message is
> sent and BGP connection will be closed,
>      which is not expected.
> 
> b. What is the reason for changing "SHALL NOT" to "MUST NOT" ?
> 
> 2. Text says that The higher degree of preference MUST be prefered
> a. What is the reason for changing SHALL to MUST ? Is this not related to
> policy matter ?
> 
> Thanks in advance
> 
> Rajesh Joshi

LOCAL_PREF is manditory on IBGP and not applicable to EBGP.
LOCAL_PREF MUST be included in IBGP and MUST NOT be included in EBGP.
The draft says this but uses more verbose wording rather than IBGP and
EBGP (I assume you know what these mean).

The route selection criteria was defined in such a way that there was
no room for differing interpretations that could cause routing loops
in multi-vendor networks.  Routing loops could in the past be formed
if (for example) routers from one vendor decided that shortest AS path
length was important and another didn't.  This is a real example.

There was clearly more than a wording cleanup in this area.  You might
want to check the mailing list archives for the full justification.

Curtis

To: [email-masked]
Subject: BGP-4 for IPv6 to Proposed Standard
Date: Mon, 16 Feb 98 14:49:11 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

The IESG pointed out that the I-D contained a reference to BGP
Capability Negotiation, and that BGP Capability Negotiation is still an
Internet Draft. To avoid this problem the authors of the I-D took out
the text on using BGP Capability Negotiation, and republished the
revised I-D (see attached). If there are any objections to this change,
please post it to the mailing list before 2/23.

Yakov.
------- Forwarded Message

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-ipv6-01.txt
Date: Tue, 10 Feb 1998 10:07:52 -0500
Sender: [email-masked]

- --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Use of BGP-4 Multiprotocol Extensions 
                          for IPv6 Inter-Domain Routing
	Author(s)	: F. Dupont, P. Marques
	Filename	: draft-ietf-idr-bgp4-ipv6-01.txt
	Pages		: 5
	Date		: 09-Feb-98
	
   BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP
   attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to
   announce and withdraw the announcement of reachability information.
   This document defines how compliant systems should make use of those
   attributes for the purpose of conveying IPv6 routing information.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-ipv6-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-ipv6-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-ipv6-01.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-ipv6-01.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-ipv6-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

From: Andrade Software Andrade Networking <[email-masked]>
Subject: Routing questions about IPv4 header
To: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sat, 14 Feb 1998 22:32:33 -0800 (PST)
Cc: [email-masked] (Alex Alten)
Sender: [email-masked]

Andrade Software & Networking
[email-masked]
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2111      

Pardon me if I've reached the wrong discussion groups.
These seemed to be the best ones for answering my 
questions.

My questions are about the behavior of routers
as IPv4 datagrams flow through them. These 
are based on my understanding of RFC 791.

I need to understand some subtle issues with the 
handling of the IPv4 header.  In particular I 
want to know if any of the following will break the 
proper routing behavior or cause IPv4 packets to be 
discarded with typical routers now deployed on the 
Internet.

Q1: In byte #7 there are three bits reserved.  The 
    highest bit is always set to 0.  Can it be set 
    to 1?

Q2: Again in byte #7, if the DF bit is 1 is the MF bit
    ignored?  Can it be set to 1?

Q3: If the DF bit is 1 are the Offset (13 bits in bytes
    #7 & #8) and the Identification (16 bits in bytes #5 
    & #6) fields ignored?  Can they be set to any value?

Q4: In byte #2 is the Type of Service Field ever used?
    Can any pattern be set here?

Q5: Options can follow byte #20.  An option has a two
    byte header, the 2nd byte is the length in bytes.
    This means that the data can be up to 254 bytes
    in length.  However the IHL has a maximum value
    of 15 (= 60 bytes).  Does this mean that the
    option data only has a real maximum of 38 bytes
    (40 minus the 2 option header bytes)?

Q6: Will routers honor datagrams that include an option 
    field that carry routing or neighbor greeting 
    information?  For example, if the payload a RIP,
    LSP or IS-IS data?  Or it is an ICMP message?

Q7: As a follow on to Q6.  Can the option be an option
    which has not yet been defined in an RFC?  E.g.
    an experimental or unregistered option number?
    Will a router honor it?  Will it allow RIP, LSP,
    IS-IS, ICMP, etc. to piggyback on it?

I appreciate any answers you may have.  Please ensure that
your response includes my email address ([email-masked])
since I am not a subscriber to your discussion group.

Thank you,

- Alex Alten
-- 

Alex Alten
P.O. Box 11406
Pleasanton, CA  94588
USA

[email-masked]
(510) 417-0159   Fax/Voice

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-ipv6-01.txt
Date: Tue, 10 Feb 1998 10:07:52 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Use of BGP-4 Multiprotocol Extensions 
                          for IPv6 Inter-Domain Routing
	Author(s)	: F. Dupont, P. Marques
	Filename	: draft-ietf-idr-bgp4-ipv6-01.txt
	Pages		: 5
	Date		: 09-Feb-98
	
   BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP
   attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to
   announce and withdraw the announcement of reachability information.
   This document defines how compliant systems should make use of those
   attributes for the purpose of conveying IPv6 routing information.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-ipv6-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-ipv6-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-ipv6-01.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-ipv6-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-ipv6-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 10 Feb 1998 07:49:35 -0800
To: Anand Kumar Goenka <[email-masked]>
From: Fred Baker <[email-masked]>
Subject: Re: Directed Broadcasts in CIDR domain..
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 12:02 PM +0530 2/10/98, Anand Kumar Goenka wrote:
>       a) A directed broadcast to 150.1.8.0/21 - in this case router has
>to forward the packet to both 150.1.10.0/23 and 150.1.16.0/23
>       b) A directed broadcast to 150.1.16.0/23 - in this case router
>has to forward the packet only to 150.1.16.0/23
>
>Question - which one of the above interpretation is correct ?

since the address is ambiguous, I would think (speaking for myself and
nobody else) that the most robust interpretation is (a).

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"The best way to predict the future is to create it"
	---Peter Drucker 

Comments: ( Received on motgate.mot.com from client pobox.mot.com, sender [email-masked] )
Date: Tue, 10 Feb 1998 12:02:22 +0530
From: Anand Kumar Goenka <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Directed Broadcasts in CIDR domain..
Sender: [email-masked]

Hi All,
      
     I am referring to sec 5.3.5 of RFC-1812-"Router Specification"
According to this RFC "All subnet directed broadcast" is meaningless in
CIDR routing domain and also "Network-prefix directed broadcast" and
"subnet Directed
Broadcast" has same meaning in CIDR routing domain.
   But there is problem in the way a CIDR capable ruoter can(or should)
interprate an incomming directed broadcast.
Scenario Description:
      Suppose router has the routing table entries for following 3
networks..
      
        1.  150.1.10.0/23
        2.  150.1.16.0/23
        3.  150.1.8.0/21

and the router received a packet with destination address 150.1.15.255 .
Considering the above routing table entries router can have following
directed 
broadcast interpretation for this packet.

       a) A directed broadcast to 150.1.8.0/21 - in this case router has
to forward the packet to both 150.1.10.0/23 and 150.1.16.0/23
       b) A directed broadcast to 150.1.16.0/23 - in this case router
has to forward the packet only to 150.1.16.0/23
       
Question - which one of the above interpretation is correct ?

An early reply will be helpfull..

Thanks & Regards,

Anand Kumar Goenka,
Motorola India Electronics Ltd,
Email: [email-masked]

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Protection of BGP Sessions via the TCP MD5 Signature Option to Proposed Standard
Reply-to: [email-masked]
Date: Fri, 06 Feb 1998 13:06:37 -0500
Sender: [email-masked]

The IESG has received a request from the Inter-Domain Routing Working
Group to consider Protection of BGP Sessions via the TCP MD5 Signature
Option <draft-heffernan-bgp-tcp-md5-00.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by February 20, 1998.

Files can be obtained via
ftp://ds.internic.net/internet-drafts/draft-heffernan-bgp-tcp-md5-00.txt

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Multiprotocol Extensions for BGP-4 to Proposed Standard
Date: Fri, 06 Feb 1998 11:54:16 -0500
Sender: [email-masked]

The IESG has approved the Internet-Draft "Multiprotocol Extensions for
BGP-4" <draft-ietf-idr-bgp4-multiprotocol-02.txt> as a Proposed
Standard.  This document is the product of the Inter-Domain Routing
Working Group.  The IESG contact persons is Joel Halpern.

Technical Summary
 
 The Multiprotocol Extensions for BGP-4 allow BGP-4 to be used for
 routing reachability information for protocols other than IPv4.  It
 can be used to carry IPv6 information, and even information for other
 internetworking protocols.  The extensions also allow for the clear
 handling of multicast RPF Information as a separate set of information
 from the unicast case.

Working Group Summary

 The working group strongly supports this work as the solution to the
 need for multiprotocol support in BGP-4.  Other solutions were
 discussed and considered, and it was concluded clearly that this was
 the best available answer.

Protocol Quality

 This specification has been reviewed by Joel M. Halpern, the Routing
 Area Director, and is a sound protocol specification. There are
 multiple  implementations of this protocol for supporting IPv6, as
 well as at least one  for IPv4 multicast.

Note to RFC Editor: 

The following text should appended to Section 7 of the document:

     Subsequent Address Family Identifiers (other than those reserved for
     vendor specific use) are assigned only by the IETF consensus process and
     IESG approval.

From: [email-masked]
To: Tony Li <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Date: Wed, 4 Feb 1998 11:42:47 -0800
Subject: Re: Regarding draft-ietf-idr-bgp4-07.txt
Sender: [email-masked]

I see a change here

The LOCAL_PREF  is changed to well known mandatory attribute from well
known descretionary.
and in the text some "SHALL" is changed to "MUST" (Page 24)

1. Text says that A BGP speaker MUST NOT include this attribute in UPDATE
message that it sends
to external peers.

a. This is contradiction to the definition of "Well Known Mandatory
attribute"( page 20).  The problem is
     if external peer does not see this attribute, according to "BGP Error
handling" (page 25), error subcode
     is set to "missing well-known attribute" , notification message is
sent and BGP connection will be closed,
     which is not expected.

b. What is the reason for changing "SHALL NOT" to "MUST NOT" ?

2. Text says that The higher degree of preference MUST be prefered
a. What is the reason for changing SHALL to MUST ? Is this not related to
policy matter ?

Thanks in advance

Rajesh Joshi

Tony Li <[email-masked]> on 02/04/98 10:59:42 AM

To:   [email-masked]
cc:   [email-masked], [email-masked], [email-masked] (Rajesh Joshi/HQ/3Com)
Subject:  Re: Regarding draft-ietf-idr-bgp4-07.txt

|  Is there any document for what exactly  the modifications/changes  done
to
|  RFC 1771 to have
|   draft-ietf-idr-bgp4-07.txt ? If not, can you point the
|  changes/modifications broadly ?
Oh dear.  Mostly I think we've cleaned up text, but Yakov may have actual
diffs.
Tony

Date: Wed, 4 Feb 1998 10:59:42 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Regarding draft-ietf-idr-bgp4-07.txt
Sender: [email-masked]

|  Is there any document for what exactly  the modifications/changes  done to
|  RFC 1771 to have
|   draft-ietf-idr-bgp4-07.txt ? If not, can you point the
|  changes/modifications broadly ?

Oh dear.  Mostly I think we've cleaned up text, but Yakov may have actual
diffs.

Tony

From: [email-masked]
To: [email-masked], [email-masked]
cc: [email-masked]
Date: Wed, 4 Feb 1998 10:48:26 -0800
Subject: Regarding draft-ietf-idr-bgp4-07.txt
Sender: [email-masked]

Hi

Is there any document for what exactly  the modifications/changes  done to
RFC 1771 to have
 draft-ietf-idr-bgp4-07.txt ? If not, can you point the
changes/modifications broadly ?

Thanks
Rajesh Joshi

Date: Wed, 4 Feb 1998 00:44:07 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

|  *  an example topology in which there is no legal path between some pair 
|  of routing domains even though physical connectivity does exist.

Any topology at all suffices.  Simply have all ASs between source and
destination not advertise any prefixes.

|  *  an example in which the absence of AS path information would lead to 
|  long convergence time.

I don't understand the question.  In the above example, you never
converge.  Is that long enough?

AS path information is not optional.  It must be present with an
advertisement.

|  * can u give an expression for the overhead of keeping and passing 
|  around complete AS path information instead of head of path information 
|  ?

The latter is not tractable.

Tony

From: "hemal patel" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Tue, 03 Feb 1998 23:17:05 PST
Sender: [email-masked]

Today I read  paper
				Title        		: A Border Gateway Protocol 4 (BGP-4)
        Author(s)       : T. Li, Y. Rekhter
        Filename        : draft-ietf-idr-bgp4-07.txt
        Pages           : 59
My questions are :
*  an example topology in which there is no legal path between some pair 
of routing domains even though physical connectivity does exist.

*  an example in which the absence of AS path information would lead to 
long convergence time.

* can u give an expression for the overhead of keeping and passing 
around complete AS path information instead of head of path information 
?

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From: [email-masked]
Date: Tue, 3 Feb 1998 23:33:46 -0500 (EST)
To: [email-masked]
Subject: Re: Should we offer Monica
Reply-to: [email-masked]
Comments: Authenticated sender is <[email-masked]>
Sender: [email-masked]

How much should we offer Monica to appear 
on http://www.212.net with her story of 
Linda and George at the Alexandria Hyatt?

[email-masked]

................................................................
to unsubscribe from this listserver hit reply
and type unsubscribe in the subject line.
................................................................

From: [email-masked]
Date: Tue, 3 Feb 1998 22:54:27 -0500 (EST)
To: [email-masked]
Subject: Re: Should we offer Monica
Reply-to: [email-masked]
Comments: Authenticated sender is <[email-masked]>
Sender: [email-masked]

How much should we offer Monica to appear 
on http://www.212.net with her story of 
Linda and George at the Alexandria Hyatt?

[email-masked]

................................................................
to unsubscribe from this listserver hit reply
and type unsubscribe in the subject line.
................................................................

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-07.txt
Date: Tue, 03 Feb 1998 09:38:27 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: A Border Gateway Protocol 4 (BGP-4)
	Author(s)	: T. Li, Y. Rekhter
	Filename	: draft-ietf-idr-bgp4-07.txt
	Pages		: 59
	Date		: 02-Feb-98
	
   The Border Gateway Protocol (BGP) is an inter-Autonomous System
   routing protocol.  It is built on experience gained with EGP as
   defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
   described in RFC 1092 [2] and RFC 1093 [3].

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-07.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-07.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-07.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
cc: [email-masked]
Subject: Re: draft-ietf-idr-bgp4-06.txt 
Date: Sun, 01 Feb 98 14:41:53 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Curtis,
 
> draft-ietf-idr-bgp4-06.txt is about to expire.
> 
> Does that concern anyone?  What happenned to updating BGP-4?

I just submitted an updated version.

Yakov.