Subject: draft-ietf-idr-bgp4-06.txt
From: Curtis Villamizar <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 30 Jan 1998 23:12:09 -0500

draft-ietf-idr-bgp4-06.txt is about to expire.

Does that concern anyone?  What happenned to updating BGP-4?

Curtis

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Document Action: Using a Dedicated AS for Sites Homed to a Single Provider to Informational
Date: Thu, 22 Jan 1998 14:31:25 -0500
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Using a Dedicated AS for
Sites Homed to a Single Provider' <draft-ietf-idr-as-dedicated-00.txt>
as a Informational.  This document is the product of the Inter-Domain
Routing Working Group. 

The IESG contact person is Joel Halpern.

Date: Tue, 20 Jan 1998 15:29:32 -0500
From: Email Submission <[email-masked]>
Reply-To: Email Submission <[email-masked]>
To: friend@bulkmailer
Subject: Ad: TAIM Certified E-mail FREE 3D Animation Software Demo
Sender: [email-masked]

Download a FREE trial version of the world's easiest-to-use 3D animation
software, Crystal 3D IMPACT! Pro.  Now it's a snap for web developers,
video enthusiasts and others to add the impact of extraordinary 3D
titles, logos, objects, buttons and pictures to web pages, e-mail
messages, banner ads, videos and presentations.  This newly released
software (for Windows 95 or NT) can be downloaded at
http://www.crystalgraphics.com/weblink1.3dimpact.html.

Crystal 3D IMPACT! Pro is a breakthrough in ease of use and lets you
start creating eye-catching, animated 3D graphics immediately with the
program's friendly wizards.  There are also many time saving features
like an Auto-Outline tool that lets you easily and accurately trace your
complicated designs and company logos.  Crystal 3D IMPACT! Pro is the
only 3D program that lets you automatically import your images as 2D
objects then animate them in 3D with a single click. 

Crystal 3D IMPACT! Pro (released November 18, 1997) is the latest 3D
product from CrystalGraphics, a leading developer of award-winning 3D
software for over 10 years.

Here's what others say about this hot new product:
"I was in awe of the simplicity of the interface!  You gotta try it
out!"
        -- Bruce Beard, Web Designer

"The awesome speed, quality and power are the best I've ever seen
in any product of its class!"
        -- Mark Wacholtz, Web Developer

"The effects are dazzling; the images almost seem to jump off the
screen.
Now anybody can make 3D animations look as if they came out of a 
high-end production house."
        -- Greg Carroll, TV Marketing Executive

TOP TEN REASONS TO DOWNLOAD CRYSTAL 3D IMPACT! PRO:
1.  The trial version is FREE!
2.  It will make your web pages, banner ads, videos and presentations
stand out!
3.  It is incredibly easy-to-use, much easier than any other 3D product!
4.  It lets you easily add 3D titles, logos, objects, buttons and
pictures to your work!
5.  It has a wizard which walks you through the 5 basic steps of
creating 3D title animations!
6.  It is extremely powerful and lets you control professional-level
rendering effects like soft-edged shadows, ray-traced refractions, video
backgrounds, object reflections and much more!
7.  Its photorealistic output will impress everyone!
8.  It renders up to 5 times faster than the competition!
9.  It includes over 145 high-quality, pre-built 3D "clipart" objects,
with more free each month at our web site!
10.  It is fully compatible with popular web authoring, digital video
editing and presentation software!

Again, here is where you can find your FREE trial version of Crystal 3D
IMPACT! Pro:
http://www.crystalgraphics.com/weblink1.3dimpact.html.

Thank you,
Your Friends at CrystalGraphics
408-496-6175

If you don't want to receive future e-mail messages about 
CrystalGraphics products, please reply to this message with 
"REMOVE" in the subject field.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-multiprotocol-02.txt
Date: Thu, 15 Jan 1998 11:54:25 -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		: Multiprotocol Extensions for BGP-4
	Author(s)	: D. Katz, Y. Rekhter, T. Bates, R. Chandra
	Filename	: draft-ietf-idr-bgp4-multiprotocol-02.txt
	Pages		: 9
	Date		: 14-Jan-98
	
Currently BGP-4 [BGP-4] is capable of carrying routing information
   only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
   enable it to carry routing information for multiple Network Layer
   protocols (e.g., IPv6, IPX, etc...). The extensions are backward
   compatible - a router that supports the extensions can interoperate
   with a router that doesn't support the extensions.

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-multiprotocol-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-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-bgp4-multiprotocol-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-bgp4-multiprotocol-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-multiprotocol-02.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: draft-ietf-idr-route-damp-01.txt
Date: Thu, 15 Jan 98 07:05:47 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Joel,

The IDR WG would like to ask the IESG to advance
draft-ietf-idr-route-damp-01.txt to a Proposed Standard.

Yakov.

To: [email-masked]
cc: [email-masked]
Subject: draft-heffernan-bgp-tcp-md5-00.txt
Date: Thu, 15 Jan 98 07:07:19 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Joel,

The IDR WG would like to ask the IESG to advance
draft-heffernan-bgp-tcp-md5-00.txt to a Proposed Standard.

Yakov.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-route-damp-01.txt,.ps
Date: Wed, 14 Jan 1998 09:53:05 -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-01.txt,.ps
	Pages		: 30
	Date		: 13-Jan-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
  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
  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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-route-damp-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-route-damp-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-route-damp-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-route-damp-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, 13 Jan 1998 13:48:09 +0100
From: "Hannes R. Boehm" <[email-masked]>
To: Project account - Bombay gate <[email-masked]>
Cc: [email-masked]
Subject: Re: Community Attributes
Sender: [email-masked]

--fUYQa+Pmc3FrFX/N
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 13, 1998 at 11:00:49AM -0530, Project account - Bombay gate wro=
te:
> Hi
> In Examples section of  RFC 1997 it is mentioned that=20
> "It is often useful to advertise both an aggregate prefix and the=20
> component more specific prefixes that were used to form the aggregate to=
=20
> optimize the 'next hop'  routing".
> My doubt is =20
> 1. What is this optimization of 'next hop' routing based on the more=20
> specific prefixes when both the aggregate prefix and the more specific=20
> prefixes are advertised.
> 2. When it is useful to advertise both aggregate prefix and the=20
> contributing prefixes.=20

2) I can give you a simple example: =20

Consider a AS that is multihomed to a single provider.=20

