Re: Why is IPv6 broken?

[Jeff Wheeler]

On Sat, Jul 9, 2011 at 5:25 PM, Bob Network  wrote:
> Why is IPv6 broken?

You should have titled your thread, "my own personal rant about
Hurricane Electric's IPv6 strategy."  You may also have left out the
dodgy explanation of peering policies and technicalities, since these
issues have been remarkably static since about 1996.  The names of the
networks change, but the song remains the same.  This is not a novel
subject on this mailing list.  In fact, there have been a number of
threads discussing HE's practices lately.  If you are so interested in
them, I suggest you review the list archive.

There are quite a few serious, unresolved technical problems with IPv6
adoption besides a few networks playing chicken with their collective
customer-bases.  The lack of will on the part of vendors and operators
to participate in the IETF process, and make necessary and/or
beneficial changes to the IPv6 standards, has left us in a situation
where IPv6 implementation produces networks which are vulnerable to
trivial DoS attacks and network intrusions.

The lack of will on the part of access providers to insist on
functioning IPv6 support on CPE and BRAS platforms has even mid-sized
ISPs facing nine-figure (as in, hundred-million-dollars) expenses to
forklift-upgrade their access networks and end-user equipment, at a
time when IPv6 seems to be the only way to continue growing the
Internet.

The lack of will on the part of major transit networks, including
Savvis, to deploy IPv6 capabilities to their customers, means that
customers caught in multi-year contracts may have no option for native
connectivity.  Cogent's policy of requiring a new contract, and from
what I am still being told by some European customers, new money, from
customers in exchange for provisioning IPv6 on existing circuits,
means a simple technical project gets caught up in the complexities of
budgeting and contract execution.

If you believe that the most serious problem facing IPv6 adoption is
that HE / Level3 / Cogent don't carry a full table, you are living in
a fantasy world.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: Why is IPv6 broken?

[David Miller]

On 7/10/2011 10:14 AM, Jeff Wheeler wrote:

On Sat, Jul 9, 2011 at 5:25 PM, Bob Network  wrote:

Why is IPv6 broken?

You should have titled your thread, "my own personal rant about
Hurricane Electric's IPv6 strategy."  You may also have left out the
dodgy explanation of peering policies and technicalities, since these
issues have been remarkably static since about 1996.  The names of the
networks change, but the song remains the same.  This is not a novel
subject on this mailing list.  In fact, there have been a number of
threads discussing HE's practices lately.  If you are so interested in
them, I suggest you review the list archive.

There are quite a few serious, unresolved technical problems with IPv6
adoption besides a few networks playing chicken with their collective
customer-bases.  The lack of will on the part of vendors and operators
to participate in the IETF process, and make necessary and/or
beneficial changes to the IPv6 standards, has left us in a situation
where IPv6 implementation produces networks which are vulnerable to
trivial DoS attacks and network intrusions.

The lack of will on the part of access providers to insist on
functioning IPv6 support on CPE and BRAS platforms has even mid-sized
ISPs facing nine-figure (as in, hundred-million-dollars) expenses to
forklift-upgrade their access networks and end-user equipment, at a
time when IPv6 seems to be the only way to continue growing the
Internet.

The lack of will on the part of major transit networks, including
Savvis, to deploy IPv6 capabilities to their customers, means that
customers caught in multi-year contracts may have no option for native
connectivity.  Cogent's policy of requiring a new contract, and from
what I am still being told by some European customers, new money, from
customers in exchange for provisioning IPv6 on existing circuits,
means a simple technical project gets caught up in the complexities of
budgeting and contract execution.


+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).  And the lack of will/fore site on the part of the IETF to
respond to input from operators that they have received. If fingers can
be pointed at both sides, i.e. operators and IETF, then both sides are to
blame.  The IETF only has value if they are publishing "standards" that
work properly in the real world.  If the implementers of these "standards"
say that they are broken, then the IETF has failed to provide value.





