RFC1670 日本語訳

Network Working Group                                        D. Heagerty
Request for Comments: 1670                                          CERN
Category: Informational                                      August 1994

Heagertyがコメントのために要求するワーキンググループD.をネットワークでつないでください: 1670年のCERNカテゴリ: 情報の1994年8月

                Input to IPng Engineering Considerations

IPng工学問題に入力されます。

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This document was submitted to the IETF IPng area in response to RFC
   1550.  Publication of this document does not imply acceptance by the
   IPng area of any ideas expressed within.  Comments should be
   submitted to the big-internet@munnari.oz.au mailing list.

RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。

Summary

概要

   This white paper expresses some personal opinions on IPng engineering
   considerations, based on experience with DECnet Phase V transition.
   It suggests breaking down the IPng decisions and transition tasks
   into smaller parts so they can be tackled early by the relevant
   experts.

この白書はDECnet Phase V変遷の経験に基づいてIPng工学問題に関するいくつかの個人的な見解を述べます。 それは、関連専門家が早くそれらに取り組むことができるようにIPng決定と変遷タスクをより小さい部分に分解するのを示します。

Timescales

スケール

   In order to allow key decisions to be taken early, I would like to
   see IPng decisions and timescales broken down into into smaller
   parts, for example:

早く取られるという重要な決定を許容するために、例えば、IPng決定とスケールが、より小さい部分に分解されるのを見たいと思います:

    - address structure and allocation mechanism
    - name service changes
    - host software and programming interface changes
    - routing protocol changes

- アドレス構造と配分メカニズム--名前サービス変化--ホストソフトウェアとプログラミングインターフェース変化--ルーティング・プロトコル変化

   Although interrelated, not all details need to be defined by the same
   date. Identify which decisions will be hard to change and which can
   be allowed to evolve. All changes should be worked on in parallel,
   but the above list indicates a feeling for urgency of a decision.
   Our experience has been that administrative changes (as may be
   required for addressing changes) need the greatest elapse time for
   implementation, whereas routing protocol changes need the least.

相関的ですが、すべての詳細が、同じ日付までに定義される必要があるというわけではありません。 どの決定が変えにくいようになるだろうか、そして、どれが発展できるか特定してください。 すべての変化が平行に扱われるべきですが、上記のリストは決定の緊急に関する感じを示します。 私たちの経験は管理変化が最もすばらしいのを必要とするという(変化を扱うのに必要であるかもしれないように)ことです。実装のために調節しますが、変化が最も最少に必要とするプロトコルを発送しますが、経過してください。

Heagerty                                                        [Page 1]

RFC 1670        Input to IPng Engineering Considerations     August 1994

工学問題1994年8月にIPngに入力されたHeagerty[1ページ]RFC1670

   I would like to see an early decision on address structure and enough
   information for service managers to start planning their transition.
   Some hosts will never be upgraded and will need to be phased out or
   configured with reduced connectivity. A lead time of 10 years (or
   more) will help to take good long term technical decisions and ease
   financial and organisational constraints.

サービス・マネージャが彼らの変遷を計画し始めるためにはアドレス構造と十分な情報の早めの決定を見たいと思います。 何人かのホストが、決してアップグレードしないで、段階的に廃止されるか、または減少している接続性で構成される必要があるでしょう。 10年(さらに)の先行時間は、良い長期技術的判断を取って、財政的、そして、organisational規制を緩和するのを助けるでしょう。

Transition and deployment

変遷と展開

   Transition requires intimate knowledge of the environment (financial,
   political as well as technical). The task needs to be broken down so
   that service managers close to their clients can take decisions and
   make them happen.

変遷は環境(財政的で、政治上の、そして、技術的な)に関する詳細な知識を必要とします。 タスクは、彼らのクライアントの近くのサービス・マネージャが、決定を取って、それらが起こるのをすることができるように砕ける必要があります。

   Let the service managers adapt the solutions for their environment by
   providing them with a transition toolbox and scenarios of their uses
   based on real examples. Clearly state the merits and limitations of
   different transition strategies.

サービス・マネージャに彼らの環境のために本当の例に基づく彼らの用途の変遷道具箱とシナリオをそれらに提供することによって、ソリューションを適合させてください。 明確に異なった変遷戦略の長所と限界を述べてください。

   Provide for transition autonomy. Let systems and sites transition at
   different times, as convenient for them.

