RFC873 日本語訳

---------

---------

     < INC-PROJECT, MAP-ILLUSION.NLS.8, >, 12-Aug-83 11:44 AMW ;;;;

<INC-プロジェクト、地図-ILLUSION.NLS.8、>、1983年8月12日11時44分AMW。

     RFC 873                                            September 1982
                                                                M82-49

RFC873 1982年9月のM82-49

                      THE ILLUSION OF VENDOR SUPPORT

業者サポートの幻想

                              M.A. PADLIPSKY
                           THE MITRE CORPORATION
                          Bedford, Massachusetts

M.A.PADLIPSKY斜め継ぎ会社のベッドフォード(マサチューセッツ)

                                 ABSTRACT

要約

          The sometimes-held position that "vendor supplied"
     intercomputer networking protocols based upon the International
     Standards Organization's Reference Model for Open System
     Interconnection are worth waiting for, in particular in
     preference to protocols based upon the ARPANET Reference Model
     (ARM), is shown to be fallacious.

オープンSystem Interconnectionのための国際Standards OrganizationのReference Modelに基づく「供給された業者」intercomputerネットワーク・プロトコルは待つ特にアルパネットReference Modelに基づくプロトコルに優先して価値があるという時々保持された位置(ARM)は、当てにならなくなるように示されます。

          The paper is a companion piece to M82-47, M82-48, M82-50,
     and M82-51.

紙はM82-47、M82-48、M82-50、およびM82-51への姉妹編です。

                                     i

i

                      THE ILLUSION OF VENDOR SUPPORT

業者サポートの幻想

                              M. A. Padlipsky

M.A.Padlipsky

     Introduction

序論

          Even one or two members of the DoD Protocol Standards
     Technical Panel join with many others (including, apparently,
     some members of the DoD Protocol Standards Steering Group, and
     clearly, somebody at the GAO) in expressing a desire to "go with
     vendor-supported intercomputer networking protocols instead of
     using our own."  The author's view of the implications of this
     desire should be clear from the title of this paper.  What
     evidence, then, is there to so stigmatize what is clearly a
     well-meant desire to save the Government money?

DoDプロトコルStandards Technical Panelの1か2人のメンバーさえ「私たち自身のを使用することの代わりに業者によって支持されたintercomputerネットワーク・プロトコルを伴う」願望を述べる際に多くの他のもの(明らかに、DoDプロトコルStandards Steering Groupの何人かのメンバー、および明確にGAOのだれかを含んでいます)と一緒になります。 作者のこの願望の含意の視点はこの紙のタイトルから明確であるはずです。 そして、したがって、明確に政府のお金を貯める善意から出ている願望であることに汚名をきせるために、どんな証拠がありますか?

     Scope

範囲

          First, we must consider what is meant by "vendor-supported
     protocols."  It can't be just X.25, because that only gets you
     through the network layer whether you're appealing to the
     International Standards Organization's widely-publicized
     Reference Model for Open System Interconnection (ISORM) or to the
     unfortunately rather tacit reference model (ARM) to which the
     ARPANET protocols (e.g., TCP, IP, Telnet, FTP) were designed.  It
     also can't be just X.25 and X.28/X.29 (even with X.75 tossed in
     to handle "internetting" and X.121 for addressing) because: 1.
     They don't serve as a protocol suite for resource sharing (also
     known as OSI), but rather only allow for remote access [1]. 2.
     They (coming as they do from the Consultative Committee on
     International Telegraphy and Telephony--and including one or two
     other protocols, in reality) don't even constitute the full
     protocol suite being worked on by the U. S. National Bureau of
     Standards, much less the somewhat different suite being evolved
     by ISO.  So it must be a suite from NBS or ISO, and for present
     purposes we needn't differentiate between them as their Reference
     Models are close enough to be shorthanded as the ISORM.

まず最初に、私たちは、何が「業者によって支持されたプロトコル」によって意味されるかを考えなければなりません。 それは単なるX.25であるはずがありません、あなたがオープンSystem Interconnection(ISORM)か残念ながらかなり暗黙の規範モデル(ARM)へのアルパネットプロトコル(例えば、TCP、IP、Telnet、FTP)が設計された国際Standards Organizationの広くピーアールされたReference Modelに求めているか否かに関係なく、それがネットワーク層であなたを手に入れるだけであるので。 また、それが単なるX.25とX.28/X.29であるはずがない(アドレシングに、「internettingハンドル」とX.121と同等の中の投げられていたX.75で)、: 1. それらはリソース・シェアリング(また、OSIとして、知られている)のためのプロトコル群として機能しませんが、むしろ単に遠隔アクセス[1]を考慮してください。 2. 彼ら(他の1か2つのプロトコルを含んでいて、国際TelegraphyとTelephonyの上のConsultative Committeeから来るとき、来ますほんとうは、)はU.S.規格基準局が働かせる、完全なプロトコル群、ましてISOによって発展されるいくらか異なったスイートを設立さえしません。 それで、それらのReference ModelsがISORMとして人手不足であることができるくらい近くにあって、それは、NBSかISOからのスイートであり、私たちが必要としない現在の目的のためにそれらを区別しなければなりません。

     Timeliness

