Re: Privacy, Integrity, Security mailing-list invitation

[Paul Ferguson]

I suppose the inevitable question would be: Is this the appropriate
venue for discussions surrounding the efforts to create a "Do Not
Track" (mumble)?

- ferg

On Thu, Mar 17, 2011 at 1:06 AM, Hannes Tschofenig
 wrote:

> Hi Dean,
>
> since you asked:
>
>> 1) What is different about this exercise from the ongoing privacy discussion 
>> on priv...@iab.org/ietf-priv...@ietf.org?
>
>
> A) priv...@iab.org
>
> The priv...@iab.org was a mailing list created for the IAB privacy workshop:
> http://www.iab.org/about/workshops/privacy/
>
> It was used by the workshop organizers only.  It will be deleted soon.
>
> B) ietf-priv...@ietf.org
>
> This mailing list has been set up to discuss issues related to privacy that 
> cut across multiple groups and areas.
>
> The initial goal of this discussion is to investigate privacy and related 
> identity management terminology. A secondary goal is to explore the 
> opportunity to develop "Privacy Consideration" guidelines similar to the 
> "Guidelines for Writing RFC Text on Security Considerations" [RFC3552] used 
> in the security area.
>
> To subscribe go to: https://www.ietf.org/mailman/listinfo/ietf-privacy
>
> C) privacy...@ietf.org
>
> There is a privacy directorate created as a result of last year's privacy 
> workshop.
> Membership (like the security area directorate): per-invitation only.
>
> Ciao
> Hannes
>
> PS: It would be nice to get review comments on the privacy terminology, the 
> privacy considerations, and policy considerations document:
> http://tools.ietf.org/html/draft-hansen-privacy-terminology-02
> http://tools.ietf.org/html/draft-morris-privacy-considerations-02
> http://tools.ietf.org/html/draft-morris-policy-cons-00
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawgster(at)gmail.com
 ferg's tech blog: http://fergdawg.blogspot.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Is this true?

[Paul Ferguson]

On Sun, Aug 29, 2010 at 12:22 AM, Fernando Gont  wrote:

>
> Agreed. I just meant that even without v6 NATs, it shouldn't come as a
> surprise if end-to-end connectivity is *not* restored by IPv6.
>

It is refreshing to hear someone actually say that out loud.

Thank you.

- ferg


-- 
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawgster(at)gmail.com
 ferg's tech blog: http://fergdawg.blogspot.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: T-shirts?

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Mar 29, 2010 at 11:55 PM, Fred Baker  wrote:

> personally, I think that should be in the weave, not the print...
>
> On Mar 27, 2010, at 8:21 AM, Christian Huitema wrote:
>
>> Can we make sure that the shirts are ASCII only?
>
> http://www.ipinc.net/IPv4.GIF
>

Hmmm... movie alert:

http://www.imdb.com/title/tt0493464/

List of assassination targets coded in a weave.. from a mystical loom.

Yes, I know... :-)

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.5.3 (Build 5003)

wj8DBQFLsaLTq1pz9mNUZTMRApJLAKCT71P8F9CdhTMUqO3P7C46rPa/DgCg/i5O
fOveXtEs3+Lcffm9J9XPPAQ=
=KqV+
-END PGP SIGNATURE-----



-- 
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawgster(at)gmail.com
 ferg's tech blog: http://fergdawg.blogspot.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: NATs *ARE* evil!

[Paul Ferguson]

I find it amazing (well, probably not so amazing)
that we are re-hashing this every few years.

It looks like NAT's are a fact of life, and we
just need to figure out how to deal with them.

- paul

At 07:59 PM 12/15/2000 -0500, Scott Bradner wrote:

>I will admit to some level of confusion
>the subject line of this thread is "NATs *ARE* evil!" yet most of the
>discussion is about the use of private addresses - something that 
>a whole lot of firewalls also do - howcum the subject line is
>not "NATs & Firewalls are evil!" or "use of private addresses is evil!"?
>
>this focus on NATs seems to be an incomplete statement of the problem

Re: RFCs in print

[Paul Ferguson]

At 06:29 PM 06/09/2000 -0700, Jeffrey Mogul wrote:

>Other people have raised the issue of equity.  I've always
>believed that RFCs should be freely copyable, with no royalty or
>permission requirements,

[...]

Ditto.

