RFC1973 日本語訳

Network Working Group                                         W. Simpson
Request for Comments: 1973                                    Daydreamer
Category: Standards Track                                      June 1996

コメントを求めるワーキンググループW.シンプソン要求をネットワークでつないでください: 1973年の空想家カテゴリ: 標準化過程1996年6月

                           PPP in Frame Relay

フレームリレーにおけるppp

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for
   the Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.

Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。

   This document describes the use of Frame Relay for framing PPP
   encapsulated packets.

このドキュメントはFrame Relayのパケットであるとカプセル化された縁どりPPPの使用について説明します。

Applicability

適用性

   This specification is intended for those implementations which desire
   to use facilities which are defined for PPP, such as the Link Control

この仕様はPPPのために定義される施設を使用することを望んでいるそれらの実装のために意図します、Link Controlなどのように

Simpson                      Standards Track                    [Page i]

RFC 1973                     PPP in Frame Relay                June 1996

Frame Relay1996年6月のシンプソンStandards Track[ページi]RFC1973PPP

   Protocol, Network-layer Control Protocols, authentication, and
   compression.  These capabilities require a point-to-point
   relationship between peers, and are not designed for multi-point or
   multi-access environments.

プロトコル、Network-層のControlプロトコル、認証、および圧縮。 これらの能力は、同輩の間の二地点間関係を必要として、マルチポイントかマルチアクセス環境のために設計されていません。

Table of Contents

目次

     1.     Introduction ..........................................    1

1. 序論… 1

     2.     Physical Layer Requirements ...........................    1

2. 物理的な層の要件… 1

     3.     The Data Link Layer ...................................    2
        3.1       Frame Format ....................................    2
        3.2       Modification of the Basic Frame .................    3

3. データ・リンク層… 2 3.1 形式を縁どってください… 2 3.2 基本枠の変更… 3

     4.     In-Band Protocol Demultiplexing .......................    4

4. バンドでは、逆多重化について議定書の中で述べてください… 4

     5.     Out-of-Band signaling .................................    5

5. バンドで出ているシグナリング… 5

     6.     Configuration Details .................................    5

6. 構成の詳細… 5

     SECURITY CONSIDERATIONS ......................................    7

セキュリティ問題… 7

     REFERENCES ...................................................    7

参照… 7

     ACKNOWLEDGEMENTS .............................................    7

承認… 7

     CHAIR'S ADDRESS ..............................................    8

議長のアドレス… 8

     AUTHOR'S ADDRESS .............................................    8

作者のアドレス… 8

Simpson                      Standards Track                   [Page ii]

RFC 1973                     PPP in Frame Relay                June 1996

Frame Relay1996年6月のシンプソンStandards Track[ページii]RFC1973PPP

1.  Introduction

1. 序論

   Frame Relay [2] is a relative newcomer to the serial link community.
   Like X.25, the protocol was designed to provide virtual circuits for
   connections between stations attached to the same Frame Relay
   network.  The improvement over X.25 is that Q.922 is restricted to
   delivery of packets, and dispenses with sequencing and flow control,
   simplifying the service immensely.

フレームRelay[2]は連続のリンク共同体への相対的な新来者です。 X.25のように、プロトコルは、同じFrame Relayネットワークに付けられたステーションの間の接続に仮想の回路を提供するように設計されました。 X.25の上の改良はQ.922がパケットの配信に制限されて、配列とフロー制御を省くということです、サービスを大きく簡素化して。

   PPP uses ISO 3309 HDLC as a basis for its framing [3].

PPPは縁ど[3]りの基礎としてISO3309HDLCを使用します。

   When Frame Relay is configured as a point-to-point circuit, PPP can
   use Frame Relay as a framing mechanism, ignoring its other features.
   This is equivalent to the technique used to carry SNAP headers over
   Frame Relay [4].

