home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / pppext / pppext-minutes-94jul.txt < prev    next >
Text File  |  1994-11-01  |  6KB  |  164 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Fred Baker/Advanced Computer Communications
  5.  
  6. Minutes of the Point-to-Point Protocol Extensions Working Group (PPPEXT)
  7.  
  8.  
  9. PPPEXT Editor
  10.  
  11. The PPPEXT Working Group has a new editor.  Bill Simpson resigned as
  12. editor as of this IETF. The chair notes that Bill's technical
  13. contributions have been many and helpful in making PPP and its
  14. extensions clearly understood and interoperably implementable by many
  15. disparate organizations.  We wish him well in his new endeavors.
  16.  
  17. The new editor is Scott Wasson.  The role of the editor is that of
  18. ``designated reviewer,'' responsible for readability, clarity of
  19. explanation, and consistency of language and technical approach among
  20. documents produced by this working group.  Scott will work out with each
  21. author how they will interact, whether by Scott submitting comments or
  22. whether he edits the author's text.
  23.  
  24.  
  25. IESG In Basket
  26.  
  27. Currently in the IESG's in basket are the following documents:
  28.  
  29.  
  30.    o To Proposed Standard:
  31.       -  draft-ietf-pppext-dataencap-02.txt
  32.       -  draft-ietf-pppext-frame-relay-03.txt
  33.       -  draft-ietf-pppext-multilink-09.txt
  34.  
  35.    o To Draft Standard:
  36.       -  OSI CP (RFC 1377)
  37.       -  DECNET CP (RFC 1376)
  38.  
  39.  
  40. Status Report on the Compression Control Protocol and Associated
  41. Documents
  42.  
  43. Compression is a major issue for ISOC at the moment.  Motorola sent a
  44. letter to ISOC indicating that the CCP may infringe on one or more of
  45. its patents.  Since ISOC (like ANSI and other organizations) requires
  46. that standards produced by our community be either patent-free or that
  47. the patent holder assure ISOC that it will negotiate reasonable terms
  48. with those who implement, the drafts cannot be approved for any status -
  49. including Informational RFC - at this point.  ISOC is seeking to
  50. communicate with Motorola, but has to date not secured the necessary
  51. assurances.  The patent numbers are 5,130,993, transmitting encoded data
  52. on unreliable networks, and 5,245,614, vocabulary memory allocation for
  53. adaptive data compression of frame-multiplexed traffic.  This affects
  54. the following drafts:
  55.  
  56.  
  57.    o draft-ietf-pppext-compression-04.txt
  58.    o draft-ietf-pppext-bsd-compress-01.txt
  59.    o draft-ietf-pppext-gandalf-00.txt
  60.    o draft-ietf-pppext-hpppc-00.txt
  61.    o draft-ietf-pppext-magnalink-01.txt
  62.    o draft-ietf-pppext-predictor-00.txt
  63.    o draft-ietf-pppext-stacker-01.txt
  64.  
  65.  
  66.  
  67. NETBIOS CP
  68.  
  69.  
  70. Those who were working with the NETBIOS CP indicate that the current
  71. draft (draft-ietf-pppext-netbios-fcp-05.txt) meets their needs and
  72. should be published as a Proposed Standard.
  73.  
  74.  
  75.  
  76. Synchronous Data Compression Consortium
  77.  
  78.  
  79. Stuart Venters made a presentation regarding the activities and
  80. conclusions of the SDCC, a consortium of DSU/CSU vendors who would like
  81. to use a variation on the PPP Compression Control Protocol to
  82. interconnect compressing DSUs.  This is an unusual application:  HDLC
  83. data (potentially PPP but potentially also X.25, Frame Relay, or other
  84. HDLC protocols) is encapsulated in PPP datagrams containing compressed
  85. data.  There can be interesting circumstances wherein a device calls a
  86. system using a compressing DSU, and the DSU seeks to open a PPP session
  87. before passing data on to the target system.  These would, of course, be
  88. temporary occurrences.  Even if the LCP came up and was authenticated,
  89. the DSU would recognize the situation when the SDCC's NCP for the case
  90. failed negotiation.
  91.  
  92. The SDCC would like to modify the LCP for use in this circumstance, to
  93. reduce the negotiation to a single message exchange.  This was
  94. discussed, and SDCC agreed to further consider the viability of this.
  95.  
  96. Primarily, the SDCC wished to know whether the PPP community felt that
  97. they should pursue public adoption of the standard.  Our belief is that
  98. we have considerable expertise to offer the SDCC in designing the
  99. application, and a vested interest in their getting it right (our
  100. implementations will at least occasionally chat with theirs).
  101. Therefore, we recommend that the SDCC use the IETF as a forum for this
  102. development.
  103.  
  104.  
  105. AppleTalk CP
  106.  
  107. Brad Parker spoke about the text changes he has published in a revision
  108. of the AppleTalk NCP; he is updating RFC 1378 for advancement to Draft
  109. Standard.  AppleTalk has been a problem in PPP interoperability, due to
  110. incomplete or incorrect implementations.  The draft seeks primarily to
  111. clarify wording to remedy this situation.  This work will continue on
  112. the list.
  113.  
  114.  
  115.  
  116. Callback Procedure
  117.  
  118. Gurdeep Singh Pall, speaking for Narendra Gidwani, described a proposed
  119. callback procedure to be used in authentication.  The idea is that there
  120. may be several numbers that the authenticator can call the authenticatee
  121. at, among which the authenticatee might select.  There is also often a
  122. delay before which there is no point in calling:  the modem has not
  123. turned around.  The procedure allows for the authenticatee to offer a
  124. set of call addresses and a minimum delay before calling.  This will be
  125. pursued as a modification of the LCP callback option.
  126.  
  127.  
  128.  
  129. Internet Protocol CP
  130.  
  131. Gurdeep went on to describe some concerns that Microsoft has with the
  132. IPCP. Microsoft would like additional options to describe primary and
  133. secondary DNS and NETBIOS name server addresses, time server addresses
  134. and for registering IP multicast usage.  The Routing and Internet Area
  135. Directors, being all present, and the working group consensus indicated
  136. that protocols (DHCP and IGMP) exist for this purpose, placing these
  137. options out of scope.
  138.  
  139. Gurdeep has agreed to update the IPCP with implementation notes in
  140. preparation for advancement to Draft Standard.  There was consensus to
  141. add a boolean option to IPCP to request forwarding of network and subnet
  142. broadcasts.  Alan Steele is planning a related effort to update the Van
  143. Jacobsen compression algorithm described in RFC 1144.
  144.  
  145.  
  146.  
  147. Authentication
  148.  
  149. David Carrel reported on the status of the sub-group working on
  150. authentication.  The status is essentially that some agreements have
  151. been hammered out, but are not at this point documented.  David will
  152. post an Internet-Draft concerning authentication requirements by
  153. 1 September.
  154.  
  155.  
  156.  
  157. Banyan Vines CP
  158.  
  159. Fred Baker presented Steve Senum's BVCP draft in a few overheads, and
  160. led a review.  Some typos were pointed out (which will be pointed out in
  161. mail on the list) and a proposed BV-Routing option was discussed.  Steve
  162. will continue development of the draft on the list.
  163.  
  164.