As an author, I agree.

And as far as I'm concerned, RFC's are already "published".

- paul

Re: Average Ethernet packet length

[Paul Ferguson]

Also some good stats at www.caida.org

- paul

At 09:08 PM 05/25/2000 -0400, Steven M. Bellovin wrote:

> >> A recent thread suggested something interesting - an average Ethernet/IP
> >> packet length of 500 bytes.  Has there been any work done in the area of
> >> finding average packet lengths, bandwidth usage, etc. of typical (read:
> >> unknown) networks?  Are there any "rules of thumb" values that are
> >> typically used?
>
>There are no good, current studies on LAN behavior that I've seen.  
>There have been a number of papers on WAN behavior.  The usual result 
>of those is that ~40-50% of packets are about 40-44 bytes, but most of 
>the bytes are carried by packets of ~500-576 or 1500 bytes.

Re: draft-ietf-nat-protocol-complications-02.txt

[Paul Ferguson]

At 08:27 PM 04/24/2000 -0400, Andrew Partan wrote:

>Or seperate the end system identifer from the routing goop.  This
>solves lots of problems (while introducing others).

Deja Vu.

- paul

RE: Re[2]: Re: Critically compare the congestion control on TCP/

[Paul Ferguson]

At 11:16 AM 03/09/2000 -0600, Schipper, Dell wrote:

>I recall that Larry Roberts a few years ago gave presentations (at
>NetWorld+InterOp ?) that compared the congestion avoidance algorithms of
>ATM-ABR service to TCP/IP.  I know he has started a new company since
>then and I do not have any contact information.

One of my favorites along those lines was:

"End-to-End Traffic Management Issues in IP/ATM Internetworks,"
draft-jagan-e2e-traf-mgmt-00.txt, S. Jagannath and N. Yin,
August 1997.

- paul

[snip]

Abstract

This document addresses the end-to-end traffic management issues in
IP/ATM internetworks. In the internetwork environment, the ATM
control mechanisms (e.g., Available Bit Rate (ABR) and UBR with Early
Packet Discard (EPD)) are applicable to the ATM subnetwork, while the
TCP flow control extends from end to end. We investigated the end to
end performance in terms of TCP throughput and file transfer delay in
cases using ABR and UBR in the ATM subnetwork. In this document, we
also discuss the issue of trade-off between the buffer requirements
at the ATM edge device (e.g., Ethernet-ATM switch, ATM router
interface) versus ATM switches inside the ATM network.

Our simulation results show that in certain scenarios (e.g., with
limited edge device buffer memory) UBR with EPD may perform
comparably to ABR or even outperform ABR. We show that it is not
sufficient to have a lossless ATM subnetwork from the end-to-end
performance point of view. The results illustrate the necessity for
an edge device congestion handling mechanism that can couple the ABR
and TCP feedback control loops.  We present an algorithm that makes
use of the ABR feedback information and edge device congestion state
to make packet dropping decisions at the edge of the ATM network.
Using the algorithm at the edge device, the end-to-end performance in
throughput and delay are improved while using ABR as the ATM
subnetwork technology and with small buffers in the edge device.

[snip]

DoS (Denial of Service) Attack resource page

[Paul Ferguson]

Folks,

Dan Senie and I got tired of keeping separate browser
bookmarks on a myriad of DoS Attack technical info, and
so we decided to slap together a web page which contains
some "good technical resources" on these DoS attacks:

  http://www.denialinfo.com/

Of course, it is pretty raw right now, but we'll make it
easier on the eyes over time, as well as add more content.
In fact, I think the page counter on the main page is broken
right now, but works on the mirror. Minor problems (it's the
content that counts, right?).

In any event, this is where you come in -- we would like to
solicit the community at-large to send along pertinent pointers
to any additional resources which we may have overlooked, or
that we just didn't know about in the first place.

Contact info is available on the web page, and so is a
URL for a mirror.

Thanks,

- paul and dan

ps. Thanks much to Kevin Siers, political cartoonist at the
Charlotte Observer, for letting use his awesome cartoon. ;-)

Re: Internet SYN Flooding, spoofing attacks

[Paul Ferguson]

At 11:15 AM 02/15/2000 +, Lloyd Wood wrote:

>A lot of surveillance can be based on 'if A is talking to B, then A
>must be as guilty as B', and message content is irrelevant. This
>helps counters that.