Frame Relayが二地点間回路として構成されるとき、PPPは縁どりメカニズムとしてFrame Relayを使用できます、他の特徴を無視して。 これはFrame Relay[4]の上でSNAPヘッダーを運ぶのに使用されるテクニックに同等です。

   At one time, it had been hoped that PPP in HDLC-like frames and Frame
   Relay would co-exist on the same links.  Unfortunately, the Q.922
   method for expanding the address from 1 to 2 to 4 octets is not
   indistinguishable from the ISO 3309 method, due to the structure of
   its Data Link Connection Identifier (DLCI) subfields.  Co-existance
   is precluded.

ひところ、HDLCのようなフレームとFrame RelayのPPPが同じリンクの上に共存することが望まれていました。 残念ながら、1〜2〜4つの八重奏にアドレスを広げるためのQ.922メソッドは3309年のISOメソッドから区別がつかなくはありません、Data Link Connection Identifier(DLCI)部分体の構造のため。 共同existanceは排除されます。

2.  Physical Layer Requirements

2. 物理的な層の要件

   PPP treats Frame Relay framing as a bit-synchronous link.  The link
   MUST be full-duplex, but MAY be either dedicated (permanent) or
   switched.

PPPは少し同期のリンクとしてFrame Relay縁どりを扱います。 リンクは、全二重でなければなりませんが、捧げられるか(永久的な)、または切り換えられるかもしれません。

   Interface Format

インタフェース形式

      PPP presents an octet interface to the physical layer.  There is
      no provision for sub-octets to be supplied or accepted.

PPPは物理的な層に八重奏インタフェースを提示します。 サブ八重奏を供給するか、または受け入れるために、支給は全くありません。

   Transmission Rate

通信速度

      PPP does not impose any restrictions regarding transmission rate,
      other than that of the particular Frame Relay interface.

PPPは特定のFrame Relayインタフェースのもの以外の通信速度に関する少しの制限も課しません。

   Control Signals

制御信号

      Implementation of Frame Relay requires the provision of control
      signals, which indicate when the link has become connected or
      disconnected.  These in turn provide the Up and Down events to the
      LCP state machine.

Frame Relayの実装は制御信号の設備を必要とします。(信号はリンクがいつ接続されるようになるか、または切断したかを示します)。 これらは順番にUpとDownイベントをLCP州のマシンに供給します。

Simpson                      Standards Track                    [Page 1]

RFC 1973                     PPP in Frame Relay                June 1996

RFC1973pppが1996年6月に船体の骨組を組み立て終えてリレーするシンプソン標準化過程[1ページ]

      Because PPP does not normally require the use of control signals,
      the failure of such signals MUST NOT affect correct operation of
      PPP.  Implications are discussed in [2].

PPPが通常制御信号の使用を必要としないので、そのような信号の失敗はPPPの正しい操作に影響してはいけません。 [2]で含意について議論します。

   Encoding

コード化

      The definition of various encodings is the responsibility of the
      DTE/DCE equipment in use, and is outside the scope of this
      specification.

様々なencodingsの定義は、使用中のDTE/DCE設備の責任であり、この仕様の範囲の外にあります。

      While PPP will operate without regard to the underlying
      representation of the bit stream, Frame Relay requires NRZ
      encoding.

PPPは関係なしでビットストリームの基底表示に作動するでしょうが、Frame RelayはNRZコード化を必要とします。

3.  The Data Link Layer

3. データ・リンク層

   This specification uses the principles, terminology, and frame
   structure described in "Multiprotocol Interconnect over Frame Relay"
   [4].

この仕様は「Multiprotocolはフレームリレーの上で内部連絡する」[4]で説明された原則、用語、および枠組構造を使用します。

   The purpose of this specification is not to document what is already
   standardized in [4].  Instead, this document attempts to give a
   concise summary and point out specific options and features used by
   PPP.

この仕様の目的は[4]で既に標準化されることを記録しないことです。 代わりに、このドキュメントは、簡潔な概要をして、特定のオプションとPPPによって使用された特徴を指摘するのを試みます。

3.1.  Frame Format

3.1. フレーム形式

   As described in [4], Q.922 header address and control fields are
   combined with the Network Layer Protocol Identifier (NLPID), which
   identifies the encapsulation which follows.  The fields are
   transmitted from left to right.