----------------------------------------------
|                                 AS2        |
|---------------------------------------------
     | Link 1                       | Link 2
     | 20.10.0.0/22                 | 20.10.0.0/22
     | 20.10.0.0/23 no_export       | 20.10.2.0/23 no_export
     |                              |
----------------------------------------------
|                                 AS1        |
|  20.10.0.0-20.10.4.                        |
|---------------------------------------------

AS1 announces the aggregate (20.10.0.0/22) on both Links, 20.10.0.0/23 with=
 the
community noexprt on Link1 and 20.10.2.0/23 with noexport on Link2.

What happens?

AS2 is not allowed to announce the more specific routes (20.10.0.0/23 and 2=
0.10.2.0/23)
-> the global routing table contains only the aggregate 20.10.0.0/22 (Path:=
 ^.*_2 1$)
BUT: AS2 has more specific routes -> it routes the net 20.10.0.0/23 via Lin=
k1 and 20.10.2.0/23
via Link2.

What happens if Link1 fails ?

AS2 looses the route for 20.10.0.0/23
-> the aggregated route (20.10.0.0/22) is used for packets to 20.10.0.0/23 =
(via Link2)

Of course this does not only work for community no_export.

-> The community has more detailed routing information than the global rout=
ing table.

1) This is some kind of optimisation, isn=B4t it ? :)

CU,=20
   Hannes Boehm

--=20
--
"The nice thing about standards is that there's so many to choose from."=20
        -- Andrew S. Tannenbaum
!------------------------------------------------------------------!
  Hannes R. Boehm
        email   : [email-masked]
        www     : http://hannes.boehm.org
        PGP-key : http://hannes.boehm.org/hannes-pgp.asc
!------------------------------------------------------------------!

--fUYQa+Pmc3FrFX/N
Content-Type: application/pgp-signature

Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 13, 1998 at 11:00:49AM -0530, Project account - Bombay gate wro=
te:
> Hi
> In Examples section of  RFC 1997 it is mentioned that=20
> "It is often useful to advertise both an aggregate prefix and the=20
> component more specific prefixes that were used to form the aggregate to=
=20
> optimize the 'next hop'  routing".
> My doubt is =20
> 1. What is this optimization of 'next hop' routing based on the more=20
> specific prefixes when both the aggregate prefix and the more specific=20
> prefixes are advertised.
> 2. When it is useful to advertise both aggregate prefix and the=20
> contributing prefixes.=20

2) I can give you a simple example: =20

Consider a AS that is multihomed to a single provider.=20

----------------------------------------------
|                                 AS2        |
|---------------------------------------------
     | Link 1                       | Link 2
     | 20.10.0.0/22                 | 20.10.0.0/22
     | 20.10.0.0/23 no_export       | 20.10.2.0/23 no_export
     |                              |
----------------------------------------------
|                                 AS1        |
|  20.10.0.0-20.10.4.                        |
|---------------------------------------------

AS1 announces the aggregate (20.10.0.0/22) on both Links, 20.10.0.0/23 with=
 the
community noexprt on Link1 and 20.10.2.0/23 with noexport on Link2.

What happens?

AS2 is not allowed to announce the more specific routes (20.10.0.0/23 and 2=
0.10.2.0/23)
-> the global routing table contains only the aggregate 20.10.0.0/22 (Path:=
 ^.*_2 1$)
BUT: AS2 has more specific routes -> it routes the net 20.10.0.0/23 via Lin=
k1 and 20.10.2.0/23
via Link2.

What happens if Link1 fails ?

AS2 looses the route for 20.10.0.0/23
-> the aggregated route (20.10.0.0/22) is used for packets to 20.10.0.0/23 =
(via Link2)

Of course this does not only work for community no_export.

-> The community has more detailed routing information than the global rout=
ing table.

1) This is some kind of optimisation, isn=B4t it ? :)

CU,=20
   Hannes Boehm

--=20
--
"The nice thing about standards is that there's so many to choose from."=20
        -- Andrew S. Tannenbaum
!------------------------------------------------------------------!
  Hannes R. Boehm
        email   : [email-masked]
        www     : http://hannes.boehm.org
        PGP-key : http://hannes.boehm.org/hannes-pgp.asc
!------------------------------------------------------------------!

--fUYQa+Pmc3FrFX/N--

Date: Tue, 13 Jan 1998 14:30:41 -0530 (IST)
From: Project account - Bombay gate <[email-masked]>
Subject: AS CONFEDERATIONS
To: [email-masked]
Sender: [email-masked]

Hello
The AS_PATH modification rules section of the RFC 1965 states that 
"When a given BGP speaker advertises the route to another BGP speaker 
located in a neighboring autonomous system that is a member of the local 
autonomous system confederation, then the advertising speaker shall 
update the AS_PATH attribute as follows.
2) If the first path segment of the AS_PATH is not of type 
AS_CONFED_SEQUENCE the local system shall prepend a new path segment of 
type AS_CONFED_SEQUENCE to the AS_PATH, including its own confederation 
identifier in that segment"

But it is suppose prepend its own AS number and not the confederation 
identifier.  Any thoughts on this issue.
Regards
Sridhar

From: [email-masked] (Project account - Bombay gate)
Subject: Clarification about SNPAs
To: [email-masked]
Date: Tue, 13 Jan 1998 13:07:33 -0530 (IST)
Sender: [email-masked]

Hi,
Is SNPA field present in the MP_REACH_NLRI attribute similar to LLC-SNAP
encapsulation for demultiplexing in NBMA type media or just provided for a
IP to MAC address resolution.
Kindly throw more light on its usage
regards
mouli

Date: Tue, 13 Jan 1998 11:00:49 -0530 (IST)
From: Project account - Bombay gate <[email-masked]>
Subject: Community Attributes
To: [email-masked]
Sender: [email-masked]

Hi
In Examples section of  RFC 1997 it is mentioned that 
"It is often useful to advertise both an aggregate prefix and the 
component more specific prefixes that were used to form the aggregate to 
optimize the 'next hop'  routing".
My doubt is  
1. What is this optimization of 'next hop' routing based on the more 
specific prefixes when both the aggregate prefix and the more specific 
prefixes are advertised.
2. When it is useful to advertise both aggregate prefix and the 
contributing prefixes. 

Regards
Sridhar

