home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / 95APR / INTERNET < prev    next >
Encoding:
Text File  |  1995-06-26  |  8.8 KB  |  251 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 BOF and working groups met during the April IETF meeting
  15. in Danvers, Massachusetts:
  16.  
  17.  
  18.    o MessageWay BOF (MSGWAY)
  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 IPv6 MIB Working Group (IPV6MIB)
  24.    o Point-to-Point Protocol Extensions Working Group (PPPEXT)
  25.  
  26.  
  27.  
  28. MessageWay BOF (MSGWAY)
  29.  
  30.  
  31. This BOF session introduced the need for processors in separate,
  32. possibly non-homogeneous MPPs (Massively Parallel Processing systems) to
  33. communicate with each other.  It was felt that IP provides more
  34. scalability and generality than necessary, and does not provide the high
  35. performance that this application requires.  The MsgWay approach is to
  36. define a Level-3 protocol that is similar in its philosophy to IP, but
  37. has implementation details geared toward high-performance, possibly at
  38. some cost of generality and wide area scalability.
  39.  
  40. Danny Cohen, the BOF chair, presented the proposed architecture.  The
  41. following topics were discussed:
  42.  
  43.  
  44.    o Why should MsgWay be an IETF activity?  It is proposed to conduct
  45.      the MsgWay activity as an IETF working group because of the firm
  46.      belief that interoperability should be handled at Level 3 (not just
  47.      at Levels 1 and 2), and because of the recognition that MPP
  48.      networks are computer communication networks with much in common
  49.      with the networks that the IETF community is dealing with.
  50.  
  51.    o Technical discussion and clarifications.  Including similarity to
  52.      IP, transport level reliability, source routing, MTU,
  53.      interconnection of separate MsgWay islands.
  54.  
  55.  
  56. The purpose of the BOF was to evaluate appropriateness of the proposed
  57. work to the IETF and to determine community interest in creating a
  58. working group.  Danny reported that in addition to those who
  59. participated in this BOF, there are about 20 other people from academia,
  60. government, and industry who expressed interest in participating in
  61. defining MsgWay, most of them had participated in two earlier meetings
  62. discussing MsgWay.
  63.  
  64. Danny will work with Frank Kastenholz, an incoming Internet Area
  65. co-Director, on a draft charter for the working group, and will post it
  66. on the MsgWay mailing list.  The MsgWay Working Group is expected to
  67. conduct its work over e-mail, to meet at IETF meetings, and to possibly
  68. have additional meetings between IETF meetings.  It is expected to have
  69. a rough draft of the minimal MsgWay protocol by the next IETF meeting,
  70. in mid-July.
  71.  
  72.  
  73.  
  74. Dynamic Host Configuration Working Group (DHC)
  75.  
  76. Topics that were discussed included the following:
  77.  
  78.    o DHC in the Mobile IP environment.
  79.  
  80.    o DHCPREVALIDATE, which will be deleted; and DHCPINFORM, which was
  81.      thought to be a good idea.
  82.  
  83.    o DHCPv6 for IPv6.  Further discussion was deferred to the mailing
  84.      list.
  85.  
  86.    o Reliable operation of replicated DHCP servers.  A new mailing list
  87.      will be created.
  88.  
  89.    o Client and server authentication.  A three-way private key exchange
  90.      was favored.  Further discussion will take place on the host-conf
  91.      mailing list.
  92.  
  93.    o ``Freely available'' DHCP implementations.  There is one from WIDE,
  94.      and there may be another soon.
  95.  
  96.  
  97.  
  98. DNS IXFR, Notification, and Dynamic Update Working Group (DNSIND)
  99.  
  100. Although it was hoped that this would be the last meeting of this group,
  101. it is now planned that the last meeting will be at the next IETF,
  102. particularly since this group may need to take on more DNS issues (with
  103. a corresponding update of the charter).
  104.  
  105. Other topics that were discussed included:
  106.  
  107.    o IXFR operation and formats.  Formats will be worked on, and delay
  108.      going to RFC until implementation.
  109.  
  110.    o Proposal to split prefixes from host identifiers in Internet
  111.      address records.
  112.  
  113.    o DNS Notify.
  114.  
  115.    o IPv6 address-to-name mapping.
  116.  
  117.    o Dynamic update.  Many issues were discussed.
  118.  
  119.  
  120.  
  121. Internet Stream Protocol V2 Working Group (ST2)
  122.  
  123. Since the Protocol Specifications have been submitted as an RFC, the
  124. primary objective of the meeting was to review and discuss the draft of
  125. the State Machine document as well as to determine the future direction
  126. of the group.
  127.  
  128. The group had already agreed to submit the ST protocol specification for
  129. publications as, per the charter, an Experimental RFC. Publication is
  130. awaiting IESG action.  The State Machine draft is in progress with a
  131. targeted completion of June.  If the State Machine draft is indeed
  132. completed in this time frame, the working group may not meet in
  133. Stockholm.
  134.  
  135. The group discussed the State Machine draft, specifically:
  136.  
  137.    o When can data be transmitted?
  138.  
  139.    o The `E' bit in REFUSE messages must be added to all state diagrams.
  140.  
  141.    o Diagrams will be updated to show Local Resource Management
  142.      interfaces on processing these messages.
  143.  
  144.    o Time out handling will be added in the next draft.
  145.  
  146.    o State machines for failure processing needs to be added.
  147.  
  148.    o A mechanism is needed to add API interfaces to state machines.
  149.  
  150.    o The handling of JOIN/JOIN REFUSE and upstream-oriented messages
  151.      must be revisited.
  152.  
  153.    o The interfaces between origin and target sides of the router state
  154.      machines must be specified in more detail.
  155.  
  156.  
  157.  
  158. IP Over Asynchronous Transfer Mode Working Group (IPATM)
  159.  
  160. The Routing Over Large Clouds (ROLC) and IPATM Working Groups met in a
  161. joint session on 3 April.
  162.  
  163. The following three major topics were discussed:
  164.  
  165.    o IP architecture extensions for ATM. Yakov Rekhter presented
  166.      draft-rekhter-ip-atm-architecture-00.txt, which discusses IP
  167.      architecture extensions for ATM. The working group concluded that
  168.      the current ROLC work meets some of Yakov's needs, and the future
  169.      work in the IPATM Working Group should address the issues, in
  170.      coordination with INTSERV and RSVP.
  171.  
  172.    o RFC 1577 client behavioral changes and NHRP and ATMARP
  173.      interactions.  Including single server issues with regard to fault
  174.      tolerance and support for alternative services.
  175.  
  176.    o ATM Forum announcement.  Relaxed document distribution policy to
  177.      allow easier access to ATM Forum documents.  There will be a BOF at
  178.      the next IETF to discuss how to foster better interactions between
  179.      the IETF and the ATM Forum.
  180.  
  181.  
  182. IPv6 MIB Working Group (IPV6MIB)
  183.  
  184. This is a newly created working group.  This group had met as a BOF at
  185. the San Jose IETF meeting, and this represented its first meeting as a
  186. working group.  The working group's charter falls into three broad
  187. categories:
  188.  
  189.  
  190.    o Identify changes, if any, to existing standards track SNMPv2
  191.      document.
  192.  
  193.    o Potential changes to existing MIBs.
  194.  
  195.    o New and additional MIBs that are specific to the IP: Next
  196.      Generation Protocol.
  197.  
  198.  
  199. The IPv6 MIB Working Group is initially chartered to identify specific
  200. areas of work and their corresponding work items, within each of the
  201. abovementioned categories.
  202.  
  203. The following topics were discussed:
  204.  
  205.  
  206.    o Working group charter.  There was general agreement on the scope of
  207.      work.  Since most of the working groups with which IPv6 MIB was
  208.      planning to coordinate are planning to shut down, the incoming Area
  209.      Directors for the Internet and Network Management Areas and the
  210.      IPV6MIB Working Group Chair agreed to (re)explore appropriate Areas
  211.      where IPv6-related management oriented work may be conducted.
  212.  
  213.    o General overview of the required effort.  Including, SNMP impact,
  214.      SNMPv2 status, technical direction, changes to existing MIBs, new
  215.      MIBs, and current work.
  216.  
  217.    o Changes not required.  No changes were proposed to SNMPv2 SMI. No
  218.      additional SNMP Protocol support (`extensions') are needed to
  219.      manage IPv6 via IPv4 Managers.  No changes would be required to the
  220.      standards-track SNMPv2 documents.
  221.  
  222.    o Textual Conventions, Transport Mappings, and organization of
  223.      existing MIBs.  No definitive result or outcome.  Follow-on
  224.      discussions will continue on the mailing list.
  225.  
  226.  
  227. Point-to-Point Protocol Extensions Working Group (PPPEXT)
  228.  
  229. The following topics were discussed:
  230.  
  231.    o Encryption Control Protocol (draft-ietf-pppext-encryption-03.txt)
  232.      was returned by the IESG. Keith Sklower will write a draft
  233.      addressing some issues.
  234.  
  235.    o ECP/CCP patent status.  Steve Coya reported on the communication
  236.      with Motorola.
  237.  
  238.    o Multilink Procedures RFC 1717.  Fine tuning.
  239.  
  240.    o Extensible Authentication Protocol.  Some clarifications and some
  241.      decisions.
  242.  
  243.    o Public Key Authentication Proposal.  This draft is either poorly
  244.      worded or fundamentally incorrect; in either case, it requires a
  245.      great deal of work.
  246.  
  247.    o IP Control Protocol.  A number of agreements and clarifications
  248.      were made with the purpose of allowing IPCP from Proposed Standard
  249.      status to Draft Standard.
  250.  
  251.