[4]で説明されるように、Q.922ヘッダーアドレスと制御フィールドはNetwork LayerプロトコルIdentifier(NLPID)に結合されます。(Identifierは続くカプセル化を特定します)。 野原は左から右まで伝えられます。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+
   |  Flag (0x7e)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Q.922 Address         |    Control    |  NLPID(0xcf)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PPP Protocol          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | 旗(0x7e)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Q.922アドレス| コントロール| NLPID(0xcf)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pppプロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The PPP Protocol field and the following Information and Padding
   fields are described in the Point-to-Point Protocol Encapsulation

以下のPPPプロトコル分野、情報、およびPadding分野はPointからポイントへのプロトコルEncapsulationで説明されます。

Simpson                      Standards Track                    [Page 2]

RFC 1973                     PPP in Frame Relay                June 1996

RFC1973pppが1996年6月に船体の骨組を組み立て終えてリレーするシンプソン標準化過程[2ページ]

   [1].

[1].

3.2.  Modification of the Basic Frame

3.2. 基本枠の変更

   The Link Control Protocol can negotiate modifications to the basic
   frame structure.  However, modified frames will always be clearly
   distinguishable from standard frames.

Link Controlプロトコルは基本枠構造への変更を交渉できます。 しかしながら、変更されたフレームは標準のフレームから区別可能にいつも明確になるでしょう。

   Address-and-Control-Field-Compression

アドレスとコントロール分野圧縮

      Because the Address and Control field values are not constant, and
      are modified as the frame is transported by the network switching
      fabric, Address-and-Control-Field-Compression MUST NOT be
      negotiated.

AddressとControl分野値が一定でなく、フレームがネットワーク切り換え骨組みによって輸送されるので変更されて、Addressとコントロール分野圧縮を交渉してはいけないということであるので。

   Protocol-Field-Compression

プロトコル分野圧縮

      Note that unlike PPP in HDLC-like framing, the Frame Relay framing
      does not align the Information field on a 32-bit boundary.
      Alignment to a 32-bit boundary occurs when the NLPID is removed
      and the Protocol field is compressed to a single octet.  When this
      improves throughput, Protocol-Field-Compression SHOULD be
      negotiated.

HDLCのような縁どりにおけるPPPと異なって、Frame Relay縁どりが32ビットの境界の情報分野を並べないことに注意してください。 NLPIDが取り外されて、プロトコル分野がただ一つの八重奏に圧縮されるとき、32ビットの境界への整列は起こります。 プロトコル分野圧縮SHOULD、これはスループットを改良します。いつ、交渉されるか。

Simpson                      Standards Track                    [Page 3]

RFC 1973                     PPP in Frame Relay                June 1996

RFC1973pppが1996年6月に船体の骨組を組み立て終えてリレーするシンプソン標準化過程[3ページ]

4.  In-Band Protocol Demultiplexing

4. バンドにおけるプロトコル逆多重化

   The PPP NLPID (CF hex) and PPP Protocol fields easily distinguish the
   PPP encapsulation from the other NLPID encapsulations described in
   [4].

PPP NLPID(CF十六進法)とPPPプロトコル分野は[4]で説明された他のNLPIDカプセル化とPPPカプセル化を容易に区別します。

   The joining of the PPP and NLPID number space has an added advantage,
   in that the LCP Protocol-Reject can be used to indicate NLPIDs that
   are not recognized.  This can eliminate "black-holes" that occur when
   traffic is not supported.

PPPとNLPID数のスペースの接合には、加えられた利点があります、認識されないNLPIDsを示すのにLCPプロトコル廃棄物を使用できるので。 これはトラフィックがサポートされないとき起こる「ブラックホール」を排除できます。

   For those network-layer protocols which have no PPP Protocol
   assignment, or which have not yet been implemented under the PPP
   encapsulation, or which have not been successfully negotiated by a
   PPP NCP, another method of encapsulation defined under [4] SHOULD be
   used.