変遷自治に備えてください。 いろいろな時間にそれらに便利であるとしてシステムとサイト変遷をさせてください。

   Identify what software needs to be changed and keep an up-to-date
   list.

どんなソフトウェアが変えられて、最新のリストを保つ必要であるか特定してください。

   Identify what is essential to have in place so that service managers
   can transition at their own pace.

サービス・マネージャはそれら自身のペースでの変遷を不可欠であることができることで、何が適所に持つのに不可欠であるか特定してください。

   Allow for a feedback loop to improve software based on experience.

フィードバックループが経験に基づくソフトウェアを改良するのを許容してください。

Configuration, Administration, Operation

構成、政権、操作

   We run IP on a wide range of equipment and operating systems.  We
   need an easy way to (re-)configure all our IP capable systems.  The
   systems need to be sent their IP parameters (e.g., their address,
   address of their default router, address of their local name servers)
   and we need to obtain data from the system (e.g., contact information
   for owner, location and name of system). We also need an easy way to
   update DNS.

私たちのすべてのIPのできるシステムを構成してください。私たちが簡単な道を必要とするさまざまな設備とオペレーティングシステムにIPを経営している、(再、)、システムは、それらのIPパラメタ(例えば、それらのアドレス、それらのデフォルトルータのアドレス、それらの地方名サーバのアドレス)が送られる必要があって、私たちは、システム(例えば、システムの所有者、位置、および名前のための問い合わせ先)からデータを得る必要があります。 また、私たちはDNSをアップデートする簡単な方法を必要とします。

   In our environment systems are regularly moved between buildings and
   we therefore find the tight coupling of IP address to physical subnet
   over restrictive. Automatic configuration could help overcome this.

中に、私たちの環境システムは定期的にビルの間に動かされます、そして、したがって、私たちは限定語に関してIPアドレスの密結合を物理的なサブネットに見つけます。 自動構成は、これに打ち勝つのを助けるかもしれません。

   We would like to efficiently load balance users of various IP based
   services (e.g., telnet, ftp, locally written applications) across a
   number of systems.

多くのシステムの向こう側に効率的に色々とIPのベースのサービス(例えば、telnet、ftp、局所的に書かれたアプリケーション)のバランスユーザを積み込みたいと思います。

Heagerty                                                        [Page 2]

RFC 1670        Input to IPng Engineering Considerations     August 1994

工学問題1994年8月にIPngに入力されたHeagerty[2ページ]RFC1670

   The ability to break down addresses and routing into several levels
   of hierarchy is important to allow the delegation of network
   management into subdomains. As the network grows so does the desire
   to increase the number of levels of hierarchy.

いくつかのレベルの階層構造にアドレスとルーティングを分解する能力は、ネットワークマネージメントの委譲をサブドメインに許容するために重要です。 ネットワークが成長するので、階層構造のレベルの数を増強する願望もそうします。

Disclaimer and acknowledgments

注意書きと承認

   This is a personal view and does not necessarily represent that of my
   employer. I have benefited from many transition discussions with my
   colleagues at CERN, other High Energy Physics DECnet managers and
   Digital Equipment Corporation engineers.

これは、個人的な視点であり、必ず私の雇い主のものを表すというわけではありません。 私はCERNの私の同僚、他のHigh Energy Physics DECnetマネージャ、およびディジタルイクイップメント社の技術者との多くの変遷議論の利益を得ました。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Author's Address

作者のアドレス

   Denise Heagerty
   Communications Systems Group
   Computing and Networks Division
   CERN
   European Laboratory for Particle Physics
   1211 Geneva 23, Switzerland

デニーズHeagerty通信網のグループコンピューティングとネットワーク事業部CERN欧州原子核共同研究機構1211ジュネーブ23、スイス

   Phone:  +41 22 767-4975
   Fax:    +41 22 767-7155
   EMail: denise@dxcoms.cern.ch

以下に電話をしてください。 +41 22 767-4975Fax: +41 22 767-7155 メールしてください: denise@dxcoms.cern.ch

Heagerty                                                        [Page 3]

Heagerty[3ページ]