[linux-users:85036] Re: Managing Network ( Was: R: Re: セグメント内に存在するDHCPサーバの検出方法)

[Takeaki Kato <kato _at_ xxxxxxxxxxxxxxxxxxxxxxx>]

加藤です。

Toshiboumi bugbird Ohta <bugbird _at_ timedia.co.jp>さんは
<3B450B1B.8345AA6B _at_ timedia.co.jp>で書きました

> > 　このケースは、繋ぐ人がそれと分かって繋いでいるわけですから。
> > 更に、SOHO利用であれば、影響範囲が小さいので、少なくとも大騒ぎにはなりませ
> > ん。
> 
> 　この仮定が成立していれば、元ポストの事故は起きて
> いないでしょう。

御意。

> 　ネットワークという有限の資源を共有するという事実
> に対して、ユーザはどの様に行動するべきであり、これ
> を実践するためにはどれだけの事を理解しているべきか
> というガイドライン（ポリシ）の策定が必要なんです。

と言うポリシィがRFC な訳であり、それが守られていない状態に置いて
は、資源の共有は出来ない訳ですよね？
＃今回の事例は、資源の共有に失敗していた訳で。

> 　…で、そのポリシのオーサライズが（強制的にも、
> 自発的にも）取れるような「啓蒙」も必要だったりしま
> す。

昔は、the Intetnet に繋ぐ人は（RFC を全部読んでないにしても）そ
れを意識していた訳で、だから、ここまで有用で、有効な資源の共有体
が出来てきた訳だと思います。

> 　最低限度、これだけの認識が管理する立場にないと
> だめです。完璧な実践はとても難しいのも事実ですが。

個人的に、完璧は難しいのは同意します。
しかし、無知なままでいい訳は無いと思います。
公共の場所に出てくる時は、それなりのマナーが必要な様に、資源を共
有するためには、共同体のマナーを知ろうよ。って事です。

> 　…ま、このままならまた事故が別の形で起きるだけで
> しょう。内部 Net なら構いませんが、お願いですから
> 外部 Net にだけは波及させないでくださいね？

僕だったら、警告の後は、ニッパーを・・・:-P

＃実際には、実験室をファイアーウォールの内側に閉じ込めました。
＃会社自体のLAN にファイアーウォールがあるので、実験室は、２重扉
＃の内側です。

---
加藤　丈明
富士通（株）　ＩＡサーバ事業部　保証技術部
Tel:0559-24-7514 Fax:0559-24-6194
内線Tel:7551-3707 Fax:7551-3703
e-mail:kato _at_ qa.psd.cs.fujitsu.co.jp