If you believe that the most serious problem facing IPv6 adoption is
that HE / Level3 / Cogent don't carry a full table, you are living in
a fantasy world.


+1

-DMM

Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Jeroen Massar]

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 sign up to the IETF mailing lists and
participate there, just like a couple of folks from NANOG are already doing.

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.

Peeking at the i...@ietf.org member list, I don't see your name there.
You can signup here: https://www.ietf.org/mailman/listinfo/ipv6

Greets,
 Jeroen

CNN security contact?

[Chris]

Yet another Casey Anthony scam floating around but via a vulnerability
in CNN's advertising system so Facebook lusers think it's authentic
and from CNN. GoDaddy domain and Softlayer hosting the site.. called
Softlayer NOC - "1 person is in the abuse department on Sunday"

-- 
--C

"The dumber people think you are, the more surprised they're going to
be when you kill them." - Sir William Clayton

Re: How long is reasonable to fix a routing issue in IPv6?

[Florian Weimer]

> On Fri, Jul 08, 2011 at 10:21:13PM +0200, Florian Weimer wrote:
>> * Jared Mauch:
>> 
>> > 2) is a mapped-v4 address a valid *source* address on the wire
>> > even if it's not a valid dest?
>> 
>> By the way, has the analogous issue involving v4 addresses from
>> RFC 1918 space ever been settled?
>
> define "valid"?

"Exempt from BCP 38 filters".  I thought that was clear enough, sorry. 8-)

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[David Miller]

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 sign up to the IETF mailing lists and
participate there, just like a couple of folks from NANOG are already doing.

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 participate in the IETF processes.  However, if key 
players do

not participate, then something is broken.  I will take my lumps for not
participating.

My point was - "If fingers can be pointed at both sides, i.e. operators and
IETF, then both sides are to blame."

In the corporate world, if I were contemplating changing the framework of a
system, then I would need to get buy in / agreement from the stakeholders of
that system. If I was going to change the framework behind an HR system, 
then
the HR managers and HR systems experts would all have to agree to the 
change.
If I changed the framework and broke all of the HR systems and then told 
my boss

that I scheduled a meeting and nobody from HR showed up and therefore I used
that as agreement in their absence, then I would get fired.  Yes, I 
understand
that corporate environments are very different from the IETF 
environment, but

there are perhaps some lessons to learn from the corporate environment.

Most RFCs operate within a meritocracy.  A standard can be proposed for
"Example Protocol v10" and if nobody likes it outside of the IETF, then 
it is

not implemented by anyone and it eventually dies on the vine.  IPv6 is
"different" in that it is the underpinning of every other 
protocol/standard that
will exist on or operate over the internet for the next 20-30 years 
(probably)

We had 10+ years of IPv6 not being implemented by anyone (seriously), yet it
didn't die on the vine.  Perhaps the process for "Example Protocol v10" 
and the
process for IPv6 should be different - given the fundamental difference 
in their

scope.

No, we can't change the past.  "Those who do not learn from history are 
doomed

to repeat it." - Santayana.  I would say that many variables that got us to
where we are today - which is out of IPv4 addresses and faced with only 
IPv6,
which many believe is fundamentally flawed, as our only way forward - 
holds some
lessons to be learned... but perhaps this is just me - and if so, I 
apologize

for the noise.




Peeking at the i...@ietf.org member list, I don't see your name there.
You can signup here: https://www.ietf.org/mailman/listinfo/ipv6


Absolutely true, fixed.



Greets,
  Jeroen


-DMM

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[William Herrin]

On Sun, Jul 10, 2011 at 1:41 PM, David Miller  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 participate in the IETF processes.  However, if key players
> do not participate, then something is broken.  I will take my lumps for not
> participating.
>
> My point was - "If fingers can be pointed at both sides, i.e. operators and
> IETF, then both sides are to blame."

Hi David,

This is a process problem, not an individual problem.

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.

This is not going to change. And it also isn't the problem -- people
who enjoy the work tend to do better work.