Date: Mon, 12 Jan 1998 19:43:14 -0500
From: Email Submission <[email-masked]>
Reply-To: Email Submission <[email-masked]>
To: friend@bulkmailer
Subject: Ad: TAIM Certified E-mail FREE 3D Animation Software Demo!
Sender: [email-masked]

 FREE 3D Animation Software Demo!

Download a FREE trial version of the world's easiest-to-use 3D animation
software, Crystal 3D IMPACT! Pro.  Now it's a snap for web developers,
video enthusiasts and others to add the impact of extraordinary 3D
titles, logos, objects, buttons and pictures to web pages, e-mail
messages, banner ads, videos and presentations.  This newly released
software (for Windows 95 or NT) can be downloaded at
http://www.crystalgraphics.com/weblink1.3dimpact.html.

Crystal 3D IMPACT! Pro is a breakthrough in ease of use and lets you
start creating eye-catching, animated 3D graphics immediately with the
program's friendly wizards.  There are also many time saving features
like an Auto-Outline tool that lets you easily and accurately trace your
complicated designs and company logos.  Crystal 3D IMPACT! Pro is the
only 3D program that lets you automatically import your images as 2D
objects then animate them in 3D with a single click. 

Crystal 3D IMPACT! Pro (released November 18, 1997) is the latest 3D
product from CrystalGraphics, a leading developer of award-winning 3D
software for over 10 years.

Here's what others say about this hot new product:
"I was in awe of the simplicity of the interface!  You gotta try it
out!"
	-- Bruce Beard, Web Designer

"The awesome speed, quality and power are the best I've ever seen
in any product of its class!"
	-- Mark Wacholtz, Web Developer

"The effects are dazzling; the images almost seem to jump off the
screen.
Now anybody can make 3D animations look as if they came out of a 
high-end production house."
	-- Greg Carroll, TV Marketing Executive

TOP TEN REASONS TO DOWNLOAD CRYSTAL 3D IMPACT! PRO:
1.  The trial version is FREE!
2.  It will make your web pages, banner ads, videos and presentations
stand out!
3.  It is incredibly easy-to-use, much easier than any other 3D product!
4.  It lets you easily add 3D titles, logos, objects, buttons and
pictures to your work!
5.  It has a wizard which walks you through the 5 basic steps of
creating 3D title animations!
6.  It is extremely powerful and lets you control professional-level
rendering effects like soft-edged shadows, ray-traced refractions, video
backgrounds, object reflections and much more!
7.  Its photorealistic output will impress everyone!
8.  It renders up to 5 times faster than the competition!
9.  It includes over 145 high-quality, pre-built 3D "clipart" objects,
with more free each month at our web site!
10.  It is fully compatible with popular web authoring, digital video
editing and presentation software!

Again, here is where you can find your FREE trial version of Crystal 3D
IMPACT! Pro:
http://www.crystalgraphics.com/weblink1.3dimpact.html.

Thank you,
Your Friends at CrystalGraphics
408-496-6175

If you don't want to receive future e-mail messages about 
CrystalGraphics products, please reply to this message with 
"REMOVE" in the subject field.

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing to Proposed Standard
Reply-to: [email-masked]
Date: Mon, 12 Jan 1998 08:23:17 -0500
Sender: [email-masked]

The IESG has received a request from the Inter-Domain Routing Working
Group to consider Use of BGP-4 Multiprotocol Extensions for IPv6
Inter-Domain Routing <draft-ietf-idr-bgp4-ipv6-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 January 26, 1998.

Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-ipv6-00.txt

Date: Sun, 11 Jan 1998 05:05:15 -0500 (EST)
From: wwqq11 <[email-masked]>
To: <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

Authenticated sender is <[email-masked]>
Subject:  Year
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Sun, 11 Jan 1998 04:59:29 -0500

EMAIL MARKETING WORKS!!

Bull's Eye Gold is the PREMIER email address collection tool.
This program allows you to develop TARGETED lists of email
addresses.  Doctors, florists, MLM, biz opp,...you can collect
anything...you are only limited by your imagination!  You can
even collect email addresses for specific states, cities, and
even countries!  All you need is your web browser and this program.
Our software utilizes the latest in search technology called
"spidering". By simply feeding the spider program a starting
website it will collect for hours. The spider will go from website
to targeted website providing you with thousands upon thousands of
fresh TARGETED email addresses. When you are done collecting,  the
spider removes duplicates and saves the email list in a ready to
send format. No longer is it necessary to send millions of ads to
get a handful of responses...SEND LESS...EARN MORE!!!

A terrific aspect of the Bull's Eye software is that there is
no difficult set up involved and no special technical mumbo-jumbo
to learn. All you need to know is how to search for your targeted
market in one of the many search engines and let the spider do the
rest! Not familiar with the search engines? No problem, we provide
you with a list of all the top search engines. Just surf to the
location of a search engine on your browser then search for the
market you wish to reach...it's that easy!

For instance if you were looking for email addresses of Doctors
in New York all you would do is:

1) Do a search using your favorite search engine by typing in
the words doctor(s) and New York
2) Copy the URL (one or more)...that's the stuff after the
http://...  for instance it might look like
http://www.yahoo.com/?doctor(s)/?New+York
3) Press the START button

THAT's IT!!!  The Bull's Eye spider will go to all the websites
that are linked, automatically extracting the email addresses
you want.

The spider is passive too! That means you can let it run all
day or all night while you are working on important things or
just having fun on your computer. There is no need to keep a
constant watch on it, just feed it your target market and give
it praise when it delivers thousands of email addresses at
the end of the day!

Features of the Bull's Eye Software:

* Does TARGETED searches of websites collecting the email
  addresses you want!
* Collects Email addresses by City, State, even specific
  Countries
* Runs Automatically...simply enter the Starting information,
  press The Start Button, and it does the rest
* Filters out duplicates
* Keeps track of URLs already visited
* Can run 24 hours per day, 7 days per week
* Fast and Easy List Management
* Also has built in filtering options...you can put in words
  that it "Must" have while searching,...you can even put in
  criteria that it  "Must NOT Have"...giving you added flexibility
* Also imports email addresses from any kind of files (text
  files, binary files, database files)
* List editor handles Multiple files to work on many lists
  simultaneously
* Has a Black-Book feature... avoid sending emails to people
  who do not want to receive it
* Built-in Mail program...send email directly on the internet
  with just a click of your mouse
* Personalized Emails...if the email address has the user's
  name when it is collected,..you can send Personalized emails!!!