PPPプロトコル課題を全く持っていないか、PPPカプセル化の下でまだ実装されていないか、またはPPP NCP、[4] SHOULDの下で定義されたカプセル化の別のメソッドで首尾よく交渉されていないそれらのネットワーク層プロトコルには、使用されてください。

   Currently, there are no conflicts between NLPID and PPP Protocol
   values.  If a future implementation is configured to send a NLPID
   value which is the same as a compressed Protocol field, that Protocol
   field MUST NOT be sent compressed.

現在、NLPIDとPPPプロトコル値との衝突が全くありません。 圧縮されたプロトコル分野と同じNLPID値を送るために将来の実装を構成するなら、圧縮されていた状態でそのプロトコル野原を送ってはいけません。

   On reception, the first octet following the header is examined.  If
   the octet is zero, it MUST be assumed that the packet is formatted
   according to [4].

レセプションでは、ヘッダーに続く最初の八重奏は調べられます。 八重奏がゼロであるなら、[4]によると、パケットがフォーマットされると思わなければなりません。

   PPP encapsulated packets always have a non-zero octet following the
   header.  If the octet is not the PPP NLPID value (CF hex), and
   Protocol-Field-Compression is enabled, and the associated NCP has
   been negotiated, then it is expected to be a compressed PPP Protocol
   value.  Otherwise, it MUST be assumed that the packet is formatted
   according to [4].

ヘッダーに続いて、パケットであるとカプセル化されたPPPはいつも非ゼロ八重奏を持っています。 八重奏がPPP NLPID値(CF十六進法)でなく、プロトコル分野圧縮が可能にされて、関連NCPが交渉されたなら、それは圧縮されたPPPプロトコル価値であると予想されます。 さもなければ、[4]によると、パケットがフォーマットされると思わなければなりません。

   The Protocol field value 0x00cf is not allowed (reserved) to avoid
   ambiguity when Protocol-Field-Compression is enabled.  The value MAY
   be treated as a PPP Protocol that indicates that another PPP Protocol
   packet follows.

プロトコル分野圧縮が可能にされるとき、プロトコル分野値の0x00cfはあいまいさを避けることができません(予約されます)。 値は別のPPPプロトコルパケットが続くのを示すPPPプロトコルとして扱われるかもしれません。

   Initial LCP packets contain the sequence cf-c0-21 following the
   header.  When a LCP Configure-Request packet is received and
   recognized, the PPP link enters Link Establishment phase.

ヘッダーに続いて、初期のLCPパケットは系列Cf-c0-21を含んでいます。 LCP Configure-リクエスト・パケットが受け取られて、認識されるとき、PPPリンクはLink特権階級フェーズに入ります。

   The accidental connection of a link to feed a multipoint network (or
   multicast group) SHOULD result in a misconfiguration indication.
   This can be detected by multiple responses to the LCP Configure-
   Request with the same Identifier, coming from different framing
   addresses.  Some implementations might be physically unable to either
   log or report such information.

misconfiguration指示における多点ネットワーク(または、マルチキャストグループ)SHOULD結果を食べさせるリンクの偶然の接続。 同じIdentifierとのLCP Configure要求への複数の応答でこれを検出できます、異なった縁どりアドレスから来て。 いくつかの実装は、そのような情報を登録するか、または物理的に報告できないかもしれません。

Simpson                      Standards Track                    [Page 4]

RFC 1973                     PPP in Frame Relay                June 1996

RFC1973pppが1996年6月に船体の骨組を組み立て終えてリレーするシンプソン標準化過程[4ページ]

   Once PPP has entered the Link Establishment phase, packets with other
   NLPID values MUST NOT be sent, and on receipt such packets MUST be
   silently discarded, until the PPP link enters the Network-Layer
   Protocol phase.

