home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 94dec / area.internet.94dec.txt < prev    next >
Text File  |  1995-02-28  |  11KB  |  237 lines
  1.  
  2. Internet Area
  3.  
  4. Directors:
  5.  
  6.  
  7.    o Stev Knowles:  stev@ftp.com
  8.    o Claudio Topolcic:  topolcic@bbn.com
  9.  
  10.  
  11. Area Summary reported by Stev Knowles/FTP Software and
  12. Claudio Topolcic/BBN
  13.  
  14. The following BOFs and working groups met during the December IETF
  15. meeting in San Jose, California:
  16.  
  17.  
  18.    o Multiprotocol Transport BOF (MPTRANS)
  19.    o Dynamic Host Configuration Working Group (DHC)
  20.    o DNS IXFR, Notification, and Dynamic Update Working Group (DNSIND)
  21.    o Internet Stream Protocol V2 Working Group (ST2)
  22.    o IP Over Asynchronous Transfer Mode Working Group (IPATM)
  23.    o Point-to-Point Protocol Extensions Working Group (PPPEXT)
  24.    o Service Location Protocol Working Group (SVRLOC)
  25.  
  26.  
  27. Multiprotocol Transport BOF (MPTRANS)
  28.  
  29. Diane Pozefsky presented the principles of MPTN as embodied in the
  30. ANYNET family of IBM products.  She explained the philosophy behind
  31. MPTN, not to use encapsulation, but to use protocol transformation at
  32. the proper level in the various stacks.  She presented the challenges of
  33. MPTN: function compensation, address mapping, transport gateway, and
  34. network management.  Diane presented the experiences of implementing
  35. MPTN in the cases of SNA over TCP, Sockets over SNA, Netbios over SNA,
  36. Sockets over Netbios.  A key question came up, of the usefulness of MPTN
  37. to the IETF, or why was this BOF scheduled?  The main answer given was
  38. that this is an opportunity for IBM to cooperate with the IETF on
  39. technology of common interest.  The discussion continued and the subject
  40. of writing several Informational RFCs was brought up.  This will be
  41. looked at by Sig Handelman and Diane.  Also, the intersection of MPTN
  42. and SNA could solve TN3270E problems, and create a general solution for
  43. 3270, and other SNA sessions (i.e LU6.2).  Finally, the idea of using
  44. MPTN as model for the IPv4 to IPv6 transition was proposed.
  45.  
  46.  
  47. Dynamic Host Configuration Working Group (DHC)
  48.  
  49. The DHC Working Group met twice.  The latest round of changes between
  50. RFC 1541 and the November Internet-Draft were discussed.  They are based
  51. on the results of the Toronto bakeoff; there were changes, none
  52. significant.  The issue of a new DHCP message, ``DHCPINFORM,'' was
  53. discussed as a way for DHCP clients to get local configuration
  54. information without requesting a network address.  After a discussion of
  55. a server-to-server protocol, it was suggested (and, in fact, several
  56. vendors have already done this) that DHCP servers could use existing
  57. distributed database technology such as NIS or Oracle, rather than
  58. reinventing the wheel.
  59.  
  60. The working group discussed the relationship between IPv6 addrconf and
  61. DHCP. By consensus, the existing semantics in DHCP can support the IPv6
  62. address configuration model, with the possible addition of a new
  63. message, DHCPREACQUIRE, which is intended as a hint to clients that they
  64. should reacquire IP addresses.  The group also discussed DHCP and
  65. dynamic DNS updates; this group will define the set of DNS updates it
  66. expects to require and pass that list to the DNS Working Group.  Along
  67. with dynamic DNS update, this working group discussed authentication and
  68. security; the DHC Working Group will define its authentication and
  69. security requirements.  Finally, the group discussed the
  70. server-to-server protocol, and came to the conclusion that, although
  71. some sites may choose to use external distributed databases in support
  72. of multiple DHCP servers, other sites will still want to use a
  73. DHCP-specific server-to-server protocol.  The working group will expand
  74. on a conceptual proposal presented on Wednesday.
  75.  
  76.  
  77.  
  78. DNS IXFR, Notification, and Dynamic Update Working Group (DNSIND)
  79.  
  80. Thomas Brisco's Load Balancing draft is moving toward becoming an
  81. Informational RFC. There were no objections to this.  The code for it
  82. may or may not be in the next BIND, but will at least be in the contrib
  83. directory.
  84.  
  85. Masataka Ohta presented the Internet-Draft
  86. draft-ietf-dnsind-ixfr-00.txt.  It is very different from the previous
  87. proposal in that the server maintains no state about the client.  There
  88. was general agreement on the approach, but more work is needed on the
  89. draft.  Security issues need review.  He will have a new Internet-Draft
  90. soon with the plan for an RFC in Danvers.
  91.  
  92. Susan Thomson presented the status of the Dynamic Update work.
  93. Broadening the scope of the work has raised questions about requirements
  94. that need to be supported and consequent new design issues.
  95. Requirements and issues were enumerated and explored.  They are included
  96. in the DNSIND minutes.
  97.  
  98. The DynUpd crew felt they had sufficient guidance to produce a new
  99. draft.  They expect more input from the mailing list.
  100.  
  101. There will be an interim meeting of the DNSIND Working Group in late
  102. January or early February, specifically to progress toward a new DynUpd
  103. draft.  This is likely to be 8 February, just before the IPng interim,
  104. in the Bay Area.  The plan is to produce an new Internet-Draft in time
  105. for a cycle at Danvers.
  106.  
  107. Mark Lottor discussed problems in the COM domain.  The COM domain is
  108. annoying in terms of size, trademark issues, etc.  Write to mkl@nw.com
  109. if you are interested in the subject.
  110.  
  111. Paul Vixie described the status of the Notify drafting work.  He will
  112. publish a new draft in the next weeks, with the intent of an RFC by
  113. Danvers.
  114.  
  115. It was the general consensus that the current nibble IPv6 address to
  116. name translation was the safest.
  117.  
  118.  
  119. Internet Stream Protocol V2 Working Group (ST2)
  120.  
  121. The ST2 Working Group met twice.  The majority of the time was spent on
  122. a detailed walk through of the current Internet-Draft.  Some minor
  123. technical issues were reviewed and resolved.  The group as a whole
  124. believes that all issues are resolved and the Internet-Draft should be
  125. completed by mid-January.  Once the Internet-Draft is published as an
  126. RFC, the only work remaining for the working group will be publishing
  127. state machines for the protocol.  The state machines will be published
  128. separately from the protocol specification.  The state machines are
  129. scheduled to be issued as an Internet-Draft in RFC quality form prior to
  130. the Danvers meeting.  The main activity in Danvers will be the review
  131. and acceptance of the state machines.  The key actions resulting from
  132. the working group are to complete the Internet-Draft by mid-January and
  133. to issue the next version of state machines in January.
  134.  
  135. Some minor issues are mentioned in the detailed minutes.
  136.  
  137.  
  138. IP Over Asynchronous Transfer Mode Working Group (IPATM)
  139.  
  140.   o Drew Perkins gave a report on the ATM Forum.  He will send an e-mail
  141.     report to the mailing list for the Kyoto meeting.
  142.  
  143.   o There are now about ten implementations of RFC 1577 in progress and it
  144.     is possible that Digital has even passed the first interoperability test
  145.     with two other vendors.
  146.  
  147.   o Dario Ercole gave a presentation on interpersonal multimedia
  148.     communications over ATM. This was shown at Interop '94.
  149.  
  150.   o Grenville Armitage led a review of the IP Multicast draft.  Its goals
  151.     are to work within RFC 1577 context and utilize UNI 3.1 multicast
  152.     services.
  153.  
  154.   o Discussion of the framework document was led by David Shur.  The general
  155.     consensus is that the group needs to close on this real soon.
  156.  
  157.   o Mark presented the suggested FY95 work plan.
  158.  
  159.  
  160.  
  161. Point-to-Point Protocol Extensions Working Group (PPPEXT)
  162.  
  163.  
  164. The status of the issues with Motorola regarding the Compression Control
  165. Protocol are as follows.  Motorola has advised Steve Coya, Executive
  166. Director of the IETF, that they plan to offer licenses on fair terms.
  167. Letters describing those terms have not yet been received by either
  168. Steve or Fred.
  169.  
  170. Fred, in the absence of its author (Steve Senum), presented the updated
  171. draft of the PPP Banyan Vines Control Protocol (BVCP)
  172. (draft-ietf-pppext-vines-01.txt) and the updated draft of the PPP XNS
  173. IDP Control Protocol (XNSCP) (draft-ietf-pppext-xnscp-00.txt).  The
  174. former formalizes the use of the control and data protocols specified by
  175. Assigned Numbers, and three options relating to routing protocol
  176. messages and fragmentation.  The latter formalizes the use of the
  177. control and data protocols specified by Assigned Numbers, and proposes
  178. no options.  The working group approved the advancement of both to
  179. Proposed Standard.
  180.  
  181. Gerry Meyer presented the PPP Encryption Control Protocol (ECP). This is
  182. draft-ietf-pppext-encryption-00.txt.  This protocol is modeled on the
  183. CCP, including the use of separate informational documents describing
  184. separate encryption procedures.  Jeff Weiss suggested adding an
  185. encryption reset and acknowledge, for use by non-self-synchronizing
  186. encryption procedures.  Jeff feels he can eliminate another potential
  187. patent problem.
  188.  
  189. The Synchronous Data Compression Consortium made a presentation to the
  190. Working Group at the last IETF meeting, describing its use of PPP
  191. between DSUs.  It has now largely completed its design and is about to
  192. ask TR 30.1 to recommend the use of the procedure.  They produced three
  193. Internet-Drafts.  Several questions were raised concerning technical
  194. aspects.  The people concerned about them will contact the author and
  195. discuss them on the dsu-compress[-request]@paradyne.com list.  These
  196. will be published as Informational RFCs when complete, due to their
  197. status in ANSI.
  198.  
  199. In the currently widely held security model, exchange of passwords in
  200. the clear does not appear wise.  Thus, PAP is no longer a recommended
  201. procedure.  CHAP, however, is still believed to be acceptable for a
  202. certain class of problems.  Bill will create a new Authentication
  203. Internet-Draft which does not have PAP in it.  The IESG can declare
  204. RFC 1334 ``Historical,'' making PAP a historical procedure, and the new
  205. CHAP-only draft will become a Draft Standard when a consensus on the
  206. list supports that.
  207.  
  208. The Kerberos and one-time passwords effort (Carrels, Blunk, and Parker)
  209. has not produced a requirements document.  Two companies, however, have
  210. deployed incompatible authentication procedures of that type.  Brad
  211. Parker will update the draft-ietf-pppext-gap-00.txt draft according to
  212. deployment experience, and we will publish that, probably as a Proposed
  213. Standard.  Fred will contact Larry Blunk to determine whether the
  214. combined effort is still likely to occur.
  215.  
  216.  
  217. Service Location Protocol Working Group (SVRLOC)
  218.  
  219. The Service Location Working Group met to discuss changes to the current
  220. draft (including reorganization of the protocol header, field size
  221. changes, query example and multiple addresses in the service instance),
  222. SCOPE, IPv6 and implementation experience.
  223.  
  224. The changes in the current draft were described in detail.
  225.  
  226. The current SCOPE mechanism was discussed and explained in detail
  227. including the relationship between foreign scope and DNS.
  228.  
  229. The differences in the Internet-Draft for IPv4 and IPv6 were discussed.
  230. The main differences are in the service instance address formats.
  231.  
  232. The implementation status was reviewed.  Only one group is currently
  233. working on an implementation of the protocol.  Implementation experience
  234. has shown that this protocol can be easily implemented on modern PC
  235. operating systems.
  236.  
  237.