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.