PPPがいったんLink特権階級フェーズに入ると、他のNLPID値があるパケットを送ってはいけません、そして、領収書の上では、静かにそのようなパケットを捨てなければなりません、PPPリンクがNetwork-層のプロトコルフェーズに入るまで。

   Once PPP has entered the Network-Layer Protocol phase, and
   successfully negotiated a particular NCP for a PPP Protocol, if a
   frame arrives using another equivalent data encapsulation defined in
   [4], the PPP Link MUST re-enter Link Establishment phase and send a
   new LCP Configure-Request.  This prevents "black-holes" that occur
   when the peer loses state.

PPPがいったんNetwork-層のプロトコルフェーズに入って、PPPプロトコルのために首尾よく特定のNCPを交渉すると、[4]で定義された別の同等なデータカプセル化を使用することでフレームが届くなら、PPP LinkはLink特権階級フェーズに再入して、新しいLCP Configure-要求を送らなければなりません。 これは同輩が状態を失うと起こる「ブラックホール」を防ぎます。

   An implementation which requires PPP link configuration, and other
   PPP negotiated features (such as authentication), MAY enter
   Termination phase when configuration fails.  Otherwise, when the
   Configure-Request sender reaches the Max-Configure limit, it MUST
   fall back to send only frames encapsulated according to [4].

構成が失敗すると、PPPリンク構成、および他のPPPの交渉された特徴(認証などの)を必要とする実装はTerminationフェーズに入るかもしれません。 Configure-要求送付者が別の方法で達する、限界をマックスと同じくらい構成してください、それは、[4]によると、カプセル化されたフレームだけを送るために後ろへ下がらなければなりません。

5.  Out-of-Band signaling

5. バンドで出ているシグナリング

   There is no generally agreed method of out-of-band signalling.  Until
   such a method is universally available, an implementation MUST use
   In-Band Protocol Demultiplexing for both Permanent and Switched
   Virtual Circuits.

一般にバンドの外の同意されたメソッド合図でないこと。 そのようなメソッドが一般に利用可能になるまで、実装はPermanentとSwitched Virtual Circuitsの両方にIn-バンドプロトコルDemultiplexingを使用しなければなりません。

6.  Configuration Details

6. 構成の詳細

   The following Configuration Options are recommended:

以下のConfiguration Optionsはお勧めです:

      Magic Number
      Protocol Field Compression

マジックナンバープロトコル分野圧縮

   The standard LCP configuration defaults apply to Frame Relay links,
   except Maximum-Receive-Unit (MRU).

Maximumがユニットを受けている(MRU)を除いて、標準のLCP構成デフォルトはFrame Relayリンクに適用されます。

   To ensure interoperability with existing Frame Relay implementations,
   the initial MRU is 1600 octets [4].  This only affects the minimum
   required buffer space available for receiving packets, not the size
   of packets sent.

Frame Relay実装、初期のMRUを存在する相互運用性に確実にするのは、1600の八重奏[4]です。 これはパケットのサイズではなく、パケットを受けるのに利用可能なスペースが送った最小の必要なバッファに影響するだけです。

   The typical network feeding the link is likely to have a MRU of
   either 1500, or 2048 or greater.  To avoid fragmentation, the
   Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
   exceed 1500, unless a peer MRU of 2048 or greater is specifically

リンクを食べさせる典型的なネットワークは1500か2048年のどちらか以上のMRUを持っていそうです。 断片化を避けるために、ネットワーク層SHOULD NOTのMaximumトランスミッションユニット(MTU)は1500を超えています、2048年以上の同輩MRUが明確にそうでないなら

Simpson                      Standards Track                    [Page 5]

RFC 1973                     PPP in Frame Relay                June 1996

RFC1973pppが1996年6月に船体の骨組を組み立て終えてリレーするシンプソン標準化過程[5ページ]

   negotiated.

交渉にされる。

   Some Frame Relay switches are only capable of 262 octet frames.  It
   is not recommended that anyone deploy or use a switch which is
   capable of less than 1600 octet frames.  However, PPP implementations
   MUST be configurable to limit the size of LCP packets which are sent
   to 259 octets (which leaves room for the NLPID and Protocol fields),
   until LCP negotiation is complete.