Well, get over it. ;-)

(Smiley included for the humor impaired.)

- paul

Re: Internet SYN Flooding, spoofing attacks

[Paul Ferguson]

At 03:41 PM 02/14/2000 -0800, Charles E. Perkins wrote:

>Mobile IP would like to send out packets with the mobile node's
>home address, while it is attached to a network in a foreign
>domain.  The home address is likely to look "incorrect" from
>the standpoint of such a filter.

If I'm not mistaken (although my coauthor has tracked the mobile
ip cruft more than have I), there is some notion of a tunneling
mechanism from the first-hop mobile ip gateway, such that the
bogon source is really never seen in that fashion (as a bogon).

Again, I admit complete ignorance of mobile ip cruft.

>Plus I don't think the gain is worth the pain.  I'd rather see
>a technology that actually solves the problem instead of swatting
>at gnats with a sledge hammer.

Well, right now, you get swatted. Figure out a better way, and
you'll stop getting swatted.

- paul

Re: Internet SYN Flooding, spoofing attacks

[Paul Ferguson]

At 11:33 PM 02/11/2000 -0500, [EMAIL PROTECTED] wrote:

>What are the chances of setting up "The Next Release" of IOS
>so that for simple configs (for example, a customer backbone and
>one upstream link to a provider) the knob would automagically default
>to Doing The Right Thing?  I of course am writing as a non-expert on
>the innnards of IOS, and I'm expecting flame-fests regarding "simple
>config" and "Right Thing".
>
>No, it's not a total fix.  It won't fix everything.  It may not
>even be possible.  But it certainly would be nice. ;)

Something like "ip default clueless"? Just kidding. ;-)

Well, overwhelming support for any suggested default mod is
always considered. Really.

Overwhelming is the operative word here.

We (as do many other vendors, I would suggest) operate
under the "Principle of Least Astonishment": How many people
would we screw if we changed the defaults of a particular
command?

If overwhelming community support were to set the tone for a default
change, we would certainly not take it lightly. :-)

- paul

Re: Internet SYN Flooding, spoofing attacks

[Paul Ferguson]

At 09:14 PM 02/11/2000 -0500, Vijay Gill wrote:

>This only works on single homed customers. Due to asymmetric routing, the
>customer can source _valid_ ip addresses from an ip source address that is
>not routed over that interface.  I too would prefer some sort of magic
>unicast RPF, but the best compromise is the built-in access filter.  The
>solution must be general enough to work for multihomed, defaulting out
>customers with blocks from n providers,

No, that is a common misconception, or rather, an overstatement of
a pretty easily described situation. It only breaks things in transit
situations, and only in transit situations where you might not have
the same forwarding path back to the source as you would via the same
interface a packet came in on.

This is a small percentage, I would thing, since the percentage of
ISP's offering transit pales in comparison to all other "access"
ISP's that do not. And in cases where ISP's _do_ offer transit, or
have transit agreements, will they really do this on their transit
interfaces? I think not.

- paul

Re: Internet SYN Flooding, spoofing attacks

[Paul Ferguson]

Vijay,

We (at least cisco, anyways) already have a knob for this:

  [no] ip verify unicast reverse-path

We call it Unicast RPF.

See also:

Craig Huegen's very useful web page on minimizing the effects
of DoS attacks:
http://users.quadrunner.com/chuegen/smurf.cgi

Cisco: Distributed Denial of Service (DDoS) News Flash,
February 9, 2000
http://www.cisco.com/warp/public/707/newsflash.html

Dave Dittrich's (University of Washington) very good
analysis of the recent DDoS attack tools.
http://www.washington.edu/People/dad/

NIPC (National Infrstructure Protection Center),
TRINOO/Tribal Flood Net/tfn2k stuff:
http://www.fbi.gov/nipc/trinoo.htm

"Handling A Distributed Denial of Service Trojan
Infection: Step-by-Step."
http://www.sans.org/y2k/DDoS.htm

CERT (Computer Emergency Response Team at CMU)
http://www.cert.org/

Cisco: Internet Security Advisories
http://www.cisco.com/warp/public/707/advisory.html

Characterizing and Tracing Packet Floods Using
Cisco Routers
http://www.cisco.com/warp/public/707/22.html

