At 03:38 PM 12/28/2009, Owen DeLong wrote:
There are lessons to be learned that are valuable. Both from
things aviation has done well that we could emulate, and, from
things aviation has done poorly that we should avoid. There
are also additional lessons to be learned about the differences
in c
On Dec 25, 2009, at 7:57 AM, Anton Kapela wrote:
> On Fri, Dec 25, 2009 at 5:44 AM, Vadim Antonov wrote:
>
>> The ISP industry has a long way to go until it reaches the same level of
>> sophistication in handling problems as aviation has.
>
> It seems that there's a logical fallacy floating ar
On Dec 24, 2009, at 11:08 PM, Scott Howard wrote:
> On Thu, Dec 24, 2009 at 6:27 PM, George Bonser wrote:
>
>> So you can put a lot of process around changes in advance but there
>> isn't quite as much to manage incidents that strike out of the clear
>> blue. Too much process at that point cou
On 12/25/09 7:57 AM, Anton Kapela wrote:
What I'm getting at is that after following this thread for a while,
I'm not convinced any amount of process-borrowing is going to solve
problems better, faster, or even avoid them in the first place. At
best, our craft is 1/3rd as "old" (if that's someho
The connection may not be immediately apparent, but I think Philip
Greenspun's article critiquing Malcolm Gladwell's musings on cranial
metrics etc. has some bearing:
http://philip.greenspun.com/flying/foreign-airline-safety
...or is at least an interesting read. In observing network opera
In general, it seems that a field has to be aware that it can kill (or
has killed) an embarrassing number of people before its members accept
the need for controls such as processes and checklists.
Here's a couple if incidents in which gruesome, public loss of life
was necessary to for thought to
At 02:08 AM 12/25/2009, Scott Howard wrote:
On Thu, Dec 24, 2009 at 6:27 PM, George Bonser wrote:
> So you can put a lot of process around changes in advance but there
> isn't quite as much to manage incidents that strike out of the clear
> blue. Too much process at that point could impede pro
> I can see situations in the future where people's lives could be
> dependent on networks working properly, or at least endangered if a
> network fails.
Actually it's not the future. My father's design bureau was making
hardware, since 70s (including network stuff) for running industrial
process
and keeps the engineer abreast of "real world" issues.
Frank
-Original Message-
From: Michael Dillon [mailto:wavetos...@googlemail.com]
Sent: Thursday, December 24, 2009 6:02 PM
To: NANOG list
Subject: Re: Revisiting the Aviation Safety vs. Networking discussion
>> i
> What I'm getting at is that after following this thread for a while,
> I'm not convinced any amount of process-borrowing is going to solve
> problems better, faster, or even avoid them in the first place. At
> best, our craft is 1/3rd as "old" (if that's somehow I measure of
> maturity) as flight
On Thu, 24 Dec 2009, Scott Howard wrote:
His actions were then "subject to the consensus of those on the conference
bridge" (ie, ATC) who could have denied his actions if they believed they
would have made the situation worse (ie, if what they were proposing would
have had them on a collision co
On Thu, Dec 24, 2009 at 01:09:26PM -0500, Randy Bush wrote:
> > I _do_ create action plans and _do_ quarterback each step and _do_
> > slap down any attempt to deviate.
>
> imagine a network engineering culture where the concept of 'attempt to
> deviate' just does not occur.
Whimsical deviations
On Fri, Dec 25, 2009 at 5:44 AM, Vadim Antonov wrote:
> The ISP industry has a long way to go until it reaches the same level of
> sophistication in handling problems as aviation has.
It seems that there's a logical fallacy floating around somewhere
(networks have parts and are complicated, airp
On Fri, 25 Dec 2009, Vadim Antonov wrote:
The ISP industry has a long way to go until it reaches the same level of
sophistication in handling problems as aviation has.
Well, to counter this one might talk about the medical business (doctors)
which hasn't been able to embrace the checklists at
Just clearing a small point about pilots (I'm a pilot) - the
pilot-in-command has ultimate responsibility for his a/c and can ignore
whatever ATC tells him to do if he considers that to be contrary to the
safety of his flight (he may be asked to explain his actions later,
though). Now, usually ign
I think any network engineer who sees a major problem is going to have a
"Houston, we have a problem" moment. And actually, he was telling the
ATC what he was going to need to do, he wasn't getting permission so
much as telling them what he was doing so traffic could be cleared out
of his way. Fir
On Thu, Dec 24, 2009 at 6:27 PM, George Bonser wrote:
> So you can put a lot of process around changes in advance but there
> isn't quite as much to manage incidents that strike out of the clear
> blue. Too much process at that point could impede progress in clearing
> the issue. Capt. Sullenbe
On Dec 25, 2009, at 9:27 AM, George Bonser wrote:
> Capt. Sullenberger did not need to fill out an incident
> report, bring up a conference bridge, and give a detailed description of
> what was happening with his plane, the status of all subsystems, and his
> proposed plan of action (subject to c
> -Original Message-
> From: Dobbins, Roland
>
> On Dec 25, 2009, at 7:01 AM, Michael Dillon wrote:
>
> > It would be interesting to see what others have to say about this
> answer.
>
> I think it's a pretty accurate summation of how these things work in a
> lot of big organizations, al
On Dec 25, 2009, at 7:01 AM, Michael Dillon wrote:
> It would be interesting to see what others have to say about this answer.
I think it's a pretty accurate summation of how these things work in a lot of
big organizations, all over the world.
There's a detrimental side to it, in that in the e
>> imagine a network engineering culture where the concept of 'attempt to
>> deviate' just does not occur.
>
> Are you trying to suggest that this is something horrible, or that it's the
> future of network engineering? :)
The model of network engineering that grew up during the 1990s is
forever
:-)
:mops work.
It depends on who wrote it and the experience the person has (on the particular
network) who generated it..
scott
: this works in a tech culture where folk follow mops obsessively. my
: experience is that most north americam engineers are too smart to do
: that, and take shoprtcuts
> and _do_ slap down any attempt to deviate
: imagine a network engineering culture where the concept of 'attempt to
: deviate
I _do_ create action plans and _do_ quarterback each step and _do_
slap down any attempt to deviate.
imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.
Are you trying to suggest that this is something horrible, or that it's the
fu
>> imagine a network engineering culture where the concept of 'attempt to
>> deviate' just does not occur.
>
> Are you trying to suggest that this is something horrible, or that
> it's the future of network engineering? :)
neither. it is one [type of] ops engineering culture, and a very
successf
On Dec 24, 2009, at 1:09 PM, Randy Bush wrote:
>> I _do_ create action plans and _do_ quarterback each step and _do_
>> slap down any attempt to deviate.
>
> imagine a network engineering culture where the concept of 'attempt to
> deviate' just does not occur.
Are you trying to suggest that this
Eddy Martinez wrote:
On Dec 24, 2009, at 10:09 AM, Randy Bush wrote:
I _do_ create action plans and _do_ quarterback each step and _do_
slap down any attempt to deviate.
imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.
I find the thought of
On Dec 24, 2009, at 10:09 AM, Randy Bush wrote:
>> I _do_ create action plans and _do_ quarterback each step and _do_
>> slap down any attempt to deviate.
>
> imagine a network engineering culture where the concept of 'attempt to
> deviate' just does not occur.
>
> randy
=]
The networking gro
> I _do_ create action plans and _do_ quarterback each step and _do_
> slap down any attempt to deviate.
imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.
randy
On Dec 24, 2009, at 9:51 AM, Randy Bush wrote:
>> I'm more persistent than smart, and I tell ya, if you prep well
>> enough, you can hand your checklist to a stoned intern and you'll
>> have no worries at all.
>
> this works in a tech culture where folk follow mops obsessively. my
> experience i
> I'm more persistent than smart, and I tell ya, if you prep well
> enough, you can hand your checklist to a stoned intern and you'll
> have no worries at all.
this works in a tech culture where folk follow mops obsessively. my
experience is that most north american engineers are too smart to do
1. I grew up at the local airport watching my CFII pop train an
endless stream of pilots.
2. The checklist for my last production gear swap had over 400 steps
and 4 time/task gates (each with a rollback plan). As I did each
sequence of steps, I called it out, and someone read their copy of the
32 matches
Mail list logo
