RFC1560 日本語訳
1560 The MultiProtocol Internet. B. Leiner, Y. Rekhter. December 1993. (Format: TXT=16651 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Leiner
Request for Comments: 1560 USRA
Category: Informational Y. Rekhter
IBM
December 1993
Leinerがコメントのために要求するワーキンググループB.をネットワークでつないでください: 1560年のUSRAカテゴリ: 情報のY.Rekhter IBM1993年12月
The MultiProtocol Internet
MultiProtocolインターネット
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 prepared by the authors on behalf of the Internet Architecture Board (IAB). It is offered by the IAB to stimulate discussion.
このドキュメントはインターネット・アーキテクチャ委員会(IAB)を代表して作者によって準備されました。 それは、議論を刺激するためにIABによって提供されます。
There has recently been considerable discussion on two topics: MultiProtocol approaches in the Internet and the selection of a next generation Internet Protocol. This document suggests a strawman position for goals and approaches for the IETF/IESG/IAB in these areas. It takes the view that these two topics are related, and proposes directions for the IETF/IESG/IAB to pursue.
最近、2つの話題についてのかなりの議論がありました: MultiProtocolは次世代インターネットプロトコルのインターネットと選択でアプローチします。 このドキュメントはこれらの領域のIETF/IESG/IABのための目標とアプローチのためにわら人形位置を示します。 それは、これらの2つの話題が関係づけられるという意見を取って、IETF/IESG/IABが追求する方向を提案します。
In particular, it recommends that the IETF/IESG/IAB should continue to be a force for consensus on a single protocol suite and internet layer protocol. The IETF/IESG/IAB should:
特に、それは、IETF/IESG/IABがずっと単一のプロトコル群とインターネット層のプロトコルに関するコンセンサスのための力であるべきであることを推薦します。 IETF/IESG/IABはそうするべきです:
- maintain its focus on the TCP/IP protocol suite,
- TCP/IPプロトコル群の上の焦点を維持してください。
- work to select a single next-generation internet protocol and
develop mechanisms to aid in transition from the current IPv4,
and
- そして働いて、ただ一つの次世代インターネットプロトコルを選択して、現在のIPv4から変遷で支援するためにメカニズムを開発してください。
- continue to explore mechanisms to interoperate and share
resources with other protocol suites within the Internet.
- インターネットの中で他のプロトコル群とリソースを共同利用して、共有するためにメカニズムを探り続けてください。
1. Introduction
1. 序論
The major purpose of the Internet is to enable ubiquitous communication services between endpoints. In a very real way, the Internet IS inter-enterprise networking. Therefore, the issue of multiprotocol Internet is not just the issue of multiple network layers, but the issue of multiple comparable services implemented
インターネットの主要な目的は終点の間の遍在している通信サービスを可能にすることです。 非常に本当の方法で、インターネットは相互企業ネットワークです。 したがって、「マルチ-プロトコル」インターネットの問題は複数のネットワーク層の問題だけではなく、実装された複数の匹敵するサービスの問題でもあります。
Internet Architecture Board [Page 1] RFC 1560 The MultiProtocol Internet December 1993
インターネット・アーキテクチャ委員会[1ページ]RFC1560MultiProtocolインターネット1993年12月
over different protocols.
異なったプロトコルの上で。
The issue of multiprotocol Internet is multidimensional and should be analyzed with respect to two simultaneous principles:
「マルチ-プロトコル」インターネットの問題は、多次元であり、2つの同時の原則に関して分析されるべきです:
- It is desirable to have a single protocol stack. The community
should try to avoid unconstrained proliferation of various
protocol stacks.
- 単一のプロトコル・スタックを持っているのは望ましいです。 共同体は様々なプロトコル・スタックの自由な増殖を避けようとするべきです。
- In reality there will always be more than one protocol stack.
Presence of multiple network layers is just one of the
corollaries of this observation, as even within a single
protocol stack, forces of evolution of that stack will lead
to periods of multiple protocols. We need to develop
mechanisms that maximize the services that can be provided
across all the protocol stacks (multiprotocol Internet).
- 1個以上のプロトコル・スタックがほんとうはいつもあるでしょう。 複数のネットワーク層の存在はただこの観測の推論の1つです、そのスタックの発展の力が単一のプロトコル・スタックの中でさえ複数のプロトコルの期間まで導くとき。 私たちは、すべてのプロトコル・スタック(「マルチ-プロトコル」インターネット)の向こう側に提供できるサービスを最大にするメカニズムを開発する必要があります。
2. Background and Context
2. バックグラウンドと文脈
2.1. The MultiProtocol Evolutionary Process
2.1. MultiProtocolの進化論のプロセス
In an IAB architectural retreat held in 1991 [Cla91], a dynamic view of the process of multiprotocol integration and accommodation was described, based on the figure below.
1991年[Cla91]に開催されたIABの建築隠れ家で、「マルチ-プロトコル」統合と宿泊設備のプロセスのダイナミックな視点は説明されました、以下の図に基づいて。
--------------- --------------
! ! ! !
! ! ! Interop- !
! Primary ! >>>>>>>>>>> ! erability !>>>>>
! Protocol ! ! ! v
! Suite ! -------------- v
! ! v
! ! v
! ! -------------- v
! ! ! ! v
! ! >>>>>>>>>>> ! Resource ! v
! ! ! Sharing !>>>>v
! ! ! ! v
--------------- -------------- v
^ v
^ -------------- v
^ ! ! v
<<<<<<<! Harmonize !<<<<<<<<<<<<<<<<<<<<
! !
! !
--------------
--------------- -------------- ! ! ! ! ! ! ! Interop Primary、>>>>>>>>>>>!erability!>>>>>!プロトコルv!Suite!-------------- v!v!v!-------------- v!v!>>>>>>>>>>>!Resource v!Sharing!>>>>v!v--------------- -------------- ^対^に-------------- v^!対<<<<<<<!Harmonize!<<<<<<<<<<<<<<<<<<<<。--------------
Figure 1: MultiProtocol Evolution Process
図1: MultiProtocol発展プロセス
Internet Architecture Board [Page 2] RFC 1560 The MultiProtocol Internet December 1993
インターネット・アーキテクチャ委員会[2ページ]RFC1560MultiProtocolインターネット1993年12月
The figure describes the process from the perspective of a community working on a single primary protocol suite (such as the IETF/IESG/IAB working on the TCP/IP protocol suite.) (Note: It must be kept in mind throughout this paper that, while the discussion is oriented from the perspective of the IETF/IESG/IAB and the TCP/IP protocol suite, there is a complementary viewpoint from the perspective of each of the communities whose primary focus is on one of the other protocol suites.) There are other protocol suites (for example, IPX, OSI, SNA). Although the primary emphasis of the community is developing a system based on a single set of protocols (protocol suite), the existence of other protocol suites demands that the community deal with two aspects of multiprotocolism. The first is interoperability between the primary protocol suite and other protocol suites. The second is resource sharing between the primary protocol suite and other protocol suites. Both interoperability and sharing may happen at multiple levels in the protocol suites.
図は単一のプライマリプロトコル群(TCP/IPプロトコル群の上で働いているIETF/IESG/IABなどの)の上で利く共同体の見解からプロセスについて説明します。 (注意: この紙中で議論がIETF/IESG/IABとTCP/IPプロトコル群の見解から適応しますが、焦点が他のプロトコル群の1つにあるそれぞれの共同体の見解からの補足的な観点があるのを覚えておかなければなりません。) 他のプロトコル群(例えば、IPX、OSI、SNA)があります。 共同体の主要な強調は体系をたてることですが、1セットのプロトコル(プロトコル群)に基づく他のプロトコル群の存在は、共同体が「マルチ-プロトコル-主義」の2つの局面に対処するのを要求します。 1番目はプライマリプロトコル群と他のプロトコル群の間の相互運用性です。 2番目はプライマリプロトコル群と他のプロトコル群の間のリソース・シェアリングです。 相互運用性と共有の両方がプロトコル群の複数のレベルで起こるかもしれません。
Achieving interoperability and resource sharing is difficult, and often unanticipated interactions occur. Interoperability can be difficult for reasons such as lack of common semantics. Resource sharing can run into problems due to lack of common operational paradigms. For example, sharing bandwidth on a link may not work effectively if one protocol suite backs off in its demands and the other does not. Interoperability and resource sharing both require cooperation between the developers/users of the different protocol suites. The challenge in this area, then, is to develop mechanisms for interoperability and resource sharing that have minimal negative affect on the primary protocol suite.
相互運用性とリソース・シェアリングを達成するのは難しいです、そして、しばしば思いがけない相互作用は起こります。 相互運用性は一般的な意味論の不足などの理由で難しい場合があります。 リソース・シェアリングは一般的な操作上のパラダイムの不足のため問題を出くわすことができます。例えば、1つのプロトコル群が要求で引き返して、もう片方が力を発揮しないなら、リンクにおける帯域幅を共有するのは力を発揮しないかもしれません。 相互運用性とリソース・シェアリングはともに異なったプロトコル群の開発者/ユーザの間の協力を必要とします。 この領域での挑戦はそして、プライマリプロトコル群の上に最小量の否定的感情を持っている相互運用性とリソース・シェアリングのためにメカニズムを開発することです。
The very attempts to achieve interoperability and resource sharing therefore lead to an attempt to bring the multiple protocol suites into some level of harmonization, even if it is just to simplify the problems of interoperability and sharing. Furthermore, the communications between the communities also leads to a level of harmonization. These processes, together with the normal process of evolution, lead to changes in the primary protocol suite, as well as the other suites.
したがって、相互運用性とリソース・シェアリングを達成するまさしくその試みは何らかのレベルの調和させることに複数のプロトコル群を運び込む試みにつながります、まさしく相互運用性と共有の問題を簡素化するつもりであってもさえ。 その上、また、共同体のコミュニケーションは調和させることのレベルにつながります。 これらのプロセスは発展の正常なプロセスと共にプライマリプロトコル群の変化に通じます、他のスイートと同様に。
Thus, the need for new technologies and the need to accommodate multiple protocols leads to a natural process of diversion. The process of harmonization leads to conversion.
したがって、新技術の必要性と複数のプロトコルに対応する必要性は転換のナチュラル・プロセスにつながります。 調和させることのプロセスは変換に通じます。
While this discussion was oriented around the relation between multiple protocol suites, it can also be applied somewhat to the process of evolution within the primary protocol suite. So, for example, as new technologies develop, multiple approaches for exploiting those technologies will also develop. The process then hopefully leads to a process of harmonization of those different
また、この議論が複数のプロトコル群での関係の周りで向けられていた間、プライマリプロトコル群の中でいくらか発展のプロセスにそれを適用できます。 また、そのように、例えば、新技術が展開するとき、それらの技術を利用するための複数のアプローチが展開するでしょう。 そして、プロセスは希望をいだいて異なったそれらの調和させることのプロセスに通じます。
Internet Architecture Board [Page 3] RFC 1560 The MultiProtocol Internet December 1993
インターネット・アーキテクチャ委員会[3ページ]RFC1560MultiProtocolインターネット1993年12月
approaches.
アプローチ。
2.2. The Basis of the Internet
2.2. インターネットの基礎
The rapid growth of the Internet has resulted from several forces. Some of them are "practical", such as the bundling of TCP/IP with Berkeley Unix and the early decision to base NSFNet on TCP/IP. However, we believe that there is a more fundamental reason for this growth. The Internet (and the TCP/IP protocol suite) were targeted at Inter-Enterprise Networking. Although the availability of TCP/IP on workstations and the desire to have a single environment serve both intra- and inter-enterprise networking led to the use of TCP/IP within organizations, the major contribution of the Internet and TCP/IP was to provide to user communities the ability to communicate with other organizations/communities in a straightforward manner using a set of common and basic services.
インターネットの急速な成長は数個の力から生じました。 それらのいくつかが「実用的です」、バークレーUnixとのTCP/IPのバンドリングやNSFNetをTCP/IPに基礎づけるという早めの決定のように。 しかしながら、私たちは、この成長の、より基本的な理由があると信じています。 インターネット(そして、TCP/IPプロトコル群)はInter-エンタープライズNetworkingをターゲットにしました。 ワークステーションの上のTCP/IPの有用性とただ一つの環境をイントラと相互企業ネットワークの両方に役立たせる願望は組織の中でTCP/IPの使用につながりましたが、インターネットとTCP/IPの主要な貢献は1セットの一般的で基本的なサービスを利用しながら正直な態度で他の組織/共同体とコミュニケートする能力をユーザーコミュニティに提供することでした。
Fundamental to this ability was the fact that the Internet was based on a single, common, virtual network service (IP) with a supporting administrative infrastructure. This allowed a ubiquitous underlying communication infrastructure to develop serving the global community, upon which a set of services could be provided to the user communities. This also allowed for a large market to develop for application services that were built upon the underlying communications.
この能力への基本的はインターネットがサポートの管理インフラストラクチャがある単一の、そして、一般的で、仮想のネットワーク・サービス(IP)に基づいたという事実でした。 これで、遍在している基本的なコミュニケーションインフラストラクチャは、グローバルな共同体(1セットのサービスをユーザーコミュニティに提供できた)に役立ちながら、展開しました。 また、これは、大きな販路が基本的なコミュニケーションで組み込まれたアプリケーション・サービスのために発展するのを許容しました。
An important corollary to having a single common virtual network service available to the end user (open network service) is that the selection of applications becomes the province of the end-user community rather than the intermediate network provider. By having this common underlying infrastructure, user communities are able to select their desired/required application services based on their unique needs, with assurance that the intermediate networking service will support their communication requirements. We believe that this has been of considerable importance in the success of the Internet.
エンドユーザ(オープンネットワークサービス)にとって、利用可能なただ一つの一般的な仮想ネットワークサービスを持っていることへの重要な推論はアプリケーションの品揃えが中間ネットワークプロバイダーよりむしろエンドユーザ社会の州になるということです。 この一般的な基本的なインフラストラクチャを持っていることによって、ユーザーコミュニティは彼らのユニークな必要性に基づく彼らの必要であるか必要なアプリケーション・サービスを選択できます、中間的ネットワークサービスがそれらのコミュニケーション要件をサポートするという保証で。 私たちは、これがインターネットの成功でかなり重要であったと信じています。
In addition to providing network layer services for TCP/IP transport layer and applications, IP may be used to provide network layer services for non-TCP/IP transport layer and applications. Such use is clearly beneficial, since it allows preservation of all the benefits of a single, common, virtual network service (IP), while at the same time widening the set of applications available to the end users.
TCP/IPトランスポート層のためのネットワーク層サービスと利用を提供することに加えて、IPは、非TCP/IPトランスポート層のためのネットワーク層サービスと利用を提供するのに使用されるかもしれません。 そのような使用は明確に有益です、それが同時にエンドユーザにとって、利用可能なアプリケーションのセットを広くしている間、単一の、そして、一般的で、仮想のネットワーク・サービス(IP)のすべての恩恵の保存を許すので。
3. Directions for Multiprotocolism
3. Multiprotocolismのための方向
Over the past few years, with the increasing scope of the Internet, has come an increasing need to develop mechanisms for accommodating other protocol suites. Most techniques have fallen into the regime of
インターネットの増加する範囲がある過去数年間にわたって、他のプロトコル群を収容するためにメカニズムを開発する増加する必要性は来ています。 テクニックが政権に落下した大部分
Internet Architecture Board [Page 4] RFC 1560 The MultiProtocol Internet December 1993
インターネット・アーキテクチャ委員会[4ページ]RFC1560MultiProtocolインターネット1993年12月
either interoperability (techniques that allow for communications between users of different protocol suites) or resource sharing (allowing common resources such as links or switches to jointly service communities using different protocol suites.) It must be noted that such techniques have been quite limited, with interoperability happening primarily at application layers and resource sharing happening to limited extent.
相互運用性(異なったプロトコル群のユーザのコミュニケーションを考慮するテクニック)かリソース・シェアリング(異なったプロトコル群を使用することで共同で共同体にサービスを提供するためにリンクかスイッチなどの一般的なリソースを許容します。)のどちらか そのようなテクニックがかなり限られていることに注意しなければなりません、相互運用性が主として応用層で起こっていて、リソース・シェアリングが限られた範囲に起こっていて。
This need to deal with multiple protocol suites has led to discussion within the community concerning the role of the IETF/IESG/IAB regarding the TCP/IP protocol suite versus other protocol suites. Questions are asked as to whether the TCP/IP protocol suite is the sole domain of interest of the IETF/IESG/IAB or if the community needs also to deal with other protocol suites, and if so, in what manner, given these other protocol suites have their own communities of interest pursuing their development and evolution.
複数のプロトコル群に対処するこの必要性は共同体の中でIETF/IESG/IABの役割に関してTCP/IPプロトコル群対他のプロトコル群に関して議論につながりました。 TCP/IPプロトコル群がIETF/IESG/IABで興味がある唯一のドメインであるかどうかかそれとも共同体が、また、他のプロトコル群に対処する必要があるかどうかに関して質問が行われます、そして、そうだとすれば、どんな方法で、考えて、それら自身の興味がある共同体はこれらの他のプロトコル群でそれらの開発と発展を追求するか。
The answer to this question lies in understanding the role of the IETF/IESG/IAB with respect to the process described above (Figure 1). The continued success of the Internet relies on a continued strong force for convergence, making sure that the primary protocol suite (TCP/IP) is successful through an evolutionary process in accommodating both the changing user requirements and emerging technologies.
(図1)を超えて説明されたプロセスに関してIETF/IESG/IABの役割を理解するのにおいてこの質問の答えがあります。 インターネットの継続的な成功は集合のための継続的な強い力を当てにします、プライマリプロトコル群(TCP/IP)が進化論のプロセスを通して両方の変化ユーザ要件を収容して、技術として現れるのに成功しているのを確実にして。
Since this process requires a continued effort to accommodate other protocol suites within the overall Internet, efforts at interoperability and sharing must continue. Thus, we can summarize the directions for the IETF/IESG/IAB as two-fold:
このプロセスが総合的なインターネットの中に他のプロトコル群を収容するために継続的な取り組みを必要とするので、相互運用性と共有における取り組みは続かなければなりません。 したがって、私たちはIETF/IESG/IABのために二面として方向をまとめることができます:
- Have as a primary focus the evolution of the primary protocol
suite (TCP/IP), acting as a force for convergence at all times
towards a single set of protocols, and
- そして焦点としてプライマリプロトコル群(TCP/IP)の発展を持ってください、集合のための力としていつも1セットのプロトコルに向かって機能して。
- Make provision for other protocol suites within the global
Internet through mechanisms for interoperability and resource
sharing.
- 相互運用性とリソース・シェアリングのためにメカニズムを通して世界的なインターネットの中に他のプロトコル群に備えてください。
4. Next Generation Internet Protocol
4. 次世代インターネットプロトコル
The principles described above for multiprotocolism can also be applied to the discussions regarding the next generation internet protocol. Currently, there are several candidates for IPng, which raises the question of how to deal with multiple protocols at that level. We note that even if just one is selected, there is an issue involved in transitioning from IPv4 to IPng.
また、「マルチ-プロトコル-主義」のために上で説明された原則は次世代インターネットプロトコルについての議論に適用できます。 現在、数人の候補がIPngを支持しています。IPngはそのレベルでどう複数のプロトコルに対処するかに関する疑問を挙げます。 私たちは、ちょうど1つが選択されても、IPv4からIPngに移行するのにかかわる問題があることに注意します。
Internet Architecture Board [Page 5] RFC 1560 The MultiProtocol Internet December 1993
インターネット・アーキテクチャ委員会[5ページ]RFC1560MultiProtocolインターネット1993年12月
Selection of a single Internet protocol is not the only way of dealing with this issue. Even if a layer of ubiquity is required (such as that provided currently by IP), we might consider providing ubiquity at a different layer. For example, we could imagine having a common transport protocol running over multiple internet protocols. We also could imagine achieving interoperability by use of common application services (such as directory services) running over diverse communication services (both transport and network layers).
ただ一つのインターネットプロトコルの選択は唯一の道にどんなこの問題に対処しないものです。 偏在の層が必要であっても(現在、IPによって提供されたそれなどの)、私たちは、異なった層で偏在を提供すると考えるかもしれません。 例えば、私たちは、複数のインターネットプロトコルをひく一般的なトランスポート・プロトコルを持っていると想像できました。 また、私たちは、さまざまの通信サービス(輸送とネットワーク層の両方)をひきながら一般的なアプリケーション・サービス(ディレクトリサービスなどの)の使用で相互運用性を達成すると想像できました。
These alternatives do not provide the considerable benefits of a single internet protocol, and therefore would be undesirable. Having a single internet protocol provides a common communication infrastructure across the various networks, thereby achieving the following:
これらの代替手段は、ただ一つのインターネットプロトコルのかなりの利益を提供しないで、したがって、望ましくないでしょう。 ただ一つのインターネットプロトコルを持っていると一般的なコミュニケーションインフラストラクチャは様々なネットワークの向こう側に提供されて、その結果、以下を達成します:
- Communities of end users can select their desired applications,
independent of the technologies used to support the intermediate
networks.
- エンドユーザの共同体は中間ネットワークをサポートするのに使用される技術の如何にかかわらず彼らの必要なアプリケーションを選択できます。
- The common underlying infrastructure provides a common
marketplace upon which application developers can create new and
exciting applications. Installation of these applications does
not require end users to select a corresponding network protocol
(although some advanced applications may require enhancements,
such as high-bandwidth approaches).
- 一般的な基本的なインフラストラクチャはアプリケーション開発者が新しくておもしろいアプリケーションを作成できる一般的な市場を提供します。 これらのアプリケーションのインストールは、エンドユーザが対応するネットワーク・プロトコルを選択するのを必要としません(いくつかの高度なアプリケーションが高帯域アプローチなどの増進を必要とするかもしれませんが)。
Thus, the community (IETF/IESG/IAB) should continue to act as a force for convergence by selecting a single next generation Internet protocol and developing methods to ease the transition from IPv4 to IPng. Specifically, at the applications layer, it is desirable to promote different approaches and "let the marketplace decide." However, it is unacceptable to treat the internet protocol layer in the same way.
したがって、共同体(IETF/IESG/IAB)は、集合のための力としてただ一つの次世代インターネットプロトコルを選択して、IPv4からIPngまでの変遷を緩和するメソッドを開発することによって機能し続けるべきです。 明確に、アプリケーション層では、異なるアプローチを促進して、「市場は決めます」は望ましいです。 しかしながら、同様に、インターネットプロトコル層を扱うのは容認できません。
5. Conclusion
5. 結論
Historically, the IETF/IESG/IAB has acted as a strong force for the development of the Internet by acting as a force for convergence on and evolution of a single primary protocol suite. This has served the community well, and this approach should be continued for the future. In particular, the IETF/IESG/IAB should:
歴史的に、IETF/IESG/IABは集合のための力としてオンに機能するのによるインターネットの開発と単一のプライマリプロトコル群の発展のための強い力として機能しました。 これは共同体によく役立ちました、そして、このアプローチは未来に続けられるべきです。 特に、IETF/IESG/IABはそうするべきです:
- maintain its focus on the TCP/IP protocol suite,
- TCP/IPプロトコル群の上の焦点を維持してください。
- work to select a single next-generation internet protocol and
develop mechanisms to aid in transition from the current IPv4,
and
- そして働いて、ただ一つの次世代インターネットプロトコルを選択して、現在のIPv4から変遷で支援するためにメカニズムを開発してください。
Internet Architecture Board [Page 6] RFC 1560 The MultiProtocol Internet December 1993
インターネット・アーキテクチャ委員会[6ページ]RFC1560MultiProtocolインターネット1993年12月
- continue to explore mechanisms to interoperate and share
resources with other protocol suites within the Internet.
- インターネットの中で他のプロトコル群とリソースを共同利用して、共有するためにメカニズムを探り続けてください。
6. References
6. 参照
[Cla91] Clark, D., Chapin, L., Cerf, V., Braden, R., and
R. Hobby, "Towards the Future Internet Architecture",
RFC 1287, MIT, BBN, CNRI, ISI, UC Davis, December 1991.
[Cla91] クラークとD.とチェーピンとL.とサーフとV.とブレーデン、R.とR.趣味、「将来のインターネットアーキテクチャ」、RFC1287、MIT、BBN、CNRI、ISI、UCデイヴィス(1991年12月)。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
Dr. Barry M. Leiner Senior Scientist Universities Space Research Association 625 Ellis Street, Suite 205 Mountain View, CA 94043
Barry M.Leiner年上の科学者大学宇宙研究協会625エリス通り博士、Suite205マウンテンビュー、カリフォルニア 94043
Phone: (415) 390-0317 Fax: (415) 390-0318 EMail: leiner@nsipo.nasa.gov
以下に電話をしてください。 (415) 390-0317 Fax: (415) 390-0318 メールしてください: leiner@nsipo.nasa.gov
Yakov Rekhter T.J. Watson Research Center, IBM Corp. P.O. Box 218, Yorktown Heights, NY 10598
ニューヨーク ヤコフRekhter T.J.ワトソン研究所、IBM社の私書箱218、ヨークタウンの高さ、10598
Phone: (914) 945-3896 EMail: yakov@watson.ibm.com
以下に電話をしてください。 (914) 945-3896 メールしてください: yakov@watson.ibm.com
Internet Architecture Board [Page 7]
インターネット・アーキテクチャ委員会[7ページ]
一覧
スポンサーリンク