* Sort by Location, Server, User Name, Contact Name
* Advanced Operations:
· Email address lists export in many different formats
  (HTML, Comma delimited, text file)
· Advanced editing...Transfer, Copy,  Addition, Delete, Crop,
  Move to Top/Bottom
· Operations between lists...Union, Subtraction, Comparison
* Program is Passive,...meaning you can run other programs at
  the same time

CALL FOR MORE INFORMATION   213-980-7850
CALL FOR MORE INFORMATION   213-980-7850

ORDERING INFORMATION

Customer Name
Company Name
Address
City
State                       Zip
Phone                                       Fax
Email Address

______ BULL'S EYE SOFTWARE   $259.00
Includes Software, Instructions, Technical Support

______ Shipping & Handling  (2-3 Day Fedex)  $10.00
                           (Fedex Overnite) $20.00

______  TOTAL
                 (CA Residents add applicable sales tax)

*All orders are for Win 95 and Win NT

                *****CREDIT CARDS ACCEPTED*****
                   MASTERCARD   VISA   AMEX

   PLEASE CALL 213-980-7850 to process your order
                        9am-5pm Pacific Time
                Checks or Money Orders send to:
                      WorldTouch Network Inc.
5670 Wilshire Blvd.  Suite 2170 Los Angeles, CA 90036
Please note:  Allow 5 business days for all checks to
clear before order is shipped.

Date: Sun, 11 Jan 1998 03:57:48 -0500 (EST)
From: zz444q <[email-masked]>
To: <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

Authenticated sender is <[email-masked]>
Subject:  Monday
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

EMAIL MARKETING WORKS!!

Bull's Eye Gold is the PREMIER email address collection tool.
This program allows you to develop TARGETED lists of email
addresses.  Doctors, florists, MLM, biz opp,...you can collect
anything...you are only limited by your imagination!  You can
even collect email addresses for specific states, cities, and
even countries!  All you need is your web browser and this program.
Our software utilizes the latest in search technology called
"spidering". By simply feeding the spider program a starting
website it will collect for hours. The spider will go from website
to targeted website providing you with thousands upon thousands of
fresh TARGETED email addresses. When you are done collecting,  the
spider removes duplicates and saves the email list in a ready to
send format. No longer is it necessary to send millions of ads to
get a handful of responses...SEND LESS...EARN MORE!!!

A terrific aspect of the Bull's Eye software is that there is
no difficult set up involved and no special technical mumbo-jumbo
to learn. All you need to know is how to search for your targeted
market in one of the many search engines and let the spider do the
rest! Not familiar with the search engines? No problem, we provide
you with a list of all the top search engines. Just surf to the
location of a search engine on your browser then search for the
market you wish to reach...it's that easy!

For instance if you were looking for email addresses of Doctors
in New York all you would do is:

1) Do a search using your favorite search engine by typing in
the words doctor(s) and New York
2) Copy the URL (one or more)...that's the stuff after the
http://...  for instance it might look like
http://www.yahoo.com/?doctor(s)/?New+York
3) Press the START button

THAT's IT!!!  The Bull's Eye spider will go to all the websites
that are linked, automatically extracting the email addresses
you want.

The spider is passive too! That means you can let it run all
day or all night while you are working on important things or
just having fun on your computer. There is no need to keep a
constant watch on it, just feed it your target market and give
it praise when it delivers thousands of email addresses at
the end of the day!

Features of the Bull's Eye Software:

* Does TARGETED searches of websites collecting the email
  addresses you want!
* Collects Email addresses by City, State, even specific
  Countries
* Runs Automatically...simply enter the Starting information,
  press The Start Button, and it does the rest
* Filters out duplicates
* Keeps track of URLs already visited
* Can run 24 hours per day, 7 days per week
* Fast and Easy List Management
* Also has built in filtering options...you can put in words
  that it "Must" have while searching,...you can even put in
  criteria that it  "Must NOT Have"...giving you added flexibility
* Also imports email addresses from any kind of files (text
  files, binary files, database files)
* List editor handles Multiple files to work on many lists
  simultaneously
* Has a Black-Book feature... avoid sending emails to people
  who do not want to receive it
* Built-in Mail program...send email directly on the internet
  with just a click of your mouse
* Personalized Emails...if the email address has the user's
  name when it is collected,..you can send Personalized emails!!!
* Sort by Location, Server, User Name, Contact Name
* Advanced Operations:
· Email address lists export in many different formats
  (HTML, Comma delimited, text file)
· Advanced editing...Transfer, Copy,  Addition, Delete, Crop,
  Move to Top/Bottom
· Operations between lists...Union, Subtraction, Comparison
* Program is Passive,...meaning you can run other programs at
  the same time

CALL FOR MORE INFORMATION   213-980-7850
CALL FOR MORE INFORMATION   213-980-7850

ORDERING INFORMATION

Customer Name
Company Name
Address
City
State                       Zip
Phone                                       Fax
Email Address

______ BULL'S EYE SOFTWARE   $259.00
Includes Software, Instructions, Technical Support

______ Shipping & Handling  (2-3 Day Fedex)  $10.00
                           (Fedex Overnite) $20.00

______  TOTAL
                 (CA Residents add applicable sales tax)

*All orders are for Win 95 and Win NT

                *****CREDIT CARDS ACCEPTED*****
                   MASTERCARD   VISA   AMEX

   PLEASE CALL 213-980-7850 to process your order
                        9am-5pm Pacific Time
                Checks or Money Orders send to:
                      WorldTouch Network Inc.
5670 Wilshire Blvd.  Suite 2170 Los Angeles, CA 90036
Please note:  Allow 5 business days for all checks to
clear before order is shipped.

Date: Sun, 11 Jan 1998 03:01:06 -0600 (CST)
From: jhjh71 <[email-masked]>
To: <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

Authenticated sender is <[email-masked]>
Subject:  January
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

EMAIL MARKETING WORKS!!

Bull's Eye Gold is the PREMIER email address collection tool.
This program allows you to develop TARGETED lists of email
addresses.  Doctors, florists, MLM, biz opp,...you can collect
anything...you are only limited by your imagination!  You can
even collect email addresses for specific states, cities, and
even countries!  All you need is your web browser and this program.
Our software utilizes the latest in search technology called
"spidering". By simply feeding the spider program a starting
website it will collect for hours. The spider will go from website
to targeted website providing you with thousands upon thousands of
fresh TARGETED email addresses. When you are done collecting,  the
spider removes duplicates and saves the email list in a ready to
send format. No longer is it necessary to send millions of ads to
get a handful of responses...SEND LESS...EARN MORE!!!

