Agenda for March 23 Telechat
Steve Coya <scoya@CNRI.Reston.VA.US> Wed, 22 March 1995 23:35 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14567; 22 Mar 95 18:35 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14563; 22 Mar 95 18:35 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19539; 22 Mar 95 18:35 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14554; 22 Mar 95 18:35 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14550; 22 Mar 95 18:35 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19533; 22 Mar 95 18:35 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14544; 22 Mar 95 18:35 EST
To: iesg@CNRI.Reston.VA.US
Subject: Agenda for March 23 Telechat
Date: Wed, 22 Mar 1995 18:35:15 -0500
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Coya <scoya@CNRI.Reston.VA.US>
Message-ID: <9503221835.aa14544@IETF.CNRI.Reston.VA.US>
INTERNET ENGINEERING STEERING GROUP (IESG) Agenda for the March 23, 1995 IESG Teleconference 1. Administrivia o Roll Call o Bash the Agenda o Approval of the Minutes - March 9 o Area Reports for 32nd IETF 2. Protocol Actions o MHS use of the X.500 Directory to support MHS Klensin Routing - Experimental <draft-ietf-mhsds-routdirectory-06.txt> o The PPP Encryption Control Protocol (ECP) - Proposed Knowles <draft-ietf-pppext-encryption-03.txt> o Extending OSPF to support demand circuits - Proposed Halpern <draft-ietf-ospf-demand-02.txt> o BGP3 - Historic Halpern <RFC 1267> & <RFC 1268> o IP over SMDS - Standard Knowles <rfc1209> 3. Working Group Actions o IP Version 6 MIB (ipv6mib) Knowles o RWhois Operational Development (rwhois) Bradner 4. RFC Editor Actions o INETPhone: Telephone Services and Servers on Internet o ICMP Domain Name messages - Experimental Knowles/ <draft-simpson-icmp-domain-name-01.txt> Topolcic 5. Working Group News We Can Use 6. Management Issues o SSL Mockapetris o Retaining a lawyer Bradner o ISOC Contributions Bradner o Update on Sun agreement Bradner o Update on Insurance Bradner 7. Waiting for AD Action o RIP Informational Document Halpern o Writeup for IPv4 Router Requirements Halpern o Write up for HTML Huizer o Writeup for RTP Mankin ================== a. Tasked Items o Memo to IETF on RFC Title Restrictions Mockapetris b. ON HOLD o The PPP Compression Control Protocol (CCP) - Proposed <draft-ietf-pppext-compression-04.txt> c. Awaiting AD approval on WG submissions o Benchmarking Methodology for Network Interconnect Devices - Informational O'Dell Ballot: Extending OSPF to support demand circuits to Proposed Standard -------- Last Call to expire on: 03/09/1995 Please return the full line with the vote. Yes No-Objection Discuss * Abstain Scott Bradner [ X ] [ ] [ ] [ ] Joel Halpern [ X ] [ ] [ ] [ ] Erik Huizer [ ] [ ] [ ] [ ] John Klensin [ ] [ X ] [ ] [ ] Stev Knowles [ X ] [ ] [ ] [ ] Allison Mankin [ ] [ ] [ ] [ ] Paul Mockapetris [ ] [ ] [ ] [ ] Mike O'Dell [ ] [ ] [ ] [ ] Joyce K. Reynolds [ ] [ ] [ ] [ ] Marshall T. Rose [ ] [ ] [ ] [ ] Jeff Schiller [ ] [ ] [ ] [ ] Claudio Topolcic [ ] [ ] [ ] [ ] Yes => I have read the spec and know it is good stuff. No Obj => I am familiar with the protocol and believe it to be OK. Note: The ballot contains analysis from the AD which may be adequate information to vote positively. Discuss => There is something fishy that may need clarification or modification. May be considered a "no" vote. Abstain => I am not familiar with the spec, have no interest/expertise in the subject or otherwise feel obliged to skip the voting. 2/3 (8) Yes or No-Objection votes needed to pass. * Indicate reason if "Discuss". To: IETF-Announce:; Cc: RFC Editor <rfc-editor@isi.edu> Cc: Internet Architecture Board <iab@isi.edu> Cc: ospf@gated.cornell.edu From: IESG Secretary <iesg-secretary@cnri.reston.va.us> Subject: Protocol Action: Extending OSPF to support demand circuits to Proposed Standard ------------- The IESG has approved the Internet-Draft "Extending OSPF to support demand circuits" <draft-ietf-ospf-demand-02.txt> as a Proposed Standard. This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact person is Joel Halpern. Technical Summary The base OSPF protocol describes operation over broadcast media, Non-Broadcast Multi-Access media, and dedicated point-to-point links. As experience has grown, it has been found that when operating over a collection of dynamic connections certain alternative behaviors are needed. Such a collection includes X.25 SVCs, Frame Relay SVCs, or a bank of ISDN Primary rate connections. This standard specifies enhancements to the basic OSPF methodology to allow effective operation over such environments. Working Group Summary There has been extensive discussion of this technology within the working group. While there were alternatives to consider, the proposed technology is the best choice of elements. Protocol Quality This has been reviewed by Joel M. Halpern, the routing AD. There is one working implementation at this time. The protocol seems sound, although due to the nature of the problem space real world experience is very important. Ballot: Application of the Border Gateway Protocol (BGP3) in the Internet to Historic -------- Last Call to expire on: 03/07/1995 Please return the full line with the vote. Yes No-Objection Discuss * Abstain Scott Bradner [ X ] [ ] [ ] [ ] Joel Halpern [ X ] [ ] [ ] [ ] Erik Huizer [ ] [ ] [ ] [ ] John Klensin [ X ] [ ] [ ] [ ] Stev Knowles [ X ] [ ] [ ] [ ] Allison Mankin [ ] [ ] [ ] [ ] Paul Mockapetris [ ] [ ] [ ] [ ] Mike O'Dell [ ] [ ] [ ] [ ] Joyce K. Reynolds [ ] [ ] [ ] [ ] Marshall T. Rose [ ] [ ] [ ] [ ] Jeff Schiller [ ] [ ] [ ] [ ] Claudio Topolcic [ ] [ ] [ ] [ ] Yes => I have read the spec and know it is good stuff. No Obj => I am familiar with the protocol and believe it to be OK. Note: The ballot contains analysis from the AD which may be adequate information to vote positively. Discuss => There is something fishy that may need clarification or modification. May be considered a "no" vote. Abstain => I am not familiar with the spec, have no interest/expertise in the subject or otherwise feel obliged to skip the voting. 2/3 (8) Yes or No-Objection votes needed to pass. * Indicate reason if "Discuss". To: IETF-Announce:; Cc: RFC Editor <rfc-editor@isi.edu> Cc: Internet Architecture Board <iab@isi.edu> Cc: bgp@ans.net From: IESG Secretary <iesg-secretary@cnri.reston.va.us> Subject: Protocol Action: Application of the Border Gateway Protocol in the Internet to Historic ------------- The IESG has reclassified RFC1267 "A Border Gateway Protocol 3 (BGP-3)" and RFC1268 "Application of the Border Gateway Protocol in the Internet" as Historic. These documents are the product of the Inter-Domain Routing Working Group. The IESG contact person is Joel Halpern. Technical Summary BGP-3 was the predecessor inter-domain routing protocol to BGP-4. As BGP-4 is now being advanced, it is no longer appropriate to standardize the previous protocol. Working Group Summary The working group supports this change. Protocol Quality This proposal has been reviewed by Joel M. Halpern, the Routing Area Director. It is a good idea. Ballot: The Transmission of IP Datagrams over the SMDS Service to Standard -------- Last Call to expire on: 03/16/1995 Please return the full line with the vote. Yes No-Objection Discuss * Abstain Scott Bradner [ X ] [ ] [ ] [ ] Joel Halpern [ X ] [ ] [ ] [ ] Erik Huizer [ ] [ ] [ ] [ ] John Klensin [ ] [ ] [ ] [ ] Stev Knowles [ X ] [ ] [ ] [ ] Allison Mankin [ ] [ ] [ ] [ ] Paul Mockapetris [ ] [ ] [ ] [ ] Mike O'Dell [ ] [ ] [ ] [ ] Joyce K. Reynolds [ ] [ X ] [ ] [ ] Marshall T. Rose [ ] [ ] [ ] [ ] Jeff Schiller [ ] [ ] [ ] [ ] Claudio Topolcic [ ] [ ] [ ] [ ] Yes => I have read the spec and know it is good stuff. No Obj => I am familiar with the protocol and believe it to be OK. Note: The ballot contains analysis from the AD which may be adequate information to vote positively. Discuss => There is something fishy that may need clarification or modification. May be considered a "no" vote. Abstain => I am not familiar with the spec, have no interest/expertise in the subject or otherwise feel obliged to skip the voting. 2/3 (8) Yes or No-Objection votes needed to pass. * Indicate reason if "Discuss". To: IETF-Announce:; Cc: RFC Editor <rfc-editor@isi.edu> Cc: Internet Architecture Board <iab@isi.edu> Cc: iplpdn@cnri.reston.va.us From: IESG Secretary <iesg-secretary@cnri.reston.va.us> Subject: Protocol Action: The Transmission of IP Datagrams over the SMDS Service to Standard ------------- The IESG has approved the Internet-Draft "The Transmission of IP Datagrams over the SMDS Service" RFC1209 as a Standard. The IESG contact persons are Stev Knowles and Claudio Topolcic. Technical Summary RFC 1209 is a widely deployed implementation of IP of SMDS service. Currently, there are several interoperable, independant implementations of the standard installed in the field, with no apparent problems. Note that RFC1209 was published as a Proposed Standard in March, 1991. It was approved as a Draft Standard by the IAB in March, 1992. There have been no changes to the text in RFC 1209. Working Group Summary The AD asked the Chair to conduct a vitual (over the net) IPLPDN meeting in order to advance the specification. The last call was relatively quiet, and the WG chair has extracted details from various vendors regarding their implementation experiences. based on this input, the WG mailing list was informed of the decision to advance the specification. Protocol Quality This RFC was reviewed by Stev Knowles, Internet Area Director, for the IESG. Ballot: The PPP Encryption Control Protocol (ECP) to Proposed Standard -------- Notes: Submitted 1/17/95 Last Call 1/18/95 Ballot 2/8/95 withdrawn by AD 3/15/95 Last Call to expire on: 02/01/1995 Please return the full line with the vote. Yes No-Objection Discuss * Abstain Scott Bradner [ ] [ ] [ X ] [ ] Joel Halpern [ ] [ X ] [ ] [ ] Erik Huizer [ ] [ ] [ ] [ ] John Klensin [ ] [ ] [ X ] [ ] Stev Knowles [ X ] [ ] [ ] [ ] Allison Mankin [ ] [ ] [ ] [ ] Paul Mockapetris [ ] [ ] [ ] [ ] Mike O'Dell [ ] [ ] [ ] [ ] Joyce K. Reynolds [ X ] [ ] [ ] [ ] Marshall T. Rose [ ] [ ] [ ] [ ] Jeff Schiller [ ] [ ] [ ] [ ] Claudio Topolcic [ ] [ X ] [ ] [ ] Yes => I have read the spec and know it is good stuff. No Obj => I am familiar with the protocol and believe it to be OK. Note: The ballot contains analysis from the AD which may be adequate information to vote positively. Discuss => There is something fishy that may need clarification or modification. May be considered a "no" vote. Abstain => I am not familiar with the spec, have no interest/expertise in the subject or otherwise feel obliged to skip the voting. 2/3 (8) Yes or No-Objection votes needed to pass. * Indicate reason if "Discuss". To: IETF-Announce:; Cc: RFC Editor <rfc-editor@isi.edu> Cc: Internet Architecture Board <iab@isi.edu> Cc: ietf-ppp@merit.edu From: IESG Secretary <iesg-secretary@cnri.reston.va.us> Subject: Protocol Action: The PPP Encryption Control Protocol (ECP) to Proposed Standard ------------- The IESG has approved the Internet-Draft "The PPP Encryption Control Protocol (ECP)" <draft-ietf-pppext-encryption-03.txt> as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Stev Knowles and Claudio Topolcic. Technical Summary As with most CP (Control Protocol) work done by the PPP-EXT WG, this Draft allows one to negotiate the use of various link layer encryption schemes with PPP. This document does not use the often used PPP Draft template, but is readable and understandable. Working Group Summary The PPPEXT WG has been working on this Draft over the last year, and while there has been techincal discussion on various points, they seem to have reached an mutually agreeable solution to the items discussed. Protocol Quality This Draft was reviewed for the IESG by Stev Knowles, one of the Internet Area Directors, for the IESG. The last call seems to have generated no response from the community. This Document was also reviewed by the Security Area Directorate. WG: IP Version 6 MIB (ipv6mib) ----------------------------- Chair: Manu Kaycee <kaycee@maelstrom.timeplex.com> Internet Area Area Directors: Stev Knowles <stev@ftp.com> Claudio Topolcic <topolcic@bbn.com> Network Management Area Advisor: Fred Baker <fred@cisco.com> Mailing lists: -------------- General Discussion: ip6mib@research.ftp.com To Subscribe: ip6mib-request@research.ftp.com Archive: TBD Description of Working Group: ----------------------------- Editor: David Arneson <arneson@ctron.com> The next generation of the Internet Protocol (IPv6) is intended to support Internet traffic for many years into the future by providing enhancements over the capabilities of the existing IPv4 service. The IPv6 working group is producing specifications for the core functionality of that service, per recommendations of the IPng Area Directors as outlined at the July 1994 IETF and in "The Recommendation for the IP Next Generation Protocol", RFC 1752, January 1995. The IPv6 MIB Working Group's charter falls into three broad categories: - identify changes, if any, to existing standards track SNMPv2 document - potential changes to existing MIBs - new and additional MIBs that are specific to the IP Next Generation Protocol The IPv6 MIB Working Group is initially chartered to identify specific areas of work and their corresponding work items, within each of the abovementioned categories. To which end, if changes or additions to the standards track SNMPv2 documents are identified, such changes will be communicated to and discused with the SNMPv2 Working Group. If, at a certain time, the SNMPv2 Working Group is inactive, this information will be communicated to the Network Management Area Director. Specification of a SNMPv2 Textual Convention for IPv6 addresses and the corresponding Transport Mappings to specify the Transport- Level address fall into this category. (As a result of an action item from the IPv6MIB BOF held in December 1994, these have already been communicated to the SNMPv2 Working Group.) As part of the second category, this Working Group will identify existing MIBs that will be impacted, some of which would need modifications to, at a minimum, include and reflect IPv6 addresses. Examples of these MIBs are: - MIB-II - Evolution of the Interfaces Group of MIB-II - IP Forwarding Table MIB - RIP Version 2 MIB Extensions - OSPF Version 2 MIB - IPCP MIB As part of its charter in this category, this Working Group will liaison and communicate with relevant Working Groups where these identified MIBs were developed. If, at a certain time, these said Working Groups are inactive, the appropriate Area Director will be apprised. Per the third category, this Working Group will identify a complete set of new and additional MIB modules, and their respective organization, in the following areas: - IPv6 and associated ICMPv6 protocols - IPv6 Neighbor Discovery - IPv6 Tunneling and Mobility - IPv6 Forwarding and Flows - IPv6 Network Address Configuration and Resolution - IPv6 Header Compression - Network Layer Security Aspects In order to maintain compliance, this Working Group will liaison with other Working Groups within the Internet Area, such as the IPng and ngtrans Working Groups. Goals and Milestones: --------------------- Apr 95 First Working Group Meeting - Discuss Charter, Initial Proposals and Discussions of work items in each major category Jun 95 Submit to the SNMPv2 Working Group, if applicable, the complete list of changes to existing standards track SNMPv2 documents Jun 95 Publish an Internet-Draft listing a set of existing MIBs that would require modifications in order to provide support for IPv6. Communicate said information to each affected Working Group chair and/or Area Director Jun 95 Submit an Internet-Draft of a Framework and Overview document, specifying a list of new MIB modules and corresponding organization Sep 95 Submit the revised Framework and Overview document as an Informational RFC Oct 95 Submit a request to re-charter and extend the Working Group WG: RWhois Operational Development (rwhois) ------------------------------------------- Chair(s) Scott Williamson <scottw@thomtech.com> Mark Kosters < markk@internic.net> Operational Requirements Area Director(s) Scott Bradner <sob@harvard.edu> Michael O'Dell <mo@uunet.uu.net> Mail List Information General Discussion: rwhois@internic.net To Subscribe: rwhois-request@internic.net Archive: rs.internic.net: /pub/rwhois/rwhios-archive Description of Working Group The RWhois Operation Development Working Group (rwhois) will be a forum for coordinating the deployment, engineering and operation of the RWhois protocol to replace the current centralized whois model. The minimum attribute set will be defined to ensure that all delegated registries maintain the required information. Required user authentication will be defined to allow remote registration with RWhois servers. Operational procedures will be established to ensure that all delegated servers conform to a set of minimum standards. If necessary the RWhois protocol specification will be updated to reflect changes in requirments identifed during the working group tenure. Goals and Milestones Ongoing Provide forum for the deployment of RWhois in the global Internet. Apr 95 Establish final charter, goals, and long-term group agenda. Jul 95 Submit an Internet-Draft which documents the minimum required data for distributed registration using RWhois. Jul 95 Submit an Internet-Draft which documents guidelines for the registration of delegated RWhois servers. Sep 95 Establish methods of authentication for remote interactive registration and document in an Internet-Draft. Sep 95 Establish an active test bed of RWhois servers between each of the regional registries.
- Agenda for March 23 Telechat Steve Coya