The problem is that the IETF routinely exceeds the scope of designing
network protocols. Participants in the working groups take what are
fundamentally operations issues unto themselves. They do so knowing
they lack adequate participation by network operators. And the process
that leads to RFCs offers inadequate checks and balances to mitigate
that behavior.

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. How is a server's
address priority NOT an issue that should be managed at an operations
level by individual server administrators? Yet the working group which
produced it came up with a static prioritization that is the root
cause of a significant portion of the IPv6 deployment headaches we
face.


I don't know the whole solution to this problem, but I'm pretty sure I
know the first step.

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

There should be an operations callout as well -- a section where
proposed operations defaults (as well as statics for which a solid
case can be made for an operations tunable) are extracted from the
thick of it and offered for operator scrutiny prior to publication of
the RFC.

Food for thought.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Why is IPv6 broken?

[bmanning]

so... how much of the heavy lifting are you personally willing to do and how 
much are you
depending/expecting others to do on your behalf?  

public whining that the v6 network does not mirror the v4 network is not 
productive and
is not news.


of course ymmv.


/bill

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Owen DeLong]

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, including you, can sign up to the IETF mailing lists and
> participate there, just like a couple of folks from NANOG are already doing.
> 
> 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.
> 
> Peeking at the i...@ietf.org member list, I don't see your name there.
> You can signup here: https://www.ietf.org/mailman/listinfo/ipv6
> 
> Greets,
> Jeroen

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 effort
as a primary part of their job function and/or get their employer to let
them spend time on it, operators are often too busy keeping what they
already have running and it can be _VERY_ difficult to get management
to support the idea of investing time in things like IETF which are not
seen by management as having direct operational impact. NANOG
is about the limit of their vision on such things and even that is not
well supported in a lot of organizations.

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
operators were shouted down by purists and religion over basic
real-world operational concerns. It seems to be a relatively routine
practice and does not lead to operators wanting to come back to
an environment where they feel unwelcome.

Owen

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Michael Thomas]

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 effort
as a primary part of their job function and/or get their employer to let
them spend time on it, operators are often too busy keeping what they
already have running and it can be _VERY_ difficult to get management
to support the idea of investing time in things like IETF which are not
seen by management as having direct operational impact. NANOG
is about the limit of their vision on such things and even that is not
well supported in a lot of organizations.
   

Vendors make up the vast bulk of attendance at ietf. And vendors are
there for one reason: to make stuff that you'll be paying  for.  So you
pay for it at ietf time, or you pay for it at deployment time. Either way,
you'll be paying.


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
operators were shouted down by purists and religion over basic
real-world operational concerns. It seems to be a relatively routine
practice and does not lead to operators wanting to come back to
an environment where they feel unwelcome.
   


If you're trying to imply that operators get singled out, that's
not been my experience. You definitely need to have a thick skin
given egos and there's definitely a large pool of professional
ietf finger waggers, but their holier than thou attitude is spread
to all in their path, from what I've seen. I won't speak for every
working group, but the ones i've been involved with have been
pretty receptive to operator input.

Mike

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Owen DeLong]

On Jul 10, 2011, at 12:23 PM, William Herrin wrote:

> On Sun, Jul 10, 2011 at 1:41 PM, David Miller  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 participate in the IETF processes.  However, if key players
>> do not participate, then something is broken.  I will take my lumps for not
>> participating.
>> 
>> My point was - "If fingers can be pointed at both sides, i.e. operators and
>> IETF, then both sides are to blame."
> 
> Hi David,
> 
> This is a process problem, not an individual problem.
> 
> 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.
> 
> This is not going to change. And it also isn't the problem -- people
> who enjoy the work tend to do better work.
> 
> The problem is that the IETF routinely exceeds the scope of designing
> network protocols. Participants in the working groups take what are
> fundamentally operations issues unto themselves. They do so knowing
> they lack adequate participation by network operators. And the process
> that leads to RFCs offers inadequate checks and balances to mitigate
> that behavior.
> 
> 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. How is a server's
> address priority NOT an issue that should be managed at an operations
> level by individual server administrators? Yet the working group which
> produced it came up with a static prioritization that is the root
> cause of a significant portion of the IPv6 deployment headaches we
> face.
> 
3484 specifies a static default. By definition, defaults in absence of
operator configuration kind of have to be static. Having a reasonable
and expected set of defaults documented in an RFC provides a known
quantity for what operators can/should expect from hosts they have
not configured. I see nothing wrong with RFC 3484 other than I would
agree that the choices made were suboptimal. Mostly that was based
on optimism and a lack of experience available at the time of writing.