A terrific aspect of the Bull's Eye software is that there is
no difficult set up involved and no special technical mumbo-jumbo
to learn. All you need to know is how to search for your targeted
market in one of the many search engines and let the spider do the
rest! Not familiar with the search engines? No problem, we provide
you with a list of all the top search engines. Just surf to the
location of a search engine on your browser then search for the
market you wish to reach...it's that easy!

For instance if you were looking for email addresses of Doctors
in New York all you would do is:

1) Do a search using your favorite search engine by typing in
the words doctor(s) and New York
2) Copy the URL (one or more)...that's the stuff after the
http://...  for instance it might look like
http://www.yahoo.com/?doctor(s)/?New+York
3) Press the START button

THAT's IT!!!  The Bull's Eye spider will go to all the websites
that are linked, automatically extracting the email addresses
you want.

The spider is passive too! That means you can let it run all
day or all night while you are working on important things or
just having fun on your computer. There is no need to keep a
constant watch on it, just feed it your target market and give
it praise when it delivers thousands of email addresses at
the end of the day!

Features of the Bull's Eye Software:

* Does TARGETED searches of websites collecting the email
  addresses you want!
* Collects Email addresses by City, State, even specific
  Countries
* Runs Automatically...simply enter the Starting information,
  press The Start Button, and it does the rest
* Filters out duplicates
* Keeps track of URLs already visited
* Can run 24 hours per day, 7 days per week
* Fast and Easy List Management
* Also has built in filtering options...you can put in words
  that it "Must" have while searching,...you can even put in
  criteria that it  "Must NOT Have"...giving you added flexibility
* Also imports email addresses from any kind of files (text
  files, binary files, database files)
* List editor handles Multiple files to work on many lists
  simultaneously
* Has a Black-Book feature... avoid sending emails to people
  who do not want to receive it
* Built-in Mail program...send email directly on the internet
  with just a click of your mouse
* Personalized Emails...if the email address has the user's
  name when it is collected,..you can send Personalized emails!!!
* Sort by Location, Server, User Name, Contact Name
* Advanced Operations:
· Email address lists export in many different formats
  (HTML, Comma delimited, text file)
· Advanced editing...Transfer, Copy,  Addition, Delete, Crop,
  Move to Top/Bottom
· Operations between lists...Union, Subtraction, Comparison
* Program is Passive,...meaning you can run other programs at
  the same time

CALL FOR MORE INFORMATION   213-980-7850
CALL FOR MORE INFORMATION   213-980-7850

ORDERING INFORMATION

Customer Name
Company Name
Address
City
State                       Zip
Phone                                       Fax
Email Address

______ BULL'S EYE SOFTWARE   $259.00
Includes Software, Instructions, Technical Support

______ Shipping & Handling  (2-3 Day Fedex)  $10.00
                           (Fedex Overnite) $20.00

______  TOTAL
                 (CA Residents add applicable sales tax)

*All orders are for Win 95 and Win NT

                *****CREDIT CARDS ACCEPTED*****
                   MASTERCARD   VISA   AMEX

   PLEASE CALL 213-980-7850 to process your order
                        9am-5pm Pacific Time
                Checks or Money Orders send to:
                      WorldTouch Network Inc.
5670 Wilshire Blvd.  Suite 2170 Los Angeles, CA 90036
Please note:  Allow 5 business days for all checks to
clear before order is shipped.

To: [email-masked]
cc: [email-masked]
Subject: Re: Route Flap Damping - changes since last call 
Date: Fri, 09 Jan 98 05:45:41 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Curtis,
 
> There is a revised I-D http://engr.ans.net/route-damp/ along with
> complete diffs against the latex source (to avoid having to reread the
> whole thing).
> 
> The changes were in response to comments and are:
> 
>   Numerous wording changes and small nits.  Spell checked.
> 
>   New subsection named "Per Route State" providing a clarification on
>   what can be considered a "route" for the purpose of damping.  This
>   contains a few words on the implications of including some of the
>   BGP attributes that are stated as optional for the purpose of route
>   damping.
> 
>   A few words of clarification intended to make it more clear that the
>   "reuse lists" are used both to identify the reachable routes that
>   are reusable after a waiting time and the unreachable routes that
>   can be completely disposed of after a waiting time.
> 
>   A number of paragraphs were added to the "Implementation Experience"
>   section to reflect the experiences and recommendations of the RIPE
>   routing-wg and the case provided by Alan Barrett on the IEPG mailing
>   list.
> 
>   The "Acknowledgements" section was updated, though I can't list
>   everyone who has provided implementation feedback in the last two
>   years without missing individuals from so I just listed the groups
>   (RIPE routing, IEPG, NANOG, IDR) where discussions occurred.
> 
> Because of the added paragraphs it might be worth repeating WG last
> call just in case there are comments about the additions before
> bothering the IESG.  I leave that decision to the WG chairs.

I would propose we'll have an "abbreviated" WG Last Call till
next Friday (Jan 16). In the absence of any objections to the
revised version of your document, on Jan 16 we'll ask the IESG
to advance the document to a Proposed Standard.

Yakov.

To: [email-masked]
cc: [email-masked]
Reply-To: [email-masked]
Subject: Route Flap Damping - changes since last call
Date: Thu, 08 Jan 1998 21:08:26 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

There were a few comments in the last call for the Route Flap Damping
draft, draft-ietf-idr-route-damp-00.txt.  I've made revisions and will
submit the revised draft (-01) to the rfc editor.

There is a revised I-D http://engr.ans.net/route-damp/ along with
complete diffs against the latex source (to avoid having to reread the
whole thing).

The changes were in response to comments and are:

  Numerous wording changes and small nits.  Spell checked.

  New subsection named "Per Route State" providing a clarification on
  what can be considered a "route" for the purpose of damping.  This
  contains a few words on the implications of including some of the
  BGP attributes that are stated as optional for the purpose of route
  damping.

  A few words of clarification intended to make it more clear that the
  "reuse lists" are used both to identify the reachable routes that
  are reusable after a waiting time and the unreachable routes that
  can be completely disposed of after a waiting time.

  A number of paragraphs were added to the "Implementation Experience"
  section to reflect the experiences and recommendations of the RIPE
  routing-wg and the case provided by Alan Barrett on the IEPG mailing
  list.

  The "Acknowledgements" section was updated, though I can't list
  everyone who has provided implementation feedback in the last two
  years without missing individuals from so I just listed the groups
  (RIPE routing, IEPG, NANOG, IDR) where discussions occurred.