いくつかのFrame Relayスイッチは262個の八重奏フレームができるだけです。 だれでも1600個未満の八重奏フレームができるスイッチを配布するか、または使用することは勧められません。 しかしながら、PPP実装は259の八重奏に送られるLCPパケットのサイズ(NLPIDとプロトコル分野の余地がある)を制限するのにおいて構成可能であるに違いありません、LCP交渉が完全になるまで。

   XID negotiation is not required to be supported for links which are
   capable of PPP negotiation.

XID交渉は、PPP交渉ができるリンクにサポートされるのに必要ではありません。

   Inverse ARP is not required to be supported for PPP links.  That
   function is provided by PPP NCP negotiation.

逆さのARPによってPPPリンクにサポートされる必要はありません。 PPP NCP交渉でその機能を提供します。

Simpson                      Standards Track                    [Page 6]

RFC 1973                     PPP in Frame Relay                June 1996

RFC1973pppが1996年6月に船体の骨組を組み立て終えてリレーするシンプソン標準化過程[6ページ]

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

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

References

参照

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
         51, RFC 1661, July 1994.

[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。

   [2]   CCITT Recommendation Q.922, "ISDN Data Link Layer Specification
         for Frame Mode Bearer Services", International Telegraph and
         Telephone Consultative Committee, 1992.

[2] CCITT推薦Q.922、「フレーム方式運搬人サービスのためのISDNデータ・リンク層仕様」、国際電信電話諮問委員会、1992。

   [3]   Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51,
         RFC 1662, July 1994.

[3] シンプソン、W.、エディタ、「HDLCのような縁どりにおけるppp」、STD51、RFC1662、1994年7月。

   [4]   Bradley, T.,  Brown, C., and A. Malis, "Multiprotocol
         Interconnect over Frame Relay", RFC 1490, July 1993.

1993年7月の[4]ブラッドリーとT.とブラウン、C.とA.Malis、「Multiprotocolはフレームリレーの上で内部連絡する」RFC1490。

   [5]   ISO/IEC TR 9577:1990(E), "Information technology -
         Telecommunications and Information exchange between systems -
         Protocol Identification in the network layer", 1990-10-15.

[5] ISO/IEC TR9577: 1990(E)、「情報技術(システムの間のテレコミュニケーションと情報交換)はネットワーク層でIdentificationについて議定書の中で述べます」、1990年10月15日。

Acknowledgments

承認

   This design was inspired by the paper "Parameter Negotiation for the
   Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
   University of California, Berkeley, 1992, unpublished.

このデザインは紙の「Multiprotocol内部連絡のためのパラメタ交渉」、キースSklower、およびクリフォード・フロストによって奮い立たせられました、カリフォルニア大学バークレイ校1992、未発表です。

Simpson                      Standards Track                    [Page 7]

RFC 1973                     PPP in Frame Relay                June 1996

RFC1973pppが1996年6月に船体の骨組を組み立て終えてリレーするシンプソン標準化過程[7ページ]

Chair's Address

議長のアドレス

   The working group can be contacted via the current chair:

現在のいすを通してワーキンググループに連絡できます:

      Karl Fox
      Ascend Communications
      3518 Riverside Drive, Suite 101
      Columbus, Ohio 43221

カールフォックスはオハイオ コミュニケーション3518リバーサイド・ドライブ、Suite101コロンブス、43221を昇ります。

      EMail: karl@ascend.com

メール: karl@ascend.com

Author's Address

作者のアドレス

   Questions about this memo can also be directed to:

また、このメモに関する質問による以下のことよう指示できます。

      William Allen Simpson
      Daydreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

ミシガン ウィリアムアレンのシンプソン空想家コンピュータシステムズのコンサルタント業務1384フォンテーヌマディソンの高さ、48071

          wsimpson@UMich.edu
          wsimpson@GreenDragon.com (preferred)

wsimpson@UMich.edu wsimpson@GreenDragon.com(都合のよい)です。

Simpson                      Standards Track                    [Page 8]

シンプソン標準化過程[8ページ]