There is another RFC and there are APIs and most operating systems
have configuration mechanisms where an operator CAN set that to
something other than the 3484 defaults.

> 
> I don't know the whole solution to this problem, but I'm pretty sure I
> know the first step.
> 

I don't know what you had in mind, but, reading RFC 5014 would be my
suggestion as a good starting point.

> 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 their own.
> 
> There should be an operations callout as well -- a section where
> proposed operations defaults (as well as statics for which a solid
> case can be made for an operations tunable) are extracted from the
> thick of it and offered for operator scrutiny prior to publication of
> the RFC.
> 

I think this would be a good idea, actually. It would probably be more
effective to propose it to IETF than to NANOG, however.
 
Owen

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Jeff Wheeler]

On Sun, Jul 10, 2011 at 3:45 PM, Owen DeLong  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 IDR (BGP, etc.) and LISP lists.  These are
populated with different people and cover entirely different topics.
My opinion is the following:

* The IDR list is welcoming of operators, but whether or not your
opinion is listened to or included in the process, I do not know.
Randy Bush, alone, posts more on this list than the sum of all
operators who post in the time I've been reading.  I think Randy's
influence is 100% negative, and it concerns me deeply that one
individual has the potential to do so much damage to essential
protocols like BGP.  Also, the priorities of this list are pretty
fucked.  Inaction within this working group is the reason we still
don't have expanded BGP communities for 32 bit ASNs.  The reason for
this is operators aren't participating.  The people on the list or the
current participants of the WG should not be blamed.  My gripe about
Randy Bush having the potential to do huge damage would not exist if
there were enough people on the list who understand what they're doing
to offer counter-arguments.

> operators were shouted down by purists and religion over basic
> real-world operational concerns. It seems to be a relatively routine
> practice and does not lead to operators wanting to come back to
> an environment where they feel unwelcome.

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 organizations who are working on it, they are either
furthering it only because they would rather work on a pet project
than something useful to customers, or because they truly cannot
understand its deep, insurmountable design flaws at Internet-scale.
You would generally hope that someone saying, "LISP can't work at
Internet-scale because anyone will be able to trivially DoS any LISP
ITR ('router' for simplicity), but here is a way you can improve it,"
well, that remark, input, and person should be taken quite seriously,
their input examined, and other assumptions about the way LISP is
supposed to work ought to be questioned.  None of this has happened.
LISP is a pet project to get some people their Ph.D.s and keep some
old guard vendor folks from jumping ship to another company.  It is a
shame that the IETF is manipulated to legitimize that kind of thing.

Then again, I could be wrong.  Randy Bush could be a genius and LISP
could revolutionize mobility.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Randy Bush]

> 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
Task Force: a very curmudgeonly view, or testing spaghetti," ACM SIGCOMM
Computer Communication Review Volume 35 Issue 5, October 2005.
http://archive.psg.com/051000.ccr-ivtf.html

NANOG List Cutover Schedule

[Michael K. Smith - Adhost]

Hello All:

We are going to cut the mailing list over to the new location at 4:00 PM PDT 
(GMT -7).  We will be testing the cutover on this list to make sure everything 
goes smoothly.  Please filter on the subject "NANOG TEST".

Regards,

Mike

--
Michael K. Smith - CISSP, GSEC, GISP
Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)