Because of the added paragraphs it might be worth repeating WG last
call just in case there are comments about the additions before
bothering the IESG.  I leave that decision to the WG chairs.

Curtis

ps- the direct URLs are:

  http://engr.ans.net/route-damp	introductory text, diffs, pointers

  http://engr.ans.net/route-damp/route-damp.html
  http://engr.ans.net/route-damp/route-damp.txt
  http://engr.ans.net/route-damp/route-damp.ps

  ftp://engr.ans.net/pub/internet-drafts/draft-ietf-idr-route-damp-01.txt
  ftp://engr.ans.net/pub/internet-drafts/draft-ietf-idr-route-damp-01.ps

Date: Thu, 8 Jan 1998 14:08:33 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>Sandy, we know MD5 to be vulnerable and the scheme does not support multiple key
>s
>either
>which is prerequisite for meaningfull security.
>If you don't consider those security deficiencies then I don't think we can have
>a meaningfull
>discussion  here ...  There are more things but I think the draft points out mos
>t
>of those accurately
>itself.

Yes, Curtis pointed out that you were talking about the suspect assurance
of MD5, vs HMAC-MD5 or such.  I thought you were talking about fundamental
problems with the approach - like vulnerabilities through TCP that remain
even though the packet is crypto-hashed.  I'm relieved.

WIthout the ability to reference the specific key out of a set of multiple
keys, this technique would require that re-keying be accomplished while
the BGP sessions were down.  If you need to change keys, you must bring
the BGP peerings down, re-key, reestablish peering.  I don't know how long
peering sessions ususally last, but my uninformed opinion is that they
would not last long enough to outlast the key lifetimes for MD5 keys.
Right?

You are right that algorithm stength, key strength, implementation strength,
etc., etc., etc., (Ran Atkinson has a good list that he's put in several
of his security documents) all have to be considered when deciding how
much assurance you get.  I was worried because I thought you were talking
about deficiencies in the assurance provided by the protocol itself.

--Sandy

Date: Thu, 8 Jan 1998 11:02:15 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: WG Last Call
Sender: [email-masked]

|  Sandy, we know MD5 to be vulnerable 

!?!? I've heard rumors as such, but documentation please?  This has major
implications in many places.

|  and the scheme does not support multiple keys either
|  which is prerequisite for meaningfull security.

Given that this is extremely ad hoc and always pair-wise, I don't see this
as an issue.

Tony

Date: Thu, 08 Jan 1998 13:42:06 -0500
From: Antoni Przygienda <[email-masked]>
Organization: Bell Labs, Lucent Technologies
To: Sandy Murphy <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: WG Last Call
Sender: [email-masked]

Sandy Murphy wrote:

> >Message is OK, I don't see necessarily that something with known deficiencies
> >should go
> >into PS to increase its value
>
> "known deficiencies"??!!!   Could you please explain this further?  I don't
> recall deficiencies in this mechanism being mentioned yet.  If you know
> of some, please speak up.  As soon as possible.  Or point me to the right
> message.
>
> --Sandy

Sandy, we know MD5 to be vulnerable and the scheme does not support multiple keys
either
which is prerequisite for meaningfull security.
If you don't consider those security deficiencies then I don't think we can have
a meaningfull
discussion  here ...  There are more things but I think the draft points out most
of those accurately
itself.

To prevent wild flaming let me tell here again that I'm not against the scheme.
I'm not saying that it's not a fine thing to do as a solution and deployed
implementations
have their charme (actually a lot of charme). However,  I don't think that it
matters that much
whether it's BCP or PS but making it PS to increase its value somehow defeats my
logic.

                    thank you, Sandy

                    --- tny

To: Tony Li <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: WG Last Call 
Date: Thu, 08 Jan 1998 12:08:59 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Tony Li writes:
> 
> |  We're sending it to the IESG because it is a protocol spec and we
> |  think it should be implemented.  That's sort of the implied message to
> |  vendors in sending any protocol spec to the IESG.  If IPSEC seriously
> |  flounders maybe it will be around long enough to go from PS to DS.
> |  
> |  You've made your point clear that the IESG is not a message passing
> |  system.  Was that the limit of your point, or are you also arguing
> |  against sending the draft to IESG for consideration as PS?
> 
> Both points.  I see we will have to disagree.  The IESG is not even an
> implied message passing system.
> 
> I'll also point out that BCP makes _much_ more sense that PS.
> 
> Tony

I think we can all see reasons to got with BCP or PS and we talked
about this at the WG meeting in DC.  We ended up with PS though no one
felt extremely strongly about it either way.  If you feel strongly
enough that it should be BCP rather than PS please tell the WG chairs
you want them to override the decision made at the WG meeting that you
were at.  Either way is OK with me though I'd prefer to stick with
what we agreed to do.

Over and out,

Curtis

Date: Thu, 8 Jan 1998 09:19:19 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: WG Last Call
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

>Message is OK, I don't see necessarily that something with known deficiencies
>should go
>into PS to increase its value

"known deficiencies"??!!!   Could you please explain this further?  I don't
recall deficiencies in this mechanism being mentioned yet.  If you know
of some, please speak up.  As soon as possible.  Or point me to the right
message.

--Sandy

Date: Wed, 07 Jan 1998 20:58:16 -0500
From: Antoni Przygienda <[email-masked]>
Organization: Bell Labs, Lucent Technologies
To: [email-masked]
CC: Tony Li <[email-masked]>, [email-masked]
Subject: Re: WG Last Call
Sender: [email-masked]

Curtis Villamizar wrote:

> In message <[email-masked]>, Antoni Przygienda writes:
> > Tony Li wrote:
> >
> > > [email-masked] (Curtis Villamizar) writes:
> > >
> > > > IMO:  Making it PS sends the right message to router vendors.  YOU NEED
> > > > TO IMPLEMENT THIS!  Making it informational carries no weight.
> > >
> > > If you want to send a message, use Federal Express.
> > >
> > > You want to convince vendors?  Use your dollars.
> > >
> > > Anyone who still thinks that a PS has any weight with a vendor is stuck
> > > living in 1990.  An RFC, regardless of its 'standard' status, is a
> > > reference document.  Nothing more.  The IETF is a publishing house that
> > > also has a lot of irrelevant political and marketing dog and pony shows.
> >
> > on the same note ;-)
> >
> > I remember the IETF T-shirt saying "We despise kings, .... " and so on.
> > Making something
> > PS to "force" router vendors to do stuff smells like a benevolent
> > dictatorship ;-)
> >
> >                                 thank you
> >
> >                                 --- tony
>
> I said "sends the right message".  I didn't claim you could force
> anybody to do anything.
>