Cisco Product Security Incident Response (PSIRT)
http://www.cisco.com/warp/public/707/sec_incident_response.shtml

"Essential IOS" - Features Every ISP Should Consider
http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip

Know your enemy: Script Kiddies
http://www.enteract.com/~lspitz/enemy.html

Cisco Flow Logs and Intrusion Detection at the Ohio
State University
http://www.usenix.org/publications/login/1999-9/osu.html


If anyone else has useful links (it doesn't matter who
is the vendor, whatever), please let me know.

- paul

At 09:01 PM 02/11/2000 -0500, Vijay Gill wrote:

>CC'd to NANOG, maybe we can move this there.
>
>On Fri, 11 Feb 2000, Paul Ferguson wrote:
>
> > It would allow the attacks to be traced back to the zombies (in
> > the case of these DDoS attacks), and the perpetrators to be traced
> > back and identified.
>
>To make that easier, what is needed is something associated with a
>downstream interface that is a part of the configuration itself, not a
>separate access-list.  This makes it much easier to track on a large box
>with many hundreds of customer links and so forth.
>
>Something like so:
>
>interface XXXm/n/p.q
>description whatever customer
>encaps ...
>ip address x y
>ip allow-source blocks-that-are-valid
>ip allow-source ...more-blocks-
>
>so on and so forth.
>
>/vijay

[fwd] Lawyers Forsee Denial Of Service Suits

[Paul Ferguson]

It has begun. Sigh.

FYI,

- paul

http://www.techweb.com/wire/story/TWB2211S0014

Re: Internet SYN Flooding, spoofing attacks

[Paul Ferguson]

Steve,

At 07:01 PM 02/11/2000 -0500, Stephen Kent wrote:

>  From a security perspective, it is never desirable to rely on a
>mechanism that assumes that everyone else does "the right thing."

I agree. Every potential target network is not only responsible
for their own security, but in my opinion, they should be
conscientiously motivated to do the Right Things for the Internet
community at-large.

Of course, it doesn't always work out that way, sadly, and I'm not
delusional that it does.

>When one suggests that a first tier ISP would not need to filter
>traffic from down stream providers, because IF they do the filtering,
>then the problem will not arise via those links, one is suggesting
>precisely this sort of model.

You're approaching this from the wrong perspective, in my opinion.

There is no assumption implied that RFC2267 filtering is needed --
it is required. What good is it if one or two or 300 people do
it, and another 157,000 do not?

Well, there is a little good, but the more people that do it, the
better off we all are.

The bottom line here is that RFC2267-style filtering (or unicast
RPF checks, or what have you) stops spoofed source address packets
from being transmitted into the Internet from places they have no
business being originated from to begin with.

In even the worst case, those conscientious network admins that
_do_ do it can say without remorse that they are doing their part,
and can at least be assured that DoS attacks using spoofed source
addresses are not being originated from their customer base.

And this is a Bad Thing?

>Edge filtering would often be helpful, but it is not a panacea, as
>pointed out by others in regard to the current set of attacks, nor is
>the performance impact trivial with most current routers.

It is negligible at the edge in most cases, but you really need to
define "edge" a little better. In some cases, it is very low speed
links, in others it is an OC-12.

>Because
>most routers are optimized for transit traffic forwarding, the
>ability to filter on the interface cards is limited, as I'm sure you
>know.

No, I don't know that at all. _Backbone_routers_ are optimized for
packet forwarding -- I do know that.

>  Also, several of the distributed DoS attacks we are seeing do
>not use fake source addresses from other sites, so simple filtering
>of the sort proposed in 2267 would not be effective in these cases.

Again, you're missing the point.

If attackers are limited to launching DoS attacks using traceable
addresses, then not only can their zombies be traced & found, but
so can their controller (the perpetrator himself). Of this, make no
mistake.

>Finally, I am aware of new routers for which this sort of filtering
>would be child's play, but they are not yet deployed.  One ought not
>suggest that edge filtering is not being applied simply because of
>laziness on the part of ISPs.

Steve, you said that -- I didn't. I think ISP's will do what their
customers pay them to do.

- paul

Re: Internet SYN Flooding, spoofing attacks

[Paul Ferguson]

Steve,

That's simply propagating FUD, and I think that by
making such sweeping assumptions, you are doing the
Internet community a disservice.