タイムリー

          Realizing that we're being asked to consider an
     ISORM-related protocol suite as what the vendors are expected to
     support has one immediate consequence which in some sense can be
     considered to dominate all of the other points to be raised:
     That is, the DoD procurement process entails quite long lead
     times.  Yet the ISORM suite is by no means complete at present.
     Without prejudice to its

私たちが、ISORM関連のプロトコル群が業者が支持すると予想されるものであるとみなすように頼まれているとわかるのにおいて、何らかの意味で上げられるために優に他のポイントを支配すると考えることができる1つの即座の結果があります: すなわち、DoD調達の過程はかなり長い先行時間を伴います。 しかし、ISORMスイートは現在のところ、決して完全ではありません。 偏見、それ

                                     1
     RFC 873                                            September 1982

1RFC873の1982年9月

     merits or demerits, only X.25 (as levels 1-3, and with some
     ambiguity as to what level X.75 belongs at) is as yet firmly in
     the ISORM suite (which it will be convenient to refer to as
     "ISORMS"), and there is even some doubt as to how firmly they're
     there.  (E.g., a British observer at a recent PSTP meeting
     assured the author that "We in the U.K. don't believe X.25 is
     officially part of the ISORM.") There are proposals which have
     been circulating for some time at Level 4, and less far along
     through the international (or even national, remembering NBS)
     standardization process, ones at Level(s) 5-7.  It must be noted
     that:  1.  These are by and large "paper protocols" (that is,
     they have not been subjected to the test of actual use).  2.
     Even ISO and NBS's warmest supporters acknowledge that the
     standardization process "takes years."  So if the DoD is to avoid
     buying what might turn out to be a series of pigs in a series of
     pokes, it can't wait for the ISORMS.

長所か欠点、X.25(レベル1-3、およびレベルX.75が何で属するかに関する何らかのあいまいさがある)しかスイートにもかかわらず、しっかりISORMスイート(「ISORMS」を呼ぶのが便利である)にありません、そして、彼らがそこにどれくらいしっかりいるかに関して何らかの疑問さえあります。 (「イギリスの私たちは、X.25が公式にISORMの一部であると信じていません」と、例えば、最近のPSTPミーティングにおけるイギリス人のオブザーバは作者に知らせました。) 国際的な(または、国家の、そして、覚えていているNBSさえ)標準化過程(Level(s)5-7のもの)でしばらくLevel4において遠くにずっと循環している提案があります。 以下のことに注意しなければなりません。 1. これらは概してそうです。「紙のプロトコル。」(すなわち、それらは実際の使用のテストにかけられていません) 2. ISOとNBSの最も暖かい支持者さえ、標準化過程が「何年もかかる」と認めます。 それで、DoDが、一連のつつきで一連のブタであると判明するかもしれないものを買うのを避けるつもりであるなら、それはISORMSを待つことができません。

          On the other side of the coin, the DoD is letting
     intercomputer networking contracts right now.  And, right now,
     there does exist a suite of protocols designed to the ARPANET
     Reference Model (ARMS, with no pun intended).  Implementations of
     the ARMS already exist for a number of operating systems already
     in use in the DoD.  Now, it is not argued that the ARMS protocols
     come "for free" in upcoming acquisitions (contractors fuss about
     the style of the available specifications, system maintainers
     fear incursions of non-vendor supplied code into operating
     systems, and so on), but it is unarguable that the ARMS can be
     procured significantly more rapidly than the ISORMS.  (It is also
     unarguable that those who speak of their unwillingness to see the
     DoD "develop new protocols rather than employ international
     standards" haven't done their homework; we're not talking about
     new protocols in the ARMS, we're talking about protocols that
     have been in real use for years.)

その一方で、DoDはたった今、intercomputerネットワーク契約をさせています。 そして、アルパネットReference Model(だじゃれが全く意図していないARMS)に設計されたひとそろいのプロトコルはたった今、存在します。 ARMSの実現は既に使用中の多くのオペレーティングシステムのためにDoDに既に存在しています。 現在、ARMSプロトコルが「ただで」今度の獲得で来る(契約者は利用可能な仕様、非業者の侵入がコードをオペレーティングシステムに供給したというシステム維持装置の恐れなどのスタイルに関して大騒ぎする)と主張されませんが、ISORMSより急速にARMSをかなり調達できるのは議論の余地がありません。(私たちは、本当に長年使用中であるプロトコルに関してまた、DoDが「世界規格を使うよりむしろ新しいプロトコルを開発すること」を確認するためにそれらの気がすすまないことについて話す人が宿題していないのも、議論の余地がありません; ARMSの新しいプロトコルに関して話していないと話しています。)

     Quality of Support

サポートの品質

          The timeliness argument can lead to a counterargument that
     the ISORMS is "worth waiting for," though, so we're not done yet.
     Let's look further at what "vendor support" means.  Clearly, the
     proponents of the position expect that vendors' implementations
     of protocols will be in conformance with the Standards for those
     protocols.  Given the nature of these specifications, though,
     what can we infer about the quality of support we can expect from
     the vendors?

タイムリー議論はもっとも私たちがまだ完了していなくて、ISORMS「待つ価値がある」反論につながることができます。 「業者サポート」が意味することでは、遠くまで探しに行きましょう。 明確に、位置の提案者は、それらのプロトコルのためのStandardsとの順応には業者のプロトコルの実現があると予想します。 もっとも、これらの仕様の本質を与える場合、私たちは私たちが業者から予想できるサポートの品質に関して何を推論できますか?

          There are two problem areas immediately apparent:
     ambiguities and options.  Let's take ambiguities first.  The
     following are some of the questions raised by knowledgable
     observers about the present state of the ISORMS:

2つのすぐに明らかな問題領域があります: あいまいさとオプション。 最初に、あいまいさを取りましょう。 ↓これはISORMSの現状に関して博識な観察者によって引き起こされた疑問のいくつかです:

                                     2
     RFC 873                                            September 1982

2 RFC873 1982年9月

          1.   Can an X.25 comm subnet offer alternate routing?  (The
               answer depends on whether "DCE's" are expected to
               follow X.25 between themselves.  The situation is
               further complicated by the fact that some ISORM
               advocates don't even include the Data Communication
               Elements in their depictions of the Model; this leads
               to the metaphorical question* "Are there parking
               garages between the highrises?")  If you can conform to
               X.25 and not offer alternate routing--which certainly
               appears to be consistent with the spec, and might even
               be construed as required by it--the DoD's inherent
               interest in "survivability" cannot be served by you.

1. X.25 commサブネットは迂回中継を提供できますか? (答えは「DCEのもの」が自分たちの間でX.25に続くと予想されるかどうかによります。 何人かのISORM支持者が彼らのModelの描写でData Communication Elementsを入れてさえいないという事実によって状況はさらに複雑にされます。 これが比喩的な質問*に通じる、「そこに車庫を駐車している、highrisesするか、」) X.25に従って、迂回中継を提供できないなら(どれが、確かに、仕様と一致しているように見えて、必要に応じてそれによって解釈さえされるかもしれないか)、あなたは「生存性」へのDoDの固有の関心に勤めることができません。

          2.   Can an X.75 internet offer alternate gatewaying?  (The
               answer is almost surely no, unless the X.75 spec is
               re-written.)  If not, again the DoD's interest is not
               served.

2. X.75インターネットは交互のgatewayingを提供できますか? (X.75仕様が書き直されない場合、答えはほぼ確実にノーです。) そうでなければ、再びDoDの関心は役立たれていません。

          3.   Does "Expedited Data" have semantics with regard to the
               L4-L5/L7 interface?  (Not as I read the spec, by the
               way.) If not, the ISORMS lacks the ability to convey an
               "Out-of-Band-Signal" to an Application protocol.  (This
               leads to the metaphorical question, "What good is an
               SST if there's nobody on duty at the Customs Shed?")

3. 「速められたデータ」には、L4-L5/L7インタフェースに関して意味論がありますか? (どんな私のようにも、方法で仕様を読まないでください。) そうでなければ、ISORMSは「バンド信号の外」をApplicationプロトコルまで運ぶ能力を欠いています。 (これは比喩的な質問、「税関Shedで勤務中であることのだれ一人がいなければ、SSTはどんな利益ですか?」に導きます)

          4.   Must all layers be traversed on each transmission?
               (There are rumors of a new ISORM "null-layer" concept;
               it's not in the last version I looked at, however, and
               apparently the answer is yes at present.)  If so, the
               DoD's inherent interest in efficiency/timeliness cannot
               be served.  (This leads to the metaphorical question,
               "Are there elevators inside the highrises, or just
               staircases?")

4. 各トランスミッションのときにすべての層を横断しなければなりませんか? (新しいISORM「ヌル層」概念の噂があります; しかしながら、それは私が見た最後のバージョンになくて、現在のところ、明らかに、答えははいです。) そうだとすれば、効率/タイムリーへのDoDの固有の関心に役立つことができません。 (これが比喩的な質問に通じる、「エレベーターが中にある、highrisesする、または、単に階段?、」、)

          5.   Can an implementation be in conformance with the ISORM
               and yet flout the prescription that "N-entities must
               communicate with each other by means of N-1 entities"?
               (Not as I read the spec.)  If not, again
               implementations must be inefficient, because the
               prescription represents an inappropriate legislation of
               implementation detail which can only lead to
               inefficient implementations.

5. 実現は、ISORMとの順応にはありますが、「N-実体はN-1実体によって互いとコミュニケートしなければならない」処方箋を侮辱できますか? (どんな私のようにも、仕様を読まないでください。) そうでなければ、一方、実現は効率が悪くなければなりません、処方箋が効率の悪い実現につながることができるだけである実現の詳細の不適当な法律を表すので。

     _______________
     *  This and other metaphorical questions are dealt with at
        greater length in reference [2].

_______________ * これと他の比喩的な質問は参照[2]で、より大きい長さで対処されています。

                                     3
     RFC 873                                            September 1982

3 RFC873 1982年9月

          6.   Is each layer one protocol or many?  (The point quoted
               in 5 would seem to imply the latter, but many ISORM
               advocates claim it's the former except for L1 and L7.)
               If each layer is a "monolith", the DoD's interest is
               not served because there are many circumstances in
               which applications of interest require different L1-3
               and L4 protocols in particular, and almost surely
               different L5 and L6 protocols.  (Areas of concern:
               Packetized Speech, Packet Radio, etc.)

6. 各層は、1つのプロトコルかそれとも多くですか? (5で引用されたポイントは後者を含意するように思えるでしょうが、多くのISORM支持者が、それがL1とL7以外の前者であると主張します。) 各層が「モノリス」であるなら、特定の、そして、ほぼ確実に異なったL5とL6プロトコルには興味深いアプリケーションが異なったL1-3とL4プロトコルを必要とする多くの事情があるので、DoDの関心は役立たれていません。 (関心の領域: Packetized Speech、Packet Radioなど)

          The upshot of these ambiguities (and we haven't exhausted
     the subject) is that different vendors could easily offer
     ISORMS's in good faith which didn't interoperate "off-the-shelf".
     Granted, they could almost certainly be fixed, but not cheaply.
     (It is also interesting to note that a recent ANSI X3T5 meeting
     decided to vote against acceptance of the ISORM as a
     standard--while endorsing it as valuable descriptively--because
     of that standards committee's realization of just the point we
     are making here:  that requiring contractual compliance with a
     Reference Model can only be desirable if the Reference Model were
     articulated with utter--and probably humanly
     unattainable--precision.)

これらのあいまいさ(私たちで、対象はくたくたになっていない)の結果は異なった業者が容易に誠実にISORMSのものを提供できたということです(「すぐ入手できること」を共同利用しませんでした)。 与えて、それらはほぼ確実に修理されましたが、安く修理できませんでした。 (それは、また、最近のANSI X3T5ミーティングが、その規格委員会のReference Modelと共に全くで文節に分けられた場合にだけReference Modelへの契約上のコンプライアンスを必要とするのが望ましい場合があるというちょうど私たちがここで指摘しているポイントの実現のために貴重であるとして描写的にそれについて宣伝している間規格としてISORMの承認に反対投票すると決めたことに注意するためにおもしろくて、たぶん人間的に達成不能です--精度)

          The area of options is also a source for concern over future
     interoperability of ISORMS implementations from different
     vendors. There's no need to go into detail because the broad
     concern borders on the obvious:  What happens when Vendor A's
     implementations rely on the presence of an optional feature that
     Vendor B's implementations don't choose to supply?  Somebody
     winds up paying--and it's unlikely to be either Vendor.

また、オプションの領域は関心のための異なった業者からのISORMS実現の将来の相互運用性の上のソースです。 広い関心が明白に近似するので詳細に立ち入る必要は全くありません: Vendor Aの実現がVendorビーズの実現が提供するのを選ばないオプション機能の存在を当てにするとき、何が起こりますか? だれかが結局支払います、そして、それはVendorでありそうにないこと。

          On the other side of the coin, the ARMS designers were all
     colleagues who met together frequently to resolve ambiguities and
     refine optionality in common.  Not that the ARMS protocols are
     held to be flawless, but they're much further along than the
     ISORMS.

その一方で、ARMSデザイナーは、あいまいさを取り除くために頻繁に顔合わせした同僚であり、一般的でoptionalityを精製します。 ARMSプロトコルが疵がないのが保持されるというわけではありませんが、それらはISORMSよりはるかにずっと遠いです。

          To conclude this section, then, there are grounds to suspect
     that the quality of vendor support will be low unless the price
     of vendor support is high.

結論すると、、このセクション、そして、業者サポートの価格が高くない場合業者サポートの品質が低くなると疑うために、根拠があります。

     Nature of the Design Process

デザイン過程の本質

          The advantage of having colleagues design protocols touched
     on above leads to another area which gives rise to concern over
     how valuable vendor-supported protocols really are.  Let's
     consider how international standards are arrived at:

同僚にプロトコルを設計させる利点は、別の領域への先導を超えてどれが業者によって支持されたプロトコルが本当にどれくらい貴重であるかに関する心配をもたらすかに触れました。 世界規格がどのように以下に到着しているか考えましょう。

                                     4
     RFC 873                                            September 1982

4 RFC873 1982年9月

          The first problem has to do with just who participates in
     the international standardization process.  The author has
     occasionally chided two different acquaintances from NBS that
     they should do something about setting standards for membership
     on standards committees.  The uniform response is to the effect
     that "They are, after all, voluntary standard organizations, and
     we take what we're given."  Just how much significance is
     properly attached to this insight is problematical.  Even the
     line of argument that runs, "How can you expect those
     institutions which have votes to send their best technical people
     to a standards committee?  Those are precisely the people they
     want to keep at home, working away," while enticing, does not,
     after all, guarantee that standards committees will attract only
     less-competent technicians.  There are even a few Old Network
     Boys from the ARPANET involved with the ISORM, and at least one
     at NBS.  However, when it is realized that the rule that only
     active implementers of TCP were allowed on the design team even
     precluded the present author's attendance (one of the oldest of
     the Old Network Boys, and the coiner of the phrase, at that), it
     should be clear that the ARMS enjoys an almost automatic
     advantage when it comes to technical quality over the ISORMS,
     without even appealing to the acknowledged-by-most politicization
     of the international standards arena.

いったいだれが国際標準化に参加するかと共に第1の問題は適性検査を受けなければなりません。 作者は時折2人の彼らが会員資格のために規格委員会に基準を定めることに関して何かをするべきであるNBSと異なった知人をたしなめました。 「それらは結局自発的の標準の組織です、そして、私たちは与えられているものを取る」という効果には一定の応答があります。 ちょうどどのくらいの意味が適切にこの洞察に付けられているかは、問題が多いです。 「あなたはどうしたら規格委員会に送る中で彼らの技術人々最も良い投票権を持っているそれらの団体を予想できますか?」と述べる論法さえ 「働き続けて、それらは正確に彼らが家に閉じ込めたがっている人々です」は、誘惑している間、規格委員会がそれほど有能でないだけの技術者を引き付けるのを結局保証しません。 アルパネットからのOld NetworkボイズがNBSでISORM、および少なくとも1つにかかわったいくつかさえあります。 しかしながら、TCPのアクティブなimplementersだけがデザインチームに許容されたという規則が現在の作者の出席(おまけにOld Networkボイズ、および句の硬貨鋳造者で最も古いものの1つ)を排除さえしたと実感されるとき、いつISORMSの上の技術的品質に来るかはARMSがほとんど自動である利点を楽しむのが明確であるはずです、世界規格アリーナの大部分で承認された政治化に求めていなくてさえいなくて。

          What, though, of the NBS's independent effort?  They have
     access to the experienced designers who evolved the ARMS, don't
     they?  One would think so, but in actual practice the NBS's
     perception of the political necessities of their situation led
     one of their representatives at a PSTP (the Department of Defense
     Protocol Standards Technical Panel) meeting to reply to a
     reminder that one of the features of their proposed Transport
     Protocol was a recapitulation of an early ARPANET Horror Story
     and would consume inordinate amounts of CPU time on participating
     Hosts only with a statement that "the NBS Transport Protocol has
     to be acceptable as ECMA [the European Computer Manufacturer's
     Association] Class 4." And even though NBS went to one of the
     traditional ARPANET-related firms for most of their protocol
     proposals, curiously enough in all the Features Analyses the
     author has seen the features attributed to protocols in the ARMS
     are almost as likely to be misstated as not.

もっとも、何、NBSの独立している努力について? 彼らはARMSを発展した経験豊富なデザイナーに近づく手段を持っているんでしょう? 人はそのように考えるでしょう; しかし、実際行なわれているところではNBSのそれらの状況の政治上の必需品の認知は、それらの提案されたTransportの特徴について思い出させるものへのそれを回答を満たしながら、PSTP(国防総省プロトコルStandards Technical Panel)で彼らの代表のひとりを導きました; プロトコルは、前のアルパネットHorror Storyの要約であり、参加Hostsで単に「NBS TransportプロトコルはECMAのヨーロッパのコンピュータManufacturerのAssociation Class4として許容できなければならない」という声明で過度の量のCPU時間を費やすでしょう。 そして、NBSは彼らのプロトコル提案の大部分に伝統的なアルパネット関連の会社の1つに行きましたが、すべてのFeatures Analysesでは、十分奇妙にも、作者は、ARMSのプロトコルの結果と考えられた特徴がほとんど同じくらい言い違えられそうであるのを見ました。

          The conclusion we should draw from all this is not that
     there's something wrong with the air in Gaithersburg, but rather
     that there's something bracing in the air that is exhaled by
     technical people whose different "home systems'" idiosyncracies
     lead naturally to an intellectual cross-fertilization, on the one
     hand, and a tacit agreement that "doing it right" takes
     precedence over "doing it expediently," on the other hand.  (If
     that sounds too corny, the reader should be aware that the author
     attended a large number of

私たちがこのすべてから達するべきである結論は他方では、一方では、異なった「家のシステムのもの」特異性が自然に知的な他家受精につながる技術人々によって息を吐き出される空気と「まさしくそれをし」て、「便宜的にそれをします」の上で優先する黙契ですがすがしい何かがむしろなかったなら空気には不具合がゲイザースバーグにあるということではありません。 (それがまた、陳腐に聞こえるなら、読者は作者が多くに出席したのを意識しているべきです。

                                     5
     RFC 873                                            September 1982

5 RFC873 1982年9月

     ARPANET protocol design meetings even if he wasn't eligible for
     TCP: in order to clarify our Host-parochial biases, we screamed
     at each other a lot, but we got the job done.)

TCPには、彼が適任でなかったとしても、アルパネットプロトコルはミーティングを設計します: 私たちのHost教区の偏見をはっきりさせるために互いに大いに金切り声を出しましたが、私たちは仕事を完了させました。)

          One other aspect of the international standardization
     process has noteworthy unfortunate implications for the resultant
     designs: However one might feel on a technical level about the
     presence of at least seven layers (some seem to be undergoing
     mitosis and growing "sublayers"), this leads to a real problem at
     the organizational--psychological level.  For each layer gets its
     own committee, and each committee is vulnerable to Parkinson's
     Law, and each layer is in danger of becoming an expansionist
     fiefdom ....  If your protocol designers are, on the other hand,
     mainly working system programmers when they're at home--as they
     tend to be in the ARPANET--they are far less inclined to make
     their layers their careers.  And if experience is weighted
     heavily--as it usually was in the ARPANET--the same designers
     tend to be involved with all or most of the protocols in your
     suite.  This not only militates against empire building, it also
     minimizes misunderstandings over the interfaces between
     protocols.

国際標準化の過程の他の1つの局面には、結果のデザインのための注目に値する不幸な意味があります: しかしながら、人は、存在に関する技術水準で少なくとも7つの層(或るものは有糸分裂と増加している「副層」を受けているように思える)では、これは組織的で実際の問題に通じます--心理学的なレベルと感じるかもしれません。 各層がそれ自身の委員会を得て、それぞれの委員会がパーキンソンの法則に傷つきやすく、各層には拡張主義の封建国になるという危険があるので… 彼らが家にいるとき、あなたのプロトコルデザイナーが他方ではシステム・プログラマを主に働かせているなら(彼らのように、アルパネットにはある傾向があってください)、彼らは遠くにそれほど彼らの層をそれらのキャリアにする傾向がありません。 --アルパネットにそれが通常あったとき経験が大いに重みを加えられるならそして、同じデザイナーは、あなたのスイートですべてかプロトコルの大部分にかかわる傾向があります。 これは帝国建設に影響するだけではありません、また、それがプロトコルの間のインタフェースの上で誤解を最小にします。

     "Space-Time" Considerations

「時空」問題

          At the risk of beating a downed horse, there's one other
     problem area with the belief that "Vendor supplied protocols will
     be worth waiting for" which really must be touched on.  Let's
     examine the likely motives of the Vendors with respect to
     "space-time" considerations.  That is, the system programmer
     designers of the ARMS were highly motivated to keep protocol
     implementations small and efficient in order to conserve the very
     resources they were trying to make sharable:  the Hosts' CPU
     cycles and memory locations.  Are Vendors similarly motivated?

馬を打ちつけるというリスクで、「業者の供給されたプロトコルは待つ価値がある」という本当に触れなければならない信念がある他の1つの問題領域があります。 「時空」問題に関してVendorsのありそうな動機を調べましょう。 すなわち、ARMSのシステム・プログラマデザイナーはそれらが共有可能させようとしていたまさしくその資源を節約するためにプロトコル実現を小さく効率的に保つために非常に動機づけられました: HostsのCPUサイクルと記憶域。 Vendorsは同様に動機づけられていますか?

          For some, the reminder that "IBM isn't in business to sell
     computers, it's in business to sell computer time" (and you can
     replace the company name with just about any one you want) should
     suffice.  Especially when you realize that it was the traditional
     answer to the neophyte programmer's query as to how come there
     were firms making good livings selling Sort-Merge utilities for
     System X when one came with the operating system (X = 7094 and
     the Operating system was IBSYS, to date the author).  But that's
     all somewhat "cynical", even if it's accurate.  Is there any
     evidence in today's world?

いくつか、「コンピュータを販売するために、ビジネスにはIBMがなくて、コンピュータ時間を販売するために、ビジネスにそれがあること」が(あなたは会社名をほとんど欲しいいずれにも取り替えることができます)十分であるべきであるということを思い出させるもののために。 特にあなたが、それがなんで1つがオペレーティングシステムで来たとき(X=7094とOperatingシステムは作者とデートするためにはIBSYSでした)System XのためのSort-マージユーティリティを販売する贅沢な生活を作る会社があった新改宗者プログラマの質問の伝統的な答えであったとわかるとき。 しかし、それが正確であっても、それはいくらかすべて「シニカルです」。 何か証拠が今日の世界にありますか?

          Well, by their fruits shall you know them:  1.  The feature
     of the NBS Transport Protocol alluded to earlier was an every
     15-second "probe" of an open connection ("to be sure the other
     guy's still

さて、それらの果実で、あなたはそれらを知っているでしょう: 1. より早く暗示されて、オープンな接続のあらゆる15秒の「徹底的調査」が(であったという「確実にまだ奴のもう片方のものである」NBS Transportプロトコルの特徴

                                     6
     RFC 873                                            September 1982

6 RFC873 1982年9月

     there").  In the early days of the ARPANET, one Host elected to
     have its Host-Host protocol (popularly miscalled "NCP" but more
     accurately AH-HP, for ARPANET Host-Host Protocol) send an echo
     ("ECO") command to each other Host each minute.  The "Network
     Daemon" on Multics (the process which fielded AH-HP commands)
     found its bill tripled as a result.  The ECMA-desired protocol
     would generate four nuisance commands each minute--from every
     Host you're talking to!  (The "M", recall, is for
     Manufacturers.)*  2.  X.25 is meant to be a network interface.
     Even with all the ambiguities of the ISORM, one would think the
     "peer" of a "DTE" (Host) X.25 module (or "entity") would be a
     "DCE" (comm subnet processor) X.25 module. But you can also "talk
     to" at least the foreign DCE's X.25 and (one believes) even the
     foreign DTE's; indeed, it's hard to avoid it.  Why all these
     apparently extraneous transmissions?  CCITT is a body consisting
     of the representatives of "the PTT's"--European for State-owned
     communications monopolies. 3.  The ISORM legislates that
     "N-entities" must communicate through "N-1 entities."  Doesn't
     that make for the needless multiplication of N-1 entities?  Won't
     that require processing more state information than a closed (or
     even an open) subroutine call within level N?  Doesn't anybody
     there care about Host CPU cycles and memory consumption?

「そこでは」) アルパネットの初期では、1Hostが、Host-ホストプロトコルを持っているのを選んだ、(しかし、「NCP」が、より正確にポピュラーに呼び違えた、ああ、-、hp、アルパネットホスト兼ホストプロトコル) それぞれの分にエコー(「エコ」)コマンドに互いにホストを送ってください。 その結果、請求書が見つけられたMultics(AH-HPコマンドをさばいた過程)の「ネットワークデーモン」は3倍になりました。 ECMAによるプロトコルが発生させる必要4迷惑は、あらゆるHostからのそれぞれの分にあなたが話していると命令します! (「M」(リコール)はメーカーのためのものです。)* 2. X.25はネットワーク・インターフェースであることが意味されます。 ISORMのすべてのあいまいさがあっても、人は"DTE"(ホスト)の「同輩」を考えるでしょう。 X.25モジュール(または、「実体」)は"DCE"(commサブネットプロセッサ)でしょう。 X.25モジュール。 しかし、また、少なくとも外国DCEのX.25と外国DTEの(人は信じています)ものさえあなたと「話すことができます」。 本当に、それを避けにくいです。 なぜこれらのすべての明らかに異質なトランスミッション? CCITTは「PTTのもの」の代表から成るボディーです--州によって所有されているコミュニケーション独占のためのヨーロッパ人。 3. ISORMは必須が「N-1実体」を通して伝えるその「N-実体」を制定します。 それはN-1実体の不必要な乗法になりませんか? それは、レベルNの中で閉じている(または、戸外さえ)サブルーチン呼出しより多くの州の情報を処理するのを必要としないでしょうか? そこのだれもHost CPUサイクルとメモリ消費を心配しませんか?

          Note particularly well that there is no need to attribute
     base motives to the designers of the ISORMS.  Whether they're
     doing all that sort of thing on purpose or not doesn't matter.
     What does matter is that their environment doesn't offer positive
     incentives to design efficient protocols, even if it doesn't
     offer positive disincentives.  (And just to anticipate a likely
     cheap shot, TCP checksums are necessary to satisfy the design
     goal of reliability; ECMA four pings a minute is[/was]
     unconscionable.)

ベース動機をISORMSのデザイナーの結果と考える必要は全くないことに特によく注意してください。彼らがわざとそのすべての種類のことをしているかどうかは重要ではありません。 重要なことは彼らの環境が効率的なプロトコルを設計するポジティブ・インセンティブを提供しないということです、積極的な行動を妨げるものを提供しないでも。 そして、ありそうな不当な言動、TCPチェックサムが信頼性のデザイン目標を満たすのに必要です; ECMA fourが1分間確認するとまさしく予期するのがあります[/はそうでした]。(非良心的である、)

     TANSTAAFL

TANSTAAFL

          We're very near the end of our analysis.  Readers familiar
     with the above acronym might be tempted to stop now, though there
     are a few good points to come.  For the benefit of those who are
     not aware:  "There Ain't No Such Thing As A Free Lunch."
     Achieving interoperability among vendor-supplied protocol
     interpreters won't come for free.  For that matter, what with all
     this "unbundling"

私たちは私たちの分析の終わりに非常に近いです。 上の頭文字語に詳しい読者が今止まるように誘惑されるかもしれません、来るために、数長所がありますが。 意識していないそれらの利益のために: 「無料の昼食なんてものがありません。」 業者によって供給されたプロトコルインタプリタの中で相互運用性を達成するのはただで来ないでしょう。 さらに言えば、すべてなどの理由でこの「アンバンドリング」

     ________________
     *  Rumor has it that the probes have since been withdrawn from
        the spec.  Bravo.  However, that they were ever in the spec is
        still extremely disquieting--and how long it took to get them
        out does not engender confidence that the ISORMS will be
        "tight" in the next few years.

________________ * 噂によると、探測装置は以来、仕様から引っ込められています。 ブラボー。 彼らは今までに仕様にいました。しかしながらそれ、スチール写真は非常に不穏であり、それらを出すにはどれくらいかかったかがISORMSがこの数年間で「きつい」という信用を生み出しません。

                                     7
     RFC 873                                            September 1982

7 RFC873 1982年9月

     stuff, who says even the incompatible ones come for free?  You
     might make up those costs by not having to pay your maintenance
     programmers to reinsert the ARMS into each new release of the
     operating system from the vendor, but not only don't good
     operating systems change all that often, but also you'll be
     paying out microseconds and memory cells at rates that can easily
     add up to ordering the next member up in the family.  In short,
     even if the lunch is free, the bread will be stale and the cheese
     will be moldy, more likely than not.  It's also the case that as
     operating systems have come to evolve, the "networking" code has
     less and less need to be inserted into the hardcore supervisor or
     equivalent.  That is, the necessary interprocess communication
     and process creation primitives tend to come with the system now,
     and device drivers/managers of the user's own devising can often
     be added as options rather than having to be built in, so the
     odds are good that it won't be at all hard to keep up with new
     releases anyway. Furthermore, it turns out that more and more
     vendors are supplying (or in process of becoming able to supply)
     TCP/IP anyway, so the whole issue of waiting for vendor support
     might well soon become moot.

もの?(そのものは両立しない方さえただで来ると言います)。 あなたのメンテナンスプログラマがARMSを業者からオペレーティングシステムの各新版に再び差し込むのを支払う必要はないことによって、それらのコストを作るかもしれませんが、良いオペレーティングシステムはしばしばそのすべてを変えるだけでなくなく、あなたが容易に家族で次期メンバーの出勤を命じるまで加えることができるレートでマイクロセカンドとメモリセルをまた払い戻すでしょう。 要するに、昼食が無料であっても、パンは新鮮でなくなるでしょう、そして、チーズはかびになるでしょう、おそらく。 また、オペレーティングシステムが発展するようになったときますます少なさが、「ネットワーク」コードでハードコア監督か同等物に挿入される必要がないのは、事実です。 すなわち、必要なプロセス間通信と過程創造基関数が、もうシステムと共に来る傾向があって、建てられる有よりむしろオプションとしてしばしばユーザの自己の工夫のデバイスドライバ/マネージャは加えることができるので、とにかく新版について行くのが全く困難でなくなるという可能性は高いです。 その上、業者サポートを待つ全体の問題がすぐたぶん論争中になることができるようにますます多くの業者がとにかくTCP/IPを供給している(または供給できるようになる過程で)と判明します。

     References

参照

     [1]  Padlipsky, M. A., "The Elements of Networking Style",
          M81-41, The MITRE Corporation, October 1981, attempts to
          clarify the distinction between "remote access" and
          "resource sharing" as networking styles.

[1] Padlipsky、M.A.、「ネットワーク様式のElements」、M81-41、MITRE社(1981年10月)はスタイルをネットワークでつなぐとして「遠隔アクセス」と「リソース・シェアリング」の区別をはっきりさせるのを試みます。

     [2]  ----------,  "A Perspective on the ARPANET Reference Model",
          M82-47, the MITRE Corporation, September 1982; also
          available in Proc. INFOCOM '83.

[2] ----------, 「アルパネット規範モデルの上の見解」、M82-47、斜め継ぎ社、1982年9月。 また、Procでは、利用可能です。 INFOCOM83年。

                                     8

8