Curtis,

I always sense some force when people jam the caps lock in their mails ;-) but
technically yes, you didn't say it, I'll be forgiven ...

> Are you (both Tonys) 1) disagreeing that this is the right message, 2)
> disagreeing that we should send as strong a message as this feeble
> IETF WG can, 3) making some other point, or 4) adding to the noise?
>
> Yes I see the smiley and I'm not offended and you shouldn't be either.
> :-)
>

Message is OK, I don't see necessarily that something with known deficiencies
should go
into PS to increase its value, BCP would be probably just fine and generally at
this point
I don't think the discussion is worth having .... I'll be excused.

                    thank you

                    --- tony

Date: Wed, 7 Jan 1998 17:56:23 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: WG Last Call
Sender: [email-masked]

|  We're sending it to the IESG because it is a protocol spec and we
|  think it should be implemented.  That's sort of the implied message to
|  vendors in sending any protocol spec to the IESG.  If IPSEC seriously
|  flounders maybe it will be around long enough to go from PS to DS.
|  
|  You've made your point clear that the IESG is not a message passing
|  system.  Was that the limit of your point, or are you also arguing
|  against sending the draft to IESG for consideration as PS?

Both points.  I see we will have to disagree.  The IESG is not even an
implied message passing system.

I'll also point out that BCP makes _much_ more sense that PS.

Tony

To: Tony Li <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: WG Last Call 
Date: Wed, 07 Jan 1998 20:50:46 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Tony Li writes:
> 
> |  Are you (both Tonys) 1) disagreeing that this is the right message, 2)
> |  disagreeing that we should send as strong a message as this feeble
> |  IETF WG can, 3) making some other point, or 4) adding to the noise?
> 
> I'm trying to make the point that making the document PS is wholly
> orthogonal to sending a message.  Thus, if that's your reason for making it
> PS, it's misguided and you're wasting people's time (e.g., the IESG's for
> reviewing it) for no purpose.
> 
> Tony

Tony,

We're sending it to the IESG because it is a protocol spec and we
think it should be implemented.  That's sort of the implied message to
vendors in sending any protocol spec to the IESG.  If IPSEC seriously
flounders maybe it will be around long enough to go from PS to DS.

You've made your point clear that the IESG is not a message passing
system.  Was that the limit of your point, or are you also arguing
against sending the draft to IESG for consideration as PS?

Curtis

Date: Wed, 7 Jan 1998 16:31:20 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: WG Last Call
Sender: [email-masked]

|  Are you (both Tonys) 1) disagreeing that this is the right message, 2)
|  disagreeing that we should send as strong a message as this feeble
|  IETF WG can, 3) making some other point, or 4) adding to the noise?

I'm trying to make the point that making the document PS is wholly
orthogonal to sending a message.  Thus, if that's your reason for making it
PS, it's misguided and you're wasting people's time (e.g., the IESG's for
reviewing it) for no purpose.

Tony

To: Antoni Przygienda <[email-masked]>
cc: Tony Li <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: WG Last Call 
Date: Wed, 07 Jan 1998 19:27:52 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Antoni Przygienda writes:
> Tony Li wrote:
> 
> > [email-masked] (Curtis Villamizar) writes:
> >
> > > IMO:  Making it PS sends the right message to router vendors.  YOU NEED
> > > TO IMPLEMENT THIS!  Making it informational carries no weight.
> >
> > If you want to send a message, use Federal Express.
> >
> > You want to convince vendors?  Use your dollars.
> >
> > Anyone who still thinks that a PS has any weight with a vendor is stuck
> > living in 1990.  An RFC, regardless of its 'standard' status, is a
> > reference document.  Nothing more.  The IETF is a publishing house that
> > also has a lot of irrelevant political and marketing dog and pony shows.
> 
> on the same note ;-)
> 
> I remember the IETF T-shirt saying "We despise kings, .... " and so on.
> Making something
> PS to "force" router vendors to do stuff smells like a benevolent
> dictatorship ;-)
> 
>                                 thank you
> 
>                                 --- tony

I said "sends the right message".  I didn't claim you could force
anybody to do anything.

Are you (both Tonys) 1) disagreeing that this is the right message, 2)
disagreeing that we should send as strong a message as this feeble
IETF WG can, 3) making some other point, or 4) adding to the noise?

Yes I see the smiley and I'm not offended and you shouldn't be either.
:-)

Curtis

Date: Wed, 7 Jan 1998 20:19:00 -0200 (EDT)
From: Reinaldo Penno Filho <[email-masked]>
To: [email-masked]
Subject: Re: How is a "route" defined? 
Sender: [email-masked]

On Thu, 11 Dec 1997, Ken Rosenfeld wrote:

vc>In the context of route dampening, how is a "route" defined?
vc>
vc><draft-ietf-idr-route-damp-00> states (p. 13):
vc>  "A route here is considered to be a tuple containing at least
vc>   NLRI prefix, next hop, and AS path."
vc>

Hi, 

Sorry if this is a newbie question but I´m having a hard time
understanding the difference between a Route, NLRI and their relation
to UPDATE messages.

In the <draft-ietf-idr-bgp4-06.txt> is said:

-->   For purposes of this protocol a route is defined as a unit of
   information that pairs **a** destination with the attributes of a path
   that destination:   <--

-->An UPDATE message is used to advertise a *single* feasible route<--

Does "a destination" means one AS or NLRI<->path attribute information?

Cause if a destination is one NLRI seems to me that a UPDATE message
can advertise several routes..

Or..

Does this mean that a collection of NLRIs and their path attributes 
is a *single* route, even tough some NLRI<-> path attributes tuples
advertise different destinations (networks)? 

Something like this...

NLRI 1 --\
          \
NLRI 2 ---- Path Attributes
          /
NLRI 3 --/

(NLRI 1, Path At.)
(NLRI 2, Path At.)
(NLRI 3, Path At.)