Is RFC2267-style filtering a perfect solution for
every situation? No. Sure there are some scenarios
where it foo bars transit traffic, but in the larger
scheme of things, most dual-homed networks are not
providing transit.

Does it impact router performance? Perhaps. It really
depends on various arbitrary issues.

 From an architectural perspective, it is very important
_where_ you filter to be effective, not cause transit
problems, and not make smoke roll out of the back of
the equipment.

Will it stop bogon source packets from being injected into
the Internet, so that anyone foolish enough top launch a
denial of service attack can be traced back, identified, and
prosecuted? Absolutely.

- paul


At 04:59 PM 02/11/2000 -0500, Stephen Kent wrote:

>Paul & Bernie,
>
>A more technically focused answer is that most routers are not
>designed to perform the filtering without adversely impacting
>throughput, and because dual homing and the mesh nature of Internet
>connectivity makes it hard to apply appropriate filters for all
>subscribers (remembering that some subscribers are really down stream
>service providers ...)
>
>Steve
>

Re: Internet SYN Flooding, spoofing attacks

[Paul Ferguson]

At 03:45 PM 02/11/2000 -0500, John Stracke wrote:

> > Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs
> > required to put filtering on their networks that PREVENTS packets with
> > invalid source addresses ever entering their infrastructure?
>
>That wouldn't help with the current version of the problem.  An attacker
>sends out a virus or worm or something; when it's running on 10^5
>machines, the attacker turns them loose on the target.  Each of the source
>addresses is valid; each of the packets sent is innocuous in and of
>itself.

Yes, it would certainly help.

It would allow the attacks to be traced back to the zombies (in
the case of these DDoS attacks), and the perpetrators to be traced
back and identified.

- paul

Re: Internet SYN Flooding, spoofing attacks

[Paul Ferguson]

At 03:33 PM 02/11/2000 -0500, [EMAIL PROTECTED] wrote:

>Given that RFC2267 is over 2 years old now, what *do* you suggest the network
>community at large do to motivate the sites that still haven't implemented it?

Do you think that if RFC2267 was advanced as a BCP that
it would carry more weight, and therefore more ISP's would
implement RFC2267-style filtering? Coupled with the latest
denial of service attacks?

- paul

Re: Internet SYN Flooding, spoofing attacks

[Paul Ferguson]

At 11:57 AM 02/11/2000 -0800, Randy Bush wrote:

> > Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs
> > required to put filtering on their networks that PREVENTS packets with
> > invalid source addresses ever entering their infrastructure?
>
>maybe you want to be reading the nanog mailing list, [EMAIL PROTECTED], where
>the problems with and tactics for this and other approaches are discussed.

Let's point folks to:

  http://www.nanog.org/mailinglist.html

instead.

The last thing I want to see on the NANOG list is a bunch of
"subscribe me" messages.

- paul

Re: Internet SYN Flooding, spoofing attacks

[Paul Ferguson]

At 02:40 PM 02/11/2000 -0500, Bernie Volz wrote:

>Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs
>required to put filtering on their networks that PREVENTS packets with
>invalid source addresses ever entering their infrastructure?

Because there is no "Internet Police", that's why.


>If every
>site connected to the Internet did this, spoofing would be much more
>difficult because you couldn't do it. Sure, you could spoof an address
>from YOUR network, but that's all. And guess what, it would be much
>easier to track and thus to shut down the intrusions should they occur.

Yes, this practice is documented in RFC2267.


>Thus ever edge router should have filter lists that prevent it
>forwarding traffic out to the Internet (ISPs network) any packet that
>does not have a source address that is valid from that site.
>
>I would hope that lots of ISPs already do this. But, perhaps not.

I would hope so, too, but apparently many do not.

Thus, the problem at hand.

- paul


>- Bernie Volz
>   Process Software

Re: Mailing list for forming WG?

[Paul Ferguson]

At 11:19 PM 02/01/2000 +, Lloyd Wood wrote:

>Then they've not been paying attention lately. A couple of services
>that spring to mind for setting up mailing lists are:
>
>http://www.onelist.com/
>http://www.egroups.com/
>
>The effort and level of knowledge required to set up a mailing list is
>pretty minimal these days.

Acually, anyone who wishes to start a mailing list, whether related
to the IETF or not, can do so -- just obtain a copy of majordomo (or
listserv or whatever) and Viola!

