On Jul 15, 2011, at 10:24 AM, Jimmy Hess wrote:
In most cases if you have a DoS attack coming from the same Layer-2 network
that a router is attached to,
it would mean there was already a serious security incident that occured to
give the attacker that special point to attack fr
This
We all make mistakes in not questioning our own positions, from time to
time. You, Jeff, seem to be making that very same mistake.
Please keep these points in mind:
* Rome wasn't built in a day. The current system didn't come
ready-made pre-built with all the bells and whistles you are
On Mon, Jul 11, 2011 at 8:17 PM, Karl Auer ka...@biplane.com.au wrote:
RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats
In this attack, the attacking node begins fabricating addresses with
the subnet prefix and continuously sending packets to them. The last
hop router is
On Sun, Jul 17, 2011 at 11:42 AM, William Herrin b...@herrin.us wrote:
My off-the-cuff naive solution to this problem would be to discard the
oldest incomplete solicitation to fit the new one and, upon receiving
an apparently unsolicited response to a discarded solicitation,
restart the
On Sun, Jul 17, 2011 at 11:07 AM, Eliot Lear l...@cisco.com wrote:
We all make mistakes in not questioning our own positions, from time to
time. You, Jeff, seem to be making that very same mistake.
Rome wasn't built in a day. The current system didn't come ready-made
pre-built with all the
On Jul 17, 2011, at 10:35 AM, Jeff Wheeler wrote:
On Sun, Jul 17, 2011 at 11:42 AM, William Herrin b...@herrin.us wrote:
My off-the-cuff naive solution to this problem would be to discard the
oldest incomplete solicitation to fit the new one and, upon receiving
an apparently unsolicited
On Sun, Jul 17, 2011 at 3:40 PM, Owen DeLong o...@delong.com wrote:
Basically an ND entry would have the following states and timers:
I've discussed what you have described with some colleagues in the
past. The idea has merit and I would certainly not complain if
vendors included it (as a knob)
On Sun, Jul 17, 2011 at 1:35 PM, Jeff Wheeler j...@inconcepts.biz wrote:
On Sun, Jul 17, 2011 at 11:42 AM, William Herrin b...@herrin.us wrote:
My off-the-cuff naive solution to this problem would be to discard the
oldest incomplete solicitation to fit the new one and, upon receiving
an
On Jul 17, 2011, at 1:17 PM, Jeff Wheeler wrote:
On Sun, Jul 17, 2011 at 3:40 PM, Owen DeLong o...@delong.com wrote:
Basically an ND entry would have the following states and timers:
I've discussed what you have described with some colleagues in the
past. The idea has merit and I would
On Jul 17, 2011, at 1:32 PM, William Herrin wrote:
On Sun, Jul 17, 2011 at 1:35 PM, Jeff Wheeler j...@inconcepts.biz wrote:
On Sun, Jul 17, 2011 at 11:42 AM, William Herrin b...@herrin.us wrote:
My off-the-cuff naive solution to this problem would be to discard the
oldest incomplete
On Jul 14, 2011, at 8:24 PM, Jimmy Hess wrote:
On Thu, Jul 14, 2011 at 9:35 PM, Jared Mauch ja...@puck.nether.net wrote:
On Jul 14, 2011, at 10:06 PM, Fernando Gont ferna...@gont.com.ar wrote:
Anyone on a layer-2 network can do something interesting like flood all f's
and kill the lan.
On Thu, 14 Jul 2011 23:13:03 PDT, Owen DeLong said:
On Jul 14, 2011, at 8:24 PM, Jimmy Hess wrote:
In most cases if you have a DoS attack coming from the same Layer-2
network that a router is attached to,
it would mean there was already a serious security incident that
occured to give
On Thu, Jul 14, 2011 at 9:47 PM, Owen DeLong o...@delong.com wrote:
Very true. This is where Mr. Wheeler's arguments depart from reality. He's
right
in that the problem can't be truly fixed without some very complicated code
added
to lots of devices, but, it can be mitigated relatively
On 07/11/2011 09:17 PM, Karl Auer wrote:
I realise this is not specific implementations as you requested, but
it seems to me that the problem is generic enough not to require that.
The attack is made possible by the design of the protocol, not any
failing of specific implementations.
On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont ferna...@gont.com.ar wrote:
On 07/11/2011 09:17 PM, Karl Auer wrote:
Vulnerability to this specific issues has a great deal to do with the
implementation. After all, whenever there's a data structure that can
Yes
In this particular case, if the
On Jul 14, 2011, at 6:24 PM, Jimmy Hess wrote:
On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont ferna...@gont.com.ar wrote:
On 07/11/2011 09:17 PM, Karl Auer wrote:
Vulnerability to this specific issues has a great deal to do with the
implementation. After all, whenever there's a data
On 07/14/2011 10:24 PM, Jimmy Hess wrote:
In this particular case, if the implementation enforces a limit on the
number of entries in the INCOMPLETE state, then only nodes that have
never communicated with the outside world could be affected by this
attack. And if those entries that are in the
On Jul 14, 2011, at 10:06 PM, Fernando Gont ferna...@gont.com.ar wrote:
It should be possible to mitigate this, so long as the attack does not
actually
originate from a neighbor on the same subnet as a router IP interface on
an IPv6 subnet with sufficient number of IPs.
Well, unless
On 07/14/2011 11:35 PM, Jared Mauch wrote:
Well, unless there's some layer-2 anti-spoofing mitigation in
place, with /64 subnets the local attacker typically *will* have
enough addresses.
Solving a local attack
Well, I was talking about not *introducing* ;-) one.
is something I consider
http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00
Sent from my iThing
On Jul 14, 2011, at 10:57 PM, Fernando Gont ferna...@gont.com.ar wrote:
On 07/14/2011 11:35 PM, Jared Mauch wrote:
Well, unless there's some layer-2 anti-spoofing mitigation in
place, with /64 subnets the local
On Thu, Jul 14, 2011 at 9:35 PM, Jared Mauch ja...@puck.nether.net wrote:
On Jul 14, 2011, at 10:06 PM, Fernando Gont ferna...@gont.com.ar wrote:
Anyone on a layer-2 network can do something interesting like flood all f's
and kill the lan. Trying to keep the majority of thoughts here for
On 07/15/2011 12:24 AM, Jimmy Hess wrote:
A similarly hazardous situation exists with IPv4, and it is basically
unheard of for IPv4's Layer 2/ARP security weaknesses to be exploited
to create a DoS condition, even though they can be (very easily),
IMO, the situation is different, in that
In message 9c391c3a-3535-4c47-a743-572876859...@bogus.com, Joel Jaeggli write
s:
On Jul 12, 2011, at 6:41 PM, Mark Andrews wrote:
=20
In message 56e0fb8f-bb53-4db0-829b-39dfbab48...@bogus.com, Joel =
Jaeggli write
s:
=20
On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote:
=20
=3D20
On Jul 12, 2011, at 10:59 PM, Mark Andrews wrote:
I didn't claim it would work with existing CPE equipment. Declaring
6to4 historic won't work with existing CPE equipment either.
If the hosts behind it stop using 2002::/16 addresses as a product of a
software update which seems rather
Jeff,
On Jul 12, 2011, at 20:13 , Jeff Wheeler wrote:
On Tue, Jul 12, 2011 at 11:42 AM, Leo Bicknell bickn...@ufp.org wrote:
I'll pick on LISP as an example, since many operators are at least
aware of it. Some operators have said we need a locator and identifier
split. Interesting
Hello Jeff,
On 13 Jul 2011, at 10:08, Luigi Iannone wrote:
Jeff,
On Jul 12, 2011, at 20:13 , Jeff Wheeler wrote:
On Tue, Jul 12, 2011 at 11:42 AM, Leo Bicknell bickn...@ufp.org wrote:
I'll pick on LISP as an example, since many operators are at least
aware of it. Some operators have
Luigi, you have mis-understood quite a bit of the content of my
message. I'm not sure if this is of any further interest to NANOG
readers, but as it is basically what seems to go on a lot, from my
observations of IETF list activity, I'll copy my reply to the list as
you have done.
On Wed, Jul
Jeff,
on one point we agree, there is value in continuing this thread.
I've tried to bring the discussion back to the technical issues, but I failed.
Personally, I find your emails aggressive and close to offensive in some
sentences.
Differently from you, in my replies (all of them public) I
On Jul 13, 2011, at 13:03 , Luigi Iannone wrote:
Jeff,
on one point we agree, there is value in continuing this thread.
There is _no_ value.
my mistake...
Luigi
I've tried to bring the discussion back to the technical issues, but I failed.
Personally, I find your emails
In message 430fff20-43ed-45bb-846d-fee8769fc...@bogus.com, Joel Jaeggli write
s:
On Jul 12, 2011, at 10:59 PM, Mark Andrews wrote:
=20
I didn't claim it would work with existing CPE equipment. Declaring
6to4 historic won't work with existing CPE equipment either.
If the hosts behind
Leo,
Maybe we can fix this by:
a) bringing together larger groups of clueful operators in the IETF
b) deciding which issues interest them
c) showing up and being vocal as a group in protocol developing working groups
To some degree, we already do this in the IETF OPS area, but judging by your
In a message written on Tue, Jul 12, 2011 at 11:28:58AM -0400, Ronald Bonica
wrote:
Maybe we can fix this by:
a) bringing together larger groups of clueful operators in the IETF
b) deciding which issues interest them
c) showing up and being vocal as a group in protocol developing working
On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica rbon...@juniper.net wrote:
Leo,
Maybe we can fix this by:
a) bringing together larger groups of clueful operators in the IETF
b) deciding which issues interest them
c) showing up and being vocal as a group in protocol developing working groups
On Tue, Jul 12, 2011 at 8:42 AM, Leo Bicknell bickn...@ufp.org wrote:
In a message written on Tue, Jul 12, 2011 at 11:28:58AM -0400, Ronald Bonica
wrote:
Maybe we can fix this by:
a) bringing together larger groups of clueful operators in the IETF
b) deciding which issues interest them
c)
On 10 Jul 2011, at 21:22, Owen DeLong wrote:
On Jul 10, 2011, at 12:23 PM, William Herrin wrote:
Consider, for example, RFC 3484. That's the one that determines how an
IPv6 capable host selects which of a group of candidate IPv4 and IPv6
addresses for a particular host name gets priority.
On Tue, Jul 12, 2011 at 11:42 AM, Leo Bicknell bickn...@ufp.org wrote:
I'll pick on LISP as an example, since many operators are at least
aware of it. Some operators have said we need a locator and identifier
split. Interesting feedback. The IETF has gone off and started
playing in the
On 07/12/2011 08:43, Cameron Byrne wrote:
Witness the latest debacle with the attempt at trying to make 6to4 historic.
Various non-practicing entities were able to derail what network
operators largely supported. Since the IETF failed to make progress
operators will do other things to stop
-Original Message-
From: Leo Bicknell [mailto:bickn...@ufp.org]
Sent: Tuesday, July 12, 2011 11:42 AM
To: Ronald Bonica
Cc: nanog@nanog.org
Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6
broken?)
[snip]
But there is no roadmap in the IETF process now
Cameron,
Please stay tuned. While 6-to-4-historic is on hold, it is far from being dead.
Expect more discussion in Quebec and on the mailing list. I doubt if there will
be any final decision before Quebec.
Ron
-Original Message-
From:
Leo Bicknell wrote:
In short, make it easy for the operators to participate at the right
time in the process. It will be better for everyone!
Unfortunately, where you want to be inserted into the process is when everybody
has
said their piece 80-dozen times and are tired and just want to
On Jul 12, 2011, at 12:40 PM, Michael Thomas wrote:
Leo Bicknell wrote:
In short, make it easy for the operators to participate at the right
time in the process. It will be better for everyone!
Unfortunately, where you want to be inserted into the process is when
everybody has
said
On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote:
On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote:
On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica rbon...@juniper.net wrote:
Leo,
Maybe we can fix this by:
a) bringing together larger groups of clueful operators in the IETF
b)
On Jul 11, 2011, at 7:19 PM, Jeff Wheeler wrote:
Again, this is only hard to understand (or accept) if you don't know
how your routers work.
* why do you think there is an ARP and ND table?
* why do you think there are policers to protect the CPU from
excessive ARP/ND punts or traffic?
*
In message 56e0fb8f-bb53-4db0-829b-39dfbab48...@bogus.com, Joel Jaeggli write
s:
On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote:
=20
On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote:
=20
On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica rbon...@juniper.net =
wrote:
Leo,
=20
Maybe
On Jul 12, 2011, at 2:21 PM, Joel Jaeggli wrote:
On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote:
On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote:
On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica rbon...@juniper.net wrote:
Leo,
Maybe we can fix this by:
a) bringing together
On Jul 12, 2011 6:42 PM, Mark Andrews ma...@isc.org wrote:
In message 56e0fb8f-bb53-4db0-829b-39dfbab48...@bogus.com, Joel Jaeggli
write
s:
On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote:
=20
On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote:
=20
On Tue, Jul 12, 2011 at 8:28
On Jul 12, 2011, at 7:20 PM, Owen DeLong wrote:
On Jul 12, 2011, at 2:21 PM, Joel Jaeggli wrote:
On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote:
On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote:
On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica rbon...@juniper.net wrote:
Leo,
On Jul 12, 2011, at 6:41 PM, Mark Andrews wrote:
In message 56e0fb8f-bb53-4db0-829b-39dfbab48...@bogus.com, Joel Jaeggli
write
s:
On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote:
=20
On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote:
=20
On Tue, Jul 12, 2011 at 8:28 AM, Ronald
On Sun, Jul 10, 2011 at 4:22 PM, Owen DeLong o...@delong.com wrote:
On Jul 10, 2011, at 12:23 PM, William Herrin wrote:
Consider, for example, RFC 3484. That's the one that determines how an
IPv6 capable host selects which of a group of candidate IPv4 and IPv6
addresses for a particular host
On Jul 10, 2011, at 11:57 PM, William Herrin wrote:
On Sun, Jul 10, 2011 at 4:22 PM, Owen DeLong o...@delong.com wrote:
On Jul 10, 2011, at 12:23 PM, William Herrin wrote:
Consider, for example, RFC 3484. That's the one that determines how an
IPv6 capable host selects which of a group of
On Mon, 11 Jul 2011, William Herrin wrote:
If the complaint is that the IETF doesn't adequately listen to the
operations folk, then I think it makes sense to consult the operations
folks early and often on potential fixes. If folks here think it would
help, -that- is when I'll it to the IETF.
Sent from my iPad
On Jul 11, 2011, at 2:57, William Herrin b...@herrin.us wrote:
On Sun, Jul 10, 2011 at 4:22 PM, Owen DeLong o...@delong.com wrote:
On Jul 10, 2011, at 12:23 PM, William Herrin wrote:
Consider, for example, RFC 3484. That's the one that determines how an
IPv6 capable host
On Mon, Jul 11, 2011 at 3:08 AM, Joel Jaeggli joe...@bogus.com wrote:
On Jul 10, 2011, at 11:57 PM, William Herrin wrote:
A more optimal answer would have been to make records more like
MX or SRV records -- with explicit priorities the clients are
encouraged to follow. I wasn't there but
On Jul 11, 2011, at 8:13 AM, William Herrin wrote:
Today's RFC candidates are required to call out IANA considerations
and security considerations in special sections. They do so because
each of these areas has landmines that the majority of working groups
are ill equipped to consider on
On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli joe...@bogus.com wrote:
On Jul 11, 2011, at 8:13 AM, William Herrin wrote:
Today's RFC candidates are required to call out IANA considerations
and security considerations in special sections. They do so because
each of these areas has landmines
\
I have found my input on the LISP list completely ignored because, as
you suggest, my concerns are real-world and don't have any impact on
someone's pet project. LISP as it stands today can never work on the
Internet, and regardless of the fine reputations of the people at
Cisco and other
On 7/10/11 6:29 PM, Randy Bush wrote:
The IETF is run by volunteers. They volunteer because they find
designing protocols to be fun. For the most part, operators are not
entertained by designing network protocols. So, for the most part they
don't partiticpate.
Randy Bush, Editorial zone: Into
On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli joe...@bogus.com wrote:
On Jul 11, 2011, at 8:13 AM, William Herrin wrote:
Today's RFC candidates are required to call out IANA considerations
and security considerations in special sections. They do so because
each of these areas has landmines
In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar
wrote:
Eh ANYBODY, including you, can sign up to the IETF mailing lists and
participate there, just like a couple of folks from NANOG are already doing.
The way the IETF and the operator community interact is
On Mon, Jul 11, 2011 at 3:18 PM, William Herrin b...@herrin.us wrote:
On the other hand, calling out ops issues in RFCs is a modest reform
that at worst shouldn't hurt anything. That beats my next best idea:
I think if this were done, some guy like me would spend endless hours
arguing with
On Mon, Jul 11, 2011 at 3:35 PM, Leo Bicknell bickn...@ufp.org wrote:
The IETF does not want operators in many steps of the process. If
you try to bring up operational concerns in early protocol development
for example you'll often get a we'll look at that later response,
which in many cases
On Jul 11, 2011, at 12:18 PM, William Herrin wrote:
On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli joe...@bogus.com wrote:
On Jul 11, 2011, at 8:13 AM, William Herrin wrote:
Today's RFC candidates are required to call out IANA considerations
and security considerations in special sections.
On Jul 11, 2011, at 12:57 PM, Jeff Wheeler wrote:
On Mon, Jul 11, 2011 at 3:35 PM, Leo Bicknell bickn...@ufp.org wrote:
The IETF does not want operators in many steps of the process. If
you try to bring up operational concerns in early protocol development
for example you'll often get a
On Mon, Jul 11, 2011 at 3:41 PM, Jeff Wheeler j...@inconcepts.biz wrote:
On Mon, Jul 11, 2011 at 3:18 PM, William Herrin b...@herrin.us wrote:
On the other hand, calling out ops issues in RFCs is a modest reform
that at worst shouldn't hurt anything. That beats my next best idea:
I think if
You disagree? What are your thoughts on fixing the problem?
I'm not sure that we agree on the dimensions of the problem.
on the question of ipv6 is broken:
* You're going to have to cope with what you have and can squeeze out of
vendors in the near term. implmentors don't change that
Once upon a time, there was only the IETF, then NOGs came and standards
became sloppy
On Mon, Jul 11, 2011 at 5:12 PM, Owen DeLong o...@delong.com wrote:
No... I like SLAAC and find it useful in a number of places. What's wrong
with /64? Yes, we need better DOS protection in switches and routers
See my slides http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf for
why no vendor's
On Mon, Jul 11, 2011 at 3:35 PM, Leo Bicknell bickn...@ufp.org wrote:
If the IETF really wanted to get useful operator impact, they would
slightly modify their process. On the front end there would be a
more clear way for operational types to add to the To-Do list stuff
we really need to make
On Mon, Jul 11, 2011 at 5:10 PM, Joel Jaeggli joe...@bogus.com wrote:
On Jul 11, 2011, at 12:18 PM, William Herrin wrote:
On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli joe...@bogus.com wrote:
On Jul 11, 2011, at 8:13 AM, William Herrin wrote:
Today's RFC candidates are required to call out
On Mon, 11 Jul 2011, William Herrin wrote:
On Mon, Jul 11, 2011 at 5:10 PM, Joel Jaeggli joe...@bogus.com wrote:
On Jul 11, 2011, at 12:18 PM, William Herrin wrote:
snip
My focus in this thread is this: how do we help the next teams avoid
the discourtesy and the smackdown that the v6
On Jul 11, 2011, at 3:37 PM, William Herrin wrote:
On Mon, Jul 11, 2011 at 5:10 PM, Joel Jaeggli joe...@bogus.com wrote:
On Jul 11, 2011, at 12:18 PM, William Herrin wrote:
On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli joe...@bogus.com wrote:
On Jul 11, 2011, at 8:13 AM, William Herrin
On Mon, Jul 11, 2011 at 5:03 PM, Jeff Wheeler j...@inconcepts.biz wrote:
On Mon, Jul 11, 2011 at 5:12 PM, Owen DeLong o...@delong.com wrote:
No... I like SLAAC and find it useful in a number of places. What's wrong
with /64? Yes, we need better DOS protection in switches and routers
See my
On Mon, 2011-07-11 at 18:48 -0500, Jimmy Hess wrote:
It would be useful to at least have the risk properly described, in
terms of what kind of DoS condition could arise on specific implementations.
RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats
Section 4.3.2
In this attack,
On Mon, Jul 11, 2011 at 7:48 PM, Jimmy Hess mysi...@gmail.com wrote:
If every vendor's implementation is vulnerable to a NDP Exhaustion
vulnerability,
how come the behavior of specific routers has not been documented
specifically?
Well, I am in the business of knowing the behavior of kit
On 07/10/2011 12:45, Owen DeLong wrote:
On Jul 10, 2011, at 9:16 AM, Jeroen Massar wrote:
On 2011-07-10 17:56 , David Miller wrote:
[..]
+1
The lack of will on the part of the IETF to attract input from and involve
operators in their processes (which I would posit is a critical element
Well, you work at Zynga, a company which makes facebook games. Before
that you worked at Nokia, company which makes phones but doesn't run
phone networks. Before that it was Check Point Software, a company
which makes firewalls but doesn't run networks. And before that it was
the University
My focus in this thread is this: how do we help the next teams avoid
the discourtesy and the smackdown that the v6 teams are getting for
not adequately recognizing the ops' issues. These guys should have
been heroes but instead they screwed the pooch and everybody's paying
for it. How do we
I said there is an ops directorate that reviews basically every draft
in front of the iesg.
and this directorate is a group of actual operators?
randy
On Jul 10, 2011, at 12:16 PM, Jeroen Massar wrote:
On 2011-07-10 17:56 , David Miller wrote:
[..]
+1
The lack of will on the part of the IETF to attract input from and involve
operators in their processes (which I would posit is a critical element in
the process).
Eh ANYBODY,
On 7/10/2011 12:16 PM, Jeroen Massar wrote:
On 2011-07-10 17:56 , David Miller wrote:
[..]
+1
The lack of will on the part of the IETF to attract input from and involve
operators in their processes (which I would posit is a critical element in
the process).
Eh ANYBODY, including you, can
On Sun, Jul 10, 2011 at 1:41 PM, David Miller dmil...@tiggee.com wrote:
On 7/10/2011 12:16 PM, Jeroen Massar wrote:
You are on NANOG out of your own free will, the same applies to the
IETF. If you don't participate here your voice is not heard either, just
like at the IETF.
True, anyone can
On Jul 10, 2011, at 9:16 AM, Jeroen Massar wrote:
On 2011-07-10 17:56 , David Miller wrote:
[..]
+1
The lack of will on the part of the IETF to attract input from and involve
operators in their processes (which I would posit is a critical element in
the process).
Eh ANYBODY,
On 07/10/2011 12:45 PM, Owen DeLong wrote:
While this is true, there are a couple of factors that make it more difficult
than it would appear on the surface.
Number one: Participating effectively in IETF is a rather time-consuming
process. While a lot of engineers and developers may have IETF
On Jul 10, 2011, at 12:23 PM, William Herrin wrote:
On Sun, Jul 10, 2011 at 1:41 PM, David Miller dmil...@tiggee.com wrote:
On 7/10/2011 12:16 PM, Jeroen Massar wrote:
You are on NANOG out of your own free will, the same applies to the
IETF. If you don't participate here your voice is not
On Sun, Jul 10, 2011 at 3:45 PM, Owen DeLong o...@delong.com wrote:
Number two: While anyone can participate, approaching IETF as an
operator requires a rather thick skin, or, at least it did the last couple
of times I attempted to participate. I've watched a few times where
I am subscribed to
The IETF is run by volunteers. They volunteer because they find
designing protocols to be fun. For the most part, operators are not
entertained by designing network protocols. So, for the most part they
don't partiticpate.
Randy Bush, Editorial zone: Into the Future with the Internet Vendor
86 matches
Mail list logo