A many to one relationship. 

So another update message to the same AS with the same NLRI but other path
attribute is another route? 

Sorry for the long and possible intricate message...

Best Regards,

Reinaldo
      
----------------------------------------------------------------------------
Brazilian Reserch Network
http://www.rnp.br
[email-masked]
----------------------------------------------------------------------------

Date: Wed, 7 Jan 1998 14:53:01 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>> > IMO:  Making it PS sends the right message to router vendors.  YOU NEED
>> > TO IMPLEMENT THIS!  Making it informational carries no weight.
>...
>Making something
>PS to "force" router vendors to do stuff smells like a benevolent
>dictatorship ;-)

I don't hear any hint of force in "sends the right message" and "YOU NEED
TO IMPLEMENT THIS".  Sounds more like good advice or strong suggestion
than force.

--Sandy

Date: Wed, 07 Jan 1998 13:50:32 -0500
From: Antoni Przygienda <[email-masked]>
Organization: Bell Labs, Lucent Technologies
To: Tony Li <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: WG Last Call
Sender: [email-masked]

Tony Li wrote:

> [email-masked] (Curtis Villamizar) writes:
>
> > IMO:  Making it PS sends the right message to router vendors.  YOU NEED
> > TO IMPLEMENT THIS!  Making it informational carries no weight.
>
> If you want to send a message, use Federal Express.
>
> You want to convince vendors?  Use your dollars.
>
> Anyone who still thinks that a PS has any weight with a vendor is stuck
> living in 1990.  An RFC, regardless of its 'standard' status, is a
> reference document.  Nothing more.  The IETF is a publishing house that
> also has a lot of irrelevant political and marketing dog and pony shows.

on the same note ;-)

I remember the IETF T-shirt saying "We despise kings, .... " and so on.
Making something
PS to "force" router vendors to do stuff smells like a benevolent
dictatorship ;-)

                                thank you

                                --- tony

Date: Wed, 7 Jan 1998 11:14:18 -0200 (EDT)
From: Reinaldo Penno Filho <[email-masked]>
To: [email-masked]
cc: Alexandre <[email-masked]>
Subject: Re: How is a "route" defined?
Sender: [email-masked]

On Thu, 11 Dec 1997, Ken Rosenfeld wrote:

vc>In the context of route dampening, how is a "route" defined?
vc>
vc><draft-ietf-idr-route-damp-00> states (p. 13):
vc>  "A route here is considered to be a tuple containing at least
vc>   NLRI prefix, next hop, and AS path."
vc>

Hi, 

Sorry if this is a newbie question but I´m having a hard time
understanding the difference between a Route, NLRI and their relation
to UPDATE messages.

In the <draft-ietf-idr-bgp4-06.txt> is said:

-->   For purposes of this protocol a route is defined as a unit of
   information that pairs **a** destination with the attributes of a path
   that destination:   <--

-->An UPDATE message is used to advertise a *single* feasible route<--

Does "a destination" means one AS or NLRI<->path attribute information?

Cause if a destination is one NLRI seems to me that a UPDATE message
can advertise several routes..

Or..

Does this mean that a collection of NLRIs and their path attributes 
is a *single* route, even tough some NLRI<-> path attributes tuples
advertise different destinations (networks)? 

Something like this...

NLRI 1 --\
          \
NLRI 2 ---- Path Attributes
          /
NLRI 3 --/

(NLRI 1, Path At.)
(NLRI 2, Path At.)
(NLRI 3, Path At.)

A many to one relationship. 

So another update message to the same AS with the same NLRI but other path
attribute is another route? 

Sorry for the long and possible intricate message...

Best Regards,

Reinaldo
      
----------------------------------------------------------------------------
Brazilian Reserch Network
http://www.rnp.br
[email-masked]
----------------------------------------------------------------------------

To: [email-masked]
cc: [email-masked]
Subject: Re: WG Last Call
From: Tony Li <[email-masked]>
Date: 07 Jan 1998 02:23:13 -0800
Lines: 16
Sender: [email-masked]

[email-masked] (Curtis Villamizar) writes:

> IMO:  Making it PS sends the right message to router vendors.  YOU NEED
> TO IMPLEMENT THIS!  Making it informational carries no weight.

If you want to send a message, use Federal Express.

You want to convince vendors?  Use your dollars.

Anyone who still thinks that a PS has any weight with a vendor is stuck
living in 1990.  An RFC, regardless of its 'standard' status, is a
reference document.  Nothing more.  The IETF is a publishing house that
also has a lot of irrelevant political and marketing dog and pony shows. 

Cynically yours,
Tony

To: Joel Halpern <[email-masked]>
cc: Yakov Rekhter <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: WG Last Call 
Date: Tue, 06 Jan 1998 12:08:02 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <Pine.GSO.3.96.971223113208.2278K-100000@lobster>, Joel Halpern writ
es:
> I have a question for the working group about this advancement.
> First, let me state that I understand that what is described here is in
> use and works.
> 
> On the other hand, judging from other factors, the desired direction would
> be to support IPsec, when that is deployed (deployable?  take your pick).
> 
> Clearly, document this (MD5 TCP Shim) is a good thing, and we should have
> it.
> The question I see is whether proposed standard is the correct status for
> this document.  Given that it works, "Experimental" is wrong since that
> would imply that it might not work.
> However, Informational would seem a better general category.  One might
> object that in fact we want a stronger imprimature than informational.  
> Would BCP be suitable?  Would an Informational document with a BCP
> applicability statement be better?
> Or can someone make a good case for proposed status?  If we accept that
> IPsec is the long term way to go, then we do not expect to advance this up
> the standards track.  Making a PS with the hope of making it historic
> seems odd to me.

Joel,

IMO:  Making it PS sends the right message to router vendors.  YOU NEED
TO IMPLEMENT THIS!  Making it informational carries no weight.

It was agreed at the WG meeting that PS to historic did make sense due
to the importance of doing something immediately to protect against
attacks such as TCP RST and then later doing IPSEC when IPSEC is
widely deployed and going to historic when IPSEC is ubiquitous.

Curtis

To: [email-masked]
cc: [email-masked]
Subject: draft-ietf-idr-bgp4-ipv6-00.txt
Date: Mon, 05 Jan 98 07:49:54 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Joel,

The IDR WG would like to ask the IESG to advance
draft-ietf-idr-bgp4-ipv6-00.txt to a Proposed Standard.

Yakov.