That's how mailing lists used to be done for working groups in
the IETF anyways -- someone just volunteered to set one up.

- paul

RE: IP network address assignments/allocations information?

[Paul Ferguson]

Tony,

I wouldn't be so quick to characterize NAT as a "dead-end" technology.

Personally, I think NAT is just fine, but I'm a self-proclaimed cynic
and also consider myself somewhat of a pragmatist. In any event, it
works for me, but I could certainly be in the minority.

I think most of the hoopla surrounding NAT's revolve around engineering
purism. And I agree that statements that assert that NAT's provide some
sort of "security through obscurity" are complete red herrings.

Having said that, I ask you: What do you foresee as a realistic IPv6
transition plan? Dual stacks? I don't see it happening, to tell you
the truth. (Maybe this 6-in-4 stuff will actually help here.)

The truth is that NAT's allow organizations to deploy machines in
networks which otherwise would not have enough address space. To
say that NAT's are unequivocally evil is unfair, methinks.

- paul

At 01:37 PM 11/30/1999 -0800, Tony Hain (Exchange) wrote:

>Yes there are problems with protocols that carry addresses, but ignoring 
>encrypted traffic that really amounts to acquiring and synchronizing 
>deployments of ALGs. In the early stages this doesn't sound hard, but will 
>vendors be willing to add new ALGs to 3 year old NAT hardware? Will they 
>create an update process that is easy enough for the average user? Will 
>the average user be able to figure out which NAT needs updating, and what 
>version it needs? Add the fact that people want to encrypt their traffic 
>for privacy, and one wonders why so much effort is spent on this dead-end 
>technology.

RE: IP network address assignments/allocations information?

[Paul Ferguson]

Hi Tony,

Well, the statement below is not true -- I sit behind a NAT/PAT
device and Real PLayer works just fine for me. I've only found a
couple of applications that will not work for me (e.g. ICQ, NTP,
SNMP), but then again, I'm not a gamer so I can't speak to the
broader range of applications that it _does_ break.

In any event, I've always personally been of the opinion that
if applications don't work in the face of NAT, then the
applications themselves are functionally deficient and should be
fixed.  :-)

Cheers,

- paul

At 10:44 AM 11/29/1999 -0800, Tony Hain (Exchange) wrote:

>1) Yes ... We have been forced into a world of NAT where simple 
>applications such as Real Player won't work without real-time manual 
>intervention at the NAT.

Is it just me, or....

[Paul Ferguson]

Is it just me, or have others experienced similar furstrtations
in reachability issues from the terminal room? I can't even get
to ietf.org to look at posted drafts Oops. Just got there.

Very spotty...

- paul

Re: IEPG Meeting

[Paul Ferguson]

Phil,

I would like to address the IEPG (pronounced "Eye E Pee
Gee -- the "g" is hard) on the topic of CALEA.

Can you carve 15 minutes for me?

- paul



At 12:13 PM 10/29/1999 -0700, Philip J. Nesser II wrote:


>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>There will be a meeting of the IEPG on the Sunday (November 7)
>preceeding the IETF in Washington.  The meeting will start at 10:00am
>and run into the afternoon depending on the number of agenda topics.
>Room to be determined.
>
>If you are unfamiliar with the IEPG please see the web site at
>www.iepg.org.
>
>This is a call for further agenda topics. Topics tend to include
>operational issues regarding the net, as well as studies on
>deployments of new technology and emerging IETF protocols.  If you
>have any interesting work on these types of issues please volunteer to
>spend a few minutes presenting it to your collegues.  This can be a
>great forum for sharing issues that might normally be buried in a
>specific Working Group to a wider audience who might have insights
>into problems or possible interactions with other work.  The material
>doesn't have to be perfect or fancy.  The group is very informal and
>supportive.
>
>For the usual suspects:
>
>I have volunteers from APNIC for a report, but still have no
>volunteers from RIPE, ARIN and INTERNIC.
>
>- --->  Phil
>
>-BEGIN PGP SIGNATURE-
>Version: PGPfreeware 5.5.3 for non-commercial use 
>
>iQA/AwUBOBnx3DW2hWRjwTVBEQJ50QCfduuPpIy2W0wL1GVptRA+JM5j6tgAoK0f
>8FPyc6sw84lSEjYCxMERE4ye
>=kEMp
>-END PGP SIGNATURE-
>