[NANOG] NANOG TEST

[Michael K. Smith - Adhost]

Please ignore

--
Michael K. Smith - CISSP, GSEC, GISP
Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)

Re: [NANOG] NANOG TEST

[Kristian Erik Hermansen]

No.
On Jul 10, 2011 7:06 PM, "Michael K. Smith - Adhost" 
wrote:
> Please ignore
>
> --
> Michael K. Smith - CISSP, GSEC, GISP
> Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com
> w: +1 (206) 404-9500 f: +1 (206) 404-9050
> PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
>
>

UPDATE: NANOG List Cutover Schedule

[Michael K. Smith - Adhost]

Hello:

We have moved the NANOG list back to its original location for the time being.  
We have a few issues to address before we can cut the system over permanently.  
I will let everyone know again when we are ready to proceed.

Thanks,

Mike

--
Michael K. Smith - CISSP, GSEC, GISP
Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


> -Original Message-
> From: Michael K. Smith - Adhost [mailto:mksm...@adhost.com]
> Sent: Sunday, July 10, 2011 3:38 PM
> To: NANOG list (nanog@nanog.org)
> Subject: NANOG List Cutover Schedule
> 
> Hello All:
> 
> We are going to cut the mailing list over to the new location at 4:00 PM PDT
> (GMT -7).  We will be testing the cutover on this list to make sure everything
> goes smoothly.  Please filter on the subject "NANOG TEST".
> 
> Regards,
> 
> Mike
> 
> --
> Michael K. Smith - CISSP, GSEC, GISP
> Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com
> w: +1 (206) 404-9500 f: +1 (206) 404-9050
> PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
> 
> 

Re: CNN security contact?

[Chris]

CNN patched the redirect vulnerability which was making it easier to
social engineer Nancy Grace tards who followed the case

Re: [NANOG] NANOG TEST

[Steve Feldman]

Another test, sorry for the noise.
Steve

Re: [NANOG] NANOG TEST

[Joe Sniderman]

On 07/10/2011 10:03 PM, Steve Feldman wrote:
> Another test, sorry for the noise.
> Steve

Well, at least the fears that nanog would be IPv4 only are unfounded..
Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:1112:1::14])...


-- 
Joe Sniderman 

Re: IMPORTANT ADMINISTRIVIA - NANOG list and website changes over the next week

[Mikael Abrahamsson]

On Fri, 8 Jul 2011, Seth Mattinen wrote:


- At this stage, mail.amsl.com will be the only MX for NANOG list 
services.


No more IPv6? I don't see an  record for it...


There seems to be one now:

mail.amsl.com.  1800IN  2001:1890:1112:1::14

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[William Herrin]

On Sun, Jul 10, 2011 at 4:22 PM, 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. How is a server's
>> address priority NOT an issue that should be managed at an operations
>> level by individual server administrators? Yet the working group which
>> produced it came up with a static prioritization that is the root
>> cause of a significant portion of the IPv6 deployment headaches we
>> face.
>>
> 3484 specifies a static default. By definition, defaults in absence of
> operator configuration kind of have to be static. Having a reasonable
> and expected set of defaults documented in an RFC provides a known
> quantity for what operators can/should expect from hosts they have
> not configured. I see nothing wrong with RFC 3484 other than I would
> agree that the choices made were suboptimal. Mostly that was based
> on optimism and a lack of experience available at the time of writing.

Hi Owen,

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 I'd be willing to bet there
was a lonely voice in the room saying, hey, this should be controlled
by the sysadmin. A lonely voice that got shouted down.


>> 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 their own.
>>
>> There should be an operations callout as well -- a section where
>> proposed operations defaults (as well as statics for which a solid
>> case can be made for an operations tunable) are extracted from the
>> thick of it and offered for operator scrutiny prior to publication of
>> the RFC.
>
> I think this would be a good idea, actually. It would probably be more
> effective to propose it to IETF than to NANOG, however.

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.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004